Stephan Szabo <[EMAIL PROTECTED]> writes:
> In addition, how should the locks be granted for a sequence like:
> T1: get shared lock on row A
> T2: get exclusive lock on row A
> T3: get shared lock on row A
> Does T3 get the lock or not? If it does, then you have the possibility of
> freezing ou
On Sun, 7 Dec 2003, Greg Stark wrote:
> It's not strictly necessary to have a list of all xids at all. The normal
> "shared read lock" is just "take the write lock, increment the readers
> counter, unlock" Anyone who wants to write has to wait (using, eg, a condition
> variable) until the readers
> Greg Stark wrote:
>> This gets the right semantics but without the debugging info of a list of
>> lockers. Other than debugging the only advantage I see to having the list of
>> lockers is for deadlock detection. Is that absolutely mandatory?
No, deadlock detection is not optional.
Mike Mascari
Greg Stark wrote:
> It's not strictly necessary to have a list of all xids at all. The normal
> "shared read lock" is just "take the write lock, increment the readers
> counter, unlock" Anyone who wants to write has to wait (using, eg, a condition
> variable) until the readers count goes to 0.
>
>
It's not strictly necessary to have a list of all xids at all. The normal
"shared read lock" is just "take the write lock, increment the readers
counter, unlock" Anyone who wants to write has to wait (using, eg, a condition
variable) until the readers count goes to 0.
This gets the right semantic
Jeff Davis wrote:
> The way I understand it, is that you're having trouble storing all of
> the xids in the row; right now you just store one and mark it "locked".
> If you were able to store several, but not necessarily all xids in all
> cases, wouldn't that be a big improvement? The xids not in t
> As I remember the implementation problem is that we do an exclusive row
> lock right now by putting the transaction id on the row and set a
> special row-lock bit in the tuple. Shared locks need to store multiple
> transaction ids, and that is where we are stuck. Shared memory is of
> finite s
Greg Stark wrote:
>
> Dr NoName <[EMAIL PROTECTED]> writes:
>
> > My question is why??? The two insert operations do not
> > conflict with each other (at least not in the
> > real-world situation). Also, why does the foreign key
> > make a difference?
>
> It's not locking the whole table, it's l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -- Dr NoName <[EMAIL PROTECTED]> wrote:
> Help!
you may look in the archives; one day ago there was the same question.
Ciao
Alvar
- --
** Alvar C.H. Freude -- http://alvar.a-blast.org/ -- http://odem.org/
** Berufsverbot? http://odem.org
Help!
I have a table that multiple processes must be able to
write to concurrently. However, it for some reason
gets locked in exclusive mode. I narrowed it down to
one SQL statement + some weirdness with foreign keys.
To debug this, I opened two psql sessions and typed in
the sql statements manua
> The deferred foreign key checks are exactly
> what I needed. They are quite useful for other reasons
> too.
I believe Postgres is just following standards.
Yes, deferred is very useful for other things, like a real data model layer
mediating between UI and database--without it you have to worry
Dr NoName wrote:
If you cannot make your transactons shorter (and
please don't tell me
that you have user interaction going on while
holding any open
transactions), then you might be able to increase
your concurrency by
deferring the foreign key check until commit.
oh! my! gawd!!!
THANK YOU! Th
> If you cannot make your transactons shorter (and
> please don't tell me
> that you have user interaction going on while
> holding any open
> transactions), then you might be able to increase
> your concurrency by
> deferring the foreign key check until commit.
oh! my! gawd!!!
THANK YOU! The d
> If you cannot make your transactons shorter (and
> please don't tell me
> that you have user interaction going on while
> holding any open
> transactions), then you might be able to increase
> your concurrency by
> deferring the foreign key check until commit.
oh! my! gawd!!!
THANK YOU!
> My question is why??? The two insert operations do not
> conflict with each other (at least not in the
> real-world situation). Also, why does the foreign key
> make a difference?
I don't know if this would help, but given the other explanations you've
gotten I would try setting the foreign key
15 matches
Mail list logo
