]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix logical replication's ideas about which type OIDs are built-in.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 13 May 2019 21:23:00 +0000 (17:23 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 13 May 2019 21:23:00 +0000 (17:23 -0400)
commitb6abc2241ac4549623d6894d7855765df6345ad5
tree7b1df97a3af9f55f83ceb8a91f5a7a109f2ee935
parentbf78f50bae0b3b5ffcbf3e3c5b03fd138be15f9a
Fix logical replication's ideas about which type OIDs are built-in.

Only hand-assigned type OIDs should be presumed to match across different
PG servers; those assigned during genbki.pl or during initdb are likely
to change due to addition or removal of unrelated objects.

This means that the cutoff should be FirstGenbkiObjectId (in HEAD)
or FirstBootstrapObjectId (before that), not FirstNormalObjectId.
Compare postgres_fdw's is_builtin() test.

It's likely that this error has no observable consequence in a
normally-functioning system, since ATM the only affected type OIDs are
system catalog rowtypes and information_schema types, which would not
typically be interesting for logical replication.  But you could
probably break it if you tried hard, so back-patch.

Discussion: https://postgr.es/m/15150.1557257111@sss.pgh.pa.us
src/backend/replication/logical/relation.c
src/backend/replication/pgoutput/pgoutput.c