hi, >>> (6) Does the application continue to run relatively sanely, or >>> does it fall over at this point? >> >> my application just exits on the error. >> >> if i re-run the application without rebooting postgres, it seems >> that i will get the error sooner than the first run. (but it might >> be just a matter of luck) > > If your application hits this again, could you check pg_stat_activity > and pg_locks and see if any SIReadLock entries are lingering after > the owning transaction and all overlapping transactions are > completed? If anything is lingering between runs of your > application, it *should* show up in one or the other of these.
this is 71ac48fd9cebd3d2a873635a04df64096c981f73 with your two patches. this psql session was the only activity to the server at this point. hoge=# select * from pg_stat_activity; -[ RECORD 1 ]----+-------------------------------- datid | 16384 datname | hoge procpid | 7336 usesysid | 10 usename | takashi application_name | psql client_addr | client_hostname | client_port | -1 backend_start | 2011-03-26 12:28:21.882226+09 xact_start | 2011-03-28 11:55:19.300027+09 query_start | 2011-03-28 11:55:19.300027+09 waiting | f current_query | select * from pg_stat_activity; hoge=# select count(*) from pg_locks where mode='SIReadLock'; -[ RECORD 1 ] count | 7057 hoge=# select locktype,count(*) from pg_locks group by locktype; -[ RECORD 1 ]-------- locktype | virtualxid count | 1 -[ RECORD 2 ]-------- locktype | relation count | 1 -[ RECORD 3 ]-------- locktype | tuple count | 7061 hoge=# > >>> (7) The message hint would help pin it down, or a stack trace at >>> the point of the error would help more. Is it possible to get >>> either? Looking over the code, it appears that the only places >>> that SSI could generate that error, it would cancel that >>> transaction with the hint "You might need to increase >>> max_pred_locks_per_transaction." and otherwise allow normal >>> processing. >> >> no message hints. these errors are not generated by SSI code, >> at least directly. > > Right, that's because we were using HASH_ENTER instead of > HASH_ENTER_NULL. I've posted a patch which should correct that. sure, with your patch it seems that they turned into different ones. PG_DIAG_SEVERITY: WARNING PG_DIAG_SQLSTATE: 53200 PG_DIAG_MESSAGE_PRIMARY: out of shared memory PG_DIAG_SOURCE_FILE: shmem.c PG_DIAG_SOURCE_LINE: 190 PG_DIAG_SOURCE_FUNCTION: ShmemAlloc PG_DIAG_SEVERITY: ERROR PG_DIAG_SQLSTATE: 53200 PG_DIAG_MESSAGE_PRIMARY: out of shared memory PG_DIAG_MESSAGE_HINT: You might need to increase max_pred_locks_per_transaction. PG_DIAG_SOURCE_FILE: predicate.c PG_DIAG_SOURCE_LINE: 2049 PG_DIAG_SOURCE_FUNCTION: CreatePredicateLock >>> Even with the above information it may be far from clear where >>> allocations are going past their maximum, since one HTAB could >>> grab more than its share and starve another which is staying below >>> its "maximum". I'll take a look at the possibility of adding a >>> warning or some such when an HTAB expands past its maximum size. > > I see from your later post that you are running with this patch. Has > that reported anything yet? i got nothing except the following one. (in the server log) WARNING: hash table "ShmemIndex" has more entries than expected DETAIL: The maximum was set to 32 on creation. YAMAMOTO Takashi > > Thanks, > > -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers