[BUGS] BUG #8395: empty aclitem arrays are considered 1-dimensional
The following bug has been logged on the website:
Bug reference: 8395
Logged by: Alexey Bashtanov
Email address: bashta...@imap.cc
PostgreSQL version: 9.1.9
Operating system: Ubuntu linux 12.04
Description:
Empty aclitem arrays are considered 1-dimensional, but in general empty
arrays are 0-dimensional. It leads to the following problems:
STEPS TO REPRODUCE
1) install fresh postgres, connect to it
2) select relacl, relacl = '{}'::aclitem[], (select aclexplode(relacl)),
array_length(relacl, 1) from pg_class where oid::regclass =
'pg_largeobject'::regclass;
3) select aclexplode('{}'::aclitem[]);
EXPECTED
2) {}, false, null, null
3) no error, zero-lines table
GOT
2) relacl | ?column? | ?column? | array_length
+--+--+--
{} | f| |0
3) ERROR: ACL arrays must be one-dimensional
also it can be reproduced on some 9.2 version
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] hstore: null value is treated as empty string by avals function
hstore: null value is treated as empty string by avals function
# select avals('gfds'=>null) = array[null], avals('gfds'=>null) =
array[''], version();
?column? | ?column? |
version
--+--+--
f| t| PostgreSQL 8.4.4 on x86_64-redhat-linux-gnu,
compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46), 64-bit
(1 row)
got f,t
expected t,f
hope the problem is clear
regards,
Alexey
--
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 #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation
The following bug has been logged online: Bug reference: 4887 Logged by: Alexey Bashtanov Email address: bashta...@imap.cc PostgreSQL version: 8.3.1, 8.3.7 Operating system: Linux 2.6.20 FC5 i686, Linux 2.6.27 FC10 i686 Description:inclusion operator (@>) on tsqeries behaves not conforming to documentation Details: Hello! '!a|b'::tsquery <@ 'a|b'::tsquery evaluates to false, but should evalueate to true (http://www.postgresql.org/docs/8.3/interactive/functions-textsearch.html says "The tsquery containment operators consider only the lexemes listed in the two queries, ignoring the combining operators.") I think negation operator is treated as a lexeme. So please correct the behaviour of operators or rewrite this line of docs. Thanks, Alexey -- 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 #4513: VACUUM FULL fails with "out of memory" error
The following bug has been logged online: Bug reference: 4513 Logged by: Alexey Bashtanov Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: Red Hat Linux 2.6.20-1.2320.fc5smp i686 Description:VACUUM FULL fails with "out of memory" error Details: Hello! Such a thing happens: when I make an attempt to vacuum full a table it waits some minutes and then throws an error: ERROR: out of memory DETAIL: Failed on request of size 288. It doesn't matter I set maintenance_work_mem to 16MB, 200MB or 1GB. This table is bad enough: it has a size of 154G but "explain select *" says there are only 524597 rows (and that value seems to be near to true). It is not wide: integer, integer, character varying(10), integer, character varying(3), date, integer. Here's the part of serverlog: == TopMemoryContext: 49416 total in 6 blocks; 8776 free (46 chunks); 40640 used TopTransactionContext: 2986336304 total in 367 blocks; 192312 free (1088 chunks); 2986143992 used Type information cache: 8192 total in 1 blocks; 1800 free (0 chunks); 6392 used Operator class cache: 8192 total in 1 blocks; 3848 free (0 chunks); 4344 used Record information cache: 8192 total in 1 blocks; 1800 free (0 chunks); 6392 used Operator lookup cache: 24576 total in 2 blocks; 14072 free (6 chunks); 10504 used MessageContext: 8192 total in 1 blocks; 5664 free (0 chunks); 2528 used smgr relation table: 8192 total in 1 blocks; 2808 free (0 chunks); 5384 used TransactionAbortContext: 32768 total in 1 blocks; 32752 free (0 chunks); 16 used Portal hash: 8192 total in 1 blocks; 3912 free (0 chunks); 4280 used PortalMemory: 8192 total in 1 blocks; 8040 free (0 chunks); 152 used PortalHeapMemory: 3072 total in 2 blocks; 2928 free (8 chunks); 144 used Vacuum: 8192 total in 1 blocks; 7872 free (0 chunks); 320 used Relcache by OID: 8192 total in 1 blocks; 3376 free (0 chunks); 4816 used CacheMemoryContext: 667472 total in 20 blocks; 108288 free (0 chunks); 559184 used pg_index_indrelid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_settings: 15360 total in 4 blocks; 6912 free (0 chunks); 8448 used pg_ts_dict_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_aggregate_fnoid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_language_name_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_statistic_relid_att_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used pg_ts_dict_dictname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_namespace_nspname_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_opfamily_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_opclass_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_ts_parser_prsname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_amop_fam_strat_index: 1024 total in 1 blocks; 88 free (0 chunks); 936 used pg_opclass_am_name_nsp_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used pg_trigger_tgrelid_tgname_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used pg_cast_source_target_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used pg_auth_members_role_member_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_attribute_relid_attnum_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used pg_ts_config_cfgname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_authid_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_ts_config_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_conversion_default_index: 1024 total in 1 blocks; 128 free (0 chunks); 896 used pg_language_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_enum_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_proc_proname_args_nsp_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used pg_ts_parser_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_database_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_conversion_name_nsp_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_class_relname_nsp_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used pg_attribute_relid_attnam_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_class_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_amproc_fam_proc_index: 1024 total in 1 blocks; 88 free (0 chunks); 936 used pg_operator_oprname_l_r_n_index: 1024 total in 1 blocks; 88 free (0 chunks); 936 used pg_index_indexrelid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_type_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_rewrite_rel_rulename_index: 1024 total in 1 blocks;
Re: [BUGS] BUG #4271: dropped columns conflict with returning rules
Hello, Tom! > What did you do *exactly*? Here's the example of command sequence that lead to this error: luh=# create table foo(a int); CREATE TABLE luh=# alter TABLE foo add column b int; ALTER TABLE luh=# alter TABLE foo drop column b; ALTER TABLE luh=# alter TABLE foo add column c int; ALTER TABLE luh=# create table foo_child() inherits (foo); CREATE TABLE luh=# create or replace rule myrule as on insert to foo do instead insert into foo_child values(new.*) returning foo_child.*; ERROR: cannot convert relation containing dropped columns to view luh=# > > this rule started to work incorrectly: it did not store foo and quackquack > > values but used nulls instead. > > This is expected behavior because the * expressions are expanded when > the rule is defined: That's OK Thanks, Alexey -- http://www.fastmail.fm - The way an email service should be -- 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 #4271: dropped columns conflict with returning rules
The following bug has been logged online: Bug reference: 4271 Logged by: Alexey Bashtanov Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: linux Description:dropped columns conflict with returning rules Details: I have created a partitioned table cache with partitions cache_id_g_4184088 and cache_id_le_4184088 those inherit cache. I provided insert by the following rule: CREATE RULE cache_partic AS ON INSERT TO cache DO INSTEAD INSERT INTO cache_id_g_4184088 VALUES (new.*) RETURNING cache_id_g_4184088.*; after I ran ALTER TABLE cache add column foo ALTER TABLE cache add column bar ALTER TABLE cache drop column bar ALTER TABLE cache add column quackquack this rule started to work incorrectly: it did not store foo and quackquack values but used nulls instead. When I tried to ReCREATE this rule, POSTGRESQL said 'ERROR: cannot convert relation containing dropped columns to view' -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
