| From: | Jason Dusek <jason(dot)dusek(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Syncing an application cache with xmin |
| Date: | 2013-02-03 18:21:10 |
| Message-ID: | CAO3NbwMwpihKEaTiGajJ9+QGY2EmCsGKiYLqb97DDLvxjBVKEg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
2013/2/3 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Jason Dusek <jason(dot)dusek(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steven Schlansker | 2013-02-03 23:37:41 | Using partial index in combination with prepared statement parameters |
| Previous Message | Tom Lane | 2013-02-03 16:09:40 | Re: Syncing an application cache with xmin |