Re: Control flow in logical replication walsender - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Control flow in logical replication walsender
Date
Msg-id CAA4eK1JubeeCqkqp4hJdqF1qDc73hg81ZmVO8w_0xTWZ3g8J9Q@mail.gmail.com
Whole thread Raw
In response to Re: Control flow in logical replication walsender  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
List pgsql-hackers
On Tue, May 7, 2024 at 9:51 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Tue, May 7, 2024 at 12:00 AM Christophe Pettus <xof@thebuild.com> wrote:
>>
>> Thank you for the reply!
>>
>> > On May 1, 2024, at 02:18, Ashutosh Bapat <ashutosh.bapat.oss@gmail.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).
Thisdid bring up one other question, though: 
>>
>> Are subtransactions written to their own individual reorder buffers (and thus potentially spill files), or are they
appendedto 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.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Control flow in logical replication walsender
Next
From: Justin Pryzby
Date:
Subject: Re: bug: copy progress reporting of backends which run multiple COPYs