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: | Raw Message | Whole Thread | 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 |