hi,
> YAMAMOTO Takashi <yamt@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
