[BUGS] BUG #6643: [PostgreSQL9.2beta1] COPY after changing fillfactor gets a PANIC.
The following bug has been logged on the website: Bug reference: 6643 Logged by: Tomonari Katsumata Email address: katsumata.tomon...@po.ntts.co.jp PostgreSQL version: Unsupported/Unknown Operating system: RHEL 6.2 x86_64 Description: Hi, Now, I'm testing PostgreSQL 9.2 Beta 1. And I have a problem. Steps to procedure are bellow. 1. CREATE DATABASE export LANG=C initdb -D $PGDATA -E SQL_ASCII pg_ctl start createdb testdb 2. CREATE TABLE psql -d testdb -f ./create_table_customer.sql 3. ALTER TABLE(fillfactor) psql -d testdb -c "ALTER TABLE customer SET (fillfactor=90);" 4. LOAD DATA (please set correct path to customer.data) psql -d testdb -f ./customer.sql Then, I have a PANIC error. == BEGIN TRUNCATE TABLE PANIC: failed to add tuple to page CONTEXT: COPY customer, line 296: "296>ALNGAT>alngat>EgBEEAyXVIAWBE>KCiDDFsqA8Kv>2586068>4067234479>ALNGAT@kuvkaEEyi>20100905>20101023>..." STATEMENT: COPY customer FROM '/home/katsumata/work/2012/20120516_PG92beta1_bug1/copy_panic_dbt1/copy_panic/customer.data' WITH DELIMITER '>'; psql:./customer.sql:3: PANIC: failed to add tuple to page CONTEXT: COPY customer, line 296: "296>ALNGAT>alngat>EgBEEAyXVIAWBE>KCiDDFsqA8Kv>2586068>4067234479>ALNGAT@kuvkaEEyi>20100905>20101023>..." PANIC: failed to add tuple to page CONTEXT: COPY customer, line 296: "296>ALNGAT>alngat>EgBEEAyXVIAWBE>KCiDDFsqA8Kv>2586068>4067234479>ALNGAT@kuvkaEEyi>20100905>20101023>..." psql:./customer.sql:3: connection to server was lost == If I skip the 3rd step(ALTER TABLE(fillfactor)), I don't have any ERROR. And It's also OK on PostgreSQL 9.1.3. Are there any changes about this behavior ? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6643: [PostgreSQL9.2beta1] COPY after changing fillfactor gets a PANIC.
On 16.05.2012 13:39, katsumata.tomon...@po.ntts.co.jp wrote: Now, I'm testing PostgreSQL 9.2 Beta 1. And I have a problem. Steps to procedure are bellow. 1. CREATE DATABASE export LANG=C initdb -D $PGDATA -E SQL_ASCII pg_ctl start createdb testdb 2. CREATE TABLE psql -d testdb -f ./create_table_customer.sql 3. ALTER TABLE(fillfactor) psql -d testdb -c "ALTER TABLE customer SET (fillfactor=90);" 4. LOAD DATA (please set correct path to customer.data) psql -d testdb -f ./customer.sql Then, I have a PANIC error. == BEGIN TRUNCATE TABLE PANIC: failed to add tuple to page CONTEXT: COPY customer, line 296: "296>ALNGAT>alngat>EgBEEAyXVIAWBE>KCiDDFsqA8Kv>2586068>4067234479>ALNGAT@kuvkaEEyi>20100905>20101023>..." STATEMENT: COPY customer FROM '/home/katsumata/work/2012/20120516_PG92beta1_bug1/copy_panic_dbt1/copy_panic/customer.data' WITH DELIMITER '>'; psql:./customer.sql:3: PANIC: failed to add tuple to page CONTEXT: COPY customer, line 296: "296>ALNGAT>alngat>EgBEEAyXVIAWBE>KCiDDFsqA8Kv>2586068>4067234479>ALNGAT@kuvkaEEyi>20100905>20101023>..." PANIC: failed to add tuple to page CONTEXT: COPY customer, line 296: "296>ALNGAT>alngat>EgBEEAyXVIAWBE>KCiDDFsqA8Kv>2586068>4067234479>ALNGAT@kuvkaEEyi>20100905>20101023>..." psql:./customer.sql:3: connection to server was lost == If I skip the 3rd step(ALTER TABLE(fillfactor)), I don't have any ERROR. And It's also OK on PostgreSQL 9.1.3. Are there any changes about this behavior ? This sounds like a bug in the new page-at-a-time behavior in COPY. Can you send me a self-contained test, including the test data? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6643: [PostgreSQL9.2beta1] COPY after changing fillfactor gets a PANIC.
On 16.05.2012 13:47, Heikki Linnakangas wrote: This sounds like a bug in the new page-at-a-time behavior in COPY. Can you send me a self-contained test, including the test data? Never mind. After staring at the code for a while, I spotted the bug, and was able to reproduce with a simpler case. It's quite easy to reproduce when you set fillfactor even lower, like 10. The problem is with this line in heap_multi_insert function: if (PageGetHeapFreeSpace(page) - saveFreeSpace < MAXALIGN(heaptup->t_len)) That doesn't work as intended, because the return value of PageGetHeapFreeSpace and saveFreeSpace are unsigned. When saveFreeSpace is larger than the amount of free space on the page, the left hand side of that comparison is supposed to go negative, but it wraps around to a highly positive number because it's unsigned. Fixed, thanks for the report! -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6643: [PostgreSQL9.2beta1] COPY after changing fillfactor gets a PANIC.
Hi, Heikki I'm sorry, forgotten attach files. I've tryed to send mail with files, but I could not... (I think this is my mail server problem.) Thank you very much for fixing it! (2012/05/16 20:14), Heikki Linnakangas wrote: On 16.05.2012 13:47, Heikki Linnakangas wrote: This sounds like a bug in the new page-at-a-time behavior in COPY. Can you send me a self-contained test, including the test data? Never mind. After staring at the code for a while, I spotted the bug, and was able to reproduce with a simpler case. It's quite easy to reproduce when you set fillfactor even lower, like 10. The problem is with this line in heap_multi_insert function: if (PageGetHeapFreeSpace(page) - saveFreeSpace < MAXALIGN(heaptup->t_len)) That doesn't work as intended, because the return value of PageGetHeapFreeSpace and saveFreeSpace are unsigned. When saveFreeSpace is larger than the amount of free space on the page, the left hand side of that comparison is supposed to go negative, but it wraps around to a highly positive number because it's unsigned. Fixed, thanks for the report! -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 9.2beta1 regression: pg_restore --data-only does not set sequence values any more
Martin Pitt writes: > while packaging 9.2 beta 1 for Debian/Ubuntu the postgresql-common > test suite noticed a regression: It seems that pg_restore --data-only > now skips the current value of sequences, so that in the upgraded > database the sequence counter is back to the default. I believe this is a consequence of commit a4cd6abcc901c1a8009c62a27f78696717bb8fe1, which introduced the entirely false assumption that --schema-only and --data-only have something to do with the order that entries appear in the archive ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6641: uuid.h warning during configure
The following bug has been logged on the website: Bug reference: 6641 Logged by: Chris Ruprecht Email address: ch...@cdrbill.com PostgreSQL version: 9.1.3 Operating system: Mac OS X 10.7.4 Description: running configure as such: export MACOSX_DEPLOYMENT_TARGET=10.7 export CC=gcc export CPP="gcc -E" export CXX=g++ export CXXFLAGS='-O3 -fno-common -arch x86_64' export CFLAGS='-O3 -fno-common -arch x86_64' export LDFLAGS='-O3 -fno-common -arch x86_64' ./configure \ --prefix=/usr/local \ --enable-integer-datetimes \ --enable-thread-safety\ --with-libxml \ --with-libxslt\ --with-ossp-uuid \ --with-tcl \ --with-perl \ --with-python \ --with-gssapi \ --with-krb5 \ --with-pam \ --with-ldap \ --with-bonjour \ --with-openssl \ --with-zlib During the configuration phase, I get this message: checking uuid.h presence... yes configure: WARNING: uuid.h: present but cannot be compiled configure: WARNING: uuid.h: check for missing prerequisite headers? configure: WARNING: uuid.h: see the Autoconf documentation configure: WARNING: uuid.h: section "Present But Cannot Be Compiled" configure: WARNING: uuid.h: proceeding with the preprocessor's result configure: WARNING: uuid.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ## configure: WARNING: ## ## checking for uuid.h... yes -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 9.2beta1 regression: pg_restore --data-only does not set sequence values any more
On Wed, May 16, 2012 at 9:08 AM, Tom Lane wrote: > Martin Pitt writes: > > while packaging 9.2 beta 1 for Debian/Ubuntu the postgresql-common > > test suite noticed a regression: It seems that pg_restore --data-only > > now skips the current value of sequences, so that in the upgraded > > database the sequence counter is back to the default. > > I believe this is a consequence of commit > a4cd6abcc901c1a8009c62a27f78696717bb8fe1, which introduced the entirely > false assumption that --schema-only and --data-only have something to > do with the order that entries appear in the archive ... > > > Darn, will investigate. cheers andrew
[BUGS] BUG #6645: Getting an error with “ERROR: PL/Perl function must return reference to hash or array”?
The following bug has been logged on the website:
Bug reference: 6645
Logged by: Evna Carroll
Email address: m...@evancarroll.com
PostgreSQL version: 9.1.2
Operating system: Linux
Description:
This is a cross post from dba.stackexchange.com:
http://dba.stackexchange.com/q/17998/2639
The follow code used to work in Postgresql 8.4.11 with perl v5.10.1:
=# select * From testfunction();
testfunction
http://www.google.com/
However, after doing a dump and load into Postgresql 9.1.3 with perl v5.14.2
I get:
ERROR: PL/Perl function must return reference to hash or array
CONTEXT: PL/Perl function "testfunction"
For reference, here is the function:
CREATE OR REPLACE FUNCTION testfunction(OUT text) AS $$
use URI;
return URI->new('http://www.google.com/')->canonical;
$$ LANGUAGE plperlu;
Again, the version of perl changed from v5.10.1 to v5.14.2; however, the
return from Data::Peek is the same across both versions:
$ perl -MData::Peek -MURI -e'DPeek(
URI->new(q[http://www.google.com])->canonical
);'
Output on both versions of perl:
\PVMG("http://www.google.com/"\0)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: [BUGS] BUG #6645: Getting an error with “ERROR: PL/Perl function must return reference to hash or array”?
On Wed, May 16, 2012 at 10:47 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6645
> Logged by: Evna Carroll
> Email address: m...@evancarroll.com
> PostgreSQL version: 9.1.2
> Operating system: Linux
> Description:
>
> This is a cross post from dba.stackexchange.com:
> http://dba.stackexchange.com/q/17998/2639
>
> The follow code used to work in Postgresql 8.4.11 with perl v5.10.1:
> CREATE OR REPLACE FUNCTION testfunction(OUT text) AS $$
> use URI;
> return URI->new('http://www.google.com/')->canonical;
> $$ LANGUAGE plperlu;
URI->canonical() returns some kind of blessed object, you can get it
to work by coercing the result to a string first:
CREATE OR REPLACE FUNCTION testfunction(OUT text) AS $$
use URI;
return URI->new('http://www.google.com/')->canonical().'';
$$ LANGUAGE plperlu;
We tightened this up over in:
commit 7c64c9f6b767b84597d69cfa2ae03d9a9655ec75
Author: Tom Lane
Date: Thu Oct 13 18:02:43 2011 -0400
Fix up Perl-to-Postgres datatype conversions in pl/perl.
This patch restores the pre-9.1 behavior that pl/perl functions returning
VOID ignore the result value of their last Perl statement. 9.1.0
unintentionally threw an error if the last statement returned a reference,
as reported by Amit Khandekar.
[...snip...]
In addition, ensure we throw errors for attempts to return arrays or hashes
when the function's declared result type is not an array or composite type,
respectively. Pre-9.1 versions rather uselessly returned strings like
ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the
hash case and returned a garbage value for the array case.
[...snip...]
As noted above if you return a reference you would get a mostly
useless string like "HASH(0x...)". Post commit above it now gives you
the error "ERROR: cannot convert Perl hash to non-composite type
text" instead. That seemed better at the time because its almost
always a mistake (with what you return or your declared return type).
That being said it seems we failed to take any magic (aka string
overloads) that a blessed reference might have. Ill see about
submitting a patch for 9.3 (9.2 just entered beta). Anyone have any
thoughts on if we should backpatch a fix?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Re: [BUGS] BUG #6645: Getting an error with “ERROR: PL/Perl function must return reference to hash or array”?
Alex Hunsaker writes: > That being said it seems we failed to take any magic (aka string > overloads) that a blessed reference might have. Ill see about > submitting a patch for 9.3 (9.2 just entered beta). Anyone have any > thoughts on if we should backpatch a fix? Right offhand I'd be +1 for making that change, but not for backpatching it; but I'm not a big plperl user. Would such a case have worked before 9.1? If it did and we broke it in 9.1, that would be a good reason to back-patch into 9.1. If it never worked, then it sounds like a new feature. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: [BUGS] Re: [BUGS] BUG #6645: Getting an error with “ERROR: PL/Perl function must return reference to hash or array”?
On Wed, May 16, 2012 at 11:53 AM, Tom Lane wrote: > Alex Hunsaker writes: >> That being said it seems we failed to take any magic (aka string >> overloads) that a blessed reference might have. Ill see about >> submitting a patch for 9.3 (9.2 just entered beta). Anyone have any >> thoughts on if we should backpatch a fix? > > Right offhand I'd be +1 for making that change, but not for backpatching > it; but I'm not a big plperl user. Would such a case have worked before > 9.1? If it did and we broke it in 9.1, that would be a good reason to > back-patch into 9.1. If it never worked, then it sounds like a new > feature. Yeah, it worked pre 9.1. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6642: Spanish collation fault
Excerpts from tulio.carrasco's message of mar may 15 21:45:00 -0400 2012: > In Spanish every vowel has the same precedence value even with or without > any type of accent, so: a = á = ä = A = Á = Ä > In which due dad column has the same value it uses the mum column and if > they also have the same value then it should use the name column. I see your point, and it makes sense, but it just doesn't work that way. The way it works is that it goes over the first column and does the two passes (first ignoring accents, second considering them) over it using the collating rules you describe; and once that is complete, it goes to look at the second column. I don't think it's possible at all to implement what you suggest, which is to make the first pass over all the columns and then the second pass over all the columns. I didn't try, but if you were to do an ORDER BY dad || ' ' || mum ' ' || name I think it should do what you want. (Not really sure the spaces are necessary). Because then you're sorting on a single string and it can do the first pass on the whole thing and then the second pass. -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6644: Query give wrong results when 'is not null' is applied in where clause
The following bug has been logged on the website: Bug reference: 6644 Logged by: Karl Walbrecht Email address: kwalbre...@cghtech.com PostgreSQL version: 9.0.3 Operating system: SunOS 5.10 Description: geom.ArcToStreight(integer) is a function which returns the following type: Composite type "geom.t_line_ref" Column | Type ---+--- line_id | integer start_id | integer mid_id| integer end_id| integer line | geometry line_type | character varying chart_id | integer The following queries show 1) the total number of rows. 2) the number of null rows. 3) the number of not null rows. The problem is that results of query 2 + the results of query 3 should equal the result of query 1 which they do not. SELECT count(*) FROM ( select geom.ArcToStreight(line_id) as a from sdat_legacy.lines where mid_node is not null ) foo ; count --- 14177 (1 row) SELECT count(*) FROM ( select geom.ArcToStreight(line_id) as a from sdat_legacy.lines where mid_node is not null ) foo WHERE foo.a is null ; count --- 13796 (1 row) SELECT count(*) FROM ( select geom.ArcToStreight(line_id) as a from sdat_legacy.lines where mid_node is not null ) foo WHERE foo.a is not null ; count --- 0 (1 row) Clearly something is amiss. 14197 Total number of rows - 13796 Number of null row 381 Expected number of not null rows 0 Number of not null rows returned -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6646: PL/Python spiexceptions raised inside Python do not include sqlstate in external code
The following bug has been logged on the website: Bug reference: 6646 Logged by: Steven Huwig Email address: st...@empiricalthought.com PostgreSQL version: 9.1.3 Operating system: Linux Description: I am trying to raise standard SQL errors from inside PL/Python code. However, they do not work as expected. They always have sqlstate = XX000 instead of the appropriate sqlstate value. create function python_exception_bug() returns void as $$ raise plpy.spiexceptions.InvalidParameterValue() $$ language 'plpython3u'; create function python_exception_sql() returns text as $$ begin select python_exception_bug(); return 'cannot happen'; exception when invalid_parameter_value then return 'expected behavior'; when others then return 'this is a bug'; end $$ language 'plpgsql'; -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6644: Query give wrong results when 'is not null' is applied in where clause
kwalbre...@cghtech.com writes: > geom.ArcToStreight(integer) is a function which returns the following type: > The following queries show 1) the total number of rows. 2) the number of > null rows. 3) the number of not null rows. > The problem is that results of query 2 + the results of query 3 should equal > the result of query 1 which they do not. Well, you didn't provide enough detail to let somebody else reproduce the problem, but I suspect your issue is that IS NULL and IS NOT NULL are not all the possible states of a composite value. Per http://www.postgresql.org/docs/9.0/static/functions-comparison.html Note: If the expression is row-valued, then IS NULL is true when the row expression itself is null or when all the row's fields are null, while IS NOT NULL is true when the row expression itself is non-null and all the row's fields are non-null. Because of this behavior, IS NULL and IS NOT NULL do not always return inverse results for row-valued expressions, i.e., a row-valued expression that contains both NULL and non-null values will return false for both tests. This definition conforms to the SQL standard, and is a change from the inconsistent behavior exhibited by PostgreSQL versions prior to 8.2. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6642: Spanish collation fault
Thank you very much Álvaro, As far as I understood from someone who knows about ;) "...the SQL standard indicates to order according the first column and consider the second column only for those records which first column has identical order values..." The bug I refer to is that first column is FINALLY ordered for character value -not the order value which the collation requests. "León", "leon", "leOn" has identical order values: none of them weights more for Spanish collation and PG is not working according it if PG makes a "second pass" that ignores collation and reorders by its character value. Best Regards Tulio On Wed, May 16, 2012 at 2:20 PM, Alvaro Herrera wrote: > > Excerpts from tulio.carrasco's message of mar may 15 21:45:00 -0400 2012: > > > In Spanish every vowel has the same precedence value even with or without > > any type of accent, so: a = á = ä = A = Á = Ä > > > In which due dad column has the same value it uses the mum column and if > > they also have the same value then it should use the name column. > > I see your point, and it makes sense, but it just doesn't work that way. > > The way it works is that it goes over the first column and does the two > passes (first ignoring accents, second considering them) over it using > the collating rules you describe; and once that is complete, it goes to > look at the second column. I don't think it's possible at all to > implement what you suggest, which is to make the first pass over all the > columns and then the second pass over all the columns. > > I didn't try, but if you were to do an ORDER BY dad || ' ' || mum ' ' || > name > I think it should do what you want. (Not really sure the spaces are > necessary). Because then you're sorting on a single string and it can > do the first pass on the whole thing and then the second pass. > > -- > Álvaro Herrera > The PostgreSQL Company - Command Prompt, Inc. > PostgreSQL Replication, Consulting, Custom Development, 24x7 support >
