Patch for bug #17056 fast default on non-plain table
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t44407psql -h localhost -U postgresBuilt from patchset v4 (message #4), July 27, 2026 at 04:48 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t44407_4 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t44407_4 && git checkout t44407_4Patchset v4 (message #4) is on t44407_4
Here's a patch I propose to apply to fix this bug (See
</messages/by-id/759e997e-e1ca-91cd-84db-f4ae963fada1@dunslane.net
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Attachments:
0001-Don-t-set-a-fast-default-for-anything-but-a-plain-ta.patchtext/x-patch; charset=UTF-8; name=0001-Don-t-set-a-fast-default-for-anything-but-a-plain-ta.patchDownload+54-4
Andrew Dunstan <andrew@dunslane.net> writes:
Here's a patch I propose to apply to fix this bug (See
</messages/by-id/759e997e-e1ca-91cd-84db-f4ae963fada1@dunslane.net
If I'm reading the code correctly, your change in RelationBuildTupleDesc
is scribbling directly on the disk buffer, which is surely not okay.
I don't understand why you need that at all given the other defenses
you added ... but if you need it, you have to modify the tuple AFTER
copying it.
regards, tom lane
On 6/17/21 11:05 AM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
Here's a patch I propose to apply to fix this bug (See
</messages/by-id/759e997e-e1ca-91cd-84db-f4ae963fada1@dunslane.netIf I'm reading the code correctly, your change in RelationBuildTupleDesc
is scribbling directly on the disk buffer, which is surely not okay.
I don't understand why you need that at all given the other defenses
you added ... but if you need it, you have to modify the tuple AFTER
copying it.
OK, will fix. I think we do need it (See Andres' comment in the bug
thread). It should be a fairly simple fix.
Thanks for looking.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 6/17/21 11:13 AM, Andrew Dunstan wrote:
On 6/17/21 11:05 AM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
Here's a patch I propose to apply to fix this bug (See
</messages/by-id/759e997e-e1ca-91cd-84db-f4ae963fada1@dunslane.netIf I'm reading the code correctly, your change in RelationBuildTupleDesc
is scribbling directly on the disk buffer, which is surely not okay.
I don't understand why you need that at all given the other defenses
you added ... but if you need it, you have to modify the tuple AFTER
copying it.OK, will fix. I think we do need it (See Andres' comment in the bug
thread). It should be a fairly simple fix.
revised patch attached.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
revised patch attached.
OK. One other point is that in HEAD, you only need the hunk that
prevents atthasmissing from becoming incorrectly set. The hacks
to cope with it being already wrong are only needed in the back
branches. Since we already forced initdb for beta2, there will
not be any v14 installations in which pg_attribute contains
a wrong value.
regards, tom lane
On 6/17/21 1:45 PM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
revised patch attached.
OK. One other point is that in HEAD, you only need the hunk that
prevents atthasmissing from becoming incorrectly set. The hacks
to cope with it being already wrong are only needed in the back
branches. Since we already forced initdb for beta2, there will
not be any v14 installations in which pg_attribute contains
a wrong value.
Good point. Should I replace the relcache.c changes in HEAD with an
Assert? Or just skip them altogether?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
On 6/17/21 1:45 PM, Tom Lane wrote:
OK. One other point is that in HEAD, you only need the hunk that
prevents atthasmissing from becoming incorrectly set.
Good point. Should I replace the relcache.c changes in HEAD with an
Assert? Or just skip them altogether?
I wouldn't bother touching relcache.c.
regards, tom lane