On Thu, Sep 8, 2016 at 2:46 AM, Haribabu Kommi wrote:
> Patch needs rebase, it is failing to apply on latest master.
> And also there are some pending comment fix from Robert.
It's been almost three weeks and this hasn't been updated, so I think
it's pretty clear that it should be marked "Returne
On Mon, Jun 20, 2016 at 9:28 PM, Asif Naeem wrote:
> Thank you for useful suggestions. PFA patch, I have tried to cover all the
> points mentioned.
>
>>
>>
Patch needs rebase, it is failing to apply on latest master.
And also there are some pending comment fix from Robert.
Regards,
Hari Babu
Fuj
On Mon, Jun 20, 2016 at 7:28 AM, Asif Naeem wrote:
> Thank you for useful suggestions. PFA patch, I have tried to cover all the
> points mentioned.
Thanks for the new patch. I think that you have failed to address
this point from my previous review:
# I see why you changed the calling conventio
Thank you for useful suggestions. PFA patch, I have tried to cover all the
points mentioned.
Regards,
Muhammad Asif Naeem
On Wed, Apr 6, 2016 at 9:06 PM, Robert Haas wrote:
> On Wed, Apr 6, 2016 at 3:32 AM, Asif Naeem wrote:
> >> Oh, I see. I think it's probably not a good idea to skip trunca
On Wed, Apr 6, 2016 at 9:06 PM, Robert Haas wrote:
> On Wed, Apr 6, 2016 at 3:32 AM, Asif Naeem wrote:
> >> Oh, I see. I think it's probably not a good idea to skip truncating
> >> those maps, but perhaps the option could be defined as making no new
> >> entries, rather than ignoring them altog
On Wed, Apr 6, 2016 at 5:15 PM, Jim Nasby wrote:
> On 4/6/16 11:06 AM, Robert Haas wrote:
>> This is too late for 9.6 at this point and certainly requires
>> discussion anyway, so please add it to the next CommitFest.
>
> If the goal here is to free up space via truncation when there's a real
> em
On Thu, Apr 7, 2016 at 2:15 AM, Jim Nasby wrote:
> On 4/6/16 11:06 AM, Robert Haas wrote:
>
>> This is too late for 9.6 at this point and certainly requires
>> discussion anyway, so please add it to the next CommitFest.
>>
>
> If the goal here is to free up space via truncation when there's a rea
Thank you Robert. Sure, I will add the updated patch on the next CommitFest
with all the suggested changes.
On Wed, Apr 6, 2016 at 9:06 PM, Robert Haas wrote:
> On Wed, Apr 6, 2016 at 3:32 AM, Asif Naeem wrote:
> >> Oh, I see. I think it's probably not a good idea to skip truncating
> >> those
On 4/6/16 11:06 AM, Robert Haas wrote:
This is too late for 9.6 at this point and certainly requires
discussion anyway, so please add it to the next CommitFest.
If the goal here is to free up space via truncation when there's a real
emergency, perhaps there's some other steps that should be ta
On Wed, Apr 6, 2016 at 3:32 AM, Asif Naeem wrote:
>> Oh, I see. I think it's probably not a good idea to skip truncating
>> those maps, but perhaps the option could be defined as making no new
>> entries, rather than ignoring them altogether, so that they never
>> grow. It seems that both of tho
On Tue, Jan 19, 2016 at 2:04 AM, Robert Haas wrote:
> On Mon, Jan 18, 2016 at 2:26 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Fri, Jan 15, 2016 at 2:16 PM, Tom Lane wrote:
> >>> Presumably the hope would be that VACUUM would truncate off some of the
> >>> heap, else there's not much g
On Mon, Jan 18, 2016 at 2:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 15, 2016 at 2:16 PM, Tom Lane wrote:
>>> Presumably the hope would be that VACUUM would truncate off some of the
>>> heap, else there's not much good that's going to happen. That leaves
>>> me wondering exactl
Robert Haas writes:
> On Fri, Jan 15, 2016 at 2:16 PM, Tom Lane wrote:
>> Presumably the hope would be that VACUUM would truncate off some of the
>> heap, else there's not much good that's going to happen. That leaves
>> me wondering exactly what the invariant is for the maps, and if it's
>> oka
On Fri, Jan 15, 2016 at 2:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> Now, I do think it's a somewhat fair complaint that if you have a
>> tablespace which is totally, 100% full, recovery is difficult. You
>> can probably DROP the table, but TRUNCATE might fail, and so might
>> VACUUM. You
On Fri, Jan 15, 2016 at 11:16 AM, Tom Lane wrote:
> I believe that there would be ramifications for some of the index AMs
> too. For example, if left to its own devices GIN would consider VACUUM
> to include flushing its pending-list pages, which more than likely will
> increase not reduce the t
Robert Haas writes:
> Now, I do think it's a somewhat fair complaint that if you have a
> tablespace which is totally, 100% full, recovery is difficult. You
> can probably DROP the table, but TRUNCATE might fail, and so might
> VACUUM. You could argue that DROP is usually a good substitute for
>
On Fri, Jan 15, 2016 at 1:24 PM, Kevin Grittner wrote:
> On Fri, Jan 15, 2016 at 11:41 AM, Robert Haas wrote:
>> Anybody else want to weigh in with thoughts on any of this?
>
> Leaving aside VACUUM issues for a moment, what problems to you see
> with an empty table that has no visibility map or f
On Fri, Jan 15, 2016 at 11:41 AM, Robert Haas wrote:
> Anybody else want to weigh in with thoughts on any of this?
Leaving aside VACUUM issues for a moment, what problems to you see
with an empty table that has no visibility map or free space map
fork? In other words, for the TRUNCATE case we c
On Fri, Jan 15, 2016 at 11:05 AM, Thom Brown wrote:
> On 15 January 2016 at 15:21, Robert Haas wrote:
>> On Fri, Sep 4, 2015 at 8:04 AM, Thom Brown wrote:
>>> Currently, when attempting to vacuum a table on a tablespace with no space
>>> left, we get an error:
>>>
>>> postgres=# vacuum test;
>>>
On 15 January 2016 at 15:21, Robert Haas wrote:
> On Fri, Sep 4, 2015 at 8:04 AM, Thom Brown wrote:
>> Currently, when attempting to vacuum a table on a tablespace with no space
>> left, we get an error:
>>
>> postgres=# vacuum test;
>> ERROR: could not extend file
>> "pg_tblspc/19605/PG_9.6_201
On Fri, Sep 4, 2015 at 8:04 AM, Thom Brown wrote:
> Currently, when attempting to vacuum a table on a tablespace with no space
> left, we get an error:
>
> postgres=# vacuum test;
> ERROR: could not extend file
> "pg_tblspc/19605/PG_9.6_201508111/12382/19616_vm": No space left on device
> HINT:
On 9/4/15 7:04 AM, Thom Brown wrote:
But shouldn't we not be creating FSM or VM files when truncating?
Maybe, but even then you still need to create a bunch of new files (at
least one for the table and one for each index), and AFAIK the first
page in each file will be properly initialized, wh
Hi,
Currently, when attempting to vacuum a table on a tablespace with no space
left, we get an error:
postgres=# vacuum test;
ERROR: could not extend file
"pg_tblspc/19605/PG_9.6_201508111/12382/19616_vm": No space left on device
HINT: Check free disk space.
This is because it first tries to g
23 matches
Mail list logo
