Re: preserving forensic information when we freeze

On Thu, Jan 2, 2014 at 7:40 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-01-02 07:35:11 -0500, Robert Haas wrote:
>> On Thu, Jan 2, 2014 at 12:26 AM, Greg Stark <stark(at)mit(dot)edu> wrote:
>> >> I fail to see why. What is so ugly about this:
>> >
>> >> select x.* from pgbench_accounts a, pg_tuple_header(a.tableoid, a.ctid) x;
>> >
>> > Two points:
>> >
>> > 1) it's a bit weird to go to this effort to eliminate system columns by
>> > using a scheme that depends on having a system column -- ctid
>> >
>> > 2) refetching a row could conceivably end up retrieving different data than
>> > was present when the row was originally read. (In some cases that might
>> > actually be the intended behaviour)
>> >
>> > If this came up earlier I'm sorry but I suppose it's too hard to have a
>> > function like foo(tab.*) which magically can tell that the record is a heap
>> > tuple and look in the header? And presumably throw an error if passed a non
>> > heap tuple.
>>
>> Yeah, that was tried. Doesn't work:
>>
>> http://www.postgresql.org/message-id/CA+TgmoZWZZw_wr8aDHWc8iEjWEiHXLPXRaNqyrfb8mw0schEhg@mail.gmail.com
>>
>> At any rate, my goal isn't really to get rid of system columns, but to
>> address Jim Nasby's gripe that the changes thus far committed make it
>> difficult to use system columns to determine whether a given tuple has
>> been frozen. It sounds like the consensus is that a system column is
>> a better way of doing that than a function, so I suppose the next step
>> is to try to hammer out the details.
>
> So, I think something like my POC patch would need to get in before we
> can go there, right? I won't be able to work on it in the next 10days or
> so, there's a bunch of stuff that's more pressing unfortunately. There's
> a fair bit of work left there...

Well, that's the question, I guess. I think the options are:

1. Add pg_infomask now. Leave your patch for a future optimization.
Suck up the catalog bloat.
2. Wait for your patch to be done. Then add pg_infomask afterwards.
Accept that it may not make 9.4, or else accept that we may have to
accept that patch after the nominal deadline.
3. Decide that exposing the frozen status of tuples is not a priority
and just don't worry about it.

One concern I have is that if we spend too much time now worrying
about these system column problems, it may reduce the amount of
optimization that gets done on top of this optimization in the 9.4
time frame. And that, I think, would be sad.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company