| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Michael Banck <michael(dot)banck(at)credativ(dot)de>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Create replication slot in pg_basebackup if requested and not yet present |
| Date: | 2017-09-12 12:53:44 |
| Message-ID: | 6f0d2862-d33c-9ede-1fd2-fc99fc51a2c5@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 9/11/17 03:11, Michael Banck wrote:
>> Is there a race condition here? The slot is created after the checkpoint
>> is completed. But you have to start streaming from the LSN where the
>> checkpoint started, so shouldn't the slot be created before the checkpoint
>> is started?
>
> So my patch only moves the slot creation slightly further forward,
> AFAICT.
>
> AIUI, wal streaming always begins at last checkpoint and from my tests
> the restart_lsn of the created replication slot is also before that
> checkpoint's lsn. However, I hope somebody more familiar with the
> WAL/replication slot code could comment on that. What I dropped in the
> refactoring is the RESERVE_WAL that used to be there when the temporary
> slot gets created, I have readded that now.
Maybe there is an argument to be made here about whether this is correct
or not, but why bother and risk the fragility? Why not create the
replication slot first thing. I would put it after the server version
checks and before we write recovery.conf.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuro Yamada | 2017-09-12 12:57:32 | Re: CLUSTER command progress monitor |
| Previous Message | Jeevan Chalke | 2017-09-12 12:51:13 | Re: Partition-wise aggregation/grouping |