Problems publishing from vw7.7 to store in postgresql 9

Anthony,

You need to change the below line in your postgresql.conf as follows and
restart the service,

bytea_output = 'escape' # hex, escape

Also, see recent discussion (attached) as to how this could be
transparently addressed in the EXDI driver.

HTH,

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Anthony Lander
Sent: Thursday, June 23, 2011 3:08 PM
To: vwnc List
Subject: [vwnc] Problems publishing from vw7.7 to store in postgresql 9

I just upgraded from postgres 8.2 to 9, and suddenly I can't publish
anymore from vw7.7. I get an MNU bitShift: (stack below). Disturbingly,
it seems to be a problem in the PostgresSQLEXDI layer.

I did a pg_dumpall from postgresql 8.2 and loaded using psql into 9.0.
Anyone have a similar problem? Or alternatively, anyone have this combo
working? If so, I can start looking to my setup...

Thanks,

 -Anthony

Unhandled exception: Message not understood: #bitShift:
Glorp.GlorpDatabaseReadError(Glorp.GlorpError)>>signal
Glorp.VWDatabaseAccessor(Glorp.DatabaseAccessor)>>handleError:for:
optimized [] in Glorp.GlorpCursoredStream>>atEnd
BlockClosure>>cull:
MessageNotUnderstood(GenericException)>>performHandler:
MessageNotUnderstood(GenericException)>>propagatePrivateFrom:
MessageNotUnderstood(GenericException)>>propagateFrom:
MessageNotUnderstood(GenericException)>>propagate
MessageNotUnderstood(GenericException)>>raiseSignal
UndefinedObject(Object)>>doesNotUnderstand:
Base64EncodingReadStream>>addOctet1To:from:
Base64EncodingReadStream>>readNextOctetArray
Base64EncodingReadStream>>nextOctetArray
Base64EncodingReadStream>>makeNextOctetArrayCurrent
Base64EncodingReadStream>>octetArray
Base64EncodingReadStream>>peek
Base64EncodingReadStream>>atEnd
Base64EncodingReadStream>>upToEnd
PostgreSQLEXDISession class>>byteaFrom:for:
optimized [] in PostgreSQLEXDISession
class>>buildTranslationsFromPostgres
PostgreSQLEXDISession>>valueFrom:ofType:
PostgreSQLEXDISession>>getFieldExternal:
PostgreSQLEXDISession(ExternalDatabaseSession)>>nextRowExternal
ExternalDatabaseAnswerStream>>getNextRow
ExternalDatabaseAnswerStream>>atEnd
Glorp.VWDatabaseAccessor(Glorp.DatabaseAccessor)>>isCursorAtEnd:
optimized [] in Glorp.GlorpCursoredStream>>atEnd
BlockClosure>>on:do:
Glorp.GlorpCursoredStream>>atEnd
Glorp.GlorpCursoredStream>>upToEnd
Glorp.SimpleQuery(Glorp.Query)>>resultCollectionFor:
Glorp.SimpleQuery(Glorp.AbstractReadQuery)>>readFromDatabaseWithParamete
rs:
Glorp.SimpleQuery(Glorp.AbstractReadQuery)>>executeWithParameters:in:
Store.Glorp.StorePundleWriter>>instantiateAllOfPackage:requiredFor:
Store.Glorp.StorePundleWriter>>instantiateAllOf:requiredFor:
Store.Glorp.StorePundleWriter>>writePundlePhase1:withChangesBasedOn:
Store.Glorp.StorePundleWriter>>writePundle:withChangesBasedOn:
optimized [] in Store.PublishSpecification>>publishSilentlyUsingSession:
Store.PublishSpecification>>publishSilentlyUsingSession:
Store.PublishSpecification>>publishSilently
Store.PublishSpecification>>publishPundle
optimized [] in Store.PublishPackageDialog>>accept
optimized [] in Store.StoreProgressOverlay class>>subsumeAll:while:
BlockClosure>>ensure:
Store.StoreProgressOverlay class>>subsumeAll:while:
Store.StoreProgressOverlay class>>subsume:while:
Store.PublishPackageDialog>>accept
optimized [] in ApplicationModel>>actionFor:
optimized [] in ActionButtonSpec>>typeConvert:
PluggableAdaptor>>setValue:
PluggableAdaptor(ValueModel)>>value:
TriggerButtonController>>pressAction
TriggerButtonTracker(BasicButtonTracker)>>finishSelectionFor:
TriggerButtonTracker>>finishSelectionFor:
TriggerButtonTracker(SelectionTracker)>>redButtonReleasedEvent:
RedButtonReleasedEvent>>dispatchTo:
TriggerButtonTracker(SelectionTracker)>>handleEvent:
EventDispatcher>>dispatch:to:
EventDispatcher>>dispatchEvent:
RedButtonReleasedEvent(Event)>>dispatch
RedButtonReleasedEvent(Event)>>dispatchForWindowManager:
optimized [] in WindowManager>>safelyDispatchForWindowManager:
BlockClosure>>on:do:
WindowManager>>safelyDispatchForWindowManager:
WindowManager>>processNextEvent
optimized [] in [] in WindowManager>>newProcess
BlockClosure>>on:do:
optimized [] in WindowManager>>newProcess
BlockClosure>>on:do:
optimized [] in Process class>>forBlock:priority:


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

From: "Alan Knight" <[hidden email]>

Date: June 17, 2011 11:01:08 AM EDT

To: "Boris Popov, DeepCove Labs" <[hidden email]>

Cc: "Henrik Sperre Johansen" <[hidden email]>, "VWDEV List" <[hidden email]>

Subject: Re: Fwd: Re: bytea columns in Postgres driver

Reply-To: <[hidden email]>

Ah, ok. That makes sense.



 _____  


Boris <mailto:[hidden email]>  Popov, DeepCove Labs
June 17, 2011 10:56 AM



Alan,



I think what Henrik is suggesting is to modify the driver to recognize the encoding from the result set (by looking for \x at the beginning and using existing bytea when absent). The server recognizes both formats for the input, so you could stick with bytea for backwards-compatibility,



http://www.postgresql.org/docs/9.0/static/datatype-binary.html



-Boris



From: [hidden email] [mailto:[hidden email]] On Behalf Of Alan Knight
Sent: 17 June 2011 10:40
To: Henrik Sperre Johansen
Cc: VWDEV List
Subject: Re: Fwd: Re: bytea columns in Postgres driver



The problem, of course, with that sort of change is that with many repositories they may be accessed by a wide range of clients, from different versions. So needing to modify or update your driver would be unpleasant as, say, a requirement for accessing the public repository.



Henrik Sperre <mailto:[hidden email]>  Johansen
June 17, 2011 9:33 AM




Struck again by the default reply recipient...

-------- Original Message --------


Subject:

Re: bytea columns in Postgres driver


Date:

Fri, 17 Jun 2011 15:04:35 +0200


From:

Henrik Sperre Johansen  <mailto:[hidden email]> <[hidden email]>


To:

Boris Popov, DeepCove Labs  <mailto:[hidden email]> <[hidden email]>



On 17.06.2011 14:36, Boris Popov, DeepCove Labs wrote:

Henrik, there's an option in postgresql.conf to go back to bytea convention in 9.0+ for the time being.

Sent from my iPhone

On 2011-06-17, at 6:03, "Henrik Sperre Johansen" <mailto:[hidden email]> <[hidden email]> wrote:

Hehe, for the time being, I hacked the driver instead and added an extra
conversion step on the way back if a hex-formatted string was returned, seemed faster than
reading more documentation :)

The issue of a non-standard way being used to store bytearrays still
remain though.

Cheers,
Henry

 _____  


Alan Knight <mailto:[hidden email]>
June 17, 2011 10:40 AM


The problem, of course, with that sort of change is that with many repositories they may be accessed by a wide range of clients, from different versions. So needing to modify or update your driver would be unpleasant as, say, a requirement for accessing the public repository.

 _____  


Henrik Sperre Johansen <mailto:[hidden email]>
June 17, 2011 9:33 AM


Struck again by the default reply recipient...

-------- Original Message --------
Subject: Re: bytea columns in Postgres driver
Date: Fri, 17 Jun 2011 15:04:35 +0200
From: Henrik Sperre Johansen  <mailto:[hidden email]> <[hidden email]>
To: Boris Popov, DeepCove Labs  <mailto:[hidden email]> <[hidden email]>


On 17.06.2011 14:36, Boris Popov, DeepCove Labs wrote:

Henrik, there's an option in postgresql.conf to go back to bytea convention in 9.0+ for the time being.

Sent from my iPhone

On 2011-06-17, at 6:03, "Henrik Sperre Johansen" <mailto:[hidden email]> <[hidden email]> wrote:

Hehe, for the time being, I hacked the driver instead and added an extra
conversion step on the way back if a hex-formatted string was returned, seemed faster than
reading more documentation :)

The issue of a non-standard way being used to store bytearrays still
remain though.

Cheers,
Henry