Re: Binary support for pgoutput plugin

On Tue, 14 Jul 2020 at 22:47, Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2020-07-14 22:28:48 -0400, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> > > What is the gain in having these checks? recv functions need to be safe
> > > against arbitrary input, so a type crosscheck doesn't buy additional
> > > safety in that regard. Not that a potential attacker couldn't just
> > > change the content anyways?
> >
> > You're confusing security issues with user-friendliness issues.
> > Detecting that you sent the wrong type via an OID mismatch error
> > is a lot less painful than trying to figure out why you've got
> > errors along the line of "incorrect binary data format".
>
> An oid mismatch error without knowing what that's about isn't very
> helpful either.
>
> How about adding an errcontext that shows the "source type oid", the
> target type oid & type name and, for records, the column name of the
> target table? That'd make this a lot easier to debug.
>

So looking at how to confirm that the subscriber has receive functions for
all of the types.

AFAICT we don't have that information since the publication determines what
is sent?

This code line 482 in proto.c attempts to limit what is sent in binary. We
could certainly be more restrictive here.

*if* (binary &&

OidIsValid(typclass->typreceive) &&

(att->atttypid < FirstNormalObjectId || typclass->typtype != 'c') &&

(att->atttypid < FirstNormalObjectId || typclass->typelem == InvalidOid))

Dave Cramer