Re: [ADMIN] Replication slots and isolation levels

Поиск
Список
Период
Сортировка
От Vladimir Borodin
Тема Re: [ADMIN] Replication slots and isolation levels
Дата
Msg-id 95FD0B1A-7BD1-4CCE-86D4-2DF2B2AE2C68@simply.name
обсуждение исходный текст
Ответ на Re: [ADMIN] Replication slots and isolation levels  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [ADMIN] Replication slots and isolation levels  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Дерево обсуждения

30 окт. 2015 г., в 16:04, Robert Haas <robertmhaas@gmail.com> написал(а):

On Fri, Oct 30, 2015 at 12:40 PM, Vladimir Borodin <root@simply.name> wrote:
I still don’t fully understand why is it so (the problem occurs while
running only one SELECT-statement in READ COMMITED so only one snapshot is
taken), but if is expected behavior shouldn’t the documentation mention that
using READ COMMITED (which is the default) you may still get conflicts with
recovery while using replication slots?

Are you doing BEGIN / one or more SELECT statements / END?

Or just a bare SELECT with no explicit transaction control?

I’ve tried two ways - bare SELECT in autocommit mode and BEGIN; SELECT; ROLLBACK. I first described the problem in thread on pgsql-admin@ [0], there is copy-paste from psql there, but during conversation initial description was lost.



--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin


--
Да пребудет с вами сила…

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Euler Taveira
Дата:
Сообщение: Re: WIP: Fix parallel workers connection bug in pg_dump (Bug #13727)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Dangling Client Backend Process