Re: [ADMIN] Replication slots and isolation levels

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Vladimir Borodin <root(at)simply(dot)name>
Cc: pgsql-admin <pgsql-admin(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [ADMIN] Replication slots and isolation levels
Date: 2015-10-29 11:03:41
Message-ID: CAB7nPqQZAqvwpJ3eQ0BXGdw26fjNuKXXGHijvdahVXreNbsASA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

On Thu, Oct 29, 2015 at 11:33 AM, Vladimir Borodin wrote:
> 29 окт. 2015 г., в 13:12, Michael Paquier написал(а):
>> In the case of repeatable read the standby will wait before applying
>> the VACUUM WAL record cleaning up a relation page. Hence you won't get
>> conflicts in this case.
>
> Standby will receive but will not apply? Or master will not vacuum needed by
> standby pages? It seems that the second one is happening because replication
> lag on standby does not increase while issuing such repeatable read
> transaction.

Standby will receive the record but not replay it until the
transaction doing REPEATABLE READ transactions that needs those rows
commits on the standby. The WAL flush position on the standby
continues to move on. This depends of course on
max_standby_streaming_delay which may decide or not to force the
transaction to cancel if it takes too long. Someone feel free to
correct me if I am missing something here.
--
Michael

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Ankur Kaushik 2015-10-29 11:24:54 PITR using pg_basebackup ERROR
Previous Message Vladimir Borodin 2015-10-29 10:33:18 Re: [ADMIN] Replication slots and isolation levels

Browse pgsql-hackers by date

  From Date Subject
Next Message Bernd Helmle 2015-10-29 11:30:51 Re: Disabling START TRANSACTION for a SuperUser
Previous Message Marko Tiikkaja 2015-10-29 11:02:07 Re: psql: add \pset true/false