pg_stat_statements doesn't work with --disable-spinlocks

[Heikki Linnakangas]

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.

- Heikki


--
Sent via pgsql-bugs mailing list (pgsql...@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[Tom Lane]

Heikki Linnakangas <hlinna...@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