Alvaro Herrera writes:
> Kyotaro HORIGUCHI wrote:
>> The line prefixed by '!' looks inverted.
> You're absolutely right. My mistake. Pushed your patch, thanks.
Don't see any such commit from here?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacke
Kyotaro HORIGUCHI wrote:
> Hi, this is a bug in the commit 0d831389749a3baaced7b984205b9894a82444b9 .
>
> It allows vucuum freeze to be skipped and inversely lets regular
> vacuum wait for lock. The attched patch fixes it.
>
>
> In table_recheck_autovac, vacuum options are determined as followin
Hi,
At Wed, 1 Apr 2015 16:50:41 +0900, Michael Paquier
wrote in
> I am sure someone will show up quickly and push the fix you provided.
Ok, I'll be a good boy.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On Wed, Apr 1, 2015 at 4:35 PM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> By the way, what should we do about this?
>
> - Waiting for someone's picking up this.
> - Making another thread to attract notice
> - Otherwise..
I am sure someone will show up quickly and push the
By the way, what shoud we do about this?
- Waiting for someone's picking up this.
- Making another thread to attract notice
- Otherwise..
At Wed, 1 Apr 2015 10:49:55 +0900, Michael Paquier
wrote in
> On Wed, Apr 1, 2015 at 2:18 AM, Jeff Janes wrote:
>
> > On Tue, Mar 31, 2015 at 1:28 AM
On Wed, Apr 1, 2015 at 2:26 AM, Jeff Janes wrote:
> Did it tell you why? If it surrendered the lock to a competing process,
> it should report that as previous INFO messages. If it doesn't give one of
> those, then it probably just thinks there are some tuples it can't remove
> yet somewhere. W
On Wed, Apr 1, 2015 at 2:18 AM, Jeff Janes wrote:
> On Tue, Mar 31, 2015 at 1:28 AM, Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
>> Hi, this is a bug in the commit 0d831389749a3baaced7b984205b9894a82444b9 .
>>
>> It allows vucuum freeze to be skipped and inversely lets regular
On Tue, Mar 31, 2015 at 1:29 AM, Michael Paquier
wrote:
>
>
> On Tue, Mar 31, 2015 at 3:42 PM, Jeff Janes wrote:
>
>> On Mon, Mar 30, 2015 at 8:54 PM, Jeff Janes wrote:
>>
>>> After freeing up the rows at the end of the table so it is eligible for
>>> truncation, then running a manual VACUUM to
On Tue, Mar 31, 2015 at 1:28 AM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hi, this is a bug in the commit 0d831389749a3baaced7b984205b9894a82444b9 .
>
> It allows vucuum freeze to be skipped and inversely lets regular
> vacuum wait for lock. The attched patch fixes it.
>
>
> I
On Tue, Mar 31, 2015 at 3:42 PM, Jeff Janes wrote:
> On Mon, Mar 30, 2015 at 8:54 PM, Jeff Janes wrote:
>
>> After freeing up the rows at the end of the table so it is eligible for
>> truncation, then running a manual VACUUM to actually release the space, I
>> kept running into the problem that
On Mon, Mar 30, 2015 at 8:54 PM, Jeff Janes wrote:
> After freeing up the rows at the end of the table so it is eligible for
> truncation, then running a manual VACUUM to actually release the space, I
> kept running into the problem that the truncation scan was consistently
> suspended and then a
After freeing up the rows at the end of the table so it is eligible for
truncation, then running a manual VACUUM to actually release the space, I
kept running into the problem that the truncation scan was consistently
suspended and then aborted due to a conflicting lock requested/held.
But the per
12 matches
Mail list logo
