Skip site navigation (1) Skip section navigation (2)

Re: SSI bug?

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <yamt(at)mwd(dot)biglobe(dot)ne(dot)jp>
Cc: <drkp(at)csail(dot)mit(dot)edu>,<heikki(dot)linnakangas(at)enterprisedb(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI bug?
Date: 2011-03-27 20:16:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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?


pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-03-27 20:21:30
Subject: Re: Libpq PGRES_COPY_BOTH - version compatibility
Previous:From: Magnus HaganderDate: 2011-03-27 20:09:05
Subject: Re: Libpq PGRES_COPY_BOTH - version compatibility

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group