Hot standby v5 patch - Databases created post backup remain inaccessible + replica SIGSEGV when coming out of standby

Поиск
Список
Период
Сортировка
От Mark Kirkwood
Тема Hot standby v5 patch - Databases created post backup remain inaccessible + replica SIGSEGV when coming out of standby
Дата
Msg-id 490FDEC2.8040303@paradise.net.nz
обсуждение исходный текст
Ответы Re: Hot standby v5 patch - Databases created post backup remain inaccessible + replica SIGSEGV when coming out of standby  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Hot standby v5 patch - Databases created post backup remain inaccessible + replica SIGSEGV when coming out of standby  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Another corner case:

1/ Setup master and replica with replica using pg_standby
2/ Create a new database (I used 'bench')
3/ Initialize the pgbench schema of size 100 in 'bench' (just to ensure 
the logs with the db creation get archived)
3/ Attempt to connect to 'bench' on the replica

Head from 2nd Nov with v5 patch applied on Freebsd 7.1-Prerelease as 
usual....


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


Not sure if this is related at all, but if the replica is then 
instructed to finish recovery via touching its trigger file, then we get:

DEBUG:  executing restore command "pg_standby -l -d -s 2 -t 
/tmp/pgsql.trigger.5439 /data0/pgarchive/8.4 00000001.history 
pg_xlog/RECOVERYHISTORY 000000000000000000000000 2>>standby.log"
DEBUG:  could not restore file "00000001.history" from archive: return 
code 0
DEBUG:  moving last restored xlog to "pg_xlog/000000020000000000000068"
LOG:  archive recovery complete
DEBUG:  Clear UnobservedXids
LOG:  clearing recovery locks
DEBUG:  reaping dead processes
LOG:  startup process (PID 4254) was terminated by signal 11: 
Segmentation fault
LOG:  aborting startup due to startup process failure
DEBUG:  proc_exit(1)
DEBUG:  shmem_exit(1)
DEBUG:  exit(1)

Using gdb:
#0  RelationClearRecoveryLocks () at inval.c:1702
1702            xl_rel_lock *lock = (xl_rel_lock *) lfirst(l);
(gdb) bt
#0  RelationClearRecoveryLocks () at inval.c:1702
#1  0x080d3849 in StartupXLOG () at xlog.c:5959
#2  0x080f1680 in AuxiliaryProcessMain (argc=2, argv=0xbfbfe6e8)   at bootstrap.c:421
#3  0x08214d4d in StartChildProcess (type=StartupProcess) at 
postmaster.c:4104
#4  0x0821725b in PostmasterMain (argc=1, argv=0xbfbfec50) at 
postmaster.c:1034
#5  0x081bfa7b in main (argc=1, argv=0xbfbfec50) at main.c:188


regards

Mark


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Kirkwood
Дата:
Сообщение: Hot standby v5 patch - restarted replica changes to warm standby mode
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: Enable pl/python to return records based on multiple OUT params