From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | InsertPgAttributeTuple() and attcacheoff |
Date: | 2018-08-14 13:19:43 |
Message-ID: | f3bb4713-1207-24a5-b89f-5d18f774c4ed@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
It seems to me that it would make sense if InsertPgAttributeTuple() were
to set attcacheoff to -1 instead of taking it from the caller.
InsertPgAttributeTuple() is the interface between in-memory tuple
descriptors and on-disk pg_attribute, so it makes sense to give it the
job of resetting attcacheoff. This avoids having all the callers having
to do so. There are also pending patches that have to work around this
in seemingly unnecessary ways.
(The comment about the "very grotty code" that I'm removing is from a
time when AppendAttributeTuples() would deform a tuple, reset
attcacheoff, then reform the tuple -- hence grotty. This is long
obsolete, since the tuple is now formed later.)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
0001-InsertPgAttributeTuple-to-set-attcacheoff.patch | text/plain | 3.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-08-14 13:35:14 | Re: Memory leak with CALL to Procedure with COMMIT. |
Previous Message | Andrew Gierth | 2018-08-14 13:16:42 | Re: Undocumented(?) limits on regexp functions |