ERROR: failed to add item to the index page

Andreas Joseph Krogh <andreas@visena.com> writes:

With master (3dbb317d32f4f084ef7badaed8ef36f5c9b85fe6) I'm getting this:
visena=# CREATE INDEX origo_email_part_hdrvl_value_idx ON
public.origo_email_part_headervalue USING btree
(lower(substr((header_value)::text, 0, 1000)) varchar_pattern_ops);
psql: ERROR: failed to add item to the index page

Hm, your example works for me on HEAD.

Usually, the first thing to suspect when you're tracking HEAD and get
bizarre failures is that you have a messed-up build. Before spending
any time diagnosing more carefully, do "make distclean", reconfigure,
rebuild, reinstall, then see if problem is still there.

(In theory, you can avoid this sort of failure with appropriate use
of --enable-depend, but personally I don't trust that too much.
I find that with ccache + autoconf cache + parallel build, rebuilding
completely is fast enough that it's something I just do routinely
after any git pull. I'd rather use up my remaining brain cells on
other kinds of problems...)

regards, tom lane

På tirsdag 30. april 2019 kl. 15:43:16, skrev Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>>: Andreas Joseph Krogh <andreas@visena.com> writes:

With master (3dbb317d32f4f084ef7badaed8ef36f5c9b85fe6) I'm getting this:
visena=# CREATE INDEX origo_email_part_hdrvl_value_idx ON
public.origo_email_part_headervalue USING btree
(lower(substr((header_value)::text, 0, 1000)) varchar_pattern_ops);
psql: ERROR: failed to add item to the index page

Hm, your example works for me on HEAD.

Usually, the first thing to suspect when you're tracking HEAD and get
bizarre failures is that you have a messed-up build. Before spending
any time diagnosing more carefully, do "make distclean", reconfigure,
rebuild, reinstall, then see if problem is still there.

(In theory, you can avoid this sort of failure with appropriate use
of --enable-depend, but personally I don't trust that too much.
I find that with ccache + autoconf cache + parallel build, rebuilding
completely is fast enough that it's something I just do routinely
after any git pull. I'd rather use up my remaining brain cells on
other kinds of problems...)

regards, tom lane I built with this: make distclean && ./configure
--prefix=$HOME/programs/postgresql-master --with-openssl --with-llvm && make -j
8 install-world-contrib-recurse install-world-doc-recurse
It's probably caused by the data: visena=# select count(*) from
origo_email_part_headervalue;
count
----------
14609516
(1 row)
I'll see if I can create a self contained example.
--
Andreas Joseph Krogh

Andreas Joseph Krogh <andreas@visena.com> writes:

I built with this: make distclean && ./configure
--prefix=$HOME/programs/postgresql-master --with-openssl --with-llvm && make -j
8 install-world-contrib-recurse install-world-doc-recurse

--with-llvm, eh? Does it reproduce without that? What platform is
this on, what LLVM version?

I'll see if I can create a self contained example.

Please.

regards, tom lane

På tirsdag 30. april 2019 kl. 15:53:50, skrev Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>>: Andreas Joseph Krogh <andreas@visena.com> writes:

I built with this: make distclean && ./configure
--prefix=$HOME/programs/postgresql-master --with-openssl --with-llvm &&

make -j

8 install-world-contrib-recurse install-world-doc-recurse

--with-llvm, eh? Does it reproduce without that? What platform is
this on, what LLVM version?

I'll see if I can create a self contained example.

Please.

regards, tom lane Ubuntu 19.04 $ llvm-config --version
8.0.0
"--with-llvm" was something I had from when pg-11 was master. It might not be
needed anymore? I'm trying a fresh build without --with-llvm and reload of data
now.
--
Andreas Joseph Krogh

På tirsdag 30. april 2019 kl. 16:03:04, skrev Andreas Joseph Krogh <
andreas@visena.com <mailto:andreas@visena.com>>: På tirsdag 30. april 2019 kl.
15:53:50, skrev Tom Lane <tgl@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>>:
Andreas Joseph Krogh <andreas@visena.com> writes:

I built with this: make distclean && ./configure
--prefix=$HOME/programs/postgresql-master --with-openssl --with-llvm &&

make -j

8 install-world-contrib-recurse install-world-doc-recurse

--with-llvm, eh? Does it reproduce without that? What platform is
this on, what LLVM version?

I'll see if I can create a self contained example.

Please.

regards, tom lane Ubuntu 19.04 $ llvm-config --version
8.0.0
"--with-llvm" was something I had from when pg-11 was master. It might not be
needed anymore? I'm trying a fresh build without --with-llvm and reload of data
now. Yep, happens without --with-llvm also. I'll try to load only the necessary
table(s) to reproduce. --
Andreas Joseph Krogh

Please fix or abstain from using the MUA that produces this monstrosity
of a Subject: "Sv: Sv: Re: Sv: Re: ERROR: failed to add item to the
index page"

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

På tirsdag 30. april 2019 kl. 16:27:05, skrev Andreas Joseph Krogh <
andreas@visena.com <mailto:andreas@visena.com>>: [snip] Yep, happens without
--with-llvm also. I'll try to load only the necessary table(s) to reproduce. I
have a 1.4GB dump (only one table) which reliably reproduces this error.
Shall I share it off-list? --
Andreas Joseph Krogh

On Tue, Apr 30, 2019 at 9:44 AM Andreas Joseph Krogh
<andreas@visena.com> wrote:

I have a 1.4GB dump (only one table) which reliably reproduces this error.
Shall I share it off-list?

I would be quite interested in this, too, since there is a chance that
it's my bug.

--
Peter Geoghegan

Andreas Joseph Krogh <andreas@visena.com> writes:

I have a 1.4GB dump (only one table) which reliably reproduces this error.
Shall I share it off-list? --

That's awfully large :-(. How do you have in mind to transmit it?

Maybe you could write a short script that generates dummy data
to reproduce the problem?

regards, tom lane

On Tue, Apr 30, 2019 at 9:47 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andreas Joseph Krogh <andreas@visena.com> writes:

I have a 1.4GB dump (only one table) which reliably reproduces this error.
Shall I share it off-list? --

That's awfully large :-(. How do you have in mind to transmit it?

I've send dumps that were larger than that by providing a Google drive
link. Something like that should work reasonably well.

--
Peter Geoghegan

På tirsdag 30. april 2019 kl. 18:48:45, skrev Peter Geoghegan <pg@bowt.ie
<mailto:pg@bowt.ie>>: On Tue, Apr 30, 2019 at 9:47 AM Tom Lane
<tgl@sss.pgh.pa.us> wrote:

Andreas Joseph Krogh <andreas@visena.com> writes:

I have a 1.4GB dump (only one table) which reliably reproduces this error.
Shall I share it off-list? --

That's awfully large :-(. How do you have in mind to transmit it?

I've send dumps that were larger than that by providing a Google drive
link. Something like that should work reasonably well. I've sent you guys a
link (Google Drive) off-list.
--
Andreas Joseph Krogh

On Tue, Apr 30, 2019 at 9:56 AM Andreas Joseph Krogh <andreas@visena.com> wrote:

I've sent you guys a link (Google Drive) off-list.

I'll start investigating the problem right away.

Thanks
--
Peter Geoghegan

On Tue, Apr 30, 2019 at 9:59 AM Peter Geoghegan <pg@bowt.ie> wrote:

I'll start investigating the problem right away.

I have found what the problem is. I simply neglected to make a
conservative assumption about suffix truncation needing to add a heap
TID to a leaf page's new high key in nbtsort.c (following commit
dd299df8189), even though I didn't make the same mistake in
nbtsplitloc.c. Not sure how I managed to make such a basic error.

Andreas' test case works fine with the attached patch. I won't push a
fix for this today.

--
Peter Geoghegan

På tirsdag 30. april 2019 kl. 19:58:31, skrev Peter Geoghegan <pg@bowt.ie
<mailto:pg@bowt.ie>>: On Tue, Apr 30, 2019 at 9:59 AM Peter Geoghegan
<pg@bowt.ie> wrote:

I'll start investigating the problem right away.

I have found what the problem is. I simply neglected to make a
conservative assumption about suffix truncation needing to add a heap
TID to a leaf page's new high key in nbtsort.c (following commit
dd299df8189), even though I didn't make the same mistake in
nbtsplitloc.c. Not sure how I managed to make such a basic error.

Andreas' test case works fine with the attached patch. I won't push a
fix for this today.

--
Peter Geoghegan Nice, thanks! --
Andreas Joseph Krogh

On Tue, Apr 30, 2019 at 11:54 AM Andreas Joseph Krogh
<andreas@visena.com> wrote:

Nice, thanks!

Thanks for the report!

--
Peter Geoghegan

Hi,

On 2019-04-30 20:54:45 +0200, Andreas Joseph Krogh wrote:

P� tirsdag 30. april 2019 kl. 19:58:31, skrev Peter Geoghegan <pg@bowt.ie
<mailto:pg@bowt.ie>>: On Tue, Apr 30, 2019 at 9:59 AM Peter Geoghegan
<pg@bowt.ie> wrote:

I'll start investigating the problem right away.

I have found what the problem is. I simply neglected to make a
conservative assumption about suffix truncation needing to add a heap
TID to a leaf page's new high key in nbtsort.c (following commit
dd299df8189), even though I didn't make the same mistake in
nbtsplitloc.c. Not sure how I managed to make such a basic error.

Andreas' test case works fine with the attached patch. I won't push a
fix for this today.

--
Peter Geoghegan Nice, thanks! --
Andreas Joseph Krogh

Andreas, unfortunately your emails are pretty unreadable. Check the
quoted email, and the web archive:

/messages/by-id/VisenaEmail.41.51d7719d814a1f54.16a6f98a5e9@tc7-visena

Greetings,

Andres Freund

På tirsdag 30. april 2019 kl. 20:59:43, skrev Andres Freund <andres@anarazel.de
<mailto:andres@anarazel.de>>: [...]
Andreas, unfortunately your emails are pretty unreadable. Check the
quoted email, and the web archive:

/messages/by-id/VisenaEmail.41.51d7719d814a1f54.16a6f98a5e9@tc7-visena

Greetings,

Andres Freund
I know that the text-version is quite unreadable, especially when quoting. My
MUA is web-based and uses CKEditor for composing, and it doesn't care much to
try to format the text/plain version (I know because I've written it, yes and
have yet to fix the Re: Sv: Re: Sv: subject issue...). But it has tons of
benefits CRM- and usage-wise so I prefer to use it. But - how use text/plain
these days:-) --
Andreas Joseph Krogh

Hi,

On 2019-04-30 21:23:21 +0200, Andreas Joseph Krogh wrote:

P� tirsdag 30. april 2019 kl. 20:59:43, skrev Andres Freund <andres@anarazel.de
<mailto:andres@anarazel.de>>: [...]
Andreas, unfortunately your emails are pretty unreadable. Check the
quoted email, and the web archive:

/messages/by-id/VisenaEmail.41.51d7719d814a1f54.16a6f98a5e9@tc7-visena

Greetings,

Andres Freund

I know that the text-version is quite unreadable, especially when quoting. My
MUA is web-based and uses CKEditor for composing, and it doesn't care much to
try to format the text/plain version (I know because I've written it, yes and
have yet to fix the Re: Sv: Re: Sv: subject issue...). But it has tons of
benefits CRM- and usage-wise so I prefer to use it. But - how use text/plain
these days:-) --

The standard on pg lists is to write in a manner that's usable for both
text mail readers and the archive. Doesn't terribly matter to the
occasional one-off poster on -general, but you're not that... So please
try to write readable mails for the PG lists.

Greetings,

Andres Freund

På tirsdag 30. april 2019 kl. 21:26:52, skrev Andres Freund <andres@anarazel.de
<mailto:andres@anarazel.de>>: > [...]

The standard on pg lists is to write in a manner that's usable for both >

text mail readers and the archive. Doesn't terribly matter to the > occasional
one-off poster on -general, but you're not that... So please > try to write
readable mails for the PG lists.

Greetings,

Andres Freund ACK. --

Andreas Joseph Krogh