Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Erik Rijkers <er(at)xs4all(dot)nl>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Date: 2020-05-27 14:52:23
Message-ID: CAFiTN-t+nKqv+oTE37NWYaZHiJGzogoWcsW1_qMcXeV5u3ErmA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 26, 2020 at 7:45 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Mon, May 25, 2020 at 8:48 PM Erik Rijkers <er(at)xs4all(dot)nl> wrote:
> >
>
> > Hi,
> >
> > I am not able to extract all files correctly from this tar.
> >
> > The first file v24-0001-* seems to have some 'binary' junk at the top.
> >
> > (The other 11 files seem normally readably)
>
> Okay, sending again.

While reviewing/testing I have found a couple of problems in 0005 and
0006 which I have fixed in the attached version.

In 0005: Basically, in the latest version, we are starting a stream
or begin txn only if there are any changes because we are doing in the
while loop, so we need to stream_stop/commit also if we have started
the stream.

In 0006: If we are streaming the serialized changed and there are
still few incomplete changes, then currently we are not deleting the
spilled file, but the spill file contains all the changes of the
transaction because there is no way to partially truncate it. So in
the next stream, it will try to resend those. I have fixed this by
sending the spilled transaction as soon as its changes are complete so
ideally, we can always delete the spilled file. It is also a better
solution because this transaction is already spilled once and that
happened because we could not stream it, so we better stream it on
the first opportunity that will reduce the replay lag which is our
whole purpose here.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Attachment Content-Type Size
v25.tar application/x-tar 280.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Moench-Tegeder 2020-05-27 15:32:45 Re: New 'pg' consolidated metacommand patch
Previous Message Jesse Zhang 2020-05-27 14:49:45 Re: Fix compilation failure against LLVM 11