Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

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

From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Michael Paquier <michael@paquier.xyz>, Ali Akbar <the.apaan@gmail.com>, Michael Paquier <michael.paquier@gmail.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, tushar <tushar.ahuja@enterprisedb.com>, pgsql-hackers@postgresql.org, rmt@lists.postgresql.org
Date: 2025-07-04T16:21:31Z
Lists: pgsql-hackers
On 2025-Jul-03, Tom Lane wrote:

> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > On 2025-Jul-03, Justin Pryzby wrote:
> >>> Actually I think we should consider backporting to all live versions
> 
> >> If you don't backpatch it, there's no point.
> 
> > Oh yeah, you're absolutely right.
> 
> No, it'd still be useful for handling upgrades from $busted_version
> to current.  But it seems also useful in the back branches, so
> +1 for back-patch.

Pushed to all branches.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"El miedo atento y previsor es la madre de la seguridad" (E. Burke)



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix new pg_upgrade query not to rely on regnamespace

  2. pg_upgrade: check for inconsistencies in not-null constraints w/inheritance

  3. Apply ALTER ... SET NOT NULL recursively in ALTER ... ADD PRIMARY KEY.