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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
