Re: SSI bug?

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