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

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 08:31:03
Message-ID: 1132129863.3388.109.camel@holly (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
On Tue, 2005-11-15 at 21:58 -0300, Alvaro Herrera wrote:
> In fact there's no problem because in D, just like in template1, all
> tuples are frozen.  How should we mark this on the catalogs?  I don't
> see any way.

All tuples might be frozen or might not be, the point is you don't know.
That's why you can't use FrozenTransactionId.

> > Perhaps we should reinstate VACUUM FULL FREEZE to do just a FREEZE with
> > a table lock and skip all that moving data around.
> Doesn't work either because of the argument above.
> What about assuming that if somebody executes a database-wide FREEZE, he
> knows what he is doing and thus we can mark datminxid as
> FrozenTransactionId?

If you lock the table before FREEZE then you will guarantee that all
rows will be frozen and you really can then set FrozenTransactionId.

Making VACUUM FREEZE take full table locks seems like a very useful
thing to me, and it would solve your problems also.

Best Regards, Simon Riggs

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2005-11-16 08:42:57
Subject: Re: [COMMITTERS] pgsql: Translation typo fix
Previous:From: Yann MichelDate: 2005-11-16 08:27:55
Subject: Re: PG_DUMP and table locking in PG7.4

pgsql-patches by date

Next:From: Simon RiggsDate: 2005-11-16 09:53:54
Subject: Re: [HACKERS] Per-table freeze limit proposal
Previous:From: Bruce MomjianDate: 2005-11-16 03:52:51
Subject: Re: pl/pgSQL doco patch

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