On Wed, Jun 8, 2011 at 9:03 PM, Greg Stark
<stark@mit.edu> wrote:
On Jun 8, 2011 1:49 PM, "Pavan Deolasee" <pavan.deolasee@gmail.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,
