Horton

Re: not null constraints, again

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: jian he <jian.universality@gmail.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>, Tender Wang <tndrwang@gmail.com>
Date: 2025-04-14T21:33:03Z
Lists: pgsql-hackers 
On 2025-Apr-14, Tom Lane wrote:

> The patch I propose there seems to prevent this, but I wonder if we
> shouldn't look closer into why it's failing in the first place.
> I would not have expected that adding pg_constraint rows implies
> stronger locks than what ALTER ADD PRIMARY KEY was using before,
> and I suspect that doing so will cause more problems than just
> breaking parallel restore.

I wasn't aware of this side effect.  I'll investigate this in more
depth.  I suspect it might be a bug in the way we run through ALTER
TABLE for the primary key.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Los cuentos de hadas no dan al niño su primera idea sobre los monstruos.
Lo que le dan es su primera idea de la posible derrota del monstruo."
                                                   (G. K. Chesterton)

Commits

  1. Suppress "may be used uninitialized" warnings from older compilers.

  2. Elide not-null constraint checks on child tables during PK creation

  3. Remove unnecessary code to handle CONSTR_NOTNULL

  4. Silence compilers about extractNotNullColumn()

  5. Add pg_constraint rows for not-null constraints