Re: Control flow in logical replication walsender

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: Christophe Pettus <xof(at)thebuild(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Control flow in logical replication walsender
Date: 2024-05-07 12:16:31
Message-ID: CAA4eK1JubeeCqkqp4hJdqF1qDc73hg81ZmVO8w_0xTWZ3g8J9Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 7, 2024 at 9:51 AM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> On Tue, May 7, 2024 at 12:00 AM Christophe Pettus <xof(at)thebuild(dot)com> wrote:
>>
>> Thank you for the reply!
>>
>> > On May 1, 2024, at 02:18, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>> > Is there a large transaction which is failing to be replicated repeatedly - timeouts, crashes on upstream or downstream?
>>
>> AFAIK, no, although I am doing this somewhat by remote control (I don't have direct access to the failing system). This did bring up one other question, though:
>>
>> Are subtransactions written to their own individual reorder buffers (and thus potentially spill files), or are they appended to the topmost transaction's reorder buffer?
>
>
> IIRC, they have their own RB,
>

Right.

>
but once they commit, they are transferred to topmost transaction's RB.
>

I don't think they are transferred to topmost transaction's RB. We
perform a k-way merge between transactions/subtransactions to retrieve
the changes. See comments: "Support for efficiently iterating over a
transaction's and its subtransactions' changes..." in reorderbuffer.c

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2024-05-07 12:27:54 Re: bug: copy progress reporting of backends which run multiple COPYs
Previous Message Amit Kapila 2024-05-07 12:02:26 Re: Control flow in logical replication walsender