Peter Eisentraut <> writes:
> On 6/8/17 23:53, Tom Lane wrote:
>> ! ERROR:  publication "addr_pub" does not exist

> The \d+ command attempts to print out any publications that the relation
> is part of.  To find the publications it is part of, it runs this query:

>     "SELECT pub.pubname\n"
>     " FROM pg_catalog.pg_publication pub,\n"
>     "      pg_catalog.pg_get_publication_tables(pub.pubname)\n"
>     "WHERE relid = '%s'\n"
>     "ORDER BY 1;",

> pg_get_publication_tables() calls GetPublicationByName(), which throws
> this error.

> So I suppose that if a publication is dropped between the time
> pg_publication is read and the function is called, you could get this error.

Yeah, I'd suspected as much but not tracked it down yet.

> How could we improve that?

What we've done in many comparable situations is to allow a
catalog-probing function to return NULL instead of failing
when handed an OID or other identifier that it can't locate.
Here it seems like pg_get_publication_tables() needs to use
missing_ok = TRUE and then return zero rows for a null result.
Arguably, a nonexistent publication publishes no tables, so
it's not clear that's not the Right Thing anyway.

BTW, isn't the above command a hugely inefficient way of finding
the publications for the target rel?  Unless you've got a rather
small number of rather restricted publications, seems like it's
going to take a long time.  Maybe we don't care too much about
manual invocations of \d+, but I bet somebody will carp if there's
not a better way to find this out.  Maybe a better answer is to
define a more suitable function pg_publications_for_table(relid)
and let it have the no-error-for-bad-OID behavior.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to