Re: [HACKERS] pg_upgrade bug in handling postgres/template1 databases

2015-02-11 Thread Bruce Momjian
On Tue, Feb 10, 2015 at 12:52:33PM -0500, Bruce Momjian wrote:
 The attached patch fixes the problem, and I have reproduced the bug and
 verified the patch fixes it.  It would have been nice if I had figured
 this out two weeks ago, before we released minor version upgrades.  This
 bug has existed back to 9.0 or earlier, so it isn't new.

Patch applied back through 9.0.  This bug was reported by an EDB
customer.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + Everyone has their own god. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] pg_upgrade bug in handling postgres/template1 databases

2015-02-10 Thread Bruce Momjian
I received a private pg_upgrade bug report related to its affect on the
removal of clog files in the upgraded cluster.  The user reported that
an upgraded cluster yielded this error very soon after being started for
the first time:

SELECT * FROM test;
ERROR:  could not access status of transaction 685
DETAIL:  Could not open file pg_clog/: No such file or directory.

I was confused as I had never seen such a report before.  After much
digging, I found out that the user was storing data _only_ in the
'postgres' database, not any other databases, and that pg_upgrade was
not preserving pg_database.datfrozenxid and pg_database.datminmxid, even
though it was processing those databases and copying over any user
tables and indexes.

When the new server was started, pg_database.datminmxid equaled the
current transaction counter and old clog files were removed, yielding
the error.

This is not a problem for users who store functions or extensions in the
postgres or template1 database, just user tables and indexes.

The attached patch fixes the problem, and I have reproduced the bug and
verified the patch fixes it.  It would have been nice if I had figured
this out two weeks ago, before we released minor version upgrades.  This
bug has existed back to 9.0 or earlier, so it isn't new.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + Everyone has their own god. +
diff --git a/src/bin/pg_dump/pg_dumpall.c b/src/bin/pg_dump/pg_dumpall.c
new file mode 100644
index 3e3b433..ec7246a
*** a/src/bin/pg_dump/pg_dumpall.c
--- b/src/bin/pg_dump/pg_dumpall.c
*** dumpCreateDB(PGconn *conn)
*** 1417,1432 
  
  			appendPQExpBufferStr(buf, ;\n);
  
! 			if (binary_upgrade)
! 			{
! appendPQExpBufferStr(buf, -- For binary upgrade, set datfrozenxid and datminmxid.\n);
! appendPQExpBuffer(buf, UPDATE pg_catalog.pg_database 
! SET datfrozenxid = '%u', datminmxid = '%u' 
!   WHERE datname = ,
!   dbfrozenxid, dbminmxid);
! appendStringLiteralConn(buf, dbname, conn);
! appendPQExpBufferStr(buf, ;\n);
! 			}
  		}
  
  		if (!skip_acls 
--- 1417,1433 
  
  			appendPQExpBufferStr(buf, ;\n);
  
! 		}
! 
! 		if (binary_upgrade)
! 		{
! 			appendPQExpBufferStr(buf, -- For binary upgrade, set datfrozenxid and datminmxid.\n);
! 			appendPQExpBuffer(buf, UPDATE pg_catalog.pg_database 
! 			SET datfrozenxid = '%u', datminmxid = '%u' 
! 			  WHERE datname = ,
! 			  dbfrozenxid, dbminmxid);
! 			appendStringLiteralConn(buf, dbname, conn);
! 			appendPQExpBufferStr(buf, ;\n);
  		}
  
  		if (!skip_acls 

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers