From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding |
Date: | 2018-04-09 12:30:39 |
Message-ID: | 33b787bf-dc20-1161-54e9-3f3b607bf59d@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On 28/03/18 19:47, Simon Riggs wrote:
> Store 2PC GID in commit/abort WAL recs for logical decoding
This forgot to update the comments in xl_xact_commit and xl_xact_abort,
for the new fields.
> +
> + if (parsed->xinfo & XACT_XINFO_HAS_GID)
> + {
> + int gidlen;
> + strcpy(parsed->twophase_gid, data);
> + gidlen = strlen(parsed->twophase_gid) + 1;
> + data += MAXALIGN(gidlen);
> + }
> + }
> +
> + if (parsed->xinfo & XACT_XINFO_HAS_ORIGIN)
> + {
> + xl_xact_origin xl_origin;
> +
> + /* we're only guaranteed 4 byte alignment, so copy onto stack */
> + memcpy(&xl_origin, data, sizeof(xl_origin));
> +
> + parsed->origin_lsn = xl_origin.origin_lsn;
> + parsed->origin_timestamp = xl_origin.origin_timestamp;
> +
> + data += sizeof(xl_xact_origin);
> }
There seems to be some confusion on the padding here. Firstly, what's
the point of zero-padding the GID length to the next MAXALIGN boundary,
which would be 8 bytes on 64-bit systems, if the start is only
guaranteed 4-byte alignment, per the comment at the memcpy() above.
Secondly, if we're memcpying the fields that follow anyway, why bother
with any alignment padding at all?
I propose the attached.
- Heikki
Attachment | Content-Type | Size |
---|---|---|
gid-in-wal-records-cleanup.patch | text/x-patch | 6.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-04-09 13:59:03 | pgsql: Add missed bms_copy() in perform_pruning_combine_step |
Previous Message | Heikki Linnakangas | 2018-04-09 11:22:19 | pgsql: Fix typo in comment. |
From | Date | Subject | |
---|---|---|---|
Next Message | Anthony Iliopoulos | 2018-04-09 12:31:27 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
Previous Message | Peter Eisentraut | 2018-04-09 12:28:02 | Re: Boolean partitions syntax |