Pavan Deolasee [EMAIL PROTECTED] writes:
Alternatively, we can just acquire AccessExclusiveLock on the main relation
before proceeding with the recursive deletion. That would solve this case,
but may be there are other similar deadlocks waiting to happen.
Surely we should be locking the
On Fri, May 16, 2008 at 1:17 PM, Gregory Stark [EMAIL PROTECTED] wrote:
Surely we should be locking the relation before even doing the dependency scan
or else someone else can come along and add more dependencies after we've
started the scan?
Yeah, that's indeed possible. I could make that
Pavan Deolasee escribió:
Also I am not sure if the issue is big enough to demand the change.
I think it is, effectively what we have now is your DDL could fail randomly
for reasons that are out of your control :(
Yeah. I think we better fix this, especially given the above mentioned
Gregory Stark [EMAIL PROTECTED] writes:
Pavan Deolasee [EMAIL PROTECTED] writes:
Alternatively, we can just acquire AccessExclusiveLock on the main relation
before proceeding with the recursive deletion. That would solve this case,
but may be there are other similar deadlocks waiting to
On Fri, May 16, 2008 at 5:24 AM, Jan Urbański
[EMAIL PROTECTED] wrote:
ERROR: deadlock detected
DETAIL: Process 25423 waits for AccessExclusiveLock on relation 16386 of
database 1; blocked by process 25428.
Process 25428 waits for AccessShareLock on relation 16390 of database
1;
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
When a heavy INSERT or UPDATE load on a table is occurring (lots of
quick INSERTs or UPDATEs within a single transaction), a VACUUM
ANALYZE (or just straight VACUUM) has a really good chance (10% or so)
of causing either the
Kevin Brown [EMAIL PROTECTED] writes:
I finally got 7.3.2 installed, and confirmed that the problem does not
exist on that version. So this is something that's limited to the
7.2.x tree. Which, I guess, means that it's not going to get fixed
for that tree (I assume that 7.2.x is effectively
I've been experimenting with Matthew T. O'Connor's pg_avd (auto vacuum
daemon), which is actually quite an interesting piece of software that
so far seems to function pretty well.
I've ported it to PG 7.2.4, which is the version I'm running on my
system, and experimenting with it has uncovered
Kevin Brown [EMAIL PROTECTED] writes:
When a heavy INSERT or UPDATE load on a table is occurring (lots of
quick INSERTs or UPDATEs within a single transaction), a VACUUM
ANALYZE (or just straight VACUUM) has a really good chance (10% or so)
of causing either the INSERT/UPDATE or the VACUUM to
Even dropping the table and all of its indexes and recreating it does
nothing to solve this problem, so I don't have any reason to suspect
corruption of the table itself. Corruption elsewhere is a
possibility, I suppose, but I haven't noticed any strangeness
elsewhere.
This sounds very
Tom Lane wrote:
Kevin Brown [EMAIL PROTECTED] writes:
When a heavy INSERT or UPDATE load on a table is occurring (lots of
quick INSERTs or UPDATEs within a single transaction), a VACUUM
ANALYZE (or just straight VACUUM) has a really good chance (10% or so)
of causing either the
11 matches
Mail list logo
