Re: Differences in Escaped bytea's when creating a plain pg_dump

Поиск
Список
Период
Сортировка
От Daniel Verite
Тема Re: Differences in Escaped bytea's when creating a plain pg_dump
Дата
Msg-id f15fa1a1-7a06-4124-aa23-5ec5731542a7@manitou-mail.org
обсуждение исходный текст
Ответ на Re: Differences in Escaped bytea's when creating a plain pg_dump  (WR <wolle321@freenet.de>)
Ответы Re: Differences in Escaped bytea's when creating a plain pg_dump  (Wolfgang Rißler <wolfgang.rissler@freenet.de>)
Список 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 по дате отправления:

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Re: Table space not returned to the OS ?
Следующее
От: Laurenz Albe
Дата:
Сообщение: Re: help for pg_wal issue