Re: Exposing the Xact commit order to the user
| От | Jan Wieck |
|---|---|
| Тема | Re: Exposing the Xact commit order to the user |
| Дата | |
| Msg-id | 4BFD3A37.3070104@Yahoo.com обсуждение исходный текст |
| Ответ на | Re: Exposing the Xact commit order to the user (Greg Stark <gsstark@mit.edu>) |
| Ответы |
Re: Exposing the Xact commit order to the user
Re: Exposing the Xact commit order to the user |
| Список | pgsql-hackers |
On 5/26/2010 10:04 AM, Greg Stark wrote: > On Sun, May 23, 2010 at 9:21 PM, Jan Wieck <JanWieck@yahoo.com> wrote: >> Each record of the Transaction Commit Info consists of >> >> txid xci_transaction_id >> timestamptz xci_begin_timestamp >> timestamptz xci_commit_timestamp >> int64 xci_total_rowcount >> > > So I think you're going about this backward > > Instead of discussing implementation I think you should start with the > API the replication system needs. In particular I'm not sure you > really want a server-side query at all. I'm wondering if you wouldn't > be better off with a public machine-parsable text format version of > the WAL. Ie, at the same time as writing out all the nitty gritty to > the binary wal we would write out a summary of public data to an xml > version containing just parts of the data stream that we can promise > won't change, such as transaction id, lsn, timestamp. Since the actual row level change information and other event data is found inside of regular tables, identified by TXID and sequence number, I am pretty sure I want that data in a server-side query. What you are proposing is to read the xid's and timestamps with an external process, that now forcibly needs to reside on the DB server itself (neither Londiste nor Slony have that requirement as of today), then bring it back into the DB at least inside the WHERE clause of a query. Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin
В списке pgsql-hackers по дате отправления: