Re: [BUGS] BUG #5938: PostgreSQL Installer outputs log file with superuser password in clear text
On Tue, Mar 22, 2011 at 4:09 PM, Dave Page dp...@pgadmin.org wrote: On Tue, Mar 22, 2011 at 3:45 PM, Dave Page dp...@pgadmin.org wrote: On Tue, Mar 22, 2011 at 5:10 AM, Craig Sacco craig.sa...@gmail.com wrote: The following bug has been logged online: Bug reference: 5938 Logged by: Craig Sacco Email address: craig.sa...@gmail.com PostgreSQL version: 9.0.3 Operating system: Microsoft Windows (all variants, 32 and 64 bit) Description: PostgreSQL Installer outputs log file with superuser password in clear text Details: The PostgreSQL installer outputs a log file to the temporary directory with the superuser password in clear text. We are deploying PostgreSQL as part of a commercial product and would like to ensure that the password is not available to ordinary users. This has been fixed for the next releases. For the sake of the archives, it should also be noted that the file is in a secure directory, much as a .pgpass file would be, so this is generally only an issue for the situation described above, and not when a user installs a copy himself. Updated one click installers for 9.0.3 on win32 and win64 and for 8.4.7 on win32 are now available from http://www.postgresql.org/download/windows -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] postgres 9 streaming replication
On Wed, Mar 23, 2011 at 9:07 PM, Alex Lai a...@sesda2.com wrote: I have no idea why I keep getting the message:\ could not connect to the primary server: FATAL: no pg_hba.conf entry for replication connection from host slave_server_ip, user my_super_user_name Can you connect from slave to master by the following command? psql replication=1 -h slave_ip -p 5432 -U my_user_name If successful, the settings in recovery.conf would be wrong. Otherwise, I guess that the setting in pg_hba.conf of the master would be wrong. Did you reload the configuration files? What happens if you use all keyword instead of specifying the real user name? What happens if you use 0.0.0.0/0 instead of specifying the slave's ip? You would need to do trial and error approach. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Service Wont Start
We have been using postgres8.4 with the postgis add on for a month. On Monday we had to reboot the server that holds all the databases we use. The server was down for ten minutes and when it was back up and running the databases wouldn't open. We tried to connect back on, but got a server doesn't listen error. Our IT department then went to start the service again. It Started but half way through starting it stopped again. And it now keeps doing that. Would be grateful if you could help. Kind regards Ade Viner Ade Viner CAD/GIS Survey Technician Operational Intelligence Team Gloucestershire Fire Rescue Service Tri Service Emergency centre Waterwells Drive Quedgeley Gloucester GL2 2AX 01452 753396 adrian.vi...@glosfire.gov.uk This e-mail has been scanned for all viruses by Star Internet, using a service powered by MessageLabs. It is believed to be free from viruses but it is your responsibility to carry out all necessary virus checks. Gloucestershire Fire and Rescue Service accepts no liability in connection therewith. This e-mail is intended for the addressee only. If you are not the named addressee you must not disclose, copy or take any action in reliance of this transmission and you should notify us as soon as possible. Thank you. SMOKE ALARMS SAVE LIVES Go to http://www.glosfire.gov.uk for advice THINK BEFORE YOU PRINT - Only print this email if absolutely necessary ___
Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
Update: It has been suggested to wrap perform around a select like this: do $$begin perform( with A as (select 1 as foo) select foo from A ); end$$; This won't work if select returns more than one statement: do $$begin perform( with A as (select generate_series(1,3) as foo) select foo from A ); end$$; ERROR: more than one row returned by a subquery used as an expression So I still say it's broken. (Sorry for top-posting: I am forced to use Outlook at work...) From: Dmitry Epstein Sent: Sunday, March 06, 2011 4:29 PM To: 'pgsql-bugs@postgresql.org' Cc: Peter Gagarinov; Vladimir Shahov Subject: Can't use WITH in a PERFORM query in PL/pgSQL? PostgreSQL 9.0.1 It seems that PostgreSQL doesn't understand the WITH construct when used in a PERFORM query inside PL/pgSQL functions and code blocks: Example: do $$begin with A as (select 1 as foo) perform foo from A; end$$; syntax error at or near perform do $$begin with A as (select 1 as foo) select foo from A; end$$; query has no destination for result data The only workaround that I can think of is to use a dummy variable to capture the query result. This has to be done even when the query doesn't have a result (as when calling a function returning void). do $$declare dummy record; begin with A as (select 1 as foo) select foo into dummy from A; end$$; Dmitry Epstein | Developer Allied Testing T + 7 495 544 48 69 Ext 417 M + 7 926 215 73 36 www.alliedtesting.comhttp://www.alliedtesting.com/ We Deliver Quality.
Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
Hello why you can do it? please, try to RETURN QUERY ... Regards Pavel Stehule $$begin perform( with A as (select generate_series(1,3) as foo) select foo from A ); end$$; -- 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 #5944: COPY FROM doesn't work with international characters
I just tried it from the psql console and it seems to work, which isn't really an option for us to use since we need to be able to let end users load data via our custom designed database application. None of them would understand or know how to use the console. Currently there's no pressing need to be able to do this for us, so we're just loading the data with a series of insert statements instead of COPY FROM. testdb=# SET CLIENT_ENCODING TO 'WIN1252'; SET testdb=# create table tmpintermediate (acnumber character varying(20),acname character varying(50) ); CREATE TABLE testdb=# copy tmpintermediate from 'c:\\temp\\thefile.txt'; WARNING: nonstandard use of \\ in a string literal LINE 1: copy tmpintermediate from 'c:\\temp\\thefile.txt'; ^ HINT: Use the escape string syntax for backslashes, e.g., E'\\'. COPY 1 testdb=# select * from tmpintermediate; acnumber |acname --+-- 230002 | Alto Desempe±o, S.A. De C.V. (1 row) The output is wrong in the select statement from the console, but appears correctly using pgadmin3. I think it's a problem with one if the redistributable libraries instead of postgresql itself. When loading through pgadmin3 or elsewhere the acname field just ends up blank using WIN1252, the COPY FROM will just ignore whatever data is supposed to be loaded into that field when there is an international character. -Original Message- From: pgsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Nathan M. Davalos Sent: Wednesday, March 23, 2011 7:59 PM To: PostgreSQL Bugs Subject: Re: [BUGS] BUG #5944: COPY FROM doesn't work with international characters AcNumber character varying(20), AcName character varying(50) The database itself is: ENCODING = 'UTF8' TABLESPACE = pg_default LC_COLLATE = 'English_United States.1252' LC_CTYPE = 'English_United States.1252' -Original Message- From: John R Pierce [mailto:pie...@hogranch.com] Sent: Wednesday, March 23, 2011 7:54 PM To: Nathan M. Davalos; PostgreSQL Bugs Subject: Re: [BUGS] BUG #5944: COPY FROM doesn't work with international characters On 03/23/11 5:42 PM, Nathan M. Davalos wrote: Just in case the reply didn't go through the character in question is F1. I replied to the message using pgsql-bugs@postgresql.org, but I'm a wee bit new to the bug reporting stuff using the mailing list. The hex of the file in total is 32.33.30.30.30.32.09.41.6C.74.6F.20.44.65.73.65.6D.70.65.F1.6F.2C.20.53.2E.41.2E.20.44.65.20.43.2E.56.2E.0D.0A k, thats certainly win-1252. I see a tab after the 230002, then the rest of it is all one field, ending in a CRLF sequence. The table you're copying this data to, what fields does it have? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- 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] Can't use WITH in a PERFORM query in PL/pgSQL?
On Thu, Mar 24, 2011 at 10:36 AM, Pavel Stehule pavel.steh...@gmail.com wrote: Hello why you can do it? please, try to RETURN QUERY ... Regards Pavel Stehule $$begin perform( with A as (select generate_series(1,3) as foo) select foo from A ); end$$; This is 'DO' statement. Also I think this is legitimate bug: you can do perform func(foo_id) from something; but not with something as (something) perform func(foo_id) from something; this might do as workaround: do $$begin perform( with A as (select 1 as foo) select array(select foo from A) ); end$$; merlin -- 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] Service Wont Start
On 24.03.2011 11:12, Viner, Adrian wrote: We have been using postgres8.4 with the postgis add on for a month. On Monday we had to reboot the server that holds all the databases we use. The server was down for ten minutes and when it was back up and running the databases wouldn't open. We tried to connect back on, but got a server doesn't listen error. Our IT department then went to start the service again. It Started but half way through starting it stopped again. And it now keeps doing that. Would be grateful if you could help. You'll have to provide more information for anyone to be able to help you. Is there anything in the log files that might give a clue? -- 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] ERROR: character 0xe3809c of encoding UTF8 has no equivalent in EUC_JP
Hi, We have a customer in Japan who would be interested in this fix, in the future. Would you like me to enter it as an official Postgres bug? Sincerely, Kasia -Original Message- From: Tatsuo Ishii [mailto:is...@postgresql.org] Sent: Tuesday, March 22, 2011 10:17 PM To: itagaki.takah...@gmail.come Cc: Kasia Tuszynska; pgsql-bugs@postgresql.org Subject: Re: [BUGS] ERROR: character 0xe3809c of encoding UTF8 has no equivalent in EUC_JP Agreed if the encoding is added as an user-defined encoding. I don't want to add built-in encodings only for Japanese language any more. I do not agree here. Adding one more encoding/conversion is not big deal. Anyway these soltions would come to be real after one or two releases at the earliest. The realistic solution available today is replacing default conversion for EUC-JP and UTF-8. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- 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 #5944: COPY FROM doesn't work with international characters
I have another example of this issue with WIN1252. This line in a copy file: 659446 828 1 /6�\bH@^W^Za$H�\b�@\\/pp/ppNo valid or unique HTTP objects found in XML response./p/p Into this table: Table public.ep_tests Column | Type | Modifiers -+--+--- id | bigint | not null v_id| integer | not null status | character(1) | not null vkey| text | details | text | Results in this error while loading the data: the following error is encounted by the \copy: ERROR: missing data for column details CONTEXT: COPY ep_tests, line 1028752: 659446 828 1 /6�\bH@↨ The dump file was produced by using 9.0.3's pg_dump in text mode to dump an 8.2 database, then using 9.0.3's psql to load the file. Both servers are UTF8, locale WIN1252. So it looks like we're not successfully escaping characters on WIN1252. The characters in question are also latin characters. We've reproduced this on a clean install. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.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 #5943: jdbc client doesn't omit pg_toast_temp tables from schema views
On Wed, 23 Mar 2011, Daniel Ceregatti wrote: The following bug has been logged online: Bug reference: 5943 Logged by: Daniel Ceregatti Email address: dan...@ceregatti.org Description:jdbc client doesn't omit pg_toast_temp tables from schema views Details: In the file org/postgresql/jdbc2/AbstractJdbc2DatabaseMetaData.java is the query: sql = SELECT nspname AS TABLE_SCHEM FROM pg_catalog.pg_namespace WHERE nspname 'pg_toast' AND nspname !~ '^pg_temp_' ORDER BY TABLE_SCHEM; Using Data Tools Platform in eclipse I was able to see all the pg_toast_temp_XXX schemas in the schema view. This has already been fixed in CVS and will be in the next set of releases. Kris Jurka -- 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] ERROR: character 0xe3809c of encoding UTF8 has no equivalent in EUC_JP
On Fri, Mar 25, 2011 at 03:33, Kasia Tuszynska ktuszyn...@esri.com wrote: We have a customer in Japan who would be interested in this fix, in the future. Would you like me to enter it as an official Postgres bug? Not a bug at all -- there are at least 3 versions of EUCJP encodings, and postgres just supports one of them. I think it won't be changed in the near term. So, you would need to define a CONVERSION for your purpose as of now. However, I think we could have an extension of conversion procedure set for Japanese confused encodings out of the core. -- Itagaki Takahiro -- 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] ERROR: character 0xe3809c of encoding UTF8 has no equivalent in EUC_JP
We have a customer in Japan who would be interested in this fix, in the future. Would you like me to enter it as an official Postgres bug? Sincerely, As I stated before, I don't regard this as a bug. BTW I wonder why you don't use CREATE CONVERSION which can be used for customer's problem today... -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
