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

Re: SSI bug?

From: yamt(at)mwd(dot)biglobe(dot)ne(dot)jp (YAMAMOTO Takashi)
To: Kevin(dot)Grittner(at)wicourts(dot)gov
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-25 02:48:07
Message-ID: 20110325024807.9AF9F19CE21@mail.netbsd.org (view raw or flat)
Thread:
Lists: pgsql-hackers
hi,

> YAMAMOTO Takashi <yamt(at)mwd(dot)biglobe(dot)ne(dot)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

In response to

pgsql-hackers by date

Next:From: Greg StarkDate: 2011-03-25 02:51:38
Subject: Re: 2nd Level Buffer Cache
Previous:From: Daniel FarinaDate: 2011-03-25 01:00:27
Subject: Avoiding timeline generation

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