Re: Syncing an application cache with xmin

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

In response to

Browse pgsql-general by date

  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