Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Date
Msg-id CAFiTN-sKDPk+B38UAw7O27GmfuECVT65nMZFco9MgeMj=0Vs0w@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions  (Michael Paquier <michael@paquier.xyz>)
Responses Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions  (Dilip Kumar <dilipbalaut@gmail.com>)
Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions  (Amit Kapila <amit.kapila16@gmail.com>)
Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions  (Robert Haas <robertmhaas@gmail.com>)
Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
On Sun, Dec 1, 2019 at 7:58 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Nov 22, 2019 at 01:18:11PM +0530, Dilip Kumar wrote:
> > I have rebased the patch on the latest head and also fix the issue of
> > "concurrent abort handling of the (sub)transaction." and attached as
> > (v1-0013-Extend-handling-of-concurrent-aborts-for-streamin) along with
> > the complete patch set.  I have added the version number so that we
> > can track the changes.
>
> The patch has rotten a bit and does not apply anymore.  Could you
> please send a rebased version?  I have moved it to next CF, waiting on
> author.

I have rebased the patch set on the latest head.

Apart from this, there is one issue reported by my colleague Vignesh.
The issue is that if we use more than two relations in a transaction
then there is an error on standby (no relation map entry for remote
relation ID 16390).  After analyzing I have found that for the
streaming transaction an "is_schema_sent" flag is kept in
ReorderBufferTXN.  And, I think that is done so that we can send the
schema for each transaction stream so that if any subtransaction gets
aborted we don't lose the logical WAL for that schema.  But, this
solution has induced a very basic issue that if a transaction operate
on more than 1 relation then after sending the schema for the first
relation it will mark the flag true and the schema for the subsequent
relations will never be sent.  I am still working on finding a better
solution for this if anyone has any opinion/solution about this feel
free to suggest.

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

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace onthe fly
Next
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Block level parallel vacuum