Re: Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
От | Simon Riggs |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to |
Дата | |
Msg-id | 1268123581.10620.76.camel@ebony обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Augment WAL records for btree
delete with GetOldestXmin() to
|
Список | pgsql-hackers |
On Sun, 2010-01-31 at 16:53 -0500, Tom Lane wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > > IIRC it was Greg Stark who suggested last time this was discussed that > > we could calculate the exact value for latestRemovedXid in the standby. > > When replaying the deletion record, the standby could look at all the > > heap tuples whose index pointers are being removed, to see which one was > > newest. > > This assumes that the standby can tell which heap tuples are being > removed, which I'm not sure is true --- consider the case where the > deletion record is carrying a page image instead of a list of deleted > tuples. But maybe we could rejigger the representation to make sure > that the info is always available. In general it sounds like a much > nicer answer. I'm looking at this now since we definitely need either this or the previous patch. XLOG_BTREE_DELETE records would not carry latestRemovedXid, this would be calculated by inspection of heap tuples. XLOG_BTREE_DELETE would have a heap relid, to allow direct access to the heap without a Relation. We would check xmin, xmax and xvac. Code will look a little like heap_fetch() though disimilar enough not to use directly. We would only look at the tuple header and info. -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: