hi, > YAMAMOTO Takashi <y...@mwd.biglobe.ne.jp> wrote: > >> thanks for quickly fixing problems. > > Thanks for the rigorous testing. :-) > >> i tested the later version >> (a2eb9e0c08ee73208b5419f5a53a6eba55809b92) and only errors i got >> was "out of shared memory". i'm not sure if it was caused by SSI >> activities or not. > >> 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_SOURCE_FILE: dynahash.c >> PG_DIAG_SOURCE_LINE: 925 >> PG_DIAG_SOURCE_FUNCTION: hash_search_with_hash_value > > Nor am I. Some additional information would help. > > (1) Could you post the non-default configuration settings?
none. it can happen with just initdb+createdb'ed database. > (2) How many connections are in use in your testing? 4. > (3) Can you give a rough categorization of how many of what types > of transactions are in the mix? all transactions are SERIALIZABLE. no transactions are with READ ONLY. (but some of them are actually select-only.) > (4) Are there any long-running transactions? no. > (5) How many of these errors do you get in what amount of time? once it start happening, i see them somehow frequently. > (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) > (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. (please look at PG_DIAG_SOURCE_xxx in the above log.) YAMAMOTO Takashi > 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. > > -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
