PostgreSQL Bugs - Re: BUG #2033: Assertion Failure: File: "procarray.c",

Author

Re: BUG #2033: Assertion Failure: File: "procarray.c",

Joel Stevenson

2005-11-09, 1:24 pm

Sorry, I realize this bug is a little lean on details.

PG is set up to serve multiple concurrent processes in a work queue
fashion, therefore these processes are in contention for the same
resources as the queue is basically a FIFO and I'm using SELECT ...
FOR UPDATE NOWAIT in each client to grab the next work segment in
line.

I've been running the setup on 8.1b3 and 8.1RC1 without this
particular Assertion failure, but had not been using the NOWAIT flag
until today. During a period of perhaps 20 processes operating on
the queue it looks like postgres failed this assertion 17 times, the
first coming very shortly after the processes began and the rest
following in quick succession.

I do have the core files if further info is needed from them.

Thanks,
Joel

At 3:19 PM +0000 11/9/05, Joel Stevenson wrote:
>The following bug has been logged online:
>
>Bug reference: 2033
>Logged by: Joel Stevenson
>Email address: joelstevenson@mac.com
>PostgreSQL version: 8.1.0
>Operating system: RHEL 3 update 6
>Description: Assertion Failure: File: "procarray.c", Line: 492
>Details:
>
>Hi,
>
>I'm running into an Assertion failure this morning w/8.1.0. I believe it is
>related to using the NOWAIT flag. Here is the log message:
>
>TRAP: FailedAssertion("!(serializable ? !((MyProc->xmin) != ((TransactionId)
>0))
> : ((MyProc->xmin) != ((TransactionId) 0)))", File: "procarray.c", Line:
>492)
>
>
>Postgres was configured using both --enable-debug and --enable-cassert.
>Full config options were:
>
>./configure CFLAGS=-O2 -pipe --with-perl --with-openssl
>--enable-thread-safety --enable-debug --enable-cassert
>--with-includes=/usr/kerberos/include
>
>Some non-default postgresql.conf params:
>max_connections = 150
>ssl = on
>shared_buffers = 4000
>work_mem = 102400
> maintenance_work_mem
= 131072
>max_stack_depth = 4096
>commit_delay = 100
>checkpoint_segments = 5
> effective_cache_size
= 173015
> stats_start_collecto
r = on
> stats_command_string
= on
>stats_block_level = on
>stats_row_level = on
> stats_reset_on_serve
r_start = on
>autovacuum = on
> autovacuum_analyze_s
cale_factor = 0.1
>
>I've removed the 'NOWAIT' for the time being, but thought I should mention
>the issue.
>
>Thanks,
>Joel
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Jim C. Nasby

2005-11-09, 1:24 pm

A backtrace from one of the cores would be a good start.

On Wed, Nov 09, 2005 at 07:44:01AM -0800, Joel Stevenson wrote:
> Sorry, I realize this bug is a little lean on details.
>
> PG is set up to serve multiple concurrent processes in a work queue
> fashion, therefore these processes are in contention for the same
> resources as the queue is basically a FIFO and I'm using SELECT ...
> FOR UPDATE NOWAIT in each client to grab the next work segment in
> line.
>
> I've been running the setup on 8.1b3 and 8.1RC1 without this
> particular Assertion failure, but had not been using the NOWAIT flag
> until today. During a period of perhaps 20 processes operating on
> the queue it looks like postgres failed this assertion 17 times, the
> first coming very shortly after the processes began and the rest
> following in quick succession.
>
> I do have the core files if further info is needed from them.
>
> Thanks,
> Joel
>
>
> At 3:19 PM +0000 11/9/05, Joel Stevenson wrote:
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane

2005-11-09, 8:24 pm

Joel Stevenson <joelstevenson@mac.com> writes:
> I've been running the setup on 8.1b3 and 8.1RC1 without this
> particular Assertion failure, but had not been using the NOWAIT flag
> until today. During a period of perhaps 20 processes operating on
> the queue it looks like postgres failed this assertion 17 times, the
> first coming very shortly after the processes began and the rest
> following in quick succession.

BTW, I imagine that the apparent correlation to NOWAIT is occurring
because your client-side code was not checking to see if the NOWAIT
query had failed before trying to launch another query in the same
transaction.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Sponsored Links