Re: Somebody has not thought through subscription locking considerations
От | Tom Lane |
---|---|
Тема | Re: Somebody has not thought through subscription locking considerations |
Дата | |
Msg-id | 11052.1491000757@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Somebody has not thought through subscription lockingconsiderations (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Ответы |
Re: Somebody has not thought through subscription lockingconsiderations
|
Список | pgsql-hackers |
Petr Jelinek <petr.jelinek@2ndquadrant.com> writes: > On 31/03/17 21:00, Tom Lane wrote: >> Looking at dependency info isn't going to fix this, it only moves the >> unsafe catalog access somewhere else (ie pg_depend instead of >> pg_subscription_rel). I suspect the only safe solution is doing an >> IsCatalogRelation or similar test pretty early in the logical replication >> code paths. > I don't follow, everything else does dependency info check in this > situation, how is this any different? What do you mean by "everything else"? The key point here is that access to the bootstrap catalogs like pg_class and pg_attribute can't be dependent on accesses to other catalogs, or we get into circularities. We certainly aren't trying to look in pg_depend when we do a heap_open. (Or, if you tell me that we are now because the logical replication patch added it, I'm going to start agitating for reverting the patch and sending it back for redesign.) regards, tom lane
В списке pgsql-hackers по дате отправления: