[BUGS] BUG #6041: Unlogged table was created bad in slave node
The following bug has been logged online: Bug reference: 6041 Logged by: Emanuel Email address: postgres@gmail.com PostgreSQL version: 9.1 beta Operating system: Ubuntu Description:Unlogged table was created bad in slave node Details: MASTER= SLAVE SYNC=6667 SLAVE ASYNC=6668 root@dell-desktop:/usr/local/pgsql# bin/psql -Upostgres -p psql (9.1beta1) Type "help" for help. postgres=# CREATE UNLOGGED TABLE voidy AS SELECT i, random() FROM generate_series(1,1000) i(i); SELECT 1000 postgres=# \q root@dell-desktop:/usr/local/pgsql# bin/psql -Upostgres -p6667 psql (9.1beta1) Type "help" for help. postgres=# \d voidy Unlogged table "public.voidy" Column | Type | Modifiers +--+--- i | integer | random | double precision | postgres=# select * from voidy ; ERROR: could not open file "base/12071/17034": No existe el archivo o directorio postgres=# \q root@dell-desktop:/usr/local/pgsql# bin/psql -Upostgres -p6668 psql (9.1beta1) Type "help" for help. postgres=# \d voidy Unlogged table "public.voidy" Column | Type | Modifiers +--+--- i | integer | random | double precision | postgres=# select * from voidy ; ERROR: could not open file "base/12071/17034": No existe el archivo o directorio -- 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 #6043: Compilation PLpgsql Succesful but execution bad
The following bug has been logged online: Bug reference: 6043 Logged by: Emanuel Email address: postgres@gmail.com PostgreSQL version: 9.1 beta Operating system: Ubuntu 10.04 2.6.31 Description:Compilation PLpgsql Succesful but execution bad Details: postgres=# CREATE OR REPLACE FUNCTION p_() RETURNS TABLE (i int) AS $$ DECLARE BEGIN SELECT * FROM p; --<<<-- here must ne RETURN QUERY .. END; $$ LANGUAGE plpgsql; CREATE FUNCTION postgres=# select p_(); ERROR: query has no destination for result data HINT: If you want to discard the results of a SELECT, use PERFORM instead. CONTEXT: PL/pgSQL function "p_" line 4 at SQL statement I don't know if it's really a bug or a feature request. But seems that the function compiles well without checking the existence of a RETURN QUERY. I think the best in this cases is raise an error during compilation. Thougths? -- 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 #6045: Compilation of contribs fail
The following bug has been logged online: Bug reference: 6045 Logged by: Emanuel Email address: postgres@gmail.com PostgreSQL version: 9.1beta Operating system: Ubuntu 10.04 2.6.31 Description:Compilation of contribs fail Details: make and make installs work well. To compile correctly I must hardcode the libdir. I happens with several contribs. root@dell-desktop:/home/ecalvo-laptop/postgresql-9.1beta1/contrib/pgstattupl e# /usr/local/pgsql/bin/psql -Upostgres < pgstattuple--1.0.sql ERROR: could not access file "MODULE_PATHNAME": No existe el archivo o directorio ERROR: could not access file "MODULE_PATHNAME": No existe el archivo o directorio ERROR: could not access file "MODULE_PATHNAME": No existe el archivo o directorio ERROR: could not access file "MODULE_PATHNAME": No existe el archivo o directorio # ECHO .control root@dell-desktop:/home/ecalvo-laptop/postgresql-9.1beta1/contrib/pgstattupl e# cat pgstattuple.control # pgstattuple extension comment = 'show tuple-level statistics' default_version = '1.0' module_pathname = '$libdir/pgstattuple' relocatable = true # PG_CONFIG LIBDIR location root@dell-desktop:/home/ecalvo-laptop/postgresql-9.1beta1/contrib/pgstattupl e# /usr/local/pgsql/bin/pg_config | grep -i libdir LIBDIR = /usr/local/pgsql/lib PKGLIBDIR = /usr/local/pgsql/lib Content of sql: root@dell-desktop:/home/ecalvo-laptop/postgresql-9.1beta1/contrib/pgstattupl e# grep -i MODULE pgstattuple--1.0.sql AS 'MODULE_PATHNAME', 'pgstattuple' AS 'MODULE_PATHNAME', 'pgstattuplebyid' AS 'MODULE_PATHNAME', 'pgstatindex' AS 'MODULE_PATHNAME', 'pg_relpages' Seems that it didn't replace the correct MODULE_PATHNAME with $libdir/contrib... -- 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 #1655: trapping errors doesn't work
The following bug has been logged online: Bug reference: 1655 Logged by: Emanuel Brokmann Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: Red Hat Linux 3.2.3-42 Description:trapping errors doesn't work Details: while executing: >>BEGIN >> insert into comlineprintboxen VALUES(109, '', '', '', >>'', ''); >>EXCEPTION >> WHEN unique_violation then >>UPDATE comlineprintboxen SET verteiler='', >>panel='', dose='', switch='', port='' WHERE >>printboxid=109 >>END; the following error occurs: >>ERROR: syntax error at or near "UPDATE" at character 8 i compared the command with the one from page 550 ff of the documentation, but can't find differences. Would be kind of you to help me Emanuel Brokmann ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #6041: Unlogged table was created bad in slave node
2011/5/26 Euler Taveira de Oliveira : > Em 26-05-2011 08:37, Emanuel escreveu: > >> Description: Unlogged table was created bad in slave node >> > Unlogged table contents are not available to slave nodes [1]. > I know it. But the error raised isn't pretty nice for common users. IMHO it could be an empty file with a message of WARNING level, for notify administratros to watch up these tables. >> postgres=# select * from voidy ; >> ERROR: could not open file "base/12071/17034": No existe el archivo o >> directorio >> > I think we should emit the real cause in those cases, if possible (not too > much overhead). The message would be "Unlogged table content is not > available in standby server". > I think that detecting if table is unlogged && file not exists, rise this message. But the problem will comes when the standby is promoted to master, in that case I didn't test what happens (file not exists, i think it will couldn't insert data directly or may force to the dba drop the table from catalog). -- -- Emanuel Calvo Helpame.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 #6043: Compilation PLpgsql Succesful but execution bad
El 27/05/2011 16:18, "Heikki Linnakangas" < heikki.linnakan...@enterprisedb.com> escribió: > On 27.05.2011 17:05, Emanuel wrote: >> postgres=# CREATE OR REPLACE FUNCTION p_() RETURNS TABLE (i int) AS $$ >> DECLARE >> BEGIN >> SELECT * FROM p; --<<<-- here must ne RETURN QUERY .. >> END; >> $$ LANGUAGE plpgsql; >> CREATE FUNCTION >> postgres=# select p_(); >> ERROR: query has no destination for result data >> HINT: If you want to discard the results of a SELECT, use PERFORM instead. >> CONTEXT: PL/pgSQL function "p_" line 4 at SQL statement >> >> I don't know if it's really a bug or a feature request. But seems that the >> function compiles well without checking the existence of a RETURN QUERY. I >> think the best in this cases is raise an error during compilation. Thanks Heikki for your fast response! ^^ > The compiler would have to determine that the loop never ends, or it > would complain that there's no RETURN at the end. > > Many compilers for other languages do that kind of analysis, but it > usually only results in a warning, and compilers sometimes get that > wrong. I don't think it's worthwhile to do that, but of course, patches > are welcome. > Yeah, it's not a very big concern, althougth cold be taken for future improvements in plpgsql. I very far for submit a patch :P Regards, E
Re: [BUGS] BUG #6043: Compilation PLpgsql Succesful but execution bad
>> >> Thanks Heikki for your fast response! ^^ >> >> >>> The compiler would have to determine that the loop never ends, or it >>> would complain that there's no RETURN at the end. >>> >>> Many compilers for other languages do that kind of analysis, but it >>> usually only results in a warning, and compilers sometimes get that >>> wrong. I don't think it's worthwhile to do that, but of course, patches >>> are welcome. >>> >> >> Yeah, it's not a very big concern, althougth cold be taken for future >> improvements >> in plpgsql. I very far for submit a patch :P >> > > The deep check of embedded SQL is not possible in PL/pgSQL - this > remove dependency between PL/pgSQL and database objects. Deeper checks > mean a broken compatibility :(. > Good point. > PL/PSM has different philosophy where full check is implemented now. > Do you think that make some test in 9.1 worthwhile for this language? I see that the last contrib was submitted years ago. Regards, -- -- Emanuel Calvo Helpame.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 #6045: Compilation of contribs fail
2011/5/29 hubert depesz lubaczewski : > On Sun, May 29, 2011 at 11:16:30AM +0000, Emanuel wrote: >> make and make installs work well. To compile correctly I must hardcode the >> libdir. I happens with several contribs. > > did you actually do make and make install *in* contrib directory? > No, I'm making the make inside the contrib/pgstattuple , not in contrib directory (as always do in other versions). > one shouldn't load sql files from the sources, and it looks like you're > trying to do it. > I'm doing like other versions: make; make install and then: psql < xxxx.sql Does it change for 9.1? -- -- Emanuel Calvo Helpame.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 #6045: Compilation of contribs fail
>> I'm doing like other versions: > >> make; make install > > That's correct. > >> and then: >> psql < .sql > > That's not correct anymore. Use CREATE EXTENSION. > Thanks Tom, I thougth that the old way was already compatible. Regards, -- -- Emanuel Calvo Helpame.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Where is pg_create_restore_point funciton in 9.1a2 ?
I'm still finding pg_create_restore_point in 9.1a2 documentation:
http://www.postgresql.org/docs/9.1/static/functions-admin.html
But I've compiled that version and I didn't found it:
postgres=# \df *create_restore*
List of functions
Schema | Name | Result data type | Argument data types | Type
+--+--+-+--
(0 rows)
postgres=# select pg_create_restore_point('name');
ERROR: function pg_create_restore_point(unknown) does not exist
LINE 1: select pg_create_restore_point('name');
^
HINT: No function matches the given name and argument types. You
might need to add explicit type casts.
postgres=# select pg_create_restore_point('name'::text);
ERROR: function pg_create_restore_point(text) does not exist
LINE 1: select pg_create_restore_point('name'::text);
^
HINT: No function matches the given name and argument types. You
might need to add explicit type casts.
By the way, another issue that I found is when I execute \df. It
doesn't display anything (I must
force with * to do that).
I don't know if it is correct but in other releases it displays all
the functions (as \d displays
all the relations in this one).
--
--
Emanuel Calvo
Helpame.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] Where is pg_create_restore_point funciton in 9.1a2 ?
2011/6/22 Jaime Casanova : > On Wed, Jun 22, 2011 at 3:28 AM, Emanuel Calvo wrote: >> I'm still finding pg_create_restore_point in 9.1a2 documentation: >> http://www.postgresql.org/docs/9.1/static/functions-admin.html >> >> But I've compiled that version and I didn't found it: >> >> postgres=# \df *create_restore* >> List of functions >> Schema | Name | Result data type | Argument data types | Type >> +--+--+-+-- >> (0 rows) >> > > the function exists... and it should appear, it does for me > > postgres=# \df *create_re* > List of functions > Schema | Name | Result data type | Argument > data types | Type > +-+--+-+ > pg_catalog | pg_create_restore_point | text | text > | normal > (1 row) I'm using alpha2 release. I recompiled and I didn't found errors during the compilation. Is still missing for me, I will try to download the source from another repo. -- -- Emanuel Calvo Helpame.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] application_name appears in Reporting and logging
I don't know but seems to be incorrect, it is really in this category? Version 9.1 beta 2 postgres=# select * from pg_settings where name = 'application_name'; -[ RECORD 1 ] name | application_name setting| psql unit | category | Reporting and Logging / What to Log short_desc | Sets the application name to be reported in statistics and logs. extra_desc | context| user vartype| string source | client -- -- Emanuel Calvo Helpame.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] [HACKERS] PostgreSQL installation
> I am from Cambodia. I want to use PostgreSQL. But I am poor of knowledge to
> install could you please help me give some guide to install PostgreSQL on
> Solaris 10,
(+ to pgsql-general)
Try to use the general list for these cases, you could obtain better
results ;)
The documentation for Solaris are in the site #1, you will find since
installation until complex trace rutines.
Enjoy it!
#1[http://www.sun.com/software/products/postgresql/index.jsp]
Regards,
--
Emanuel Calvo Franco
ArPUG [www.arpug.com.ar] / AOSUG Member
www.emanuelcalvofranco.com.ar
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
