Thread

Commits

  1. Fix off-by-one bug in XactLogCommitRecord

  2. Fix confusion on the padding of GIDs in on commit and abort records.

  3. Store 2PC GID in commit/abort WAL recs for logical decoding

  1. pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding

    Simon Riggs <simon@2ndquadrant.com> — 2018-03-28T16:47:39Z

    Store 2PC GID in commit/abort WAL recs for logical decoding
    
    Store GID of 2PC in commit/abort WAL records when wal_level = logical.
    This allows logical decoding to send the SAME gid to subscribers
    across restarts of logical replication.
    
    Track relica origin replay progress for 2PC.
    
    (Edited from patch 0003 in the logical decoding 2PC series.)
    
    Authors: Nikhil Sontakke, Stas Kelvich
    Reviewed-by: Simon Riggs, Andres Freund
    
    Branch
    ------
    master
    
    Details
    -------
    https://git.postgresql.org/pg/commitdiff/1eb6d6527aae264b3e0b9c95aa70bb7a594ad1cf
    
    Modified Files
    --------------
    src/backend/access/rmgrdesc/xactdesc.c |  39 ++++++++++++
    src/backend/access/transam/twophase.c  | 105 ++++++++++++++++++++++++++++-----
    src/backend/access/transam/xact.c      |  78 ++++++++++++++++++++++--
    src/include/access/twophase.h          |   5 +-
    src/include/access/xact.h              |  27 ++++++++-
    5 files changed, 230 insertions(+), 24 deletions(-)
    
    
  2. Re: pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding

    Heikki Linnakangas <hlinnaka@iki.fi> — 2018-04-09T12:30:39Z

    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
    
  3. Re: pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding

    Michael Paquier <michael@paquier.xyz> — 2018-04-10T07:24:35Z

    On Mon, Apr 09, 2018 at 03:30:39PM +0300, Heikki Linnakangas wrote:
    > 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?
    
    It seems to me that you are right here: those complications are not
    necessary.
    
         if (replorigin)
    +    {
             /* Move LSNs forward for this replication origin */
             replorigin_session_advance(replorigin_session_origin_lsn,
                                        gxact->prepare_end_lsn);
    +    }
    This is better style.
    
    +   /* twophase_gid follows if XINFO_HAS_GID. As a null-terminated string. */
    +   /* xl_xact_origin follows if XINFO_HAS_ORIGIN, stored unaligned! */
    
    Worth mentioning that the first one is also unaligned with your patch?
    And that all the last fields of xl_xact_commit and xl_xact_abort are
    kept as such on purpose?
    --
    Michael
    
  4. Re: pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding

    Heikki Linnakangas <hlinnaka@iki.fi> — 2018-04-17T20:15:08Z

    On 10/04/18 03:24, Michael Paquier wrote:
    > +   /* twophase_gid follows if XINFO_HAS_GID. As a null-terminated string. */
    > +   /* xl_xact_origin follows if XINFO_HAS_ORIGIN, stored unaligned! */
    > 
    > Worth mentioning that the first one is also unaligned with your patch?
    
    Hmm. 'twophase_gid' is actually 4-byte aligned here. But it's a string, 
    so it doesn't matter whether it it is or not.
    
    > And that all the last fields of xl_xact_commit and xl_xact_abort are
    > kept as such on purpose?
    
    I think that's clear without an explicit comment. If it wasn't on 
    purpose, we wouldn't have a comment pointing it out (or we would fix it 
    so that it was aligned).
    
    Pushed, thanks for the review!
    
    - Heikki
    
    
    
  5. Re: pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding

    Nikhil Sontakke <nikhils@2ndquadrant.com> — 2018-06-14T11:02:06Z

    Hi Heikki,
    
    
    >
    > Pushed, thanks for the review!
    >
    
    There was a slight oversight in the twophase_gid length calculation in
    the XactLogCommitRecord() code path in the cf5a1890592 commit. The
    corresponding XactLogAbortRecord() code path was ok. PFA, a small
    patch to fix the oversight.
    
    Regards,
    Nikhils
    -- 
     Nikhil Sontakke                   http://www.2ndQuadrant.com/
     PostgreSQL Development, 24x7 Support, Training & Services
    
  6. Re: pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2018-06-15T19:04:18Z

    On 2018-Jun-14, Nikhil Sontakke wrote:
    
    > There was a slight oversight in the twophase_gid length calculation in
    > the XactLogCommitRecord() code path in the cf5a1890592 commit. The
    > corresponding XactLogAbortRecord() code path was ok. PFA, a small
    > patch to fix the oversight.
    
    Thanks, pushed.
    
    -- 
    Álvaro Herrera                https://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
    
    
  7. Re: pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2018-06-15T19:04:57Z

    On 2018-Jun-14, Nikhil Sontakke wrote:
    
    > There was a slight oversight in the twophase_gid length calculation in
    > the XactLogCommitRecord() code path in the cf5a1890592 commit. The
    > corresponding XactLogAbortRecord() code path was ok. PFA, a small
    > patch to fix the oversight.
    
    Forgot to add: maybe it would be useful to have tests in core where
    these omissions become evident.  Do you have some?
    
    -- 
    Álvaro Herrera                https://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
    
    
  8. Re: pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2018-06-15T19:12:18Z

    By the way, why do we need to strlen() the target buffer when strlcpy
    already reports the length?  (You could argue that there is a difference
    if the string is truncated ... but surely we don't care about that case)
    I propose the attached.
    
    -- 
    Álvaro Herrera                https://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    
  9. Re: pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding

    Nikhil Sontakke <nikhils@2ndquadrant.com> — 2018-06-17T08:34:26Z

    Hi Alvaro,
    
    
    >> There was a slight oversight in the twophase_gid length calculation in
    >> the XactLogCommitRecord() code path in the cf5a1890592 commit. The
    >> corresponding XactLogAbortRecord() code path was ok. PFA, a small
    >> patch to fix the oversight.
    >
    > Forgot to add: maybe it would be useful to have tests in core where
    > these omissions become evident.  Do you have some?
    >
    Thanks for the commit.
    
    I do have some tests. They are part of the "logical decoding of 2PC"
    patch which adds the needed infrastructure to *actually* use this code
    present in the core as of now. I am going to submit it in the upcoming
    commitfest.
    
    Regards,
    Nikhils
    -- 
     Nikhil Sontakke                   http://www.2ndQuadrant.com/
     PostgreSQL Development, 24x7 Support, Training & Services
    
    
    
  10. Re: pgsql: Store 2PC GID in commit/abort WAL recs for logical decoding

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2018-06-20T16:23:42Z

    On 2018-Jun-15, Alvaro Herrera wrote:
    
    > By the way, why do we need to strlen() the target buffer when strlcpy
    > already reports the length?  (You could argue that there is a difference
    > if the string is truncated ... but surely we don't care about that case)
    > I propose the attached.
    
    I decided not to push this after all.  Yes, one strlen is saved, but
    there is some code clarity lost also, and this is certainly not a
    contention point.
    
    -- 
    Álvaro Herrera                https://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services