Re: preserving forensic information when we freeze

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Jim Nasby <jim(at)nasby(dot)net>
Subject: Re: preserving forensic information when we freeze
Date: 2014-01-02 14:49:27
Message-ID: 20140102144927.GB842@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-01-02 09:40:54 -0500, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Thu, Jan 2, 2014 at 12:26 AM, Greg Stark <stark(at)mit(dot)edu> wrote:
> >> 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
>
> > 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.
>
> Actually, I thought the function approach was a good proposal. You are
> right that func(tab.*) isn't going to work, because it's going to get a
> Datum-ified tuple not a pointer to raw on-disk storage. But an inspection
> function that's handed a ctid could work.

Well, we discussed that upthread, and the overhead of going through a
function is quite noticeable because the tuple needs to be fetched from
the heap again.
Check http://archives.postgresql.org/message-id/CA%2BTgmoYdWOZa_UiewbqE73AQCM2etpMjukkcmYPkGatH8kPTow%40mail.gmail.com

To get rid of part of the performance problem, we could possibly invent
a way to pass a HeapTuple instead of a blessed HeapTupleHeader to
functions, but that might not be so easy.

> And I really really *don't* want to see us bloating pg_attribute, nor
> infringing further on application column namespace, by adding even more
> exposed columns. So -1 for just blindly doing that.

Upthread there's a POC patch of mine, that started to explore what's
necessary to simply never store system columns (except maybe oid) in
pg_attribute. While it passes the regression tests it's not complete,
but the amount of work looks reasonable. Check
http://archives.postgresql.org/message-id/20131223124504.GB19795%40alap2.anarazel.de

Now, that obviously doesn't get rid of the namespace problem. I'd
suggested a system: prefix, Robert _pg_. Neither is pretty, but imo
should work.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-01-02 16:08:33 Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Previous Message Tom Lane 2014-01-02 14:40:54 Re: preserving forensic information when we freeze