Re: Support logical replication of DDLs - Mailing list pgsql-hackers

From shveta malik
Subject Re: Support logical replication of DDLs
Date
Msg-id CAJpy0uB06BvEZOWEaYJd7OtEkK9jSMAyYq4YZwqh_=AnxDu=aw@mail.gmail.com
Whole thread Raw
In response to Re: Support logical replication of DDLs  (shveta malik <shveta.malik@gmail.com>)
Responses Re: Support logical replication of DDLs
Re: Support logical replication of DDLs
List pgsql-hackers
On Tue, May 2, 2023 at 8:30 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Fri, Apr 28, 2023 at 5:11 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > Now, I think we can try to eliminate this entire ObjTree machinery and
> > directly from the JSON blob during deparsing. We have previously also
> > discussed this in an email chain at [1]. I think now the functionality
> > of JSONB has also been improved and we should investigate whether it
> > is feasible to directly use JSONB APIs to form the required blob.
>
> +1.
> I will investigate this and will share my findings.
>


Please find the PoC patch for create-table after object-tree removal.
It is based on the patch dated May
2(ddl-replication-2023_05_02.tar.gz). The patches from 0001-0007 are
all the same, the patch '0008' is the new patch for objTree removal.
It is a WIP patch, sharing it for early feedback on the design part.
It covers most of the parts for create-table except a few things (eg:
with-clause, inheritance, owner) which are under implementation.

Regarding testing, some basic tests are done, extensive testing to be
done once we finish the patch. There are some expected diffs in
'test_ddl_deparse_regress' due to lack of complete create-table's
deparsing implementation yet.

The crux of this patch:
Earlier it was: ParseTree->Objtree->Jsonb->ddlMessage
Now it will be: ParseTree->Jsonb->ddlMessage

Some insights on how the object-tree removal is done:

In the current ObjTree implementation, we create a new tree of type
'ObjTree' and add 'ObjElem'(s) to it. ObjTree is basically a linked
list of ObjElem(s), plus some additional information which tells 'fmt'
and whether the concerned clause is 'present' in the given query or
not. Each ObjTree can further have another ObjTree as its child.
ObjElem OTOH has 3 main components:
1) name of element  (indicating clause's name)
2) value of element (indicating clause's value)
3) type of 'value'  (string,bool,array etc)

While conversion from ObjTree to jsonb, ObjTree maps to JsonbValue of
type 'jbvObject' and each of its ObjElem(s) maps to a pair of
'JsonbValue'(s) of required type.  Basically for each ObjElem created,
we create 2 'JsonbValue' structures. One structure is for the name of
'ObjElem' while another structure is for the 'value' of ObjElem,
'type' same as ObjElem's type. So the mapping goes as:

ObjElem  -->  JsonbValue of type jbvString for name of ObjElem +
JsonbValue of required type(same as type of 'value') for 'value' of
ObjElem. These together form a 'JsonbPair'.

ObjTree   --> JsonbValue of type jbvObject having all the JsonbPair(s)
contained in it.  'fmt:string' and 'present:true/false' are 2
key:Value pairs in each jbvObject.

Above means, if we want to remove ObjTree creation, wherever we were
creating ObjTree, we now need to create JsonbValue of type
'jbvObject' and wherever we were creating ObjElem, we now need to
create 2 JsonbValue structures for the 'name' and 'value' respectively
' and add those to the parent JsonbValue(type=jbvObject) structure.

We push all these jsonbValue to JsonbParseState using 'pushJsonbValue'
calls. Later these JsonbValue(s) are converted to Jsonb using '
JsonbValueToJsonb' which is then converted to string using
'JsonbToCString' and logged into WAL.
There is no change in this particular flow.

thanks
Shveta

Attachment

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Next
From: shveta malik
Date:
Subject: Re: Support logical replication of DDLs