| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Vladimir Borodin <root(at)simply(dot)name> |
| Cc: | Oleksii Kliukin <alexk(at)hintbits(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-admin <pgsql-admin(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Replication slots and isolation levels |
| Date: | 2015-10-30 13:04:29 |
| Message-ID: | CA+TgmoYn=Myxu9QHBHzwZmQtsHn=GYCix6O+LNyHxQrgP86T8w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-hackers |
On Fri, Oct 30, 2015 at 12:40 PM, Vladimir Borodin <root(at)simply(dot)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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vladimir Borodin | 2015-10-30 13:49:00 | Re: [ADMIN] Replication slots and isolation levels |
| Previous Message | Andres Freund | 2015-10-30 12:59:59 | Re: [ADMIN] Replication slots and isolation levels |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabio Oliveira De Mendonca | 2015-10-30 13:20:30 | Re: ExclusiveLock on PostgreSQL - Fabio Mendonça |
| Previous Message | Robert Haas | 2015-10-30 13:02:34 | Re: September 2015 Commitfest |