Re: Binary support for pgoutput plugin

From: Dave Cramer <davecramer(at)gmail(dot)com>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Binary support for pgoutput plugin
Date: 2019-10-30 14:03:01
Message-ID: CADK3HHL_cGsoTip9s7ALdUaTbpjxsNH4EuwR=AMMB6dDUt=4dA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 27 Oct 2019 at 11:00, Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote:

> > On Mon, Jun 17, 2019 at 10:29:26AM -0400, Dave Cramer wrote:
> > > Which is what I have done. Thanks
> > >
> > > I've attached both patches for comments.
> > > I still have to add documentation.
> >
> > Additional patch for documentation.
>
> Thank you for the patch! Unfortunately 0002 has some conflicts, could
> you please send a rebased version? In the meantime I have few questions:
>
> -LogicalRepRelId
> +void
> logicalrep_read_insert(StringInfo in, LogicalRepTupleData *newtup)
> {
> char action;
> - LogicalRepRelId relid;
> -
> - /* read the relation id */
> - relid = pq_getmsgint(in, 4);
>
> action = pq_getmsgbyte(in);
> if (action != 'N')
> @@ -175,7 +173,6 @@ logicalrep_read_insert(StringInfo in,
> LogicalRepTupleData *newtup)
>
> logicalrep_read_tuple(in, newtup);
>
> - return relid;
> }
>
> ....
>
> - relid = logicalrep_read_insert(s, &newtup);
> + /* read the relation id */
> + relid = pq_getmsgint(s, 4);
> rel = logicalrep_rel_open(relid, RowExclusiveLock);
> +
> + logicalrep_read_insert(s, &newtup);
>
> Maybe I'm missing something, what is the reason of moving pq_getmsgint
> out of logicalrep_read_*? Just from the patch it seems that the code is
> equivalent.
>
> > There is one obvious hack where in binary mode I reset the input
> > cursor to allow the binary input to be re-read From what I can tell
> > the alternative is to convert the data in logicalrep_read_tuple but
> > that would require moving a lot of the logic currently in worker.c to
> > proto.c. This seems minimally invasive.
>
> Which logic has to be moved for example? Actually it sounds more natural
> to me, if this functionality would be in e.g. logicalrep_read_tuple
> rather than slot_store_data, since it has something to do with reading
> data. And it seems that in pglogical it's also located in
> pglogical_read_tuple.
>

Ok, I've rebased and reverted logicalrep_read_insert

As to the last comment, honestly it's been so long I can't remember why I
put that comment in there.

Thanks for reviewing

Dave

Attachment Content-Type Size
0001-First-pass-at-working-code-without-subscription-opti.patch application/octet-stream 21.3 KB
0003-document-new-binary-option-for-CREATE-SUBSCRIPTION.patch application/octet-stream 2.9 KB
0002-add-binary-column-to-pg_subscription.patch application/octet-stream 8.9 KB
0004-get-relid-inside-of-logical_read_insert.patch application/octet-stream 2.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-10-30 14:09:47 Re: Add SQL function to show total block numbers in the relation
Previous Message Peter Eisentraut 2019-10-30 13:49:38 Remove HAVE_LONG_LONG_INT