Re: Autoanalyze and OldestXmin

On Wed, Jun 8, 2011 at 9:03 PM, Greg Stark <stark(at)mit(dot)edu> wrote:

>
> On Jun 8, 2011 1:49 PM, "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> wrote:
> >
> >
> > Hi All,
>
> > There is a PROC_IN_ANALYZE flag, but we don't seem to be using it
> anywhere. Since acquire_sample_rows() returns palloced tuples, can't we let
> OldestXmin advance after scanning a page by ignoring procs with the flag
> set, just like we do for PROC_IN_VACUUM ?
>
> I don't even think the pallocing of tuples is a necessary condition. The
> key requirement is that this process will not access any other tables in
> this snapshot. In which case we don't need to take it into account when
> vacuuming other tables.
>
>
I first thought that analyze and vacuum can not run concurrently on the same
table since they take a conflicting lock on the table. So even if we ignore
the analyze process while calculating the OldestXmin for vacuum, we should
be fine since we know they are working on different tables. But I see
analyze also acquires sample rows from the inherited tables with a
non-conflicting lock. I probably do not understand the analyze code well,
but is that the reason why we can't ignore analyze snapshot while
determining OldestXmin for vacuum ?

> It's not safe to vacuum tuples from the table being analyzed because the
> vacuum could get ahead of the analyze.
>

What can go wrong if that happens ? Is the worry that we might get stale
analyze result or are there more serious issues to deal with ?

> This is kind of like the other property it would be nice to know about
> transactions: that they've locked all the tables they're going to lock. That
> would be sufficient but overly strong test. It's possible to know that if
> other tables are accessed they'll be with a brand new snapshot.
>
I definitely do that understand this :-)

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com