| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Florent Guiliani <florent(at)guiliani(dot)fr> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Retrieve the snapshot's LSN |
| Date: | 2015-07-16 16:40:07 |
| Message-ID: | CA+TgmoZG3Lw7_4=GYG=Uti=Zn+qnsnS=m_9OJde_-K47AYhg6A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 15, 2015 at 12:51 PM, Florent Guiliani <florent(at)guiliani(dot)fr> wrote:
> During slot creation, the snapshot building and exporting code seems
> highly coupled with the logical decoding stuff. It doesn't seems much
> reusable to retrieve the snapshot's LSN outside of logical decoding.
I don't think "the snapshot's LSN" has a well-defined meaning in
general. The obvious meaning would be "the LSN such that all commits
prior to that LSN are visible and all later commits are invisible",
but such an LSN need not exist. Suppose A writes a commit record at
LSN 0/10000, and then B writes a commit record at 0/10100, and then B
calls ProcArrayEndTransaction(). At this point, B is visible and A is
not visible, even though A's commit record precedes that of B.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2015-07-16 16:42:07 | Re: Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file |
| Previous Message | Robert Haas | 2015-07-16 16:28:50 | Re: Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file |