From: | "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, fabriziomello(at)gmail(dot)com, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, Rahila Syed <rahila(dot)syed(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Minimal logical decoding on standbys |
Date: | 2022-12-22 07:50:34 |
Message-ID: | a78de011-81cf-729c-e110-e6d636fdca4d@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 12/21/22 10:06 AM, Drouvot, Bertrand wrote:
> Hi,
>
> On 12/20/22 10:41 PM, Robert Haas wrote:
>> On Tue, Dec 20, 2022 at 3:39 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I guess whatever else we
>> do here, we should fix the comments.
>>
>
> Agree, please find attached a patch proposal doing so.
>
>
>> Bottom line is that I think the two cases that have alignment issues
>> as coded are xl_hash_vacuum_one_page and gistxlogDelete. Everything
>> else is OK, as far as I can tell right now.
>>
>
> Thanks a lot for the repro(s) and explanations! That's very useful/helpful.
>
> Based on your discovery about the wrong comments above, I'm now tempted to fix those 2 alignment issues
> by using a FLEXIBLE_ARRAY_MEMBER within those structs (as you proposed in [1]) (as that should also prevent
> any possible wrong comments about where the array is located).
>
> What do you think?
As mentioned above, It looks to me that making use of a FLEXIBLE_ARRAY_MEMBER is a good choice.
So, please find attached v35 making use of a FLEXIBLE_ARRAY_MEMBER in xl_hash_vacuum_one_page and gistxlogDelete (your 2 repros are not failing anymore).
I've also added a few words in the commit message in 0001 about it.
So, we end up with:
(gdb) ptype /o struct xl_hash_vacuum_one_page
/* offset | size */ type = struct xl_hash_vacuum_one_page {
/* 0 | 4 */ TransactionId snapshotConflictHorizon;
/* 4 | 4 */ int ntuples;
/* 8 | 1 */ _Bool isCatalogRel;
/* XXX 1-byte hole */
/* 10 | 0 */ OffsetNumber offsets[];
/* XXX 2-byte padding */
/* total size (bytes): 12 */
}
(gdb) ptype /o struct gistxlogDelete
/* offset | size */ type = struct gistxlogDelete {
/* 0 | 4 */ TransactionId snapshotConflictHorizon;
/* 4 | 2 */ uint16 ntodelete;
/* 6 | 1 */ _Bool isCatalogRel;
/* XXX 1-byte hole */
/* 8 | 0 */ OffsetNumber offsets[];
/* total size (bytes): 8 */
}
While looking at it, I've a question: xl_hash_vacuum_one_page.ntuples is an int, do you see any reason why it is not an uint16? (we would get rid of 4 bytes in the struct).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Attachment | Content-Type | Size |
---|---|---|
v35-0006-Fixing-Walsender-corner-case-with-logical-decodi.patch | text/plain | 7.5 KB |
v35-0005-Doc-changes-describing-details-about-logical-dec.patch | text/plain | 2.1 KB |
v35-0004-New-TAP-test-for-logical-decoding-on-standby.patch | text/plain | 20.4 KB |
v35-0003-Allow-logical-decoding-on-standby.patch | text/plain | 11.5 KB |
v35-0002-Handle-logical-slot-conflicts-on-standby.patch | text/plain | 27.7 KB |
v35-0001-Add-info-in-WAL-records-in-preparation-for-logic.patch | text/plain | 33.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-12-22 07:56:11 | Re: appendBinaryStringInfo stuff |
Previous Message | David Rowley | 2022-12-22 07:48:39 | Re: appendBinaryStringInfo stuff |