Re: REPACK (CONCURRENTLY) might keep dropped-column data - Mailing list pgsql-hackers

From shihao zhong
Subject Re: REPACK (CONCURRENTLY) might keep dropped-column data
Date
Msg-id CAGRkXqR5cxvro6UAyqAQx2XzU54XeNwYYfP8Mwhjz5m-1hyiRA@mail.gmail.com
Whole thread
In response to Re: REPACK (CONCURRENTLY) might keep dropped-column data  (Antonin Houska <ah@cybertec.at>)
Responses Re: REPACK (CONCURRENTLY) might keep dropped-column data
List pgsql-hackers
Hi Antonin,

> Can you please be more specific about this? I don't understand why the new
> heap has no TOAST relation in such a case.

heapam_relation_needs_toast_table() skips dropped columns. In my test
the dropped column was the only varlena one, the rest are ints. So
the old heap still has its TOAST table, and the new heap gets none:

    CREATE TABLE rd (id int PRIMARY KEY, n int, b text);
    ALTER TABLE rd DROP COLUMN b;
    REPACK rd;
    SELECT reltoastrelid FROM pg_class WHERE relname = 'rd';  -- 0

I think the function is right. The copy never carries a dropped
column's value over, so the new heap has nothing to toast. Only a
replayed change can bring one in, and then it has to fit in the page.

> Is this needed even for DELETE?

No. 

In your script the live columns are too wide, so nothing can help.
Here the value belongs to a dropped column, and REPACK can drop it.

v2 clears the columns only when replaying an INSERT. restore_tuple() 
and prepare_concurrent_update() stay as they are.

Thanks,
Shihao
Attachment

pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: [PATCH] pg_walsummary: suppress limit output with --quiet
Next
From: Fujii Masao
Date:
Subject: Re: [PATCH] pg_walsummary: suppress limit output with --quiet