To: Kevin.Grittner@wicourts.gov
Cc: drkp@csail.mit.edu, heikki.linnakangas@enterprisedb.com,
	pgsql-hackers@postgresql.org
Subject: Re: SSI bug?
In-Reply-To: Your message of "Fri, 18 Mar 2011 12:50:16 -0500"
	<4D835508020000250003BAD2@gw.wicourts.gov>
References: <4D835508020000250003BAD2@gw.wicourts.gov>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Message-Id: <20110325024807.9AF9F19CE21@mail.netbsd.org>
Date: Fri, 25 Mar 2011 02:48:07 +0000 (UTC)
From: yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)

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