Re: [ADMIN] Replication slots and isolation levels - Mailing list pgsql-hackers

From Vladimir Borodin
Subject Re: [ADMIN] Replication slots and isolation levels
Date
Msg-id 95FD0B1A-7BD1-4CCE-86D4-2DF2B2AE2C68@simply.name
Whole thread Raw
In response to Re: [ADMIN] Replication slots and isolation levels  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [ADMIN] Replication slots and isolation levels  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Euler Taveira
Date:
Subject: Re: WIP: Fix parallel workers connection bug in pg_dump (Bug #13727)
Next
From: Tom Lane
Date:
Subject: Re: Dangling Client Backend Process