Skip site navigation (1) Skip section navigation (2)

Re: Assertion failure with small block sizes

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL-development Hackers" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Assertion failure with small block sizes
Date: 2007-10-16 03:38:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> If I push the TOAST_TUPLES_PER_PAGE up to 16 I get another failure on the same
>> line from trying to toast a sequence. If I add RELKIND_SEQUENCE to the
>> assertion then it passes all regression tests even if I push
>> TOAST_TUPLES_PER_PAGE up to 1024 -- ie, try to toast everything as far as
>> possible. Perhaps heapam.c:1761 should just check for RELKIND_SEQUENCE as
>> well.
> Hmm.  I'm inclined to reverse the tests (there are 3 not just 1) in
> heapam.c, so that it explicitly tries to toast only in plain tables,
> rather than adding more exclusion cases.  Thoughts?

Well RELKIND_UNCATALOGED can be usefully toasted in that data can be
compressed internally. I suppose we know none normally receive such treatment
at normal block sizes. If we want to make the tuple threshold configurable
down the line would we want it affecting initdb bootstrapping? My experiments
show it isn't a problem but I don't particularly see any reason why it's

We may want some future relkinds to be toastable but I don't see a problem
adding new cases to the test.

  Gregory Stark

In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2007-10-16 03:58:59
Subject: Re: Assertion failure with small block sizes
Previous:From: Tom LaneDate: 2007-10-16 02:32:47
Subject: Re: Assertion failure with small block sizes

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group