From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Darcy Buskermolen <darcy(at)wavefire(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Foreign key trigger timing bug? |
Date: | 2005-12-07 17:46:22 |
Message-ID: | 200512071746.jB7HkMq06194@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
I think this is the foreign key trigger timing issue.
---------------------------------------------------------------------------
Darcy Buskermolen wrote:
> On Friday 09 September 2005 08:46, Stephan Szabo wrote:
> > On Fri, 9 Sep 2005, Tom Lane wrote:
> > > Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> > > > Is there a case other than a before trigger updating a row we will want
> > > > to act upon later in the statement where we'll get a row with xmax of
> > > > our transaction and cmax greater than the current command?
> > >
> > > The greater-cmax case could occur via any kind of function, not only a
> > > trigger, ie
> > >
> > > update tab set x = foo(x) where ...
> > >
> > > where foo() is a volatile function that internally updates the tab
> > > table.
> >
> > I *thought* I was missing a case, I just couldn't figure out what.
> >
> > > I suppose you could say that this is horrible programming practice and
> > > anyone who tries it deserves whatever weird behavior ensues ... but
> > > it's not the case that every such situation involves a trigger.
> >
> > Well, the change I was thinking of would have made it an error if foo(x)
> > updated a row that was then later selected by the update rather than the
> > current behavior which I think would have ignored the already updated row,
> > so that's probably not going to work.
>
> I see that this still is not addressed fulling in beta 3. Can anybody give a
> quick overview of where this is sitting, and if it's likely to make it's way
> into 8.1 gold ?
>
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/docs/faq
>
> --
> Darcy Buskermolen
> Wavefire Technologies Corp.
>
> http://www.wavefire.com
> ph: 250.717.0200
> fx: 250.763.1759
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Jochem van Dieten | 2005-12-07 18:01:35 | Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing |
Previous Message | Bruce Momjian | 2005-12-07 17:33:04 | Foreign key trigger timing bug? |
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Seltenreich | 2005-12-07 19:48:00 | Re: TODO item -- Improve psql's handling of multi-line queries |
Previous Message | Simon Riggs | 2005-12-07 17:40:56 | Re: Skipping VACUUM of indexes when no work required |