Re: Somebody has not thought through subscription lockingconsiderations
От | Petr Jelinek |
---|---|
Тема | Re: Somebody has not thought through subscription lockingconsiderations |
Дата | |
Msg-id | dde48621-7e1b-10fc-b162-5efc1922cfd3@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Somebody has not thought through subscription lockingconsiderations (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Ответы |
Re: Somebody has not thought through subscription locking considerations
|
Список | pgsql-hackers |
On 31/03/17 20:23, Tom Lane wrote: > Petr Jelinek <petr.jelinek@2ndquadrant.com> writes: >> On 31/03/17 19:35, Tom Lane wrote: >>> At the very least, it would be a good idea to exclude the system >>> catalogs from logical replication, wouldn't it? > >> They are excluded. > > Well, the exclusion is apparently not checked early enough. I would say > that touches of system catalogs should never result in any attempts to > access the logical relation infrastructure, but what we have here is > such an access. > >> The problematic part is that the pg_subscription_rel manipulation >> functions acquire ShareRowExclusiveLock and not the usual >> RowExclusiveLock because there were some worries about concurrency. > > No, the problematic part is that there is any heap_open happening at > all. That open could very easily result in a recursive attempt to read > pg_class, for example, which is going to be fatal if we're in the midst > of vacuum full'ing or reindex'ing pg_class. It's frankly astonishing > to me that this patch seems to have survived testing under > CLOBBER_CACHE_ALWAYS, because it's only the catalog caches that are > preventing such recursive lookups. > Hmm okay, so the solution is to either use standard dependency info for this so that it's only called for tables that are actually know to be subscribed or have some exceptions in the current code to call the function only for user catalogs. Any preferences? -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: