Re: tracking commit timestamps
От | Petr Jelinek |
---|---|
Тема | Re: tracking commit timestamps |
Дата | |
Msg-id | 546E767E.50009@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: tracking commit timestamps (Steve Singer <steve@ssinger.info>) |
Ответы |
Re: tracking commit timestamps
|
Список | pgsql-hackers |
On 19/11/14 17:30, Steve Singer wrote: > On 11/19/2014 08:22 AM, Alvaro Herrera wrote: >> >> I think we're overblowing the pg_upgrade issue. Surely we don't need to >> preserve commit_ts data when upgrading across major versions; and >> pg_upgrade is perfectly prepared to remove old data when upgrading >> (actually it just doesn't copy it; consider pg_subtrans or pg_serial, >> for instance.) If we need to change binary representation in a future >> major release, we can do so without any trouble. >> > > That sounds reasonable. I am okay with Petr removing the LSN portion > this patch. > I did that then, v9 attached with following changes: - removed lsn info (obviously) - the pg_xact_commit_timestamp and pg_last_committed_xact return NULLs when timestamp data was not found - made the default nodeid crash safe - this also makes use of the do_xlog parameter in TransactionTreeSetCommitTsData if nodeid is set, although that still does not happen without extension actually using the API - added some more regression tests - some small comment and docs adjustments based on Michael's last email I didn't change the pg_last_committed_xact function name and I didn't make nodeid visible from SQL level interfaces and don't plan to in this patch as I think it's very premature to do so before we have some C code using it. Just to explain once more and hopefully more clearly how the crash safety/WAL logging is handled since there was some confusion in last review: We only do WAL logging when nodeid is also logged (when nodeid is not 0) because the timestamp itself can be read from WAL record of transaction commit so it's pointless to log another WAL record just to store the timestamp again. Extension can either set default nodeid which is then logged transparently, or can override the default logging mechanism by calling TransactionTreeSetCommitTsData with whatever data it wants and do_xlog set to true which will then write the WAL record with this overriding information. During WAL replay the commit timestamp is set from transaction commit record and then if committs WAL record is found it's used to overwrite the commit timestamp/nodeid for given xid. Also, there is exactly one record in SLRU for each xid so there is no point in making the SQL interfaces return multiple results. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: