| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Subject: | Re: Somebody has not thought through subscription locking considerations |
| Date: | 2017-03-31 22:52:37 |
| Message-ID: | 11052.1491000757@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2017-03-31 23:00:38 | Re: Somebody has not thought through subscription locking considerations |
| Previous Message | Douglas Doole | 2017-03-31 22:46:57 | Table collision in join.sql and aggregates.sql |