pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Vladimir Borodin <root@simply.name>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Oleksii Kliukin <alexk@hintbits.com>
Cc: pgsql-admin <pgsql-admin@postgresql.org>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [ADMIN] Replication slots and isolation levels
Date: Fri, 30 Oct 2015 13:59:59 +0100
Message-ID: <20151030125959.GA6677@alap3.anarazel.de> (raw)
In-Reply-To: <CAB7nPqT1kGYHUomtJivC95EDsL6OQWcy2+76DnG5Y2Cj1DdYTg@mail.gmail.com>
References: <CAB7nPqTW_v4odZrRX7vYtf5OWVBwzK=oDffwikgrOunQFsa8JA@mail.gmail.com>
	<52570F37-5C6E-40F9-A2E3-01858705B3E8@simply.name>
	<CAB7nPqQZAqvwpJ3eQ0BXGdw26fjNuKXXGHijvdahVXreNbsASA@mail.gmail.com>
	<0E6700E4-195C-450D-A051-D19F92B2A9D7@simply.name>
	<CAB7nPqTSVXR1WQegikpnkATjR3oz8FQE3hUf9RUk+o9VN0+zrQ@mail.gmail.com>
	<86D2C6D2-C332-4BF9-A82E-C9F7FA471712@simply.name>
	<B0D38B8D-C174-44EE-9F84-31B8EE68AA8C@hintbits.com>
	<CA+TgmoZzi8-72PksOf8NDBz8nGU97NH_VUgNybxyB_5U_tBBCg@mail.gmail.com>
	<088B276D-4073-4582-82D4-08F50E43B426@simply.name>
	<CAB7nPqT1kGYHUomtJivC95EDsL6OQWcy2+76DnG5Y2Cj1DdYTg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

On 2015-10-30 13:42:19 +0100, Michael Paquier wrote:
> On Fri, Oct 30, 2015 at 12:40 PM, Vladimir Borodin wrote:
> > On Thu, Oct 29, 2015 at 3:29 PM, Oleksii Kliukin wrote:
> >> Could it be a consequence of how REPEATABLE READ transactions handle
> >> snapshots? With REPEATABLE READ the snapshot is acquired only once at the
> >> beginning of a transaction; a READ COMMITTED transaction re-evaluates its
> >> snapshot with each new command.
> >
> > 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 COMMITTED (which is the default) you may still get conflicts with
> > recovery while using replication slots?
> 
> Replication slots and hot_standby_feedback are two different unrelated
> concepts, slots being aimed at retaining WAL.

Uh. Slots also retain the xmin horizon if hot_standby_feedback is
enabled on the standby?

> I guess that's the origin of your confusion:
> http://www.postgresql.org/message-id/20150616192141.GD2626@alap3.anarazel.de

That just says what I said above, I don't see how this makes replication
slots and hs feedback unrelated?

Greetings,

Andres Freund


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



view thread (19+ messages)  latest in thread

Message-ID: <20151030125959.GA6677@alap3.anarazel.de>
Permalink:  ../20151030125959.GA6677@alap3.anarazel.de/
Also on:    postgresql.org/message-id/20151030125959.GA6677@alap3.anarazel.de

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: andres@anarazel.de, michael.paquier@gmail.com, root@simply.name, robertmhaas@gmail.com, alexk@hintbits.com, pgsql-hackers@postgresql.org
  Subject: Re: [ADMIN] Replication slots and isolation levels
  In-Reply-To: <20151030125959.GA6677@alap3.anarazel.de>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox