"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 TABLE can be added as a separate patch. I consider those
to be optimizations which are of dubious benefit, especially compared
to the complexity of the extra code required.
Also, Heikki pointed out that explicitly releasing the predicate
locks after a DROP DATABASE is an optimization, which on reflection
also seems to be of dubious value compared to the code needed.
Unless someone can find a way in which any of these early cleanups
are needed for correctness, I suggest they are better left as
enhancements in some future release, where there can be some
demonstration that they matter enough for performance to justify the
extra code, and there can be more testing to ensure the new code
doesn't break anything.
I stashed the partial work on the more aggressive cleanup, so if
there's a consensus that we want it, I can post a patch pretty
In making sure that the new code for this patch was in pgindent
format, I noticed that the ASCII art and bullet lists recently added
to OnConflict_CheckForSerializationFailure() were mangled badly by
pgindent, so I added the dashes to protect those and included a
pgindent form of that function. That should save someone some
trouble sorting things out after the next global pgindent run.
Description: application/octet-stream (28.7 KB)
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2011-06-06 02:16:32|
|Subject: Re: reducing the overhead of frequent table locks - now,
with WIP patch|
|Previous:||From: Tom Lane||Date: 2011-06-06 02:07:41|
|Subject: Re: Auto adjust send buffer size to congention window |