Thread: GiST intarray Memory Allocation
Hi All Platform: Win32 (XP SP2) PG: 8.0.3 (default config file) I have a table with circa 5.5Million rows and an int4[] column containing about 28 elements each. When I try to put a CREATE INDEX name ON table USING gist(column); I get the following : ERROR: invalid memory alloc request size 2825271912 Any help appreciated or if you need more info just ask. Thanks Garrett
On Sun, Sep 04, 2005 at 04:49:27PM +0100, Garrett Heaver wrote: > I have a table with circa 5.5Million rows and an int4[] column containing > about 28 elements each. > > When I try to put a CREATE INDEX name ON table USING gist(column); > I get the following : > > ERROR: invalid memory alloc request size 2825271912 Hmm. Have you tried a plain SELECT * FROM table? It sounds like your table may be corrupt. Another alternative is that the opclass functions are buggy. If the table is not corrupt, you could try giving us complete working instructions to try to reproduce the bug. -- Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end." (2nd Commandment for C programmers)
Performed full table select - worked perfectly I can give you a dump of the table if that will help Thanks Garrett -----Original Message----- From: Alvaro Herrera [mailto:alvherre@alvh.no-ip.org] Sent: 04 September 2005 17:09 To: Garrett Heaver Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] GiST intarray Memory Allocation On Sun, Sep 04, 2005 at 04:49:27PM +0100, Garrett Heaver wrote: > I have a table with circa 5.5Million rows and an int4[] column containing > about 28 elements each. > > When I try to put a CREATE INDEX name ON table USING gist(column); > I get the following : > > ERROR: invalid memory alloc request size 2825271912 Hmm. Have you tried a plain SELECT * FROM table? It sounds like your table may be corrupt. Another alternative is that the opclass functions are buggy. If the table is not corrupt, you could try giving us complete working instructions to try to reproduce the bug. -- Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end." (2nd Commandment for C programmers)
Just to confirm also I dumped the database and restored to a Suse Linux 9.3 Box Same problem occurs (different alloc request size though) I can forward a dump of the database if required Cheers Garrett -----Original Message----- From: pgsql-bugs-owner@postgresql.org [mailto:pgsql-bugs-owner@postgresql.org] On Behalf Of Garrett Heaver Sent: 04 September 2005 17:14 To: 'Alvaro Herrera' Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] GiST intarray Memory Allocation Performed full table select - worked perfectly I can give you a dump of the table if that will help Thanks Garrett -----Original Message----- From: Alvaro Herrera [mailto:alvherre@alvh.no-ip.org] Sent: 04 September 2005 17:09 To: Garrett Heaver Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] GiST intarray Memory Allocation On Sun, Sep 04, 2005 at 04:49:27PM +0100, Garrett Heaver wrote: > I have a table with circa 5.5Million rows and an int4[] column containing > about 28 elements each. > > When I try to put a CREATE INDEX name ON table USING gist(column); > I get the following : > > ERROR: invalid memory alloc request size 2825271912 Hmm. Have you tried a plain SELECT * FROM table? It sounds like your table may be corrupt. Another alternative is that the opclass functions are buggy. If the table is not corrupt, you could try giving us complete working instructions to try to reproduce the bug. -- Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end." (2nd Commandment for C programmers) ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
"Garrett Heaver" <garrett.heaver@researchandmarkets.com> writes: > Just to confirm also > I dumped the database and restored to a Suse Linux 9.3 Box > Same problem occurs (different alloc request size though) > I can forward a dump of the database if required Please (unless you've already heard from Oleg or Teodor, who are probably more qualified to debug it than I am). Offlist of course. regards, tom lane