Re: [HACKERS] Re: Hot standby v5 patch - Databases created post backup remain inaccessible + replica SIGSEGV when coming out of standby
Simon Riggs wrote:
On Tue, 2008-11-04 at 18:33 +1300, Mark Kirkwood wrote:
postgres=# \l
List of databases
Name| Owner | Encoding | Collation | Ctype | Access
Privileges
---+--+---+---+---+-
bench | postgres | SQL_ASCII | C | C |
postgres | postgres | SQL_ASCII | C | C |
template0 | postgres | SQL_ASCII | C | C |
{=c/postgres,postgres=CTc/postgres}
template1 | postgres | SQL_ASCII | C | C |
{=c/postgres,postgres=CTc/postgres}
(4 rows)
postgres=# \c bench
FATAL: database bench does not exist
Previous connection kept
CREATE DATABASE didn't trigger the db flat file update, code for which
existed and was triggered in the cases when a transaction would normally
rebuild the flat files. Simple fix, but stupid oversight.
Spotted another problem which is that BuildFlatFile may not be built
consistently if a rebuild is triggered prior to us reaching the recovery
consistency point. This is fixed by forcing a rebuild of the flat files
when we hit the recovery point.
Both one line changes, but I'll go looking for other issues there.
Patching with v5d lets me access the newly created database, another one
down!
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: Hot standby v5 patch - Databases created post backup remain inaccessible + replica SIGSEGV when coming out of standby
On Tue, 2008-11-04 at 09:52 +, Simon Riggs wrote: postgres=# \c bench FATAL: database bench does not exist Previous connection kept CREATE DATABASE didn't trigger the db flat file update, code for which existed and was triggered in the cases when a transaction would normally rebuild the flat files. Simple fix, but stupid oversight. Issue resolved. Spotted another problem which is that BuildFlatFile may not be built consistently if a rebuild is triggered prior to us reaching the recovery consistency point. This is fixed by forcing a rebuild of the flat files when we hit the recovery point. Issue resolved. Both one line changes, but I'll go looking for other issues there. I also mentioned previously that I hadn't implemented locking yet during flat file updates. After spending longer looking at the code around this I no longer think it is required. These changes will be rolled into the next patch version, soon. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
