max_standby_delay considered harmful
in [PgSql]
|
Prev: Further Hot Standby documentation required
Next: [HACKERS] Streaming replication - unable to stop the standby
From: Alvaro Herrera on 12 May 2010 15:36 Excerpts from Stefan Kaltenbrunner's message of mié may 12 15:10:28 -0400 2010: > the startup process has the following backtrace: > > (gdb) bt > #0 0x00007fbe24cb2c83 in select () from /lib/libc.so.6 > #1 0x00000000006e811a in pg_usleep () > #2 0x000000000048c333 in XLogPageRead () > #3 0x000000000048c967 in ReadRecord () > #4 0x0000000000493ab6 in StartupXLOG () > #5 0x0000000000495a88 in StartupProcessMain () > #6 0x00000000004ab25e in AuxiliaryProcessMain () > #7 0x00000000005d4a7d in StartChildProcess () > #8 0x00000000005d70c2 in PostmasterMain () > #9 0x000000000057d898 in main () I just noticed that we have some code assigning the return value of time() to a pg_time_t variable. Is this supposed to work reliably? (xlog.c lines 9267ff) -- -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 12 May 2010 15:40 On Wed, 2010-05-12 at 15:36 -0400, Alvaro Herrera wrote: > I just noticed that we have some code assigning the return value of > time() to a pg_time_t variable. Is this supposed to work reliably? > (xlog.c lines 9267ff) Code's used that for a while now. Checkpoints and everywhere. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 12 May 2010 15:51 On Wed, May 12, 2010 at 3:36 PM, Alvaro Herrera <alvherre(a)alvh.no-ip.org> wrote: > Excerpts from Stefan Kaltenbrunner's message of mié may 12 15:10:28 -0400 2010: > >> the startup process has the following backtrace: >> >> (gdb) bt >> #0 0x00007fbe24cb2c83 in select () from /lib/libc.so.6 >> #1 0x00000000006e811a in pg_usleep () >> #2 0x000000000048c333 in XLogPageRead () >> #3 0x000000000048c967 in ReadRecord () >> #4 0x0000000000493ab6 in StartupXLOG () >> #5 0x0000000000495a88 in StartupProcessMain () >> #6 0x00000000004ab25e in AuxiliaryProcessMain () >> #7 0x00000000005d4a7d in StartChildProcess () >> #8 0x00000000005d70c2 in PostmasterMain () >> #9 0x000000000057d898 in main () > > I just noticed that we have some code assigning the return value of > time() to a pg_time_t variable. Is this supposed to work reliably? > (xlog.c lines 9267ff) I' -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 12 May 2010 15:55 On Wed, May 12, 2010 at 3:51 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Wed, May 12, 2010 at 3:36 PM, Alvaro Herrera <alvherre(a)alvh.no-ip.org> wrote: >> Excerpts from Stefan Kaltenbrunner's message of mié may 12 15:10:28 -0400 2010: >> >>> the startup process has the following backtrace: >>> >>> (gdb) bt >>> #0 0x00007fbe24cb2c83 in select () from /lib/libc.so.6 >>> #1 0x00000000006e811a in pg_usleep () >>> #2 0x000000000048c333 in XLogPageRead () >>> #3 0x000000000048c967 in ReadRecord () >>> #4 0x0000000000493ab6 in StartupXLOG () >>> #5 0x0000000000495a88 in StartupProcessMain () >>> #6 0x00000000004ab25e in AuxiliaryProcessMain () >>> #7 0x00000000005d4a7d in StartChildProcess () >>> #8 0x00000000005d70c2 in PostmasterMain () >>> #9 0x000000000057d898 in main () >> >> I just noticed that we have some code assigning the return value of >> time() to a pg_time_t variable. Is this supposed to work reliably? >> (xlog.c lines 9267ff) > > I' I have a love-hate relationship with GMail, sorry. I am wondering if we are not correctly handling the case where we get a shutdown request while we are still in the PM_STARTUP state. It looks like we might go ahead and switch to PM_RECOVERY and then PM_RECOVERY_CONSISTENT without noticing the shutdown. There is some logic to handle the shutdown when the startup process exits, but if the startup process never exits it looks like we might get stuck. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 12 May 2010 17:34
On Wed, 2010-05-12 at 14:43 -0400, Robert Haas wrote: > I thought that it > would be a good idea for Simon to look at it because, on the surface, > it APPEARS to have something to do with Hot Standby, since that's what > Stefan was testing when he found it. He was also testing SR, yet you haven't breathed a word about that for some strange reason. It didn't APPEAR like it was HS at all, not from basic logic or from technical knowledge. So you'll have to forgive me if I don't leap into action when you say something is an HS problem in the future. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |