On Tue, Mar 14, 2017 at 2:48 PM, Peter Geoghegan <p...@bowt.ie> wrote: > I think that that's safe, but it is a little disappointing that it > does not allow us to skip work in the case that you really had in mind > when writing the patch. Better than nothing, though, and perhaps still > a good start. I would like to hear other people's opinions.
Hmm. So, the SQL-callable function txid_current() exports a 64-bit XID, which includes an "epoch". If PostgreSQL used these 64-bit XIDs natively, we'd never need to freeze. Obviously we don't do that because the per-tuple overhead of visibility information is already high, and that would make it much worse. But, we can easily afford the extra overhead in a completely dead page. Maybe we can overcome the _bt_page_recyclable() limitation by being cleverer about how it determines if recycling is safe -- it can examine epoch, too. This would also be required in the similar function vacuumRedirectAndPlaceholder(), which is a part of SP-GiST. We already have BTPageOpaqueData.btpo, a union whose contained type varies based on the page being dead. We could just do the same with some other field in that struct, and then store epoch there. Clearly nobody really cares about most data that remains on the page. Index scans just need to be able to land on it to determine that it's dead, and VACUUM needs to be able to determine whether or not there could possibly be such an index scan at the time it considers recycling.. Does anyone see a problem with that? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
