| From: | Oleksii Kliukin <alexk(at)hintbits(dot)com> |
|---|---|
| To: | Vladimir Borodin <root(at)simply(dot)name> |
| Cc: | 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: [ADMIN] Replication slots and isolation levels |
| Date: | 2015-10-29 14:29:43 |
| Message-ID: | B0D38B8D-C174-44EE-9F84-31B8EE68AA8C@hintbits.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-hackers |
> On 29 Oct 2015, at 14:39, Vladimir Borodin <root(at)simply(dot)name> wrote:
>
> f I understand right, with hot_standby_feedback = on standby tells the master xmin of the earliest transaction on standby. And autovacuum worker on master takes it into account when doing vacuum cleanup (because it can see it from pg_replications_slots view), AFAIK with GetOldestXmin function. But I don’t understand why with READ COMMITED transactions xmin in pg_replication_slots view on master continues to increase while with REPEATABLE READ xmin freezes until this transaction finishes.
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.
http://www.postgresql.org/docs/current/static/transaction-iso.html
Kind regards,
--
Oleksii
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jerry Sievers | 2015-10-29 18:28:02 | Re: PITR using pg_basebackup ERROR |
| Previous Message | Vladimir Borodin | 2015-10-29 13:39:22 | Re: [ADMIN] Replication slots and isolation levels |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-10-29 14:51:20 | Re: pg_dump |
| Previous Message | Syed, Rahila | 2015-10-29 14:22:56 | Re: [PROPOSAL] VACUUM Progress Checker. |