Peter Eisentraut <peter.eisentr...@2ndquadrant.com> 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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers