On 08/10/2015 11:17 AM, Andres Freund wrote:
On 2015-08-10 07:26:29 +0100, Simon Riggs wrote:
On 10 August 2015 at 07:14, Peter Geoghegan <p...@heroku.com> wrote:
On Sun, Aug 9, 2015 at 11:03 PM, Simon Riggs <si...@2ndquadrant.com>
wrote:
If 5) fails to bring a workable solution by the Jan 2016 CF then we
commit
2) instead.
Is there actually a conflict there? I didn't think so.
I didn't explain myself fully, thank you for asking.
Having a freeze map would be wholly unnecessary if we don't ever need to
freeze whole tables again. Freezing would still be needed on individual
blocks where an old row has been updated or deleted; a freeze map would not
help there either.
So there is no conflict, but options 2) and 3) are completely redundant if
we go for 5). After investigation, I now think 5) is achievable in 9.6, but
if I am wrong for whatever reason, we have 2) as a backstop.
I don't think that's true. You can't ever delete the clog without
freezing. There's no need for anti-wraparound scans anymore, but you
still need to freeze once.
What's your definition of freezing? As long as you remove all dead
tuples, you can just leave the rest in place with their original
XID+epoch in place, and assume that everything old enough is committed.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
