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: 4D8F54E6020000250003BD16@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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?

Thanks,

-Kevin

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-03-27 20:21:30 Re: Libpq PGRES_COPY_BOTH - version compatibility
Previous Message Magnus Hagander 2011-03-27 20:09:05 Re: Libpq PGRES_COPY_BOTH - version compatibility