Greg Stark <[EMAIL PROTECTED]> writes:
> I don't know the details, but with postgres's model wouldn't it be a simply
> matter of treating every tuple found as having been inserting or deleted
> without checking to see if the transaction id in the tuple is committed?
No. At least not if you want a
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On 25 Aug 2004, Greg Stark wrote:
>
> > It's only allowed when the transaction is in READ UNCOMMITTED isolation level.
> > Something Postgres doesn't currently support. In fact I'm not aware of any SQL
> > database that supports it, though I'm sure t
On Wed, Aug 25, 2004 at 05:10:30PM -0400, Bruce Momjian wrote:
> Christopher Kings-Lynne wrote:
> > > OK, TODO updated:
> > >
> > > * Implement dirty reads or shared row locks and use them in RI triggers
> >
> > Can someone explain to me what a dirty read is and how it relates to RI
> > triggers
Christopher Kings-Lynne wrote:
> > OK, TODO updated:
> >
> > * Implement dirty reads or shared row locks and use them in RI triggers
>
> Can someone explain to me what a dirty read is and how it relates to RI
> triggers?
Dirty read allows you to see uncommited rows. I think RI triggers need
it
On 25 Aug 2004, Greg Stark wrote:
> It's only allowed when the transaction is in READ UNCOMMITTED isolation level.
> Something Postgres doesn't currently support. In fact I'm not aware of any SQL
> database that supports it, though I'm sure there's one somewhere.
Looks like mysql also supports it
On 8/25/2004 1:32 AM, Greg Stark wrote:
A dirty read is a read that includes data that hasn't been committed yet. Or
as the SQL 92 standard puts it:
[...]
It could also be useful for referential integrity checks since, for example,
it would let you see if someone has deleted the referenced record b
On Wed, 25 Aug 2004, Mark Kirkwood wrote:
>
>
> Greg Stark wrote:
>
> > It's only allowed when the transaction is in READ UNCOMMITTED
> > isolation level.
> >
> >Something Postgres doesn't currently support. In fact I'm not aware of any SQL
> >database that supports it, though I'm sure there's one
On Wed, 25 Aug 2004 03:54 pm, Mark Kirkwood wrote:
> Greg Stark wrote:
> > It's only allowed when the transaction is in READ UNCOMMITTED
> > isolation level.
> >
> >Something Postgres doesn't currently support. In fact I'm not aware of any
> > SQL database that supports it, though I'm sure there's
Greg Stark wrote:
It's only allowed when the transaction is in READ UNCOMMITTED
isolation level.
Something Postgres doesn't currently support. In fact I'm not aware of any SQL
database that supports it, though I'm sure there's one somewhere.
FYI - DB2 supports this isolation level, I don't kn
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > OK, TODO updated:
> > * Implement dirty reads or shared row locks and use them in RI triggers
>
> Can someone explain to me what a dirty read is and how it relates to RI
> triggers?
A dirty read is a read that includes data that hasn't bee
OK, TODO updated:
* Implement dirty reads or shared row locks and use them in RI triggers
Can someone explain to me what a dirty read is and how it relates to RI
triggers?
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to
Richard Huxton <[EMAIL PROTECTED]> writes:
> ... Don't forget having to deal with a backend dying without being able to
> decrement the count (not my idea, Bruce (iirc) mentioned it last time
> this was discussed). I think at the least you'd need a
> max-trans-id-with-lock number stored next to
Christopher Kings-Lynne wrote:
> > I think the speed complaint I was just raising could possibly be
> > answered by setting an infomask bit indicating that the row might
> > be present in a separate table of active row locks. (I'm not sure
> > how the bit would get cleared without race conditions,
Richard Huxton wrote:
> Christopher Kings-Lynne wrote:
> >> Uh ... the interesting question is usually not "does this backend hold
> >> any row locks", it is "is this row locked by any backends". If the
> >> latter question is not *exceedingly* cheap to answer, at least in the
> >> normal case whe
Christopher Kings-Lynne wrote:
Uh ... the interesting question is usually not "does this backend hold
any row locks", it is "is this row locked by any backends". If the
latter question is not *exceedingly* cheap to answer, at least in the
normal case where the answer is no, you don't have a workab
I think the speed complaint I was just raising could possibly be
answered by setting an infomask bit indicating that the row might
be present in a separate table of active row locks. (I'm not sure
how the bit would get cleared without race conditions, but let's
suppose that can be done.) A little
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Tue, 24 Aug 2004, Christopher Kings-Lynne wrote:
>> OK, what I mean is to know if a row is locked by any backend, why can't
>> we just put a reference count of the number of locks on that row,
>> instead of recording each backend separately? Wouldn't
On Tue, 24 Aug 2004, Christopher Kings-Lynne wrote:
> > Uh ... the interesting question is usually not "does this backend hold
> > any row locks", it is "is this row locked by any backends". If the
> > latter question is not *exceedingly* cheap to answer, at least in the
> > normal case where th
Uh ... the interesting question is usually not "does this backend hold
any row locks", it is "is this row locked by any backends". If the
latter question is not *exceedingly* cheap to answer, at least in the
normal case where the answer is no, you don't have a workable solution,
because you'll be
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> ie. why can't we just record the number of locks each backend has, sort
> of, and use a reference counting sort of method. Per-backend in case
> the backend dies and we need to discount those locks..?
Uh ... the interesting question is usual
pg_subtrans is trivial to index --- it's a linear array subscripted by
TransactionId. I'm not sure what we'd do to handle row locks, which
would need a key like (DBoid, RELoid, BlockNum, LineNum) and would be
extremely non-dense in that space.
'Tis something to think about though...
I've been thin
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Just random speculation, but could we use a pg_subtrans-like setup to do
> row share locks?
pg_subtrans is trivial to index --- it's a linear array subscripted by
TransactionId. I'm not sure what we'd do to handle row locks, which
would need
Just random speculation, but could we use a pg_subtrans-like setup to do
row share locks?
ie. Store them in a sort of table to avoid the problems with limited
shared memory size?
Chris
Tom Lane wrote:
Log Message:
---
Rearrange pg_subtrans handling as per recent discussion. pg_subtrans
23 matches
Mail list logo
