On Apr 23, 2007, at 11:38 PM, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
On Sat, 2007-04-21 at 19:43 -0400, Neil Conway wrote:
Attached is a very quick hack of a patch to do this.
Does anyone have any feedback on this approach? If people are
satisfied
with this solution, I can
On Sat, 2007-04-21 at 19:43 -0400, Neil Conway wrote:
Attached is a very quick hack of a patch to do this.
Does anyone have any feedback on this approach? If people are satisfied
with this solution, I can get a cleaned up patch ready to apply shortly.
-Neil
---(end of
Neil Conway [EMAIL PROTECTED] writes:
On Sat, 2007-04-21 at 19:43 -0400, Neil Conway wrote:
Attached is a very quick hack of a patch to do this.
Does anyone have any feedback on this approach? If people are satisfied
with this solution, I can get a cleaned up patch ready to apply shortly.
On Mon, 2007-04-23 at 17:38 -0400, Tom Lane wrote:
I'm really still opposed to the entire concept. You're proposing to put
a lot of fragile-looking code into a seldom-exercised error path.
There's certainly not a lot of code: the patch just adds a few
syscache lookups, wrapped in a
Neil Conway wrote:
On Mon, 2007-04-23 at 17:38 -0400, Tom Lane wrote:
I'm really still opposed to the entire concept. You're proposing to put
a lot of fragile-looking code into a seldom-exercised error path.
There's certainly not a lot of code: the patch just adds a few
syscache lookups,
Neil Conway [EMAIL PROTECTED] writes:
On Fri, 2007-04-20 at 02:55 -0400, Tom Lane wrote:
I don't think you've thought of quite all of the failure cases. One
that's a bit pressing is that a deadlock isn't necessarily confined to
objects in your own database.
I'm not sure I follow. If we
On Sat, 2007-04-21 at 02:38 -0400, Tom Lane wrote:
Maybe so, but you're going to be writing quite a lot of duplicative
code, because the existing routines you might have been thinking of
using (lsyscache.c etc) don't behave that way.
Right, I'm envisioning doing a conditional LockAcquire and
On Sat, 2007-04-21 at 17:56 -0400, Neil Conway wrote:
Right, I'm envisioning doing a conditional LockAcquire and then
heap_open() / heap_getnext() by hand. That will be relatively slow, but
code that emits a deadlock error message is almost by definition not
performance critical.
... although
The error message we currently produce when a deadlock occurs is pretty
unfriendly:
ERROR: deadlock detected
DETAIL: Process 32068 waits for AccessExclusiveLock on relation
16413 of database 16384; blocked by process 32064.
Process 32064 waits for AccessExclusiveLock on relation
Neil Conway [EMAIL PROTECTED] writes:
I whipped up a quick patch to use names as well as OIDs for the
identifiers in the message, but on reflection the simple approach to
doing this is problematic: when we do syscache lookups to lookup the
identifier names, we might need to acquire an
Tom Lane [EMAIL PROTECTED] writes:
I don't think you've thought of quite all of the failure cases. One
that's a bit pressing is that a deadlock isn't necessarily confined to
objects in your own database.
We could do the syscache lookups for only the object we're waiting on and
store that
On Fri, 2007-04-20 at 02:55 -0400, Tom Lane wrote:
I don't think you've thought of quite all of the failure cases. One
that's a bit pressing is that a deadlock isn't necessarily confined to
objects in your own database.
I'm not sure I follow. If we conditionally acquire the locks we need and
12 matches
Mail list logo
