From: Euler Taveira <euler@eulerto.com>
To: Amit Kapila <amit.kapila16@gmail.com>
To: Noah Misch <noah@leadboat.com>
Cc: Peter Eisentraut <peter@eisentraut.org>
Cc: Shlok Kyal <shlok.kyal.oss@gmail.com>
Cc: kuroda.hayato@fujitsu.com <kuroda.hayato@fujitsu.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Fabrízio de Royes Mello <fabriziomello@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>
Subject: Re: speed up a logical replica setup
Date: Tue, 25 Jun 2024 21:50:59 -0300
Message-ID: <d19dbcce-34c4-43e9-91a4-1ae79d5a4a66@app.fastmail.com> (raw)
In-Reply-To: <CAA4eK1+JeAStsHqyA+UEXjPaej_U2MrscZvMPhHYqB6GkJT-Bw@mail.gmail.com>
References: <2f0b73f3-e7c0-4e95-9712-1993442a6b64@app.fastmail.com>
<CAA4eK1JtnzqYNQ_S+mj_XsPfgk7szxegKiVQq4-8fY1wUcUnpg@mail.gmail.com>
<34637e7f-0330-420d-8f45-1d022962d2fe@app.fastmail.com>
<7a970912-0b77-4942-84f7-2c9ca0bc05a5@eisentraut.org>
<d546c4bb-92d1-4e2d-898f-48234b12ed25@app.fastmail.com>
<CANhcyEWdTTO71v+GFYUTsOOUvHus1qccg88bRmsU9KykJqjSrQ@mail.gmail.com>
<44de4e04-db22-40ed-8ba9-46387dc8bf83@app.fastmail.com>
<3fa9ef0f-b277-4c13-850a-8ccc04de1406@eisentraut.org>
<20240623062157.97.nmisch@google.com>
<CAA4eK1JGyqFXfvXD+Z81WNz=gOSq1_Ze8MqdLE9PMvTWnVpuZA@mail.gmail.com>
<20240624220845.ba.nmisch@google.com>
<CAA4eK1+JeAStsHqyA+UEXjPaej_U2MrscZvMPhHYqB6GkJT-Bw@mail.gmail.com>
On Tue, Jun 25, 2024, at 3:24 AM, Amit Kapila wrote:
> On Tue, Jun 25, 2024 at 3:38 AM Noah Misch <noah@leadboat.com> wrote:
> >
> > On Mon, Jun 24, 2024 at 05:20:21PM +0530, Amit Kapila wrote:
> > > On Sun, Jun 23, 2024 at 11:52 AM Noah Misch <noah@leadboat.com> wrote:
> > > >
> > > > > +static void
> > > > > +create_publication(PGconn *conn, struct LogicalRepInfo *dbinfo)
> > > > > +{
> > > >
> > > > > + appendPQExpBuffer(str, "CREATE PUBLICATION %s FOR ALL TABLES",
> > > > > + ipubname_esc);
> > > >
> > > > This tool's documentation says it "guarantees that no transaction will be
> > > > lost." I tried to determine whether achieving that will require something
> > > > like the fix from
> > > > https://postgr.es/m/flat/de52b282-1166-1180-45a2-8d8917ca74c6@enterprisedb.com.
> > > > (Not exactly the fix from that thread, since that thread has not discussed the
> > > > FOR ALL TABLES version of its race condition.) I don't know. On the one
> > > > hand, pg_createsubscriber benefits from creating a logical slot after creating
> > > > the publication. That snapbuild.c process will wait for running XIDs. On the
> > > > other hand, an INSERT/UPDATE/DELETE acquires its RowExclusiveLock and builds
> > > > its relcache entry before assigning an XID, so perhaps the snapbuild.c process
> >
> > Correction: it doesn't matter how the original INSERT/UPDATE/DELETE builds its
> > relcache entry, just how pgoutput of the change builds the relcache entry from
> > the historic snapshot.
> >
> > > > isn't enough to prevent that thread's race condition. What do you think?
> > >
> > > I am not able to imagine how the race condition discussed in the
> > > thread you quoted can impact this patch. The problem discussed is
> > > mainly the interaction when we are processing the changes in logical
> > > decoding w.r.t concurrent DDL (Alter Publication ... Add Table). The
> > > problem happens because we use the old cache state.
> >
> > Right. Taking the example from
> > http://postgr.es/m/20231119021830.d6t6aaxtrkpn743y@awork3.anarazel.de, LSNs
> > between what that mail calls 4) and 5) are not safely usable as start points.
> > pg_createsubscriber evades that thread's problem if the consistent_lsn it
> > passes to pg_replication_origin_advance() can't be in a bad-start-point LSN
> > span. I cautiously bet the snapbuild.c process achieves that:
> >
> > > I am missing your
> > > point about the race condition mentioned in the thread you quoted with
> > > snapbuild.c. Can you please elaborate a bit more?
> >
> > When pg_createsubscriber calls pg_create_logical_replication_slot(), the key
> > part starts at:
> >
> > /*
> > * If caller needs us to determine the decoding start point, do so now.
> > * This might take a while.
> > */
> > if (find_startpoint)
> > DecodingContextFindStartpoint(ctx);
> >
> > Two factors protect pg_createsubscriber. First, (a) CREATE PUBLICATION
> > committed before pg_create_logical_replication_slot() started. Second, (b)
> > DecodingContextFindStartpoint() waits for running XIDs to complete, via the
> > process described at the snapbuild.c "starting up in several stages" diagram.
> > Hence, the consistent_lsn is not in a bad-start-point LSN span. It's fine
> > even if the original INSERT populated all caches before CREATE PUBLICATION
> > started and managed to assign an XID only after consistent_lsn. From the
> > pgoutput perspective, that's indistinguishable from the transaction starting
> > at its first WAL record, after consistent_lsn. The linked "long-standing data
> > loss bug in initial sync of logical replication" thread doesn't have (a),
> > hence its bug. How close is that to accurate?
> >
>
> Yeah, this theory sounds right to me. The key point is that no DML
> (processing of WAL corresponding to DML) before CREATE PUBLICATION ...
> command would have reached pgoutput level because we would have waited
> for it during snapbuild.c. Can we conclude that the race condition
> discussed in the other thread won't impact this patch?
As Noah said the key point is the CREATE PUBLICATION *before* creating the
replication slots -- that wait transactions to complete.
--
Euler Taveira
EDB https://www.enterprisedb.com/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: euler@eulerto.com, amit.kapila16@gmail.com, noah@leadboat.com, peter@eisentraut.org, shlok.kyal.oss@gmail.com, kuroda.hayato@fujitsu.com, tomas.vondra@enterprisedb.com, pgsql-hackers@lists.postgresql.org, michael@paquier.xyz, andres@anarazel.de, ashutosh.bapat.oss@gmail.com, fabriziomello@gmail.com, vignesh21@gmail.com
Subject: Re: speed up a logical replica setup
In-Reply-To: <d19dbcce-34c4-43e9-91a4-1ae79d5a4a66@app.fastmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox