Re: Something is rotten in the state of Denmark...

On Wed, Apr 1, 2015 at 7:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I've been able to reproduce this. The triggering event seems to be that
> the "VACUUM FULL pg_am" in vacuum.sql has to happen while another backend
> is starting up. With a ten-second delay inserted at the bottom of
> PerformAuthentication(), it's trivial to hit it manually. The reason we'd
> not seen this before the rolenames.sql test was added is that none of the
> other tests that run concurrently with vacuum.sql perform mid-test
> reconnections, or ever have AFAIR. So as long as they all managed to
> start up before vacuum.sql got to the dangerous step, no problem.
>
> I've not fully tracked it down, but I think that the blame falls on the
> MVCC-snapshots-for-catalog-scans patch; it appears that it's trying to
> read pg_am's pg_class entry with a snapshot that's too old, possibly
> because it assumes that sinval signaling is alive which I think ain't so.

Hmm, sorry for the bug. It looks to me like sinval signaling gets
started up at the beginning of InitPostgres(). Perhaps something like
this?

diff --git a/src/backend/utils/time/snapmgr.c b/src/backend/utils/time/snapmgr.c
index 7cfa0cf..47c4002 100644
--- a/src/backend/utils/time/snapmgr.c
+++ b/src/backend/utils/time/snapmgr.c
@@ -303,7 +303,7 @@ GetNonHistoricCatalogSnapshot(Oid relid)
* Mark new snapshost as valid. We must do this last,
in case an
* ERROR occurs inside GetSnapshotData().
*/
- CatalogSnapshotStale = false;
+ CatalogSnapshotStale = !IsNormalProcessingMode();
}

return CatalogSnapshot;

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company