Amit Langote writes:
> On 2018/10/01 4:20, Tom Lane wrote:
>> Running the regression tests with the patch I showed in
>> https://www.postgresql.org/message-id/16565.1538327...@sss.pgh.pa.us
> Maybe you've noticed but the relation_open calls coming from bootstrap.c
> all pass NoLock which trigger
On 2018/10/01 4:20, Tom Lane wrote:
> Running the regression tests with the patch I showed in
> https://www.postgresql.org/message-id/16565.1538327...@sss.pgh.pa.us
> exposes two places where HEAD is opening relations without having
> any lock at all on them:
Maybe you've noticed but the relation_
Michael Paquier writes:
> Okay, that's bad. Wouldn't it be sufficient to use what the caller
> passes out as lockmode instead of enforcing AEL though?
No, because at the bottom of that function we're going to do a DROP
CONSTRAINT on the old FK constraint, and that needs AEL anyway.
If we tried t
On Sun, Sep 30, 2018 at 03:20:44PM -0400, Tom Lane wrote:
> 1. ALTER TABLE ... ALTER COLUMN TYPE, on a column that is part of
> a foreign key constraint, opens the rel that has the other end of
> the constraint before it's acquired a lock on said rel.
>
> The comment in ATPostAlterTypeCleanup clai
Running the regression tests with the patch I showed in
https://www.postgresql.org/message-id/16565.1538327...@sss.pgh.pa.us
exposes two places where HEAD is opening relations without having
any lock at all on them:
1. ALTER TABLE ... ALTER COLUMN TYPE, on a column that is part of
a foreign key co
