| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)ru> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, andres(at)anarazel(dot)de, dim(at)tapoueh(dot)org, pgsql-hackers(at)postgresql(dot)org, simon(at)2ndquadrant(dot)com |
| Subject: | Re: Physical replication slot advance is not persistent |
| Date: | 2020-06-16 07:27:27 |
| Message-ID: | 20200616072727.GA2361@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 10, 2020 at 08:57:17PM +0300, Alexey Kondratov wrote:
> New test reproduces this issue well. Left it running for a couple of hours
> in repeat and it seems to be stable.
Thanks for testing. I have been thinking about the minimum xmin and
LSN computations on advancing, and actually I have switched the
recomputing to be called at the end of pg_replication_slot_advance().
This may be a waste if no advancing is done, but it could also be an
advantage to enforce a recalculation of the thresholds for each
function call. And that's more consistent with the slot copy, drop
and creation.
> we can safely use $current_lsn used for pg_replication_slot_advance(), since
> reatart_lsn is set as is there. It may make the test a bit simpler as well.
We could do that. Now I found cleaner the direct comparison of
pg_replication_slots.restart before and after the restart. So I have
kept it.
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| slot-advance-compute-v2.patch | text/x-diff | 2.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2020-06-16 07:28:14 | Re: BufFileRead() error signalling |
| Previous Message | Magnus Hagander | 2020-06-16 07:26:34 | Re: language cleanups in code and docs |