Re: Truncating/vacuuming relations on full tablespaces - Mailing list pgsql-hackers

<div dir="ltr">Thank you Robert. Sure, I will add the updated patch on the next CommitFest with all the suggested
changes.<br/></div><div class="gmail_extra"><br /><div class="gmail_quote">On Wed, Apr 6, 2016 at 9:06 PM, Robert Haas
<spandir="ltr"><<a href="mailto:robertmhaas@gmail.com" target="_blank">robertmhaas@gmail.com</a>></span>
wrote:<br/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div
class="HOEnZb"><divclass="h5">On Wed, Apr 6, 2016 at 3:32 AM, Asif Naeem <<a
href="mailto:anaeem.it@gmail.com">anaeem.it@gmail.com</a>>wrote:<br /> >> Oh, I see.  I think it's probably
nota good idea to skip truncating<br /> >> those maps, but perhaps the option could be defined as making no
new<br/> >> entries, rather than ignoring them altogether, so that they never<br /> >> grow.  It seems that
bothof those are defined in such a way that if<br /> >> page Y follows page X in the heap, the entries for page Y
inthe<br /> >> relation fork will follow the one for page X.  So truncating them<br /> >> should be OK;
it'sjust growing them that we need to avoid.<br /> ><br /> > Thank you Robert. PFA basic patch, it introduces
EMERGENCYoption to VACUUM<br /> > that forces to avoid extend any entries in the VM or FSM. It seems working<br />
>fine in simple test scenarios e.g.<br /> ><br /> >> postgres=# create table test1 as (select
generate_series(1,100000));<br/> >> SELECT 100000<br /> >> postgres=# vacuum  EMERGENCY test1;<br />
>>VACUUM<br /> >> postgres=# select pg_relation_filepath('test1');<br /> >>  pg_relation_filepath<br
/>>> ----------------------<br /> >>  base/13250/16384<br /> >> (1 row)<br /> >> [asif@centos66
inst_96]$find . | grep base/13250/16384<br /> >> ./data/base/13250/16384<br /> >> postgres=# vacuum
test1;<br/> >> VACUUM<br /> >> [asif@centos66 inst_96]$ find . | grep base/13250/16384<br /> >>
./data/base/13250/16384<br/> >> ./data/base/13250/16384_fsm<br /> >> ./data/base/13250/16384_vm<br />
><br/> ><br /> > Please do let me know if I missed something or more information is required.<br /> >
Thanks.<br/><br /></div></div>This is too late for 9.6 at this point and certainly requires<br /> discussion anyway, so
pleaseadd it to the next CommitFest.  But in<br /> the meantime, here are a few quick comments:<br /><br /> You should
onlysupport EMERGENCY using the new-style, parenthesized<br /> options syntax.  That way, you won't need to make
EMERGENCYa keyword.<br /> We don't want to do that, and we especially don't want it to be<br /> partially reserved, as
youhave done here.<br /><br /> Passing the EMERGENCY flag around in a global variable is probably not<br /> a good
idea;use parameter lists.  That's what they are for.  Also,<br /> calling the variable that decides whether EMERGENCY
wasset<br /> Extend_VM_FSM is confusing.<br /><br /> I see why you changed the calling convention for
visibilitymap_pin()<br/> and RecordPageWithFreeSpace(), but that's awfully invasive.  I wonder<br /> if there's a
betterway to do that, like maybe having vacuumlazy.c ask<br /> the VM and FSM for their length in pages and then not
tryingto use<br /> those functions for block numbers that are too large.<br /><br /> Don't forget to update the
documentation.<br/><div class="HOEnZb"><div class="h5"><br /> --<br /> Robert Haas<br /> EnterpriseDB: <a
href="http://www.enterprisedb.com"rel="noreferrer" target="_blank">http://www.enterprisedb.com</a><br /> The Enterprise
PostgreSQLCompany<br /></div></div></blockquote></div><br /></div>