YAMAMOTO Takashi wrote:
> Kevin Grittner wrote:
>> (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)
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.
>> (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.
>> 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?
Thanks,
-Kevin
