Re: [HACKERS] WAL logging freezing
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] WAL logging freezing |
Дата | |
Msg-id | 18776.1162392656@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] WAL logging freezing ("Simon Riggs" <simon@2ndquadrant.com>) |
Список | pgsql-patches |
"Simon Riggs" <simon@2ndquadrant.com> writes: > Do we need another GUC? I thought your observation about a PITR slave > having that set lower than its master still remains unresolved. No, AFAICS that's not an issue in this design. The facts-on-the-ground are whatever is recorded in pg_class.relvacuumxid, and whether a particular table has been vacuumed with a shorter or longer freeze window doesn't affect correctness. In particular, a slave with ambitions towards having a shorter window would still be unable to truncate its clog before having re-vacuumed everything. So, not only could we have a GUC variable, but it could be USERSET; there's no breakage risk as long as we constrain the value range to something sane. It strikes me that VACUUM FREEZE could be replaced by SET vacuum_freeze_limit = 0 VACUUM ... which would be a good thing because the FREEZE keyword has to be partially reserved in this syntax, and that is contrary to spec. regards, tom lane
В списке pgsql-patches по дате отправления: