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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Per-table freeze limit proposal
Date: 2005-09-24 02:53:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
On Wed, Sep 14, 2005 at 11:30:52PM -0400, Tom Lane wrote:

> Updating the pg_database entry
> will have to be the responsibility of VACUUM itself.  It's not that
> terrible: you don't have to scan pg_class unless you see that the
> pg_class.relfreezexid value you are replacing is equal to
> pg_database.datfreezexid, and with the exact computation suggested
> above, that won't be a common occurrence.

Ok, this patch is a first cut at that.  I made it slightly smarter,
because we want to do it only once if we issue a database-wide vacuum,
instead of once per table.  However, I also had to cope with the
possibility that the table with the minimum Xid value is dropped, so I
made that set the datminxid to InvalidXid.  If after a VACUUM the
datminxid is found to be Invalid, pg_class is scanned inconditionally.

There's the usual gotcha with shared relations: vacuuming them on one
database is not going to update their pg_class entries in other
databases, so they will be vacuumed more frequently than really
necessary.  I don't see how to fix that -- one way would be storing
their stats in one database only, but it seems dangerous.

Note that I use LockSharedObject() to lock the database while we are
updating the pg_database row.  This means that more than one database
can be updated concurrently (this is important because we have to keep
the lock while we seqscan pg_class).  This may be a bad idea from the
point of view of the buffer manager; maybe we need an additional
LockBuffer() just before we are going to modify the tuple.

With this in place, it's no longer necessary to issue database-wide
vacuums anymore.  Note that I haven't tested the part where the clog
grows enough to be truncated, nor really anything more complicated than
a single backend doing database-wide or single-table vacuums (with an
optional parallel backend with an open transaction).  Still, it shows
what the basics of the patch are.

Alvaro Herrera       
"Lo esencial es invisible para los ojos" (A. de Saint Ex├║pery)

In response to

pgsql-hackers by date

Next:From: Jeremy DrakeDate: 2005-09-24 02:57:43
Subject: Re: 64-bit API for large objects
Previous:From: Dave PageDate: 2005-09-23 23:35:55
Subject: Re: PgAdmin3 1.2.2 Install on Win32 Disrupts Pg Service

pgsql-patches by date

Next:From: Michael FuhrDate: 2005-09-24 03:02:54
Subject: Re: PL/Python error checking
Previous:From: Bruce MomjianDate: 2005-09-23 21:39:15
Subject: Re: Patching dblink.c to avoid warning about open transaction

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