Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" inchild table must be marked NOT NULL - Mailing list pgsql-hackers

From Ali Akbar
Subject Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" inchild table must be marked NOT NULL
Date
Msg-id CACQjQLrN88BrpUAFv-soW+bCnDEkkWGc+z6cmSEMfGMpd+Aa=g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" inchild table must be marked NOT NULL  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" inchild table must be marked NOT NULL
List pgsql-hackers

2017-12-13 9:10 GMT+07:00 Michael Paquier <michael.paquier@gmail.com>:

It is not the first time that this topic shows up. See for example
this thread from myself's version of last year:
https://www.postgresql.org/message-id/CAB7nPqTPXgX9HiyhhtAgpW7jbA1iskMCSoqXPEEB_KYXYy1E1Q@mail.gmail.com
Or this one:
http://www.postgresql.org/message-id/21633.1448383428@sss.pgh.pa.us

And the conclusion is that we don't want to do what you are doing
here, and that it would be better to store NOT NULL constraints in a
way similar to CHECK constraints.

Thanks for the link to those thread.

Judging from the discussion there, it will be a long way to prevent DROP NOT NULL. So for this problem (pg_upgrade failing because of it), i propose that we only add a check in pg_upgrade, so anyone using pg_upgrade can know and fix the issue before the error?

If it's OK, i can write the patch.
 
> How about: ".. if some parent has the same"
>
> +               heap_close(parent, AccessShareLock);
>
> Maybe, we shouldn't be dropping the lock so soon.

Yes, such things usually need to be kept until the end of the
transaction, and usually you need to be careful about potential lock
upgrades that could cause deadlocks. This patch looks wrong for both
of those things.

Thanks. Judging from above, it's better that we continue the DROP NOT NULL problem in another patch (and another thread)
 
Best Regards,
Ali Akbar

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Top-N sorts verses parallelism
Next
From: Craig Ringer
Date:
Subject: Re: Using ProcSignal to get memory context stats from a running backend