Re: BUG #17928: Standby fails to decode WAL on termination of primary

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17928: Standby fails to decode WAL on termination of primary
Date: 2023-08-18 04:55:32
Message-ID: ZN75xA4v14ImLvhy@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Aug 18, 2023 at 02:30:31PM +1200, Thomas Munro wrote:
> Give me a couple of days and I'll look into how back-patchable the
> tests can be made, and see what else we can test. Perhaps it's not
> strictly necessary to back-patch the fix further than 15, but I think
> we should definitely consider it, and I don't like the idea of not
> having the tests accompanying the change.

Okay, cool.

> If you have any ideas about how to write a more efficient version of
> advance_to_record_splitting_zone() (or I guess that should really be
> advance_to_record_header_splitting_zone()), and generally how to make
> the perl better,

Yeah, I think that there are ways to reduce the number of records
generated.

> and how to get those constants we need from the
> source or binaries, then I'm all ears.

A new perl routine able to do a pg_control --includedir that scans a
defined header with a regexp would be able to make the job for the
constants. If you're interested, I can code that up.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Emile Amewoto 2023-08-18 05:36:23 Postgresql15 crash with :FATAL: could not open shared memory segment "/PostgreSQL.0000000": No such file or directory
Previous Message Zhijie Hou (Fujitsu) 2023-08-18 04:21:53 RE: BUG #18055: logical decoding core on AllocateSnapshotBuilder()