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 A408EACD-71C8-4699-A0E7-92ADD00F3817@simply.name
Whole thread Raw
In response to Re: [ADMIN] Replication slots and isolation levels  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers

2 нояб. 2015 г., в 23:37, Robert Haas <robertmhaas@gmail.com> написал(а):

On Fri, Oct 30, 2015 at 9:49 AM, Vladimir Borodin <root@simply.name> wrote:
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.

[0]
http://www.postgresql.org/message-id/7F74C5EA-6741-44FC-B6C6-E96F18D761FB@simply.name

Hmm.  That behavior seems unexpected to me, but I might be missing something.

Me too. That’s why I started the thread. One small detail that might have a value is that the big table being queried is partitioned into 64 inhereted tables. Now I’m trying to write a simple script to reproduce the problem, but that is not so easy because AFAIK VACUUM on master should happen while single query on standby is running and it should vacuum those rows that have not been accessed by the query on standby yet.


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


--
May the force be with you…

pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: WIP: Rework access method interface
Next
From: Bruce Momjian
Date:
Subject: Re: Patent warning about the Greenplum source code