Re: New 9.5.0100 does not work properly

Hi Walter and Heikki,

Probably I found the cause.

On 2016/01/12 17:36, Walter Willmertinger wrote:

The "Write Conflict" is independent of the setting "row versioning". When I strted it was switched off. I switched to "On", but the same result.

Here is an excerpt from mylog:

[7.065]conn=000001F55B153090, query='SELECT "KundenCode","DatumEreignis","AufnahmeDurchPersonalNr","WeiterAnPersonalNr","Status","Notiz","KdID","Prioritaet","ProgErledigt","update_cs","ZuletztBearbeitetPersonalNr" FROM "public"."Notizen" WHERE "KundenCode" = E'1' AND "KdID" = 83'

Doesn't the target table contain boolean items?
Then the driver has to handle parse and describe message before executing the
update query.

[8.455]ParseAndDescribeWithLibpq: plan_name= query=UPDATE "public"."Notizen" SET "Notiz"=$1 WHERE "KundenCode" = $2 AND "KdID" = $3 AND "DatumEreignis" = $4 AND "AufnahmeDurchPersonalNr" = $5 AND "WeiterAnPersonalNr" = $6 AND "Status" = $7 AND "Prioritaet" IS NULL AND "ProgErledigt" = $8 AND "update_cs" = $9 AND "ZuletztBearbeitetPersonalNr" IS NULL
[8.456]conn=000001F55B153090, query='BEGIN'
[8.457]ParseWithLibpq: plan_name= query=UPDATE "public"."Notizen" SET "Notiz"=$1 WHERE "KundenCode" = $2 AND "KdID" = $3 AND "DatumEreignis" = $4 AND "AufnahmeDurchPersonalNr" = $5 AND "WeiterAnPersonalNr" = $6 AND "Status" = $7 AND "Prioritaet" IS NULL AND "ProgErledigt" = $8 AND "update_cs" = $9 AND "ZuletztBearbeitetPersonalNr" IS NULL

But a simple query is issued without using extended protocol because the
*Server side prepare* option is turned off.

[8.460]conn=000001F55B153090, query='UPDATE "public"."Notizen" SET "Notiz"=E'Test xxx' WHERE "KundenCode" = E'1' AND "KdID" = 83 AND "DatumEreignis" = E'2015-09-30 13:48:13'::timestamp AND "AufnahmeDurchPersonalNr" = 80 AND "WeiterAnPersonalNr" = 80 AND "Status" = E'E' AND "Prioritaet" IS NULL AND "ProgErledigt" = E'0' AND "update_cs" = E'2015-09-30 13:48:15'::timestamp AND "ZuletztBearbeitetPersonalNr" IS NULL'

Though this update returns the response 'UPDATE 1', SQLRowCount() doesn't
work as expected due to SC_set_Result() in prepareParameters().

[8.464]conn=000001F55B153090, query='ROLLBACK'

One way to avoid the bug is to turn on the *Server side prepare*
option.
Though an appropriate bug fix is not clear to me, the attached
patch is an example.

regards,
Hiroshi Inoue