From: yamt@mwd.biglobe.ne.jp
To: Kevin.Grittner@wicourts.gov
Cc: drkp@csail.mit.edu
Cc: heikki.linnakangas@enterprisedb.com
Cc: pgsql-hackers@postgresql.org
Subject: Re: SSI bug?
Date: Fri, 25 Mar 2011 02:48:07 +0000 (UTC)
Message-ID: <20110325024807.9AF9F19CE21@mail.netbsd.org> (raw)
In-Reply-To: <4D835508020000250003BAD2@gw.wicourts.gov>
References: <4D835508020000250003BAD2@gw.wicourts.gov>
hi,
> YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> wrote:
>
>> thanks for quickly fixing problems.
>
> Thanks for the rigorous testing. :-)
>
>> i tested the later version
>> (a2eb9e0c08ee73208b5419f5a53a6eba55809b92) and only errors i got
>> was "out of shared memory". i'm not sure if it was caused by SSI
>> activities or not.
>
>> PG_DIAG_SEVERITY: WARNING
>> PG_DIAG_SQLSTATE: 53200
>> PG_DIAG_MESSAGE_PRIMARY: out of shared memory
>> PG_DIAG_SOURCE_FILE: shmem.c
>> PG_DIAG_SOURCE_LINE: 190
>> PG_DIAG_SOURCE_FUNCTION: ShmemAlloc
>>
>> PG_DIAG_SEVERITY: ERROR
>> PG_DIAG_SQLSTATE: 53200
>> PG_DIAG_MESSAGE_PRIMARY: out of shared memory
>> PG_DIAG_SOURCE_FILE: dynahash.c
>> PG_DIAG_SOURCE_LINE: 925
>> PG_DIAG_SOURCE_FUNCTION: hash_search_with_hash_value
>
> Nor am I. Some additional information would help.
>
> (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)
> (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.
(please look at PG_DIAG_SOURCE_xxx in the above log.)
YAMAMOTO Takashi
> 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.
>
> -Kevin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: yamt@mwd.biglobe.ne.jp, Kevin.Grittner@wicourts.gov, drkp@csail.mit.edu, heikki.linnakangas@enterprisedb.com
Subject: Re: SSI bug?
In-Reply-To: <20110325024807.9AF9F19CE21@mail.netbsd.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox