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 waiti
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
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 mak
"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 th
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
>
I got this on HEAD while doing lots of CREATE -> COPY -> DROP on table.
(...)
DEBUG: ProcessUtility
DEBUG: drop auto-cascades to toast table pg_toast.pg_toast_16774
DEBUG: drop auto-cascades to type pg_toast.pg_toast_16774
DEBUG: drop auto-cascades to index pg_toast.pg_toast_16774_index
DEBUG
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 effecti
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
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
> 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
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 VACUU
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 wha
12 matches
Mail list logo
