Re: Adding a stored generated column without long-lived locks

From: Alberto Piai <alberto(dot)piai(at)gmail(dot)com>
To: Alberto Piai <alberto(dot)piai(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org
Cc: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Subject: Re: Adding a stored generated column without long-lived locks
Date: 2026-07-03 06:42:18
Message-ID: DJOPT622HYJK.3JRH1VQCV5CDL@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

v5 had a rather brittle test that was relying on a DEBUG message being
emitted when phase 3 verifies or rewrites a table (via
client_min_messages). That was failing on the CI because the output
depends on any other setting that might affect logging (in this case it
was log_statement).

The attached v6 replaces it with an injection_point test. If adding new
injection points to detect scans/rewrites is considered too much, I can
back it out and set/reset log_statement too. But I do prefer the
injection_point test.

If the new injection point is good, there are also a couple more tests
which might be updated to use it.

Regards,

Alberto

--
Alberto Piai
Sensational AG
Zürich, Switzerland

Attachment Content-Type Size
v6-0001-Support-changing-a-column-into-a-stored-generated.patch text/plain 70.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2026-07-03 06:51:57 Path Traversal Vulnerability in pg_dump Directory Format
Previous Message Kyotaro Horiguchi 2026-07-03 06:37:42 Mark class_descr strings for translation