Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I propose applying this patch from 8.1 onwards. HEAD would get an
> additional treatment to avoid the balancing problem.
If you're going to insert an early unlock, it should be as early as
possible, ie right after the RelationTruncate() call. The book
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > What I'm requesting here is that the sleep in count_nondeletable_pages()
> > > be removed and that change backpatched to 8.2 and 8.1.
> >
> > Are you sure that that is, and always will be, the only sleep i
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Simon Riggs wrote:
> On Fri, 2007-06-29 at 09:29 +0900, ITAGAKI Takahiro wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]
On Fri, 2007-06-29 at 09:29 +0900, ITAGAKI Takahiro wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > What I'm requesting here is that the sleep in count_nondeletable_pages()
> > be removed and that change backpatched to 8.2 and 8.1.
>
> Agreed. We'd better to shorten the exclusive locking
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > What I'm requesting here is that the sleep in count_nondeletable_pages()
> > be removed and that change backpatched to 8.2 and 8.1.
>
> Are you sure that that is, and always will be, the only sleep in that
> part of the code path?
I
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What I'm requesting here is that the sleep in count_nondeletable_pages()
> be removed and that change backpatched to 8.2 and 8.1.
Are you sure that that is, and always will be, the only sleep in that
part of the code path?
Seems like it might be better
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> What I'm requesting here is that the sleep in count_nondeletable_pages()
> be removed and that change backpatched to 8.2 and 8.1.
Agreed. We'd better to shorten the exclusive locking as far as possible.
> We don't know how many pages we can truncate u
Simon Riggs wrote:
> On Thu, 2007-06-28 at 17:16 -0400, Alvaro Herrera wrote:
>
> > I noticed that lazy vacuum acquires an exclusive lock at the end, to be
> > able to truncate the table. This is not a surprise. If it cannot
> > acquire the lock, it simply skips truncating the table and goes on
On Thu, 2007-06-28 at 17:16 -0400, Alvaro Herrera wrote:
> I noticed that lazy vacuum acquires an exclusive lock at the end, to be
> able to truncate the table. This is not a surprise. If it cannot
> acquire the lock, it simply skips truncating the table and goes on with
> life.
>
> However, wh
Hi,
I noticed that lazy vacuum acquires an exclusive lock at the end, to be
able to truncate the table. This is not a surprise. If it cannot
acquire the lock, it simply skips truncating the table and goes on with
life.
However, what's problematic is that if a non-zero cost delay has been
set, i
10 matches
Mail list logo
