Re: Exposing the Xact commit order to the user - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Exposing the Xact commit order to the user
Date
Msg-id 4C07E55E0200002500031EF8@gw.wicourts.gov
Whole thread Raw
In response to Re: Exposing the Xact commit order to the user  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Exposing the Xact commit order to the user  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote:
> Greg Stark <gsstark@mit.edu> wrote:
>  
>> what kind of interface you need
>  
> For the potential uses I can see, it would be great to have a SRF
> which took two parameters: xid of last known commit and a limit
> how many commits past that to return.
Jan's very first post had it right; my idea was flawed:
| Exposing the data will be done via a set returning function. The
| SRF takes two arguments. The maximum number of rows to return and
| the last serial number processed by the reader. The advantage of
| such SRF is that the result can be used in a query that right away
| delivers audit or replication log information in transaction
| commit order. The SRF can return an empty set if no further
| transactions have committed since, or an error if data segments
| needed to answer the request have already been purged.
| 
| Purging of the data will be possible in several different ways.
| Autovacuum will call a function that drops segments of the data
| that are outside the postgresql.conf configuration with respect to
| maximum age or data volume. There will also be a function reserved
| for superusers to explicitly purge the data up to a certain serial
| number.
Apologies for not looking back to the start of the thread before
that last post.  It was all laid out right at the start.
-Kevin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Did we really want to force an initdb in beta2?
Next
From: Bruce Momjian
Date:
Subject: Re: Exposing the Xact commit order to the user