Re: Differences in Escaped bytea's when creating a plain pg_dump - Mailing list pgsql-general

From Daniel Verite
Subject Re: Differences in Escaped bytea's when creating a plain pg_dump
Date
Msg-id f15fa1a1-7a06-4124-aa23-5ec5731542a7@manitou-mail.org
Whole thread Raw
In response to Re: Differences in Escaped bytea's when creating a plain pg_dump  (WR <wolle321@freenet.de>)
Responses Re: Differences in Escaped bytea's when creating a plain pg_dump  (Wolfgang Rißler <wolfgang.rissler@freenet.de>)
List pgsql-general
    WR wrote:

> First run worked.
> Second run worked.
> Then I changed to SET standard_conforming_strings = off;
> Third run worked.
> Fourth run throw the error
> Then I changed back to  SET standard_conforming_strings = on;
> Fifth run throw the error too.
> And only adding E and second backslash helped.

This kind of unstable behavior can be seen if the SET may not be
executed by the same session (same connection to the server) as the
subsequent queries.
SET affects only the session it's being run in.

For instance a connection pooler configured in statement mode may
produce that behavior. The solution in the case of a connection pooler
is to group related statements into a transaction.

Maybe pgAdmin has a pooler like that, but if you're issuing the statements
in the same SQL window, I would find it quite surprising that it doesn't
run them by the same session.
Or maybe you're mixing queries from different SQL windows that each
have their own connection, and in some cases you do the SET
in a window and the INSERT in another window.
Or maybe it's a pgAdmin bug.


Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite



pgsql-general by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Table space not returned to the OS ?
Next
From: Laurenz Albe
Date:
Subject: Re: help for pg_wal issue