Re: [HACKERS] Non-transactional pg_class, try 2
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] Non-transactional pg_class, try 2 |
Дата | |
Msg-id | 20060710163014.GA25554@surnet.cl обсуждение исходный текст |
Ответ на | Re: [HACKERS] Non-transactional pg_class, try 2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > I think we could give autovac a "reason for being started", which would > > normally be the periodic stuff, but if the postmaster got the signal > > from a backend, pass that info to autovac and it could use a different > > database selection algorithm -- say, just select the oldest database, > > even if it's not in danger of Xid wraparound. > > I don't think it's worth the trouble to provide such a signaling > mechanism (it'd be a bit of a PITA to make it work in both fork and > EXEC_BACKEND cases). ISTM it's sufficient for autovac to look at the > GUC state and notice whether it's nominally enabled or not. If not, > it should only consider anti-wraparound vacuum operations. > > If the signal is given just when VACUUM sees a datvacuumxid value that's > old enough to cause autovac to decide it had better go prevent > wraparound, then this will work without any additional data transfer. > We could negotiate exactly how old DBs need to be to cause this; if you > want to make it less than a billion xacts so that we can keep pg_clog > cut down to size, that's fine with me. Committed. I didn't do anything but the simplest stuff; autovacuum checks whether it's enabled in GUC, and if it doesn't then it just picks the oldest database and issues a database-wide vacuum. The vac_truncate_clog routine will send a signal at the same time as the WARNING about nearing Xid wraparound would be emitted. One funny thing I noticed is that if there is more than one database needing db-wide vacuum, vacuum will send a signal; autovacuum will process one database; and autovacuum will send a signal as well when it's done because of the other databases. But autovacuum will get the second signal and do nothing, because of the code to check for frequent autovacuum starts. This kind of suprised me at first but it's really to be expected. I considered disabling that timing code in the case of getting the signal, but I don't think it's worth it. One important improvement we'd may want to do is changing vacuum so that it only calls vac_truncate_clog once if invoked by autovacuum (currently it'll be called every time a table is vacuumed). Also I think we could change the OldestXmin stuff so that it only takes database-local transactions into account for non-shared tables. But in the spirit of incremental improvement I think we're much better now. Happy sprinting to everyone, -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
В списке pgsql-patches по дате отправления: