> > Incrementing comand counter is not enough - dirty reads are required
> > to handle concurrent PK updates.
> 
>     What's that with you and dirty reads? Every so often you tell
>     me that something would require them -  you  really  like  to
>     read dirty things - no? :-)

Dirty things occure - I like to handle them -:)
All MVCC stuff is just ability to handle dirties, unlike old,
locking, behaviour when transaction closed doors to table while
doing its dirty things. "Welcome to open world but be ready to
handle dirty things" -:)

>     So  let  me  get it straight: I execute the entire UPDATE SET
>     A=A+1, then increment the command counter and  don't  see  my
>     own  results?  So  an  index  scan with heap tuple check will
>     return OLD (+NEW?) rows? Last  time  I  fiddled  around  with
>     Postgres it didn't, but I could be wrong.

How are you going to see concurrent PK updates without dirty reads?
If two transactions inserted same PK and perform duplicate check at
the same time - how will they see duplicates if no one committed yet?
Look - there is very good example of using dirty reads in current
system: uniq indices, from where we started this thread. So, how uniq
btree handles concurrent (and own!) duplicates? Btree calls heap_fetch
with SnapshotDirty to see valid and *going to be valid* tuples with
duplicate key. If VALID --> ABORT, if UNCOMMITTED (going to be valid)
--> wait for concurrent transaction commit/abort (note that for
obvious reasons heap_fetch(SnapshotDirty) doesn't return OLD rows
modified by current transaction). I had to add all this SnapshotDirty
stuff right to get uniq btree working with MVCC. All what I propose now
is to add ability to perform dirty scans to SPI (and so to PL/*), to be
able make right decisions in SPI functions and triggers, and make those
decisions *at right time*, unlike uniq btree which makes decision
too soon. Is it clear now how to use dirty reads for PK *and* FK?

You proposed using share *row* locks for FK before. I objected then and
object now. It will not work for PK because of PK rows "do not exist"
for concurrent transactions. What would work here is *key* locks (locks
placed for some key in a table, no matter does row with this key exist
or not). This is what good locking systems, like Informix, use. But
PG is not locking system, no reasons to add key lock overhead, because
of PG internals are able to handle dirties and we need just add same
abilities to externals.

Vadim
 

Thu, 21 Jun 2001 10:50:31 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: RE: [BUGS] Update is not atomic
Mikheev, Vadim wrote:
>
> Dirty things occure - I like to handle them -:)
>

    Got it now - you're right. Thanks for your patience.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


Thu, 21 Jun 2001 14:13:53 -0400 (EDT)
Jan Wieck <JanWieck@Yahoo.com>
Re: RE: [BUGS] Update is not atomic
Jan Wieck wrote:
> 
> Mikheev, Vadim wrote:
> >
> > Dirty things occure - I like to handle them -:)
> >
> 
>     Got it now - you're right. Thanks for your patience.

But can we count on you (or Vadim) to actually fix this anytime soon ?

-------------
Hannu

Mon, 25 Jun 2001 14:52:02 +0200
Hannu Krosing <hannu@tm.ee>
Re: RE: [BUGS] Update is not atomic