On Wed, May 12, 2010 at 3:51 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, May 12, 2010 at 3:36 PM, Alvaro Herrera <alvherre@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