Re: vacuum on table1 skips rows because of a query on table2

Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> On Mon, 2019-10-28 at 13:00 -0400, Robert Haas wrote:
>> I wish that this argument were completely correct, but it isn't,
>> because the current query could involve a function written in some
>> procedural language (or in C) which could do anything, including
>> accessing tables that the query hasn't previously touched. It could be
>> that the function will only be called towards the end of the current
>> query's execution, or it could be that it's going to be called
>> multiple times and does different things each time.

> Even if you call a function that uses a new table in a READ COMMITTED
> transaction, that function would use the snapshot of the statement that
> called the function and *not* the transaction snapshot, so the function
> could see no tuples older than the statement's snapshot.

> So VACUUM could remove tuples that were visible when the transaction
> started, but are not visible in the current statement's snapshot.

I don't think that's particularly relevant here. Our sessions already
advertise the xmin from their oldest live snapshot, which would be
the statement snapshot in this case. What the OP is wishing for is
analysis that's finer-grained than "global xmin" allows for ---
but per Robert's comments and my own nearby comments, you would need
a *whole* lot more information to do noticeably better.

> Of course a C function could completely ignore MVCC and access any
> old tuple, but do we want to cater for that?

That's already not guaranteed to work, since a tuple older than the
xmin your session is advertising could disappear at any moment.

regards, tom lane