Re: Some thoughts about i/o priorities and throttling vacuum
От | Shridhar Daithankar |
---|---|
Тема | Re: Some thoughts about i/o priorities and throttling vacuum |
Дата | |
Msg-id | 3F90026F.3020300@persistent.co.in обсуждение исходный текст |
Ответ на | Re: Some thoughts about i/o priorities and throttling vacuum ("Matthew T. O'Connor" <matthew@zeut.net>) |
Ответы |
Re: Some thoughts about i/o priorities and throttling vacuum
|
Список | pgsql-hackers |
Matthew T. O'Connor wrote: > On Fri, 2003-10-17 at 10:25, Shridhar Daithankar wrote: > >>OK. So here is what I understand. I have a table which contains 100 rows which >>appeated there due to some insert operation. Then I vacuum it. And sit there for >>internity for rest of the database to approach the singularity(the xid >>wraparound..:-) Nice term, isn't it?). >> >>So this static table is vulnerable to xid wraparound? I doubt. > > > No that table would probably be ok, because you did a vacuum on it after > the inserts. The problem is that pg_autovacuum may choose not to do a > vacuum if you didn't cross a threshold, or someone outside of > pg_autovacuum may have done the vacuum and autovac doesn't know about > it, so it can't guarantee that all tables in the database are safe from > xid wraparound. > > One additional thing, some of this might be possible if pg_autovacuum > saved its data between restarts. Right now it restarts with no memory > of what happened before. Well, the unmaintened gborg version adopted approach of storing such info. in a table, so that it survives postgresql/pg_atuvacuum restart or both. That was considered a tablespace pollution back then. But personally I think, it should be ok. If ever it goes to catalogues, I would rather add few columns to pg_class for such a stat. But again, thats not my call to make. Shridhar
В списке pgsql-hackers по дате отправления: