Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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.

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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 >

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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 >>>

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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,

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

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,

[HACKERS] Truncating/vacuuming relations on full tablespaces

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