Re: [HACKERS] Per-table freeze limit proposal
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] Per-table freeze limit proposal |
Дата | |
Msg-id | 20050924025309.GA11341@surnet.cl обсуждение исходный текст |
Список | 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)
Вложения
В списке pgsql-patches по дате отправления: