Re: Missing FIN_CRC32 calls in logical replication code - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Missing FIN_CRC32 calls in logical replication code
Date
Msg-id 20141113224113.GM13473@awork2.anarazel.de
Whole thread Raw
In response to Re: Missing FIN_CRC32 calls in logical replication code  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On 2014-11-14 00:04:52 +0200, Heikki Linnakangas wrote:
> On 11/11/2014 06:55 PM, Andres Freund wrote:
> >On 2014-11-03 21:58:51 +0200, Heikki Linnakangas wrote:
> >>PS. I find the name "ReplicationSlotOnDiskDynamicSize" confusing, as it is
> >>in fact a fixed size struct. I gather it's expected that the size of that
> >>part might change across versions, but by that definition nothing is
> >>constant.
> >
> >Well, the idea is that the 'constant' part is version independent. The
> >part following afterwards (dynamic) can differ based on the 'version'
> >struct member. The reason is that that allows files from older releases
> >to be read after a pg_upgrade.
> >
> >If you have suggestions for better names.
> 
> (It's a bit late, I know, but...)
> 
> I would actually suggest using the 'magic' field as the version identifier.
> Increment it by one on every version change. It would be handy to have the
> version ID as the first field in the file.

What's the advantage of that over having a distinct magic field first,
and a version field second? That's how it currently is.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Segmentation fault in pg_dumpall from master down to 9.1 and other bug introduced by RLS
Next
From: Stephen Frost
Date:
Subject: Re: Segmentation fault in pg_dumpall from master down to 9.1 and other bug introduced by RLS