Michael <michael@gameservice.ru> writes:
> M> (gdb) bt
> M> #0 0x485dc277 in kill () from /lib/libc.so.7
> M> #1 0x485dc1d6 in raise () from /lib/libc.so.7
> M> #2 0x485dadda in abort () from /lib/libc.so.7
> M> #3 0x0824c075 in errfinish ()
> M> #4 0x0824c8b1 in elog_finish ()
> M> #5 0x081c9184 in s_lock ()
> M> #6 0x081c8d48 in LWLockAcquire ()
> M> #7 0x081c61ec in LockAcquire ()
> M> #8 0x081c4289 in LockRelationOid ()
> M> #9 0x080938fc in relation_open ()
> M> #10 0x08096d5a in index_open ()
> M> #11 0x08096139 in systable_beginscan ()
> M> #12 0x08134f10 in RelationBuildTriggers ()
> M> #13 0x08245d4d in RelationCacheInitializePhase2 ()
> M> #14 0x08256af0 in InitPostgres ()
> M> #15 0x081cfd13 in PostgresMain ()
> M> #16 0x081a90ec in ClosePostmasterPorts ()
> M> #17 0x081a9ea7 in PostmasterMain ()
> M> #18 0x0816912f in main ()
On closer look ... there is something awfully strange about this
backtrace. If it's gotten as far as RelationBuildTriggers, then this is
not the first spinlock acquisition in the life of this backend, nor the
first LWLockAcquire, nor even the first time to re-acquire a previously
released LWLock. Not to mention that the startup process must've
successfully done such things too. That seems to eliminate all of the
simple theories about how spinlocks might be broken.
How repeatable is this --- does it happen on every connection attempt,
or only sometimes? Can you start and stop the postmaster without
any problems being logged?
regards, tom lane