emesika | 20 Jan 11:33 2013
Picon

BUG #7817: psql does not relate to footer settings in extended mode

The following bug has been logged on the website:

Bug reference:      7817
Logged by:          Eli Mesika
Email address:      emesika <at> redhat.com
PostgreSQL version: 9.1.7
Operating system:   Fedora 16
Description:        

psql does not relate to footer settings in extended mode
Sometimes we need to run a sql command withot generating header and footer.
This can be done using the -t flag and --pset=footer=off
The problem is that the footer is still diaplyed even if it was set to off
if we use the extended mode for the query (-x flag)

Steps to Reproduce:
1) create a table without any data
for example
create table text(i int);
2) run
psql -U <user> -t --pset=footer=off <db>
3) No output is generated
4) run
psql -U <user> -t --pset=footer=off -x <db>
5) Output generated : "(No Rows)"

Actual results:
psql does not honour the footer settings when output is defined to be in
Extended Mode

(Continue reading)

seebs | 20 Jan 06:26 2013
Picon

BUG #7816: test for compiler output produces bogus results

The following bug has been logged on the website:

Bug reference:      7816
Logged by:          Peter Seebach
Email address:      seebs <at> seebs.net
PostgreSQL version: 9.1.4
Operating system:   Linux
Description:        

Your modified acx_pthread.m4 tests for any compiler output to stderr at all,
and considers it evidence that a flag is invalid.

This test is not actually correct, although it usually works.

The reason this bit me is that I have cause to build stuff with a patched
gcc which has a check for possible licensing-related stuff (not for gcc
itself, but because gcc's in the usage path; long story), and if that fails
or can't be run, it prints a diagnostic to stderr. This is not an error, and
it does not prevent successful compilation.

But if it happens during the postgresql configure, it results in configure
deciding that -lpthread isn't available, and dying.

In general, it is Bad Mojo to assume that all messages on stderr indicate
failures. If there is an error, the compiler is expected to exit with a
non-zero exit status. If it doesn't exit non-zero, you should assume that it
worked. This is why configure doesn't normally fail tests just because there
is some message on stderr...

--

-- 
(Continue reading)

wln | 20 Jan 04:38 2013

(unknown)

subscribe
end

 

giomac | 18 Jan 23:19 2013
Picon

BUG #7815: Upgrading PostgreSQL from 9.1 to 9.2 with pg_upgrade/postgreql-setup fails - invalid status retrieve

The following bug has been logged on the website:

Bug reference:      7815
Logged by:          George Machitidze
Email address:      giomac <at> gmail.com
PostgreSQL version: 9.2.2
Operating system:   Fedora 18 Linux
Description:        

https://bugzilla.redhat.com/show_bug.cgi?id=896161
Upgrading PostgreSQL from 9.1 to 9.2 with pg_upgrade/postgreql-setup fails
with invalid message "There seems to be a postmaster servicing the old
cluster". Looks like pg_upgrade is checking pid file too early without
waiting for master process to exit:

open("/var/lib/pgsql/data-old/postmaster.pid", O_RDONLY) = 5

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Casey Allen Shobe | 17 Jan 22:05 2013

Using newline or control codes in custom psql prompts corrupts display when viewing history

I'm not sure if this is a bug in psql, but it seems like it.  I've ran into similar things with a bash custom prompt, but as long as I put a newline character in after all my custom color stuff and don't use any color codes on the second line, this fixes the issue at a bash prompt.
 
For instance, for bash, I am using:
 
PS1="\n\e[1;32m\]\u\[\e[0;31m\] <at> \e[0;32m\]\h.`dnsdomainname`\e[0;31m\]:\e[0;35m\]\w   \e[0;37m\](\`if [ \$? = 0 ]; then echo \[\e[33m\]^_^; else echo \[\e[31m\]O_O; fi\`\e[0;37m\])\e[0m\]\n\$ "
This works with no problem, although there IS a similar problem if I put a control character AFTER the final \n.  For similar functionality within psql, I am using:
 
\set PROMPT1 '\n%[%033[1;32m%]%n%[%033[0;31m%] <at> %[%033[0;32m%]%M%[%033[0;31m%]:%[%033[0;33m%]%> %[%033[0;31m%][%[%033[0;36m%]%/%[%033[0;31m%]] %[%033[0m%]\n%R%# '
\set PROMPT2 '%R%# '
(note the newline character (\n) and lack of color codes following it near the end of each)
 
It looks exactly how I want, and I'm very happy with this, until I hit the up arrow on my keyboard until hitting a history entry that's either multiline or a single long line.  At this point I see only part of the command, as it overwrites the second prompt line and a bunch is truncated from the beginning.  If I keep going up through history a few more times, or simply press down arrow, then the cursor moves backwards up onto the first line maybe 50 characters to the right of the last colorized stuff.
 
I've attached a screenshot that attempts to show what I'm talking about.
 
Following this screenshot, I tried a non-colorized version of the prompt:
 
\set PROMPT1 '\n%n <at> %M:%> [%/] %R%# '
 
Unfortunately, the problem still manifested.  Ultimately, I was able to reproduce it with a \n and enough characters.  I am able to reproduce the bug with the following simple prompt:
 
\set PROMPT1 '\ntest prompt '
 
That said, it's reproducible with no newlines and only the colorization control characters as well.  Either of these as well as probably some other special characters cause the problem.
 
Any advice welcome,
--
Casey Allen Shobe
casey <at> shobe.info



--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
tsunezumi | 17 Jan 12:07 2013

BUG #7814: Rotation of the log is not carried out.

The following bug has been logged on the website:

Bug reference:      7814
Logged by:          Tsunezumi
Email address:      tsunezumi <at> efficlabo.com
PostgreSQL version: 9.2.2
Operating system:   WindowsServer2008Standard 64bit
Description:        

Rotation of the log is not carried out. 

"log_rotation_size" is not effective. 

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

analyst.kleber | 15 Jan 20:50 2013
Picon

BUG #7813: Problem in installation

The following bug has been logged on the website:

Bug reference:      7813
Logged by:          Kleber William
Email address:      analyst.kleber <at> gmail.com
PostgreSQL version: 9.2.2
Operating system:   Windows 8 x64
Description:        

Good afternoon.

I'm not able to install postgres 9.x on my windows 8 x64, what procedure to
follow.

Sincerely,
William Kleber
Support Servers

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

1584171677 | 15 Jan 15:18 2013

BUG #7811: strlen(NULL) cause psql crash

The following bug has been logged on the website:

Bug reference:      7811
Logged by:          Meng Qingzhong
Email address:      1584171677 <at> qq.com
PostgreSQL version: 9.2.2
Operating system:   Windows 7
Description:        

 I find a bug this time really and I have fixed it. The bug is in psql, my
oprating system is Windows 7, and the IDE is Visual Studio 2010. The version
of postgreSQL is 9.2.2
      I give you a description about how to trigger this bug first´╝Ü
          (1) start the server with the command "postgres -D pgdata"
          (2) start the client with the command "psql"
          (3) close the server
          (4) execute a query from the client "slect *from t; ". At this
time, the client detected that it lost the connection with the server.
          (5) execute the following command from the client "\?", then the
client will crash.

      I have found the reason which caused that.

          (1) When the client execute "slect *from t; ", it execute the
function "ResetCancelConn()" at line 364 in src\bin\psql\common.c ,and the
function set pset.db to NULL.
          (2) When the client execute "\?", it execute the function fprintf
at line 254 in help.c. The value returned by PQdb(pset.db) is an argument of
 fprintf, and at this time   PQdb returned NULL.
          (3) This NULL was finally passed to strlen at line 779 in
snprintf.c through several simple fuction calls, so psql crashed.

      I hava fixed the bug in the following way which may be not the best:

          (1) add a string named strofnull, and in the function "dopr" in
file src\port\snprintf.c
                  char *strofnull="(null)";

          (2) add an if statment before calling fmtstr at about line 720 in
file src\port\snprintf.c

                  if (strvalue==NULL)
		  {
		          strvalue=strofnull;
		  }

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

chip | 15 Jan 17:06 2013

BUG #7812: pgadmin3_92 will not uninstall

The following bug has been logged on the website:

Bug reference:      7812
Logged by:          Chip Schweiss
Email address:      chip <at> innovates.com
PostgreSQL version: 9.2.2
Operating system:   Centos 6
Description:        

After using yum to install pgadmin3 it will not uninstall:

# yum -v erase pgadmin3_92
Loading "downloadonly" plugin
Loading "fastestmirror" plugin
Loading "refresh-packagekit" plugin
Config time: 0.014
Yum Version: 3.2.29
rpmdb time: 0.000
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package pgadmin3_92.x86_64 0:1.16.1-1.rhel6 will be erased
Checking deps for pgadmin3_92.x86_64 0:1.16.1-1.rhel6 - e
--> Finished Dependency Resolution
Dependency Process ending
Depsolve time: 2.644

Dependencies Resolved

======================================================================================================================
 Package                     Arch                   Version                 
        Repository                  Size
======================================================================================================================
Removing:
 pgadmin3_92                 x86_64                 1.16.1-1.rhel6          
         <at> nrg-pgsql                  14 M

Transaction Summary
======================================================================================================================
Remove        1 Package(s)

Installed size: 14 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Member: pgadmin3_92.x86_64 0:1.16.1-1.rhel6 - e
Removing Package pgadmin3_92-1.16.1-1.rhel6.x86_64
rpm_check_debug time: 0.006
Running Transaction Test
Member: pgadmin3_92.x86_64 0:1.16.1-1.rhel6 - e
Removing Package pgadmin3_92-1.16.1-1.rhel6.x86_64
Transaction Test Succeeded
Transaction Test time: 0.100
Member: pgadmin3_92.x86_64 0:1.16.1-1.rhel6 - e
Removing Package pgadmin3_92-1.16.1-1.rhel6.x86_64
Running Transaction
Error in PREUN scriptlet in rpm package pgadmin3_92
Warning: scriptlet or other non-fatal errors occurred during transaction.
pgadmin3_92-1.16.1-1.rhel6.x86_64 was supposed to be removed but is not!
  Verifying  : pgadmin3_92-1.16.1-1.rhel6.x86_64                            
                                     1/1
VerifyTransaction time: 0.009
Transaction time: 0.437

Failed:
  pgadmin3_92.x86_64 0:1.16.1-1.rhel6

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

richardbrown360 | 15 Jan 01:22 2013
Picon

BUG #7810: cant uninstall or install program

The following bug has been logged on the website:

Bug reference:      7810
Logged by:          rich
Email address:      richardbrown360 <at> hotmail.com
PostgreSQL version: 8.4.13
Operating system:   windows 7
Description:        

I can't seem to get rid of all the application. 
I cant reinstall the program without errors. 
the installation gets stuck at installing the \data file. 
I have tried for 6 hours to install the program again and i also tired
different versions none work.

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

joe | 15 Jan 00:13 2013

BUG #7809: Running pg_dump on slave w/ streaming replication fails if there are unlogged tables

The following bug has been logged on the website:

Bug reference:      7809
Logged by:          Joe Van Dyk
Email address:      joe <at> tanga.com
PostgreSQL version: 9.2.2
Operating system:   Ubuntu
Description:        

Running pg_dump on a streaming replication slave with a database that has
unlogged_tables will fail unless you provide the "--no-unlogged-table-data"
option with the following (scary) error:

pg_dump: Dumping the contents of table "tracking_import_data" failed:
PQgetResult() failed.
pg_dump: Error message from server: ERROR:  could not open file
"base/16388/190326": No such file or directory
pg_dump: The command was: COPY public.tracking_import_data (uuid,
tracking_number) TO stdout;

(this guy  encountered the error as well:
http://www.postgresql.org/message-id/DE2DE764-307D-4A23-A9A9-6608AC0977CB <at> ticketevolution.com
)

Could running pg_dump against a slave always use the
"--no-unlogged-table-data" option?

In my case, I had automatic scripts that run pg_dump (without the unlogged
option) against the slave, and they failed right after I added an unlogged
table for the first time.

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Gmane