postgres.git / summary / log / commit / refs

commit    ee0d06c0b9993fb06b940c21a7bfde7de8186a2e
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Fri Apr 03 04:07:29 2015 +0000
First released in: 9.5.0, 9.4.2

    Fix rare startup failure induced by MVCC-catalog-scans patch.
    
    While a new backend nominally participates in sinval signaling starting
    from the SharedInvalBackendInit call near the top of InitPostgres, it
    cannot recognize sinval messages for unshared catalogs of its database
    until it has set up MyDatabaseId.  This is not problematic for the catcache
    or relcache, which by definition won't have loaded any data from or about
    such catalogs before that point.  However, commit 568d4138c646cd7c
    introduced a mechanism for re-using MVCC snapshots for catalog scans, and
    made invalidation of those depend on recognizing relevant sinval messages.
    So it's possible to establish a catalog snapshot to read pg_authid and
    pg_database, then before we set MyDatabaseId, receive sinval messages that
    should result in invalidating that snapshot --- but do not, because we
    don't realize they are for our database.  This mechanism explains the
    intermittent buildfarm failures we've seen since commit 31eae6028eca4365.
    That commit was not itself at fault, but it introduced a new regression
    test that does reconnections concurrently with the "vacuum full pg_am"
    command in vacuum.sql.  This allowed the pre-existing error to be exposed,
    given just the right timing, because we'd fail to update our information
    about how to access pg_am.  In principle any VACUUM FULL on a system
    catalog could have created a similar hazard for concurrent incoming
    connections.  Perhaps there are more subtle failure cases as well.
    
    To fix, force invalidation of the catalog snapshot as soon as we've
    set MyDatabaseId.
    
    Back-patch to 9.4 where the error was introduced.


 src/backend/utils/init/postinit.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/src/backend/utils/init/postinit.c b/src/backend/utils/init/postinit.c
index 28243ad58f9..6e269cdfbab 100644
--- a/src/backend/utils/init/postinit.c
+++ b/src/backend/utils/init/postinit.c
@@ -823,6 +823,14 @@ InitPostgres(const char *in_dbname, Oid dboid, const char *username,
 	/* (We assume this is an atomic store so no lock is needed) */
 	MyProc->databaseId = MyDatabaseId;
 
+	/*
+	 * We established a catalog snapshot while reading pg_authid and/or
+	 * pg_database; but until we have set up MyDatabaseId, we won't react to
+	 * incoming sinval messages for unshared catalogs, so we won't realize it
+	 * if the snapshot has been invalidated.  Assume it's no good anymore.
+	 */
+	InvalidateCatalogSnapshot();
+
 	/*
 	 * Now, take a writer's lock on the database we are trying to connect to.
 	 * If there is a concurrently running DROP DATABASE on that database, this


[parent: a1f4ade01ca6]