On Thu, Dec 1, 2016 at 8:56 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Dec 1, 2016 at 12:43 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> On Thu, Dec 1, 2016 at 2:18 AM, Robert Haas <robertmhaas@gmail.com> wrote: >>> On Wed, Nov 23, 2016 at 8:50 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >>>> [ new patch ] >>> >>> Committed with some further cosmetic changes. >> >> Thank you very much. >> >>> I think it would be worth testing this code with very long overflow >>> chains by hacking the fill factor up to 1000 >> >> 1000 is not a valid value for fill factor. Do you intend to say 100? > > No. IIUC, 100 would mean split when the average bucket contains 1 > page worth of tuples. >
I also think so. > I want to split when the average bucket > contains 10 pages worth of tuples. >
oh, I think what you mean to say is hack the code to bump fill factor and then test it. I was confused that how can user can do that from SQL command.
I just occasionally insert a bunch of equal tuples, which have to be in overflow pages no matter how much splitting happens.
I am getting vacuum errors against HEAD, after about 20 minutes or so (8 cores).
49233 XX002 2016-12-05 23:06:44.087 PST:ERROR: index "foo_index_idx" contains unexpected zero page at block 64941
49233 XX002 2016-12-05 23:06:44.087 PST:HINT: Please REINDEX it.
49233 XX002 2016-12-05 23:06:44.087 PST:CONTEXT: automatic vacuum of table "jjanes.public.foo"
Testing harness is attached. It includes a lot of code to test crash recovery, but all of that stuff is turned off in this instance. No patches need to be applied to the server to get this one to run.
With the latest HASH WAL patch applied, I get different but apparently related errors
41993 UPDATE XX002 2016-12-05 22:28:45.333 PST:ERROR: index "foo_index_idx" contains corrupted page at block 27602
41993 UPDATE XX002 2016-12-05 22:28:45.333 PST:HINT: Please REINDEX it.
41993 UPDATE XX002 2016-12-05 22:28:45.333 PST:STATEMENT: update foo set count=count+1 where index=$1
