Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Per-table freeze limit proposal

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
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 10:52:55
Message-ID: 20051116105255.GB11090@surnet.cl (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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.

We can only do that (mark the table Frozen) if and only if all following
transactions are forced to mark the table "unfrozen" as soon as they
change it.  Are we going to do that?

Note that trying to unfreeze a table might be difficult -- we might need
to obtain a lock on pg_class after we have opened and locked the target
relation, leading to possible deadlock on INSERT.  Yikes.

-- 
Alvaro Herrera       Valdivia, Chile   ICBM: S 39º 49' 17.7", W 73º 14' 26.8"
"Ciencias políticas es la ciencia de entender por qué
 los políticos actúan como lo hacen"  (netfunny.com)

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2005-11-16 11:21:58
Subject: Re: Reproducable deadlock situation (possibly with foreign keys)
Previous:From: Alvaro HerreraDate: 2005-11-16 10:46:24
Subject: Re: [COMMITTERS] pgsql: Translation typo fix

pgsql-patches by date

Next:From: Simon RiggsDate: 2005-11-16 13:55:20
Subject: Re: [HACKERS] Per-table freeze limit proposal
Previous:From: Simon RiggsDate: 2005-11-16 09:53:54
Subject: Re: [HACKERS] Per-table freeze limit proposal

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group