[COMMITTERS] pgsql: Cope with possible failure of the oldest MultiXact to exist.

2015-06-05 Thread Robert Haas
Cope with possible failure of the oldest MultiXact to exist. Recent commits, mainly b69bf30b9bfacafc733a9ba77c9587cf54d06c0c and 53bb309d2d5a9432d2602c93ed18e58bd2924e15, introduced mechanisms to protect against wraparound of the MultiXact member space: the number of multixacts that can exist at o

[COMMITTERS] pgsql: Cope with possible failure of the oldest MultiXact to exist.

2015-06-05 Thread Robert Haas
Cope with possible failure of the oldest MultiXact to exist. Recent commits, mainly b69bf30b9bfacafc733a9ba77c9587cf54d06c0c and 53bb309d2d5a9432d2602c93ed18e58bd2924e15, introduced mechanisms to protect against wraparound of the MultiXact member space: the number of multixacts that can exist at o

[COMMITTERS] pgsql: Cope with possible failure of the oldest MultiXact to exist.

2015-06-05 Thread Robert Haas
Cope with possible failure of the oldest MultiXact to exist. Recent commits, mainly b69bf30b9bfacafc733a9ba77c9587cf54d06c0c and 53bb309d2d5a9432d2602c93ed18e58bd2924e15, introduced mechanisms to protect against wraparound of the MultiXact member space: the number of multixacts that can exist at o

[COMMITTERS] pgsql: Fix incorrect order of database-locking operations in InitPostgr

2015-06-05 Thread Tom Lane
Fix incorrect order of database-locking operations in InitPostgres(). We should set MyProc->databaseId after acquiring the per-database lock, not beforehand. The old way risked deadlock against processes trying to copy or delete the target database, since they would first acquire the lock and the

[COMMITTERS] pgsql: Fix incorrect order of database-locking operations in InitPostgr

2015-06-05 Thread Tom Lane
Fix incorrect order of database-locking operations in InitPostgres(). We should set MyProc->databaseId after acquiring the per-database lock, not beforehand. The old way risked deadlock against processes trying to copy or delete the target database, since they would first acquire the lock and the

[COMMITTERS] pgsql: Fix incorrect order of database-locking operations in InitPostgr

2015-06-05 Thread Tom Lane
Fix incorrect order of database-locking operations in InitPostgres(). We should set MyProc->databaseId after acquiring the per-database lock, not beforehand. The old way risked deadlock against processes trying to copy or delete the target database, since they would first acquire the lock and the

[COMMITTERS] pgsql: Fix incorrect order of database-locking operations in InitPostgr

2015-06-05 Thread Tom Lane
Fix incorrect order of database-locking operations in InitPostgres(). We should set MyProc->databaseId after acquiring the per-database lock, not beforehand. The old way risked deadlock against processes trying to copy or delete the target database, since they would first acquire the lock and the

[COMMITTERS] pgsql: Fix incorrect order of database-locking operations in InitPostgr

2015-06-05 Thread Tom Lane
Fix incorrect order of database-locking operations in InitPostgres(). We should set MyProc->databaseId after acquiring the per-database lock, not beforehand. The old way risked deadlock against processes trying to copy or delete the target database, since they would first acquire the lock and the

[COMMITTERS] pgsql: Fix incorrect order of database-locking operations in InitPostgr

2015-06-05 Thread Tom Lane
Fix incorrect order of database-locking operations in InitPostgres(). We should set MyProc->databaseId after acquiring the per-database lock, not beforehand. The old way risked deadlock against processes trying to copy or delete the target database, since they would first acquire the lock and the

[COMMITTERS] pgsql: Get rid of a //-style comment.

2015-06-05 Thread Tom Lane
Get rid of a //-style comment. Not sure how "//XXX" got into a committed patch in the first place, as it's both content-free and against project style. pgindent made a bit of a hash of it, too. Going forward, we should have at least one buildfarm member using "gcc -ansi" to catch such things, at