On 4/1/07, Tom Lane [EMAIL PROTECTED] wrote:
Good point. I'm envisioning a procarray.c function along the
lines of
bool TransactionHasSnapshot(xid)
which returns true if the xid is currently listed in PGPROC
and has a nonzero xmin. CIC's cleanup wait loop would check
this and ignore
Pavan Deolasee [EMAIL PROTECTED] writes:
When I looked at the code, it occurred to me that possibly we are
OK with just taking shared lock on the procarray. That means that
some other transaction can concurrently set its serializable snapshot
while we are scanning the procarray. But that
On 4/11/07, Tom Lane [EMAIL PROTECTED] wrote:
[ itch... ] The problem is with time-extended execution of
GetSnapshotData; what happens if the other guy lost the CPU for a good
long time while in the middle of GetSnapshotData? He might set his
xmin based on info you saw as long gone.
You
Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
Good point. I'm envisioning a procarray.c function along the
lines of
bool TransactionHasSnapshot(xid)
which returns true if the xid is currently listed in PGPROC
and has a nonzero xmin. CIC's cleanup wait loop would check
Pavan Deolasee [EMAIL PROTECTED] writes:
If you haven't finished this yet, would you like me to work
on this ? If I do it, I would mostly follow the path you
suggested above, unless I run into something else.
I'm not intending to work on it.
regards, tom lane
On Sat, 2007-03-31 at 17:45 +0530, Pavan Deolasee wrote:
Isn't CREATE INDEX CONCURRENTLY prone deadlock conditions ?
I saw one with VACUUM today. But I think it can happen with other
commands like VACUUM FULL, CLUSTER, CREATE INDEX
CONCURRENTLY and so on. These commands conflict on the
Pavan Deolasee [EMAIL PROTECTED] writes:
Isn't CREATE INDEX CONCURRENTLY prone deadlock conditions ?
Can you give a specific example? The deadlock code will grant locks
out-of-order in cases where the alternative is to abort somebody.
I think you may be describing a missed opportunity in that
On 3/31/07, Tom Lane [EMAIL PROTECTED] wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
Isn't CREATE INDEX CONCURRENTLY prone deadlock conditions ?
Can you give a specific example?
txn1 - CREATE INDEX CONCURRENTLY (takes ShareUpdateExclusiveLock)
txn2 - VACUUM ANALYZE (waits on
Pavan Deolasee [EMAIL PROTECTED] writes:
On 3/31/07, Tom Lane [EMAIL PROTECTED] wrote:
Can you give a specific example?
txn1 - CREATE INDEX CONCURRENTLY (takes ShareUpdateExclusiveLock)
txn2 - VACUUM ANALYZE (waits on ShareUpdateExclusiveLock)
tnx1 - waits for txn2 to complete in the second
On 3/31/07, Tom Lane [EMAIL PROTECTED] wrote:
Hmm ... only if it's already set inVacuum true ... there's a window
where it has not.
I wonder whether we could change CIC so that the reference
snapshot lists only transactions that are running and have already
determined their serializable
Pavan Deolasee [EMAIL PROTECTED] writes:
Yes, it may work. Do we need to take some extra care because
proc-xmin is set while holding SHARED lock on proc array ?
Good point. I'm envisioning a procarray.c function along the
lines of
bool TransactionHasSnapshot(xid)
which returns true if
11 matches
Mail list logo
