Re: Syncing an application cache with xmin
От | Jason Dusek |
---|---|
Тема | Re: Syncing an application cache with xmin |
Дата | |
Msg-id | CAO3NbwMwpihKEaTiGajJ9+QGY2EmCsGKiYLqb97DDLvxjBVKEg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Syncing an application cache with xmin (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
2013/2/3 Tom Lane <tgl@sss.pgh.pa.us>: > Jason Dusek <jason.dusek@gmail.com> writes: >> The idea would be, to store information about the last XID in >> the last sync and search for XIDs committed since then upon >> reconnecting for sync. Perhaps `txid_current_snapshot()' >> preserves enough information. Is this a plausible technique? > > Perfectly plausible, and often done in one guise or another. > You can't expect row XIDs to survive forever --- they'll be > replaced by FrozenXID after awhile to avoid problems due to > transaction counter wraparound. But for delays of a few > minutes, in a database with an unremarkable transaction rate, > that's not an issue. What is the relationship of the epoch-extended XID returned by `txid_current()' to the XIDs in rows? Do all rows from a previous epoch always have the FrozenXID? -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B
В списке pgsql-general по дате отправления: