> > > I doubt if it's a bug of SELECT. Well what
> > > 'concurrent UPDATE then SELECT FOR UPDATE +
> > > SELECT' return ?
> >
> > I'm going to add additional check to heapgettup and
> > heap_fetch:
>
> SELECT seems to be able to return a different result
> from that of preceding SELECT FOR UPDATE
> > >> I assume this is not possible in 7.1?
> > >
> > >Just looked in heapam.c - I can fix it in two hours.
> > >The question is - should we do this now?
> > >Comments?
> >
> > It's a bug; how confident are you of the fix?
95% -:)
> I doubt if it's a bug of SELECT. Well what
> 'concurrent UPDAT
> >Reported problem is caused by bug (only one tuple version must be
> >returned by SELECT) and this is way to fix it.
> >
>
> I assume this is not possible in 7.1?
Just looked in heapam.c - I can fix it in two hours.
The question is - should we do this now?
Comments?
Vadim
---
> > I don't think that we dare try to make any basic changes in
> > MVCC for 7.1 at this late hour, so Forest is going to have
> > to live with that answer for awhile. But I would like to see
> > a cleaner answer in future releases.
>
> Is it the MVCC's restriction that each query inside a functi
> I would like to insert a bunch of rows in a table in a
> transaction. Some of
> the insertions will fail due to constraints violation. When
> this happens,
> Postgres automatically ends the transaction and rolls back
> all the previous
> inserts. I would like to continue the transaction and i
> > Just out of curiousity, does Postgres support nested transactions?
>
> I'd like to know too, and not just out of curiousity. I have
> a use for that.
Hopefully, savepoints will be available in 7.2 and give required
functionality.
Vadim
Try this for both FK tables:
create table tmp2(idx2 int4, col2 int4, constraint
tmpcon2 foreign key(col2) references tmp1(idx) INITIALLY DEFERRED);
This will defer constraint checks till transaction commit...
though constraint triggers should use SnapshotDirty instead of
SELECT FOR UPDATE anyway
Use
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
inside BEGIN/END block. Default is READ COMMITTED.
Vadim
>
> It appears that postgres 7.0 does not support repeatable read for
> transaction isolation. Is this planned? If so, when?
>
> -Michael
> _
> Is it true that SELECT ... FOR UPDATE only acquires a ROW
> SHARE MODE lock, and that it isn't self-conflicting?
SELECT FOR UPDATE acquires ROW SHARE LOCK on *table* level.
But rows returned by SELECT FOR UPDATE is locked *exclusively*
- so any other transaction which tries to mark the same
> Yeah, a scan over just the index itself would be a perfect way to
^
I believe that Oracle updates index statistic on-fly...
Meta-page is always in cache for inserts, so there will be no
additional reads.
> gather stats. The normal objection to it (can't
> > Oracle has index keys distribution page... And we have near empty
> > meta-page for each index AM... And backend reads this page for
> > each insert...
>
> That certainly would make sense. We have hesitated to gather more
> statistics because of the time involved. Fuller statistics
> on ju
> For example we could count up distinct values for the first
> column of an index by scanning its index relation.
Oracle has index keys distribution page... And we have near empty
meta-page for each index AM... And backend reads this page for
each insert...
Vadim
12 matches
Mail list logo
