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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Virender Singla <virender(dot)cse(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: vacuum on table1 skips rows because of a query on table2
Date: 2019-10-25 16:46:57
Message-ID: 19474.1572022017@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Virender Singla <virender(dot)cse(at)gmail(dot)com> writes:
> Currently I see the vacuum behavior for a table is that, even if a long
> running query on a different table is executing in another read committed
> transaction.
> That vacuum in the 1st transaction skips the dead rows until the long
> running query finishes.
> Why that is the case, On same table long running query blocking vacuum we
> can understand but why query on a different table block it.

Probably because vacuum's is-this-row-dead-to-everyone tests are based
on the global xmin minimum. This must be so, because even if the
long-running transaction hasn't touched the table being vacuumed,
we don't know that it won't do so in future. So we can't remove
rows that it should be able to see if it were to look.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-10-25 16:52:20 Re: define bool in pgtypeslib_extern.h
Previous Message Tom Lane 2019-10-25 16:38:05 Re: [Proposal] Arbitrary queries in postgres_fdw