Min Xid problem proposal
От | Alvaro Herrera |
---|---|
Тема | Min Xid problem proposal |
Дата | |
Msg-id | 20051209163305.GA25980@surnet.cl обсуждение исходный текст |
Ответы |
Re: Min Xid problem proposal
|
Список | pgsql-hackers |
Anybody remembers my patch to allow tracking the minimum Xid present in a table, allowing to update the freeze xid on a per-table basis? The motivation behind it was to remove the requirement of database-wide vacuums. The problem I found with it was that it required all tables to be vacuumed at least once every billion transactions, even frozen tables, because there was the danger that somebody may insert new tuples into the table without marking that fact in the catalogs (thus minxid would remain FrozenTransactionId but reality would be different.) My proposal to solve that problem, is to make any transaction that inserts or modifies tuples in a table that is marked as frozen, unfreeze it first. The problem I had last time was finding a good spot in the code for doing so. I'm now proposing to do it in the parser, in setTargetTable(). This routine currently opens the target relation and acquires RowExclusiveLock on it. At this point we can check its relminxid, and if it's FreezeTransactionId, open pg_class and change the value there. The problem with this is that it seems to turn a possibly innocuous insert into an operation that needs to open pg_class. But in the case of a relation not in the relcache, it will happen anyway, so it's not really all that serious. (The assumption here is that an unfreeze event is at least as unlikely as a cache miss or a cache invalidation.) The attached patch implements this idea. (Of course it doesn't work standalone; it requires the rest of my min-xid patch.) I attach it here separately because it's small and the proposal can be reviewed independently of the rest of the patch, which is quite bigger. Note that there's a FIXME on heap_unfreeze() saying that the shared invalidation would not occur if the transaction aborts. This comment comes verbatim from vacuum.c's vac_update_relstats(); however I made a small experiment and it seems to be false. I'm not sure about it, but it seems to me to be critical to send a invalidation message so that other backends will notice immediately when we unfreeze a relation. Comments? -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 "La victoria es para quien se atreve a estar solo"
Вложения
В списке pgsql-hackers по дате отправления: