Re: BUG #19864: pg_get_publication_tables() gets cache lookup error after concurrent DROP PUBLICATION

I found one more issue, which looks like an existing bug. The same
window exists on master with GetPublication(). If the publication is
dropped after get_publication_internal() has succeeded for the last
table of the publication, the remaining lookups for that row
(PUBLICATIONNAMESPACEMAP and PUBLICATIONRELMAP) find no entry, so the
row is built as if there were no column list and no row filter (all
columns and a NULL qual). For earlier tables the next row hits the new
error, but for the last table there is no next row, so the query
succeeds with a wrong result.

Try with this setup:
create table tab1(a int, b int, c int);
create table tab2(a int, b int, c int);
create table tab3(a int, b int, c int);
create publication pub for table tab1(a) where (a > 1), tab2(b) where
(b > 2), tab3(c) where (c > 3);

Run this:
SELECT * FROM pg_get_publication_tables('pub')

When above query is reading last table tab3, drop the publication
immediately in another session post get_publication_internal(). You
will see that the output for 'attrs' and 'qual' is wrong for tab3. It
gives all columns (1 2 3) and a NULL qual instead of col 3 and (c > 3)
qual.

While running this, the cache should be cold (the first query in the
session). With a cold cache, these lookups open the catalogs, which
processes the drop's invalidation. In an already-warm session/cache,
the lookups hit the cache and the result is correct.

I think this bug will impact tablesync in a way that it will end up
syncing tab3 with all columns and all rows and will mark it ready.

Thinking about a potential solution. If the fix is simple enough, we
can address it in sae ethread, else we can raise a new bug,

thanks
Shveta