From: Tom Lane on
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
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
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