Re: [Bug]Vacuum full silently NULL out fast default columns

SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>

From: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Álvaro Herrera <alvherre@kurilemu.de>, Antonin Houska <ah@cybertec.at>
Date: 2026-05-04T14:26:34Z
Lists: pgsql-hackers

Attachments

Hi,

On Mon, May 4, 2026 at 6:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> writes:
> > VACUUM FULL silently turns columns added via ALTER TABLE ... ADD COLUMN
> ...
> > DEFAULT <const> into NULL
> > on all pre-existing rows. The issue exists for other operations like
> > CLUSTER, REPACK.
>
> That is a seriously awful bug.  Fortunately it is not in any shipping
> release.  A quick bisect run agrees that it broke here:
>
> 28d534e2ae0ac888b5460f977a10cd9bb017ef98 is the first bad commit
> commit 28d534e2ae0ac888b5460f977a10cd9bb017ef98 (HEAD)
> Author: Álvaro Herrera <alvherre@kurilemu.de>
> Date:   Mon Apr 6 21:55:08 2026 +0200
>
>     Add CONCURRENTLY option to REPACK
>
> > Patch attached. Added a regression test in fast_default.sql covering
> > VACUUM FULL, CLUSTER, and REPACK on a table with fast-default columns
> > including a NOT NULL CHECK column.
>
> I don't know if this is the best code fix (I don't like putting extra
> checks into a loop condition like this).  But I agree we need some
> more tests covering this area.
>
Thanks for reviewing! Attached v2 patch. Agreed, tried to optimize LOC in
V1. Before the change
loop was not breaking early, I fixed that as well in V2.

Thanks,
Satya