| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| 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>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: WAL segments removed from primary despite the fact that logical replication slot needs it. |
| Date: | 2023-02-06 15:22:09 |
| Message-ID: | 20230206152209.yglmntznhcmaueyn@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 2023-Feb-06, Masahiko Sawada wrote:
> I've also confirmed that this issue is fixed by the attached patch,
> which clears candidate_restart_lsn and friends during
> ReplicationSlotRelease().
Hmm, interesting -- I was studying some other bug recently involving the
xmin of a slot that had been invalidated and I remember wondering if
these "candidate" fields were being properly ignored when the slot is
marked not in use; but I didn't check. Are you sure that resetting them
when the slot is released is the appropriate thing to do? I mean,
shouldn't they be kept set while the slot is in use, and only reset if
we destroy it?
(But, actually, in that case, maybe we don't need to reset them: instead
we need to make sure to ignore the values for slots that are not in_use.
However, I don't know what the semantics are for these "candidate"
fields, so maybe this is wrong.)
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-02-06 15:34:24 | Re: exceptional result of postres_fdw external table joining local table |
| Previous Message | Tom Lane | 2023-02-06 15:19:43 | Re: BUG #17767: psql: tab-completion causes warnings when standard_conforming_strings = off |