Re: Postgres concurrency : urgent - Mailing list pgsql-general

From Vadim Mikheev
Subject Re: Postgres concurrency : urgent
Date
Msg-id 382BAA56.DE0D051B@krs.ru
Whole thread Raw
In response to Re: Postgres concurrency : urgent  ("V Krishnaraj" <kimi@intercept.co.in>)
List pgsql-general
V Krishnaraj wrote:
>
> After a few times, there lots of messages are spewed out in the postgres
> server log. A typical message looks like this.
> NOTICE: Message from PostgreSQL backend:
> The Postmaster has informed me that some other backend died abnormally a
> nd possibly corrupted shared memory.
> I have rolled back the current transaction and am going to terminate you
> r database system connection and exit.
> Please reconnect to the database system and repeat your query.

Typical messages are not interest ones -:)
Please find what backend exited with !0 code and was there
message before that or not. If there was no message about some
exceptional conditions then try to re-compile with CASSERT
enabled (configure --enable-cassert) or post to us gdb'
output for .../data/base/_your_database_/core file.

> 2. I'm surprised that select for update is not implemented. I looked at > the manual and it says this is implemented
inv 6.5.1. So also my  
> programs are behaving consistent with Select for Update (Giving
> conccurent access message on already locked rows).

Well, FOR UPDATE is not implemented for server side cursors.
But works for SELECT.

> 3.I'm not sure whether what I want is
> > > LOCK <<tablename>> IN ACCESS EXCLUSIVE MODE;
> I'll have to test this.
> What exactly I want is, I want the selects on transactions to wait till
> the main locking transaction updates and commits. I want to queue all
> requests in a serialzed fashion.

Vadim

pgsql-general by date:

Previous
From: "V Krishnaraj"
Date:
Subject: Re: Postgres concurrency : urgent
Next
From: Marcin Inkielman
Date:
Subject: Re: [GENERAL] Postgres concurrency : urgent