Re: Intermittent regression test failures from index-only plan changes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Intermittent regression test failures from index-only plan changes
Date: 2012-01-07 17:30:33
Message-ID: 20053.1325957433@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Fri, Jan 6, 2012 at 10:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Background auto-VACUUMs shouldn't cause this problem because they don't
>> take snapshots, and ideally it'd be nice if auto-ANALYZE couldn't create
>> the issue either, but ANALYZE does need a snapshot so it's hard to see
>> how to avoid having it trip the all-visible logic. Anybody have any
>> ideas?

> That seems like a huge production problem looming over us, not just a
> regression test issue.

It could be mildly annoying, but I'm not sure it rises to the level of a
"huge production problem".

> I feel like this is a trick question, but I'll ask anyway: Can't we
> just ignore ANALYZE?

AFAICS, no. ANALYZE will run user-defined code: not only user-supplied
stats collection functions, but user-defined index expressions. We
cannot assume that none of that ever requires a snapshot.

BTW, if you think this is a fatal issue, then I'm afraid it's also
a fatal objection to your proposal to turn SnapshotNow into an MVCC
snapshot. Even if we could assume ANALYZE doesn't run any user-defined
code, it most certainly must be able to do system catalog accesses,
and that will mean SnapshotNow which would become an MVCC snapshot.
What's worse, VACUUM would also begin taking MVCC snapshots for
its catalog accesses, and thus could no longer be ignored for the
purpose of determining global xmin.

I have an uneasy feeling that the assumption that VACUUM doesn't take
MVCC snapshots is wired into more places than just GetSnapshotData,
but can't think of any other places just now.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2012-01-07 17:36:42 Re: Collect frequency statistics for arrays
Previous Message Tom Lane 2012-01-07 17:18:23 Re: LWLOCK_STATS