| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, Radim Marek <radim(at)boringsql(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #19490: Streaming standby on 16.14 stops applying WAL on MultiXactOffsetSLRU when primary is 16.8 |
| Date: | 2026-05-27 00:30:11 |
| Message-ID: | ahY7E7mjjyHkm17J@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Tue, May 26, 2026 at 11:29:58PM +0500, Andrey Borodin wrote:
> On 26 May 2026, at 17:28, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> looks correct
Neither do I see an issue in doing the first steps of
RecordNewMultiXact() without holding the lock. The consistency that
we get across all the stable branches after this patch makes the whole
logic neater.
> I observe:
> Without the change startup deadlocks.
> With the change standby catches up, the DEBUG1 message "next offsets page is not
> initialized, initializing it now" confirms the compat block fires correctly.
Cool, thanks for the patch and double-checking things, Andrey! I did
not check the fix beyond a check-world (aka no cross-version replay
done here), but looking closely through the code I don't immediately
see why this would be wrong across the v14~v16 range.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-05-27 00:49:55 | Re: BUG #19493: Assertion failure in pg_plan_advice with EXISTS subquery and DO_NOT_SCAN advice |
| Previous Message | PG Bug reporting form | 2026-05-26 19:00:01 | BUG #19494: Error on transaction commit inside pipeline triggers psql's Assert |