Re: hot_standby_feedback vs excludeVacuum and snapshots

From: Andres Freund <andres(at)anarazel(dot)de>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: hot_standby_feedback vs excludeVacuum and snapshots
Date: 2018-06-11 16:56:45
Message-ID: 20180611165645.f5aqtlvog7fekc46@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-06-11 10:15:39 +0100, Simon Riggs wrote:
> diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
> index 9db184f8fe..c280744fdd 100644
> --- a/src/backend/storage/ipc/procarray.c
> +++ b/src/backend/storage/ipc/procarray.c
> @@ -1995,10 +1995,6 @@ GetRunningTransactionData(void)
> volatile PGXACT *pgxact = &allPgXact[pgprocno];
> TransactionId xid;
>
> - /* Ignore procs running LAZY VACUUM */
> - if (pgxact->vacuumFlags & PROC_IN_VACUUM)
> - continue;
> -
> /* Fetch xid just once - see GetNewTransactionId */
> xid = pgxact->xid;
>
> @@ -2009,13 +2005,21 @@ GetRunningTransactionData(void)
> if (!TransactionIdIsValid(xid))
> continue;
>
> - xids[count++] = xid;
> -
> + /*
> + * Be careful not to exclude any xids from calculating the values of
> + * oldestRunningXid and suboverflowed.
> + */
> if (TransactionIdPrecedes(xid, oldestRunningXid))
> oldestRunningXid = xid;
>
> if (pgxact->overflowed)
> suboverflowed = true;
> +
> + /* Ignore procs running LAZY VACUUM */
> + if (pgxact->vacuumFlags & PROC_IN_VACUUM)
> + continue;
> +
> + xids[count++] = xid;

I don't think this is a good idea. We shouldn't continue down the path
of having running xacts not actually running xacts, but rather go back
to including everything. The case presented in the thread didn't
actually do what it claimed originally, and there's a fair amount of
potential for the excluded xids to cause problems down the line.

Especially not when the fixes should be backpatched. I think the
earlier patch should be reverted, and then the AEL lock release problem
should be fixed separately.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-06-11 17:11:42 Re: CF bug fix items
Previous Message Andres Freund 2018-06-11 16:49:52 Re: pgsql: Fix and document lock handling for in-memory replication slot da