On 10/22/15 6:39 PM, Alvaro Herrera wrote:
Jim Nasby wrote:

That would be the minimal-impact version, yes. But I suspect if we went
through the trouble to do that, it would be just as easy to attempt the
freeze regardless of what scan_all is set to.

You mean if !scan_all we conditional-get the cleanup lock, if we get it
then prune, if not then freeze?  That seems nice on paper but I think
it's useless because unless scan_all is true, then relfrozenxid doesn't
advance anyway.

Actually, advancing relfrozenxid only depends on having hit all pages in the table, which can happen even if !scan_all. Aside from that, once the freeze map hits this would be useful in setting bits there.

What I wish I knew is whether this problem was worth worrying about or not.
Hopefully the extra logging in 9.5 will shed some light at some point...

As I recall, Andres says it isn't, but I have recollections of scans
that take a very long time to finish because they keep running into a
vacuum that has a page locked.

I guess lets see if the new logging we have on this sheds some light then.
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to