| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | depesz(at)depesz(dot)com, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-bugs mailing list <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: WAL segments removed from primary despite the fact that logical replication slot needs it. |
| Date: | 2022-11-17 08:02:58 |
| Message-ID: | 20221117080258.6q3gob3pc3zqz2hm@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
On 2022-11-15 23:59:37 +0900, Masahiko Sawada wrote:
> > Is something like the following scenario possible to happen?
> >
> > 1. wal sender updates slot's restart_lsn and releases the spin lock
> > (not saved in the disk yet)
> > 2. someone updates slots' minimum restart_lsn (note that slot's
> > restart_lsn in memory is already updated).
You mean ReplicationSlotsComputeRequiredLSN(), or update that specific slot's
restart_lsn? The latter shouldn't happen.
> > 3. checkpointer removes WAL files older than the minimum restart_lsn
> > calculated at step 2.
For xmin we have protection against that via the split between
catalog_xmin/effective_catalog_xmin. We should probably mirror that for
restart_lsn as well.
We should also call ReplicationSlotsComputeRequiredLSN if only update_restart
is true...
> > 4. wal sender restarts for some reason (or server crashed).
I don't think walsender alone restarting should change anything, but
crash-restart obviously would.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | hubert depesz lubaczewski | 2022-11-17 10:26:57 | Re: WAL segments removed from primary despite the fact that logical replication slot needs it. |
| Previous Message | Andres Freund | 2022-11-17 07:25:12 | Re: WAL segments removed from primary despite the fact that logical replication slot needs it. |