On 08.06.2011 03:16, Kevin Grittner wrote:
+ /*
+* It's OK to remove the old lock first because of the
ACCESS
+* EXCLUSIVE lock on the heap relation when this is
called. It is
+* desirable to do so
On 08.06.2011 14:18, Heikki Linnakangas wrote:
I just looked back
at your old email where you listed the different DDL operations, and
notice that we missed VACUUM FULL as well
(http://archives.postgresql.org/message-id/4dbd7e9102250003d...@gw.wicourts.gov).
I'll look into that.
Never mind
(sorry for repeatedly replying to self. I'll go for a coffee after this...)
On 08.06.2011 14:18, Heikki Linnakangas wrote:
Committed after adjusting that comment. I did a lot of other cosmetic
changes too, please double-check that I didn't screw up anything.
Also, it would be nice to have
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
(sorry for repeatedly replying to self. I'll go for a coffee after
this...)
That's so nice of you to try to make me feel better for the serious
brain fade I suffered yesterday. ;-)
On 08.06.2011 14:18, Heikki Linnakangas
On 06.06.2011 05:13, Kevin Grittner wrote:
Kevin Grittner wrote:
Maybe I should submit a patch without added complexity of the
scheduled cleanup and we can discuss that as a separate patch?
Here's a patch which adds the missing support for DDL.
It makes me a bit uncomfortable to do catalog
Heikki Linnakangas wrote:
It makes me a bit uncomfortable to do catalog cache lookups while
holding all the lwlocks. We've also already removed the reserved
entry for scratch space while we do that - if a cache lookup errors
out, we'll leave behind quite a mess. I guess it shouldn't fail,
Kevin Grittner wrote:
Heikki Linnakangas wrote:
I think the logic is actually wrong at the moment: When you
reindex a single index, DropAllPredicateLocksFromTableImpl() will
transfer all locks belonging to any index on the same table, and
any finer-granularity locks on the heap. It would
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
It makes me a bit uncomfortable to do catalog cache lookups while
holding all the lwlocks. We've also already removed the reserved entry
for scratch space while we do that - if a cache lookup errors out, we'll
leave behind quite
Tom Lane t...@sss.pgh.pa.us wrote:
If you don't believe that a catcache lookup will ever fail, I will
contract to break the patch.
As you probably know by now by reaching the end of the thread, this
code is going away based on Heikki's arguments; but for my
understanding, so that I don't
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
If you don't believe that a catcache lookup will ever fail, I will
contract to break the patch.
As you probably know by now by reaching the end of the thread, this
code is going away based on Heikki's
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
What am I missing?
Out-of-memory. Query cancel. The attempted catalog access
failing because it results in a detected deadlock. I could
probably think of several more if I spent ten minutes on it; and
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
We've also already removed the reserved entry for scratch space
This and Tom's concerns have me wondering if we should bracket the
two sections of code where we use the reserved lock target entry
with HOLD_INTERRUPTS() and
On 07.06.2011 20:03, Kevin Grittner wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote:
We've also already removed the reserved entry for scratch space
This and Tom's concerns have me wondering if we should bracket the
two sections of code where we use the reserved lock
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
It makes me a bit uncomfortable to do catalog cache lookups while
holding all the lwlocks.
I think I've caught up with the rest of the class on why this isn't
sane in DropAllPredicateLocksFromTableImpl, but I wonder about
On 07.06.2011 20:42, Kevin Grittner wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote:
It makes me a bit uncomfortable to do catalog cache lookups while
holding all the lwlocks.
I think I've caught up with the rest of the class on why this isn't
sane in
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I think I've caught up with the rest of the class on why this isn't
sane in DropAllPredicateLocksFromTableImpl, but I wonder about
CheckTableForSerializableConflictIn. We *do* expect to be throwing
errors in here, and we need some way to tell
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Predicate locks on indexes are only needed to lock key ranges, to
notice later insertions into the range, right? For locks on tuples
that do exist, we have locks on the heap. If we're just about to
delete every tuple in the heap,
Tom Lane t...@sss.pgh.pa.us wrote:
Just to answer the question (independently of Heikki's concern
about whether this is needed at all): it depends on the
information you have. If all you have is the index OID, then yeah
a catcache lookup in pg_index is probably the best thing. If you
have
On 07.06.2011 21:10, Kevin Grittner wrote:
I think that leaves me
with all the answers I need to get a new patch out this evening
(U.S. Central Time).
Great, I'll review it in my morning (in about 12h)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
On 07.06.2011 21:10, Kevin Grittner wrote:
I think that leaves me with all the answers I need to get a new
patch out this evening (U.S. Central Time).
Great, I'll review it in my morning (in about 12h)
Attached. Passes all
Heikki Linnakangas wrote:
On 03.06.2011 23:44, Kevin Grittner wrote:
Heikki Linnakangas wrote:
I think you'll need to just memorize the lock deletion command in
a backend-local list, and perform the deletion in a post-commit
function.
Hmm. As mentioned earlier in the thread, cleaning
Kevin Grittner wrote:
Maybe I should submit a patch without added complexity of the
scheduled cleanup and we can discuss that as a separate patch?
Here's a patch which adds the missing support for DDL. Cleanup of
predicate locks at commit time for transactions which ran DROP TABLE
or TRUNCATE
On Sun, Jun 05, 2011 at 12:45:41PM -0500, Kevin Grittner wrote:
Is this possible? If a transaction gets its snapshot while OID of N
is assigned to relation X, can that transaction wind up seeing an OID
of N as a reference to relation Y? If not, there aren't any false
positives possible.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 03.06.2011 21:04, Kevin Grittner wrote:
Also, if anyone has comments or hints about the placement of those
calls, I'd be happy to receive them.
heap_drop_with_catalog() schedules the relation for deletion at the end
of
On 04.06.2011 19:19, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
On 03.06.2011 21:04, Kevin Grittner wrote:
Also, if anyone has comments or hints about the placement of those
calls, I'd be happy to receive them.
heap_drop_with_catalog() schedules the
Heikki Linnakangas wrote:
On 04.06.2011 19:19, Tom Lane wrote:
Heikki Linnakangas writes:
On 03.06.2011 21:04, Kevin Grittner wrote:
Also, if anyone has comments or hints about the placement of
those calls, I'd be happy to receive them.
heap_drop_with_catalog() schedules the relation for
On 1 May 2011 I wrote:
Consider this a WIP patch
Just so people know where this stands...
By 8 May 2011 I had the attached. I didn't post it because I was
not confident I had placed the calls to the SSI functions for DROP
TABLE and TRUNCATE TABLE correctly. Then came PGCon and also the
On 03.06.2011 21:04, Kevin Grittner wrote:
Also, if anyone has comments or hints about the placement of those
calls, I'd be happy to receive them.
heap_drop_with_catalog() schedules the relation for deletion at the end
of transaction, but it's still possible that the transaction aborts and
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
On 03.06.2011 21:04, Kevin Grittner wrote:
Also, if anyone has comments or hints about the placement of
those calls, I'd be happy to receive them.
heap_drop_with_catalog() schedules the relation for deletion at
the end of
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
I think you'll need to just memorize the lock deletion command in
a backend-local list, and perform the deletion in a post-commit
function. Something similar to the PendingRelDelete
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
I think you'll need to just memorize the lock deletion command
in a backend-local list, and perform the deletion in a
post-commit function.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
I think you'll need to just memorize the lock deletion command in
a backend-local list, and perform the deletion in a post-commit
function.
Hmm. As mentioned earlier in the thread, cleaning these up doesn't
actually have any
On 03.06.2011 23:44, Kevin Grittner wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote:
I think you'll need to just memorize the lock deletion command in
a backend-local list, and perform the deletion in a post-commit
function.
Hmm. As mentioned earlier in the thread,
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
On 03.06.2011 23:44, Kevin Grittner wrote:
Hmm. As mentioned earlier in the thread, cleaning these up
doesn't actually have any benefit beyond freeing space in the
predicate locking collections. I'm not sure that benefit is
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Tuple locks should be safe from that because we use the tuple xmin
as part of the target key, but page and heap locks
That should have read page and relation locks.
I guess that tips the scales in favor of it being worth the extra
code.
On 30.04.2011 01:04, Kevin Grittner wrote:
TRUNCATE TABLE and DROP TABLE should generate a rw-conflict *in* to
the enclosing transaction (if it is serializable) from all
transactions holding predicate locks on the table or its indexes.
Note that this could cause a transactions which is running
Heikki Linnakangas wrote:
On 30.04.2011 01:04, Kevin Grittner wrote:
TRUNCATE TABLE and DROP TABLE should generate a rw-conflict *in*
to the enclosing transaction (if it is serializable) from all
transactions holding predicate locks on the table or its indexes.
Note that this could cause a
Just a quick status update.
I wrote:
Consider this a WIP patch
The serializable branch on my git repo has a modified form of this
which has been tested successfully with:
DROP INDEX
REINDEX
VACUUM FULL
CLUSTER
ALTER TABLE
I'm holding off on posting another version of the patch until I
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
I haven't dug into ALTER INDEX enough to know whether it can ever
cause an index to be rebuilt. If so, we need to treat it like
DROP INDEX and REINDEX -- which should change all predicate locks
of any granularity on the index into relation
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
This'll take some study.
I've gone through the list of commands in the development docs with
an eye toward exposing anything else we might have missed in dealing
with the SSI predicate locking. Some of this needs further
research, but I'm
On Wed, Apr 27, 2011 at 8:59 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
For correct serializable behavior in the face of concurrent DDL
execution, I think that a request for a heavyweight ACCESS EXCLUSIVE
lock might need to block until all SIREAD locks on the relation have
been
Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Apr 27, 2011 at 8:59 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
For correct serializable behavior in the face of concurrent DDL
execution, I think that a request for a heavyweight ACCESS
EXCLUSIVE lock might need to block until all
Composing my rather long-winded response to Simon got me thinking --
which just led me to realize there is probably a need to fix another
thing related to SSI.
For correct serializable behavior in the face of concurrent DDL
execution, I think that a request for a heavyweight ACCESS EXCLUSIVE
On 27.04.2011 22:59, Kevin Grittner wrote:
For correct serializable behavior in the face of concurrent DDL
execution, I think that a request for a heavyweight ACCESS EXCLUSIVE
lock might need to block until all SIREAD locks on the relation have
been released. Picture, for example, what might
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
On 27.04.2011 22:59, Kevin Grittner wrote:
For correct serializable behavior in the face of concurrent DDL
execution, I think that a request for a heavyweight ACCESS
EXCLUSIVE lock might need to block until all SIREAD locks on the
On Wed, Apr 27, 2011 at 02:59:19PM -0500, Kevin Grittner wrote:
For correct serializable behavior in the face of concurrent DDL
execution, I think that a request for a heavyweight ACCESS EXCLUSIVE
lock might need to block until all SIREAD locks on the relation have
been released. Picture,
Dan Ports d...@csail.mit.edu wrote:
On Wed, Apr 27, 2011 at 04:09:38PM -0500, Kevin Grittner wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Hmm, could we upgrade all predicate locks to relation-level
predicate locks instead?
Tied to what backend?
I think Heikki was
47 matches
Mail list logo
