[BUGS] BUG #7820: Extension uuid-ossp cannot be installed on Windows - getting syntax error
The following bug has been logged on the website: Bug reference: 7820 Logged by: Jan-Peter Seifert Email address: jan-peter.seif...@gmx.de PostgreSQL version: 9.1.7 Operating system: Windows 7 64-bit Description: The statement: 'CREATE EXTENSION uuid-ossp' just gives me a syntax error: ERROR: syntax error at or near - LINE 1: CREATE EXTENSION uuid-ossp ^ ** Fehler ** ERROR: syntax error at or near - SQL Status:42601 Zeichen:22 Obviously CREATE EXTENSION expects underscores instead of hyphens. I had to replace the hyphen in file names and in the scripts to make the module work. -- 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 #7820: Extension uuid-ossp cannot be installed on Windows - getting syntax error
On 22.01.2013 15:31, jan-peter.seif...@gmx.de wrote: The statement: 'CREATE EXTENSION uuid-ossp' just gives me a syntax error: ERROR: syntax error at or near - LINE 1: CREATE EXTENSION uuid-ossp ^ ** Fehler ** ERROR: syntax error at or near - SQL Status:42601 Zeichen:22 Obviously CREATE EXTENSION expects underscores instead of hyphens. Try: CREATE EXTENSION uuid-ossp - Heikki -- 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 #7820: Extension uuid-ossp cannot be installed on Windows - getting syntax error
On Tue, Jan 22, 2013 at 2:31 PM, jan-peter.seif...@gmx.de wrote: The statement: 'CREATE EXTENSION uuid-ossp' just gives me a syntax error: ERROR: syntax error at or near - LINE 1: CREATE EXTENSION uuid-ossp ^ ** Fehler ** ERROR: syntax error at or near - SQL Status:42601 Zeichen:22 Obviously CREATE EXTENSION expects underscores instead of hyphens. I had to replace the hyphen in file names and in the scripts to make the module work. This is not a bug. You need to quote identifiers that have non-identifier characters in them, like so: CREATE EXTENSION uuid-ossp; Vik
Re: [BUGS] BUG #7814: Rotation of the log is not carried out.
Jeff Janes jeff.ja...@gmail.com writes: For what it is worth, I can reproduce this on Windows 7, using the 9.2.2 and 9.1.7 windows 64 installers from EDB (i.e. http://www.enterprisedb.com/postgresql-922-installers-win64?ls=Crossovertype=Crossover), with completely default installation (EDB changes the default to be logging_collector=on), and using the below to blow up the log files with error messages: perl -le 'print FOO$_; foreach 1..1e7' | psql 9.1.7 rotates the log files in $DATA/pg_log, while 9.2.2 does not rotate based on size. [ scratches head for awhile... ] Hm, what you are testing is the default rotation parameters, right? log_rotation_age = 1 day, log_rotation_size = 10MB? So you didn't wait to see what would happen at a rotation-age boundary. If so, does pg_ctl reload kick it into rotating once the file is too big? (Or you could reduce log_rotation_age to a small value, but that would make it hard to tell which condition triggered rotation.) Here's what I think is probably happening: on Windows, the syslogger process actually contains two threads, one of which handles data transfer while the other worries about things like log rotation. In prior versions, the control thread woke up once a second, so it would notice within one second if the data transfer thread had filled the current file to more than log_rotation_size. In 9.2, we got rid of those unnecessary wakeups, which means log rotation won't occur until there's some other event that kicks the control thread into activity. There's no bug on non-Windows because we don't use two threads on other platforms; data transfer is done by the main thread so it's already awake upon any write to the log file, and it won't miss the rotation condition. (Size-based rotations were therefore always more precise on non-Windows machines...) So what we need on Windows is for the data transfer thread to notice when Log_RotationSize 0 ftell(syslogFile) = Log_RotationSize, and then either signal the control thread to wake up, or do the rotation itself. Probably the former is less risk. I'm not coding this fix though, since I'm not in a position to test it. 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 #7819: missing chunk number 0 for toast value 1235919 in pg_toast_35328
Pius Chan pc...@contigo.com writes: Hi Tom, Yes, we start seeing this ERROR after upgrade to 9.1.7. The ERROR is from the cluster jms_messages command. Last night, the ERROR happened three times: (1) at 00:20:01 ERROR: missing chunk number 0 for toast value 1239124 in pg_toast_35328 (2) at 00:25:01 ERROR: missing chunk number 0 for toast value 1239124 in pg_toast_35328 (3) at 00:35:01 ERROR: missing chunk number 0 for toast value 1241022 in pg_toast_35328 The cluster jms_messages runs every 5 minutes. However, so far, it seems that the ERROR happens at about mid-night and 35328 is the toast area of the jms_message table: So what else is this application doing around midnight? In particular, it seems like something must've happened between 00:15 and 00:20 to create the problem with OID 1239124, and then something else happened between 00:25 and 00:30 to get rid of it. And then a similar sequence happened between 00:30 and 00:40 involving OID 1241022. Most likely the trigger events are application actions against jms_messages, but we have no info about what. (It's also possible that autovacuums of jms_messages are involved, so you might want to crank up your logging enough so you can see those in the postmaster log.) I had first thought that this might have something to do with the toast-value-processing changes we made in CLUSTER a year or so ago, but a look in the commit logs confirms that those patches were in 9.1.3. So I have no idea what might've broken between 9.1.3 and 9.1.7. We need data, or even better an actual test case. 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 #7814: Rotation of the log is not carried out.
On Tuesday, January 22, 2013, Tom Lane wrote: Jeff Janes jeff.ja...@gmail.com javascript:; writes: For what it is worth, I can reproduce this on Windows 7, using the 9.2.2 and 9.1.7 windows 64 installers from EDB (i.e. http://www.enterprisedb.com/postgresql-922-installers-win64?ls=Crossovertype=Crossover ), with completely default installation (EDB changes the default to be logging_collector=on), and using the below to blow up the log files with error messages: perl -le 'print FOO$_; foreach 1..1e7' | psql 9.1.7 rotates the log files in $DATA/pg_log, while 9.2.2 does not rotate based on size. [ scratches head for awhile... ] Hm, what you are testing is the default rotation parameters, right? log_rotation_age = 1 day, log_rotation_size = 10MB? So you didn't wait to see what would happen at a rotation-age boundary. Correct, I did not wait. But from the original reporter's screenshot, it seemed to be rotating correctly based on time, just not on size. If so, does pg_ctl reload kick it into rotating once the file is too big? Yes, triggering a reload (through pgAdmin) does cause it to kick over to a new log file. ... So what we need on Windows is for the data transfer thread to notice when Log_RotationSize 0 ftell(syslogFile) = Log_RotationSize, and then either signal the control thread to wake up, or do the rotation itself. Probably the former is less risk. I'm not coding this fix though, since I'm not in a position to test it. If I can follow though on Andrew Dunstan's instructions to get mingw up and running, I'll take it for a spin. Cheers, Jeff
[BUGS] BUG #7822: PGDG packaged postgresql92 binaries do not find their libraries
The following bug has been logged on the website: Bug reference: 7822 Logged by: Georgi Georgiev Email address: georgi-georgiev-pg...@japannext.co.jp PostgreSQL version: 9.2.2 Operating system: CentOS 6.3 Description: The postgresql92 package would configure the postgresql92-libs libraries for system-wide use (using update-alternatives in the post-install scriptlet), but it does not run ldconfig, so the binaries cannot find their libraries. In short, psql is unusable. Steps to reproduce: Remove all postgresql libraries: $ sudo yum remove -y postgresql\* Install the PGDG 9.2 binaries $ sudo yum install -y postgresql92 Verify that the psql binary is not properly linked: $ ldd /usr/bin/psql | head -n2 linux-vdso.so.1 = (0x7fffb27ff000) libpq.so.5 = not found The ld.so.conf.d update should probably be moved to the postgresql92-libs packages, as this would allow other packages that require libpq.so.5 to keep working (like php-pgsql and perl-DBD-Pg). -- 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 #7823: PGDG packaged pgadmin3_92 removes its /usr/bin/pgadmin3 link
The following bug has been logged on the website: Bug reference: 7823 Logged by: Georgi Georgiev Email address: georgi-georgiev-pg...@japannext.co.jp PostgreSQL version: 9.2.2 Operating system: CentOS 6.3 Description: Updating pgadmin3_92 removes the /usr/bin/pgadmin3 symlink. There is also a harmless warning from the post-install scriptlet when it tries to create that symlink and it is already there (happens on an update). Running Transaction Updating : pgadmin3_92-1.16.1-1.rhel6.x86_64 1/2 Non-fatal POSTIN scriptlet failure in rpm package pgadmin3_92-1.16.1-1.rhel6.x86_64 ln: creating symbolic link `/usr/bin/pgadmin3': File exists warning: %post(pgadmin3_92-1.16.1-1.rhel6.x86_64) scriptlet failed, exit status 1 Cleanup: pgadmin3_92-1.16.0-1.rhel6.x86_64 2/2 And after this /usr/bin/pgadmin3 is gone. -- 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 #7824: documentation bug: Extract DOW
The following bug has been logged on the website: Bug reference: 7824 Logged by: Tim Romano Email address: tim.rom...@yahoo.com PostgreSQL version: 9.2.2 Operating system: Windows 7 x64 Description: Documentation seems to indicate that only a Timestamp value is a valid argument to the Extract function when trying to get the DOW, but a Date also works: dow The day of the week (0 - 6; Sunday is 0) (for timestamp values only) SELECT EXTRACT(DOW FROM TIMESTAMP '2001-02-16 20:38:40'); Result: 5 -- 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 #7825: pgAdmin III won't allow unchecking superuser
The following bug has been logged on the website: Bug reference: 7825 Logged by: Randy Boudwin Email address: rboud...@automatedlogic.com PostgreSQL version: 9.2.2 Operating system: Win 7 64 Description: When I attempt to uncheck the superuser permission on a user I created pgAdmin throws up a confirmation window. Regardless of whether I select Yes or No, it still closes the dialog and rechecks the superuser permission. -- 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 #7821: constant disconnection with external network
The following bug has been logged on the website: Bug reference: 7821 Logged by: Alessandro Linguanoto Email address: alessan...@nwsoftware.com.br PostgreSQL version: 9.0.6 Operating system: Windows Description: I use PostgreSQL 9.0.6 and I´m with a problem using PostgreSQL with external network, by internet (cloud). If the user open the application and don´t use the application by minutes, the connection with database is lost, but if the user to use application constantly, the connection with database isn't interrupted. Is there some setting to avoid this kind of problem? -- 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 #7824: documentation bug: Extract DOW
On Wed, Jan 23, 2013 at 2:10 AM, tim.rom...@yahoo.com wrote: The following bug has been logged on the website: Bug reference: 7824 Logged by: Tim Romano Email address: tim.rom...@yahoo.com PostgreSQL version: 9.2.2 Operating system: Windows 7 x64 Description: Documentation seems to indicate that only a Timestamp value is a valid argument to the Extract function when trying to get the DOW, but a Date also works: dow The day of the week (0 - 6; Sunday is 0) (for timestamp values only) The document also mentions: (Expressions of type date will be cast to timestamp and can therefore be used as well.) ISTM that for timestamp values only means that a source of type interval or time can not b used. Other functions will also accept those additional types. I don't know if the documentation needs to make that more clear though. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee
