Re: Postgres concurrency : urgent
От | Vadim Mikheev |
---|---|
Тема | Re: Postgres concurrency : urgent |
Дата | |
Msg-id | 382BAA56.DE0D051B@krs.ru обсуждение исходный текст |
Ответ на | Re: Postgres concurrency : urgent ("V Krishnaraj" <kimi@intercept.co.in>) |
Список | 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 по дате отправления: