Re: [HACKERS] Per-table freeze limit proposal

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Per-table freeze limit proposal
Date: 2005-11-16 13:55:20
Message-ID: 1132149320.3388.139.camel@holly
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Wed, 2005-11-16 at 07:52 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On Wed, 2005-11-16 at 08:31 +0000, Simon Riggs wrote:
>
> > > All tuples might be frozen or might not be, the point is you don't know.
> > > That's why you can't use FrozenTransactionId.
>
> > Thinking some more, when initdb issues VACUUM FREEZE we know for certain
> > that nobody else is issuing commands against the database at that point,
> > which is equivalent to a table lock. So we should be able to have a
> > VACUUM FREEZE detect that and if so, set FrozenTransactionId.
> >
> > In normal concurrent running, I would like VACUUM FREEZE to issue a full
> > table SHARE lock to ensure that we can set FrozenTransactionId for that
> > also. Otherwise we will not be able to move frozen tables to read only
> > media.
>
> You missed one point however. Even if VACUUM FREEZE freezes all tuples,
> any transaction following that one is able to insert non-frozen tuples
> into the table. At that instant, having marked the table with Frozen is
> bogus, no matter what amount of locks you took on it.

(OK I think we are getting there now, after my usual comms errors.)

We need something stronger than VACUUM FREEZE then. Perhaps an ALTER
TABLE READONLY. That would do a FREEZE and place a permanent table share
lock, so we wouldn't need to set/unset the Frozen state. We'd do that as
a permissions thing, rather than an actual lock. That way copies of the
data could still be taken with ease and the copies would not themselves
be READONLY.

Not sure what you'd call it to make a whole database readonly all at
once...but whatever we call it we know initdb wants to run it on
template1.

Then your original thought becomes fully viable.

This is particularly important because I see the need to be able to
freeze older data partitions and migrate them to readonly media as part
of very high volume data applications.

Best Regards, Simon Riggs

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Alan Dorman 2005-11-16 13:58:52 Re: bind variables, soft vs hard parse
Previous Message Pollard, Mike 2005-11-16 13:52:51 Re: question about count(b) where b is a custom type

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2005-11-16 14:40:37 Re: [PATCHES] pl/pgSQL doco patch
Previous Message Alvaro Herrera 2005-11-16 10:52:55 Re: [HACKERS] Per-table freeze limit proposal