Heikki Linnakangas <hlinnakan...@vmware.com> writes:
> pg_stat_statements (re-)initializes spinlocks as part of normal
> operation. With --disable-spinlock, spinlocks are implemented using
> semaphores, and semaphores are expected to be created at postmaster
> startup. Hence, you get an assertion failure:
> postgres=# select * from pg_stat_statements ;
> The connection to the server was lost. Attempting reset: Failed.
> !>
> TRAP: FailedAssertion("!(!IsUnderPostmaster)", File: "pg_sema.c", Line: 326)
> Even if that worked, re-initializing a spinlock with SpinLockInit, like
> pg_stat_statement does, would always allocate a new semaphore, so you
> would run out very quickly.
You'd run out even without that, since we're only leaving a dozen or two
extra semaphores available, and this code wants a spinlock per hash
entry.
I think that we can probably write this off as an unsupported
combination. If you're running without real spinlocks, any sort of
performance optimization is a complete waste of time until you fix that,
so what's the point of using pg_stat_statements?
Having said that, though, I agree that assuming that spinlocks can be
reinitialized is being overly intimate with the implementation details.
It's not too hard to imagine it failing with some future version of
spinlocks, even disregarding the rather dubious assumption that no two
processes would be touching the new entry at about the same time.
We should probably try to find a way of avoiding that.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
