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

Re: Bug #514: Backend crashes periodically

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Warren Volz" <wrv(at)po(dot)cwru(dot)edu>, <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Bug #514: Backend crashes periodically
Date: 2001-11-14 13:51:30
Message-ID: EKEJJICOHDIEMGPNIFIJGEJJFOAA.Inoue@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-bugs
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> 
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > What I meant is
> >   Session 2 invokes the session_del rule and really
> >   updates a sis_user row by the rule though it deletes
> >   no session row.
> 
> Hmmm ... that's an ugly thought, isn't it?  And I'm not sure there's
> anything we can do to defend against it.  If both sessions are executing
> the UPDATE at the same time, then neither can possibly know that the
> other is about to do a DELETE.  So the UPDATE will happen twice, which
> is harmless in the given scenario but would be decidedly not so if the
> UPDATE were changing some sort of total or balance.

Yes it seems a pretty serious problem.
The problem is that session 2 sees a not yet deleted( by session 1)
session row and an already updated( by session 1) sis_user row at
the same time. There's no such snapshot that could see both rows.

How do you think about the following query ?

  update sis_user set last_visit = session.last_access_time
  where sis_user_id = session.sis_user_id
  and session.session_key = 'zzz';

UPDATE acquires row level locks on the target sis_user rows
but doesn't acuiqre any row level lock on the related session
rows. Could it guarantee the consistency of the query ?

regards,
Hiroshi Inoue

In response to

Responses

pgsql-bugs by date

Next:From: Alexei BarantsevDate: 2001-11-14 13:51:56
Subject: UPDATE bug in PostgreSQL-7.1.3
Previous:From: Thomas LockhartDate: 2001-11-14 07:38:40
Subject: Re: Problem with 7.1.3 and -DUSE_AUSTRALIAN_RULES

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