Andrew, Tom,
I just did a test run using Andrew's patch with a database with over 400
objects. I didn't see any locks waiting during the entire run. So the
patch logic appears to work.
Note that it also shows up that some CONSTRAINT declarations really
shouldn't require an exclusive lock.
Josh Berkus wrote:
Andrew,
Do we have a final version of this patch yet? I have to do an upgrade
test run today, so it would be a good time to test it.
I'm working on an updated patch right now. But it is only cosmetically
different from the one I posted before. Functionally it's identi
Andrew,
Do we have a final version of this patch yet? I have to do an upgrade
test run today, so it would be a good time to test it.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
Andrew Dunstan writes:
> Tom Lane wrote:
>> ... Seems like it's nearly a one-liner fix, too.
> Well, what I have in mind is a bit bigger, but not large. See attached
> patch.
Hmm, you do need two instances of the loop, don't you? Might be
better to refactor along the lines of
if (has
Adnrew,
Well, what I have in mind is a bit bigger, but not large. See attached
patch.
I'll test it this weekend.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
Tom Lane wrote:
Andrew Dunstan writes:
What you're missing is that we need to compare the lockdeps of each item
(i.e. both the candidate item and the running item) with all the deps
(not just the lockdeps) of the other item. If neither item has any
lockdeps there will be no conflict. Thi
Andrew Dunstan writes:
> What you're missing is that we need to compare the lockdeps of each item
> (i.e. both the candidate item and the running item) with all the deps
> (not just the lockdeps) of the other item. If neither item has any
> lockdeps there will be no conflict. This will allow co
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
Doesn't that eliminate any chance of running two CREATE INDEXes
concurrently on the same table?
No, since neither of them will have any locking dependencies, which are
only for items that take an exclusive lock on th
Andrew Dunstan writes:
> Tom Lane wrote:
>> Doesn't that eliminate any chance of running two CREATE INDEXes
>> concurrently on the same table?
> No, since neither of them will have any locking dependencies, which are
> only for items that take an exclusive lock on the table(s), such as FK
> con
Tom Lane wrote:
Andrew Dunstan writes:
Yeah. I think the correct logic is roughly this: When considering if a
candidate item has a locking conflict with a running item, then if
*either* of them has a locking dependency that coincides with *any*
dependency of the other item, then the cand
Andrew Dunstan writes:
> Yeah. I think the correct logic is roughly this: When considering if a
> candidate item has a locking conflict with a running item, then if
> *either* of them has a locking dependency that coincides with *any*
> dependency of the other item, then the candidate is reject
Josh Berkus wrote:
Tom, Andrew,
Well, we certainly want to be able to run CREATE INDEXes in parallel,
so this would appear to require hard-wiring some conception of shared
versus exclusive lock into pg_restore. I think it might be a bit late
to consider that for 8.4.
I'm pretty sure I had
Tom, Andrew,
Well, we certainly want to be able to run CREATE INDEXes in parallel,
so this would appear to require hard-wiring some conception of shared
versus exclusive lock into pg_restore. I think it might be a bit late
to consider that for 8.4.
I'm pretty sure I had the logic for this co
Tom Lane wrote:
Andrew Dunstan writes:
We still have a little work to do on dependencies in parallel
pg_restore. The current test compares the candidate's locking
dependencies with those of the running jobs, and allows the candidate is
there isn't a match. That's not a broad enough test.
Andrew Dunstan writes:
> We still have a little work to do on dependencies in parallel
> pg_restore. The current test compares the candidate's locking
> dependencies with those of the running jobs, and allows the candidate is
> there isn't a match. That's not a broad enough test. The candidate
We still have a little work to do on dependencies in parallel
pg_restore. The current test compares the candidate's locking
dependencies with those of the running jobs, and allows the candidate is
there isn't a match. That's not a broad enough test. The candidate will
block if there's a curre
16 matches
Mail list logo
