Re: Subscription test 013_partition.pl fails under CLOBBER_CACHE_ALWAYS

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Subscription test 013_partition.pl fails under CLOBBER_CACHE_ALWAYS
Дата
Msg-id 1353598.1600199178@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Subscription test 013_partition.pl fails under CLOBBER_CACHE_ALWAYS  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Subscription test 013_partition.pl fails under CLOBBER_CACHE_ALWAYS  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Subscription test 013_partition.pl fails under CLOBBER_CACHE_ALWAYS  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
I wrote:
> [ $subject ]

I found some time to trace this down, and what it turns out to be is
that apply_handle_truncate() is making use of a LogicalRepRelMapEntry's
localreloid field without any consideration for the possibility that
that's been set to zero as a result of a cache flush.  The visible
symptom of "cache lookup failed for relation 0" comes from trying
to invoke find_all_inheritors with a zero OID.

Now, study of apply_handle_truncate doesn't immediately reveal where
a cache flush could have occurred, but I realized that it's actually
possible that the LogicalRepRelMapEntry is *already* marked invalid
when logicalrep_rel_open() returns!  That's because for some reason
it does GetSubscriptionRelState last, after it's already marked the
entry valid, and that function does plenty o' catalog accesses.

It's not really clear to me why setting localreloid to zero is a sane
way to represent "this entry needs to be revalidated".  I think a
separate flag would be more appropriate.  Once we have lock on the
target relation, it seems to me that no interesting changes should
be possible as long as we have lock; so there's no very good reason
to destroy useful state to remind ourselves that we should recheck
it next time.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: recovering from "found xmin ... from before relfrozenxid ..."
Следующее
От: Tom Lane
Дата:
Сообщение: Re: recovering from "found xmin ... from before relfrozenxid ..."