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: | 20050924025309.GA11341@surnet.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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 http://www.amazon.com/gp/registry/CTMLCN8V17R4
"Lo esencial es invisible para los ojos" (A. de Saint Exúpery)
Attachment | Content-Type | Size |
---|---|---|
vacuum-min-xid.patch | text/plain | 80.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Drake | 2005-09-24 02:57:43 | Re: 64-bit API for large objects |
Previous Message | Dave Page | 2005-09-23 23:35:55 | Re: PgAdmin3 1.2.2 Install on Win32 Disrupts Pg Service |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2005-09-24 03:02:54 | Re: PL/Python error checking |
Previous Message | Bruce Momjian | 2005-09-23 21:39:15 | Re: Patching dblink.c to avoid warning about open transaction |