Re: [HACKERS] Start logical decoding from any lsn present in the wal segment - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: [HACKERS] Start logical decoding from any lsn present in the wal segment
Date
Msg-id CAMsr+YG4TmTywDOZG=Pj=eCdOR4Y7_Jdev8S-XxdFu4XbZRR4Q@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Start logical decoding from any lsn present in the wal segment  (sanyam jain <sanyamjain22@live.in>)
List pgsql-hackers
On 29 June 2017 at 16:32, sanyam jain <sanyamjain22@live.in> wrote:
> Hi,
>
> Currently logical decoding finds a consistent point by generating a snapshot
> and stream changes after consistent point.I want to change this behaviour to
> something which stream changes from a lsn in the past provided its present
> in wal segment. Can this behaviour be implemented

No, it can't. Not without infinite catalog bloat, anyway.

To perform logical decoding we need catalogs that contain historic
data in the form of dead tuples preserved in the heaps. Say you ALTER
TABLE to add a column and drop one. There'll be a new pg_attribute row
for the new column, and the old pg_attribute row will get marked with
attisdropped by writing a new row version.

When we're doing logical decoding and examining WAL from before the
ALTER TABLE, we need to see the old state of the catalogs. So a
historic snapshot is created with an (xmin,xmax) range that means it
won't see the new pg_attribute row, and it'll see the old row-version
of the dropped attribute where attisdropped is not set. So it'll see a
table definition that matches how it was at the time the WAL it's
looking at was generated.

If you could only see the latest table definition from pg_catalog
you'd have no way to correctly decode such WAL.

That's what all the catalog_xmin business in the code is about.

There are some other complications too, around finding safe points in
the WAL stream where running xacts are precisely known; see
xl_running_xacts and the snapshot builder.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Michal Novotny
Date:
Subject: [HACKERS] Segmentation fault in libpq
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] What does it mean by XLOG_BACKUP_RECORD?