Prev: pgsql: Augment WAL records forbtree delete with GetOldestXmin() to
Next: [HACKERS] contrib\xml2 package's xpath_table function in PostgreSQL
From: Tom Lane on 31 Jan 2010 15:41 Simon Riggs <simon(a)2ndQuadrant.com> writes: > At the moment a btree delete record will cancel every request > 1. no matter how long they have been running > 2. no matter if they haven't accessed the index being cleaned (they > might later, is the thinking...) That seems seriously horrid. What is the rationale for #2 in particular? I would hope that at worst this would affect sessions that are actively competing for the index being cleaned. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 31 Jan 2010 16:53 Heikki Linnakangas <heikki.linnakangas(a)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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 31 Jan 2010 17:10
Simon Riggs <simon(a)2ndQuadrant.com> writes: > Should I revoke this change? Please. We can always put it back later if nothing better gets implemented. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |