[BUGS] Installer: Spurious service account ... not removed on uninstall
Hi folks A Stack Overflow user noticed that the EDB installer for PostgreSQL emits the message: The data directory (bla bla) and service user account (NT AUTHORITY\NetworkService) have not been removed when 9.2 is uninstalled. They were quite confused by this. It occurs to me that if the standard NetworkService account is used, it'd be good to suppress the user account not removed part of the message entirely. http://stackoverflow.com/q/17394116/398670 -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- 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 #7771: packaging error causes build failure
On 24/12/2012 6:30 PM, mamf...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 7771 Logged by: Michael Felt Email address: mamf...@gmail.com PostgreSQL version: 8.3.22 Operating system: AIX Description: There are three references to the file @LongLink in the tar file : postgresql-8.3.22.tar.bz2 Use GNU tar. Your tar doesn't understand the GNU long-filename extensions to the tar format. You'll need GNU make to compile, too. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- 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 #7760: records with duplicate primary keys
On 20/12/2012 1:22 AM, acummi...@aperiogroup.com wrote: The following bug has been logged on the website: Bug reference: 7760 Logged by: Alan Cummings Email address: acummi...@aperiogroup.com PostgreSQL version: 9.1.7 Operating system: Ubuntu Linux 10.04.1 Description: We found 6 duplicated primary keys in a table. All fields were identical in the duplicated records, including the primary key. (Total records ~ 22,000). We recently updated from 9.1.2 to 9.1.7, so the issue may have been present in 9.1.2. Have you had your database running with fsync=off at any point? What storage system is the database on? RAID array? If so, details - drive types, controller if any, writeback/writethrough, BBU enabled,etc? SSD, and if so which SSD? Has the DB host unexpectedly powered off or rebooted at any point? This should never cause a problem unless you run with unsafe settings like fsync=off, but is important to know. Did you REINDEX as part of the upgrade to 9.1.7? A corrupt unique index could hide duplicate records, and a reindex might well cause the problem to become apparent. We have fixed the issue in our table by backing up the table in pgAdmin to a plain file, deleting the duplicated records in the text file, then restoring the table. I can send the original backup with the duplicated records if that would be helpful -- it is about 11MB. Is the backup a `pg_dump`? Or a raw copy of the database directory? The pg_dump output won't usually provide much information, it's the actual database on disk that's significant. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- 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] Prepared Statement Name Truncation
On 11/19/2012 09:43 PM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Let me be clear here: I don't think we can or should ever make this into an error by default. Doing that would break spec-compliant applications, whether or not they are using names that actually have any conflicts. If we increase the length to the spec requirement (full disclosure- I havn't checked the spec on this myself), I'd be for making it an error if someone goes over that limit. Right now we have a risk of spec compliant applications not working under PG for nearly zero good justification in today's age (iow- I don't really buy the concern about the size, and if that is a reasonable concern then we could look at putting in the effort to make it variable length and seriously reduce today's wasted space). Wasted space is only part of the issue; it's also potentially significantly cheaper to compare and copy fixed length names, especially when you can copy on-stack arrays rather than palloc'ing memory. I have not checked to see whether this is a concern in Pg's codebase; I'm just aware it's been a reason for the use of fixed length strings in software in general. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services
Re: [BUGS] BUG #7661: pgstattuple from unpackaged fails on old installation
On 11/15/2012 03:32 PM, Stuart Bishop wrote: That's a known issue with several of the extensions. You need to upgrade the contrib module install to the current version, *then* wrap the unpackaged contrib module into an extension with FROM UNPACKAGED. Yeah, just thought I'd stick it in the... umm... bugtracker, as so far 'FROM unpackaged' has failed in 66% of up updates. Is the real solution is for the foo--unpackaged--1.0.sql script to recreate missing objects before adding them to the extension? For simple extensions running the create script should do the job, yes. It's not so clear cut for extensions that define data types, though. If I recall correctly the general advice for those has been to: - Create the new versions of extensions in the DB you're going to restore to; then - restore your database to that DB with the extensions pre-created in it. I'm surprised not to find any documentation on coping with this issue in: http://www.postgresql.org/docs/current/static/contrib.html http://www.postgresql.org/docs/9.2/static/contrib.html or http://www.postgresql.org/docs/current/static/extend-extensions.html http://www.postgresql.org/docs/9.2/static/extend-extensions.html (though it's possible it's there and I missed it). There used to be brief mention in contrib.html before the extensions changes went in, saying: After a major-version upgrade of PostgreSQL, run the installation script again, even though the module's objects might have been brought forward from the old installation by dump and restore. This ensures that any new functions will be available and any needed corrections will be applied. ... but I'm not certain that advice is sufficient for all contrib modules. Extensions were created because upgrading DBs that used contrib modules was a painful mess. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services
Re: [BUGS] Re: BUG #7628: Installation of PostgreSQL 9.2.1 on Windows 7 may take too long
On 11/15/2012 02:11 AM, limkimhuot wrote: Dear all, Today is my fourth day I have been trying to install PostgreSQL (postgresql-9.2.1-1-windows-x64) in my window 7 x64, yet it fails all the time. I don't know much about VB script or I am very new in VB. Is it correct if I place code of the new environment variable like this: SYSTEMDRIVER = %SYSTEMDRIVE% strProgramFiles = objShell.ExpandEnvironmentStrings(%PROGRAMFILES%) strSystemDrive = objShell.ExpandEnvironmentStrings(%SYSTEMDRIVER%) This is a typo in the installer. It was recognised and fixed a few weeks ago; I expect the public installers will have the fix in the next patch release. You can work around it in the mean time by editing your system environment settings to add a SYSTEMDRIVER environment variable. http://support.microsoft.com/kb/310519 -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services
Re: [BUGS] BUG #7661: pgstattuple from unpackaged fails on old installation
On 11/15/2012 02:19 PM, stu...@stuartbishop.net wrote: The following bug has been logged on the website: Bug reference: 7661 Logged by: Stuart Bishop Email address: stu...@stuartbishop.net PostgreSQL version: 9.1.6 Operating system: Ubuntu 12.04 Description: The pgstattuple upgrade from unpackaged script expects the pgstatindex function to exist, but it does not on particularly old databases (My pgstattuple originally installed with 8.3 or 8.4?). That's a known issue with several of the extensions. You need to upgrade the contrib module install to the current version, *then* wrap the unpackaged contrib module into an extension with FROM UNPACKAGED. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- 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] duplicate key value violates unique constraint tableName_pk
On 11/07/2012 07:21 PM, Saravanan Nagarajan wrote: Hi , I am using Copy From while dumping bulk data into PGSQL DB from file. While I am trying to insert the rows, if the primary key already exists, the complete transaction terminated. Postgres cannot handle the constraint violations , i found it into http://wiki.postgresql.org/wiki/COPY#Caveats_with_implementation . Is there any possible way to insert bulk data using Copy From with REPLACE/IGNORE duplicates. Typically you COPY into a temporary or UNLOGGED table, then merge the data into the target table using appropriate `UPDATE ... FROM ... WHERE` and `INSERT ... SELECT ... WHERE` statements. -- Craig Ringer -- 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 #7638: postgresql taking up all my hard drive space
On 11/03/2012 01:22 AM, gryphons...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 7638 Logged by: shawn darling Email address: gryphons...@gmail.com PostgreSQL version: 9.0.0 Operating system: windows 7 Description: I need to know can i get rid of it or what is it even for? how do I at least leesen the ammount of space its taking up? 191 gigs? PostgreSQL is a database server. If you don't know what it is, it's highly likely it was installed by another program that you do use. Do not uninstall it unless you know for sure that you do not use it. As for the space taken up, that's just weird. Do you have any database programs, accounting, logging, image management, photo management, music management, etc programs on your computer? If in doubt, open the Services control panel, and stop the PostgreSQL service. Then see what programs stop working. Please DO NOT RESPOND TO THIS EMAIL. This page is for bug reports, and this is not a bug. If you need further assistance I suggest asking on http://superuser.com or on the PostgreSQL general mailing list http://archives.postgresql.org/pgsql-general/ . I will not respond to replies that go directly to me. -- Craig Ringer
Re: [BUGS] BUG #7628: Installation of PostgreSQL 9.2.1 on Windows 7 may take too long
On 11/01/2012 01:23 PM, Sandeep Thakkar wrote: Thanks George. I have fixed the typo in initcluster.vbs on all affected branches. Out of interest, how long has that typo been there? Could this be the cause of *all* the various and persistent issues we've had with icacls.exe running for ages on some systems? Or have there been previous problems detected and fixed too? -- Craig Ringer -- 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 #7624: Misleading Log Message Inconsistent Configuration Design
On 10/28/2012 03:35 PM, t...@cs.ucsd.edu wrote: I really suggest to make the configuration file consistent in this case. But I understand it might not be easy. But at least I think we should print a better log message which pinpoints to the absolute path like FATAL: 58P01: could not create lock file /home/tianyin/postgresql-9.2.1/local/pgsql/data/local/pgsql/data/.s.PGSQL.5432.lock: No such file or directory Essentially, you want PostgreSQL to print absolute paths in error messages, instead of paths relative to the server datadir? I'd prefer to do it slightly differently, but I like the general idea. I'd instead want to write: FATAL: 58P01: could not create lock file local/pgsql/data/.s.PGSQL.5432.lock (cwd=/home/tianyin/postgresql-9.2.1/local/pgsql/data/): No such file or directory By spelling out the CWD explicitly there's no impression given that the user ever actually specified the whole path in the configuration anywhere, so it's clearer how the path came to be. It also shows which part of the path is known-good (since it's the CWD) and which could be at issue. -- Craig Ringer -- 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 #7620: array_to_json doesn't support heterogeneous arrays
On 10/24/2012 11:46 PM, Greg Hazel wrote:
Another option that just occurred to me is a new function (say, to_json) that
converts the parameter to its json representation, with type json.
Then this would be possible:
select array_to_json(ARRAY[to_json('foo'), to_json(100), to_json(true)]);
That's been repeatedly discussed (and requested, and had patches posted)
on -hackers. Right now the standing opinion appears to be that json
represents a whole json document, and json documents must be arrays or
JavaScript objects, not scalars, so it is not valid to provide a scalar
to_json.
I posted patches to support this functionality - as did several others
as it turns out - and they've all been rejected.
--
Craig Ringer
--
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] Posrgresql for Suse linux 64-bit version on OS/390
On 10/23/2012 07:26 PM, Sree Krishna Priya Kuppa wrote: Hi Team, Required a copy of PostgreSQL to install on z/linux i.e Suse Linux 64-bit on OS/390. Please suggest where to get the setup file. This isn't a bug report; consider asking on pgsql-general. See the bug reporting guidelines linked to on the bug report form you used. -- Craig Ringer -- 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 #7620: array_to_json doesn't support heterogeneous arrays
On 10/24/2012 07:32 AM, gha...@gmail.com wrote:
The following bug has been logged on the website:
Bug reference: 7620
Logged by: Greg Hazel
Email address: gha...@gmail.com
PostgreSQL version: 9.2.1
Operating system: Amazon Linux
Description:
array_to_json(ARRAY['foo', 100, true]) complains because arrays can't have
mixed types, but json arrays can.
The issue here isn't array_to_json, it's PostgreSQL arrays.
What you appear to want is a way to call row_to_json so that it produces
a json array instead of a json object as it currently does. That way you
could pass it a ROW() construct, composite type, or record, and have it
output a heterogeneous JSON array.
This isn't a bug, but it's a perfectly reasonable feature request if
re-interpreted a little. It will never work with PostgreSQL arrays,
though, because the arrays themselves cannot contain mixed types:
regress=# SELECT ARRAY[1,'test'];
ERROR: invalid input syntax for integer: test
LINE 1: SELECT ARRAY[1,'test'];
^
Instead you want a way to take this:
regress=# SELECT ROW(1,'test');
row
--
(1,test)
(1 row)
and output the json:
[1,test]
instead of a json object:
regress=# SELECT row_to_json(ROW(1,'test'));
row_to_json
--
{f1:1,f2:test}
(1 row)
Would a version of `row_to_json` that output a json array satisfy your
needs?
--
Craig Ringer
--
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 #7619: Query cost estimate appears to not use n_distinct setting
On 10/23/2012 06:46 PM, niko.kiir...@mapvision.fi wrote: The following bug has been logged on the website: Bug reference: 7619 Logged by: Niko Kiirala Email address: niko.kiir...@mapvision.fi PostgreSQL version: 9.2.1 Operating system: Windows 7 SP 1 (64-bit) Description: I am working on a potentially large database table, let's call it observation, that has a foreign key to table measurement. Each measurement is associated with either none or around five observations. In this kind of situation, it is well known that the statistics on the foreign key column in observation table can get arbitrarily bad as the row count increases. Especially, the estimate of the number of distinct values in the foreign key column can be completely off. For anyone wondering why this feels familiar, the same message was posted to pgsql-performance earlier: http://postgresql.1045698.n5.nabble.com/High-cost-estimates-when-n-distinct-is-set-td5728596.html It's clear that there's a practical performance issue here, but less clear that it's a bug. Nonetheless, thanks for writing it up in so much detail and chasing it up further - though it'd be nice if you'd mentioned your earlier post. I'd love to help, but you've clearly already done a lot of work on this and I'm not sure I have anything useful to add. If you don't have any luck, consider asking one of the professional PostgreSQL consulting firms for their input. -- Craig Ringer -- 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 #7613: INTIDB
On 10/19/2012 03:13 AM, henrique.assesso...@hotmail.com wrote: The following bug has been logged on the website: Bug reference: 7613 Logged by: Henrique Silva Email address: henrique.assesso...@hotmail.com PostgreSQL version: 8.3.20 Operating system: Windows Seven Description: Falha ao executar o Initdb.1! There's no sign this is a bug. It looks more likely that the permissions on initdb are wrong. Please read: wiki.postgresql.org/wiki/Guide_to_reporting_problems and follow up with a question on pgsql-general or superuser.com if you continue to have problems. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [Spam] Re: [BUGS] BUG #7577: JDBC Driver - Compiled with Java 7
On 10/16/2012 08:10 PM, Sean Hogan wrote: On 12-10-16 12:08 AM, Craig Ringer wrote: On 10/15/2012 11:10 PM, seancompusult wrote: Does anyone have a solution for people like me who must use Java 5? I had no problems building current git head of the JDBC driver with Java SE 5, nor the REL_9_2_STABLE branch. Ah, quite right. I was having a problem running ant, because it itself was compiled with Java 7. :-( IMO the whole approach of relying on compiling with specific Java versions is flawed, but at least I've gotten past this issue so I'm happy. Thanks for that. Yes, it's flawed, but it's also unfortunately necessary. javac offers flags like -source 1.5 -target 1.5 for controlling bytecode generation and source compatibility. That's fine, but it offers absolutely no way to say treat standard library packages, classes and methods added after Java SE 5 as missing. This means that for testing at least it's required to build with a variety of JDK versions. I agree that it'd be nice to support downlevel class generation for end users. It may even be possible; I haven't dug into build.xml in detail yet. -- Craig Ringer -- 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 #7600: Database crash with data corruption
On 10/15/2012 04:17 PM, Michał Hankiewicz wrote: You misunderstand me. According to the server logs I have sent in the first message process received signal 2 (it is SIGINT) and according to the documentation this signal should not couse server crash. Wrong values of sequences does not mean hole in generated values, but sequence started to generate the same values once again causing unique constraint violation. OK, that sounds more like a problem. It wasn't clear from your original post that it was replaying used sequence values. SIGINT should normally just terminate the statement, eg: regress=# SELECT pg_sleep(100); ERROR: canceling statement due to user request so I agree that something isn't right here. Is this something you've been able to reproduce? Or is it a one-off incident so far? -- Craig Ringer -- 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 #7602: Select with many joins against the same table is very slow compared to 9.2.0.
On 10/15/2012 06:55 PM, daniel.he...@sweco.se wrote: The following bug has been logged on the website: Bug reference: 7602 Logged by: Daniel Hedén Email address: daniel.he...@sweco.se PostgreSQL version: 9.2.1 Operating system: Windows 7 / Vista 64-Bit Description: Select with many joins against the same table is very slow compared to 9.2.0. In my case 16 times, this query takes a second max on 9.2.0 but on 9.2.1 it takes more than 30 minutes. Could you have accidentally reset `join_collapse_limit` to its default value? Show `EXPLAIN ANALYZE` output for both old and new cases, if possible. At least for the new one. (Please reply to the mailing list, not to me). -- Craig Ringer -- 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 #7603: Application takes long time to fetch data from postgresql database
On 10/15/2012 10:54 PM, devenmtha...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 7603 Logged by: Deven Email address: devenmtha...@gmail.com PostgreSQL version: 9.0.3 Operating system: Windows 2003 R2 64 BITS Description: Hi, My application takes longer time (we see time out even) when data to be fetched from Postgresql 9.0.3 is around 190 records. I am doing an improvement at application level, but from database side any performance tuning do i need to do? This is not a bug report. See http://www.postgresql.org/docs/current/static/bug-reporting.html Please ask on the pgsql-general mailing list or on dba.stackexchange.com . Read this first: https://wiki.postgresql.org/wiki/Slow_Query_Questions Also, you're on a very old release in the 9.0 series. Update to 9.0.11 urgently. The Pg team doesn't release patches just for fun, they're released to fix bugs and security issues. See: http://www.postgresql.org/support/versioning/ http://www.postgresql.org/docs/9.0/static/release.html -- Craig Ringer -- 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 #7577: JDBC Driver - Compiled with Java 7
On 10/15/2012 11:10 PM, seancompusult wrote: Does anyone have a solution for people like me who must use Java 5? I had no problems building current git head of the JDBC driver with Java SE 5, nor the REL_9_2_STABLE branch. export PATH=$HOME/java/jdk1.5.0_22/bin:$HOME/java/jdk1.5.0_22/jre/bin:$PATH; export JAVA_HOME=$HOME/java/jdk1.5.0_22/ ant clean jar -- Craig Ringer -- 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 #7595: terminate process in an unusual way
On 10/15/2012 10:34 AM, kimseowoong wrote: There was no any antivirus and no history install or uninstall antivirus software Any custom file-system (anything not NTFS)? Security software? Does copying the data directory to another location complete without error? Could you have run out of disk space? Invalid argument would be an odd error message for that, but who knows with Windows. -- Craig Ringer -- 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] Sorry to bother you. Please tell me exactly how the compiler was built ODBC
On 10/12/2012 10:29 PM, Копыченко Павел wrote: Sorry to bother you. Please tell me exactly how the compiler was built ODBC driver psqlodbc-09.01.0200 architecture for Windows 64? What exact version of the compiler? please This isn't a bug report. You might want to ask on the psql-odbc mailing list. It'd help to explain what *exactly* you want to know and why. Do you just need the exact compiler version? Do you need to reproduce the build? Do you need library / build environment info? -- Craig Ringer -- 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 #7600: Database crash with data corruption
On 10/12/2012 09:35 PM, hankiew...@gmail.com wrote: 5) after recovery was completed we have discovered that sequences on production database had wrong values To follow up on Tom's explanation, if you're relying on sequences not having holes then your design is dangerously mistaken. A simple ROLLBACK throws away any IDs that were obtained from sequences in that transaction. If you're saying that the sequence is wrong in that it's LOWER than IDs present in the table, then that's a problem. -- Craig Ringer -- 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 #7595: terminate process in an unusual way
On 10/11/2012 05:00 PM, hikkis...@hotmail.com wrote: 2012-10-10 16:01:55 KST PANIC: could not write to log file 4, segment 232 at offset 15237120, length 16384: Invalid argument That's a ... weird ... error. Do you have antivirus software running on your computer? That'd be my first suspect. -- Craig Ringer -- 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 #7590: Data corruption using pg_dump only with -Z parameter
On 10/10/2012 02:38 AM, Tom Lane wrote: hrt...@gmail.com writes: The following bug has been logged on the website: Bug reference: 7590 Logged by: Jan Vodi�ka Email address: hrt...@gmail.com PostgreSQL version: 9.2.1 Operating system: Windows 8 Description: pg_dump -Z1 my_db backup always make corrupted package. On Windows, that doesn't seem terribly surprising: Windows will probably do newline munging on the process's stdout, which will corrupt compressed data since it's not plain text. pg_dump might want to refuse to write to stdout when in a non-plain-text mode on Windows if that's the case. -- Craig Ringer -- 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 #7590: Data corruption using pg_dump only with -Z parameter
On 10/10/2012 03:07 AM, Jan Vodička wrote: = not able to unpack, invalid Try this one generated by pg_dump -Z1 backup.gz in windows: http://mstu.cz/~hrtlik/backup.gz http://mstu.cz/%7Ehrtlik/backup.gz (0.5kB) original pg_dump backup.gz without compression: http://mstu.cz/~hrtlik/backup.sql http://mstu.cz/%7Ehrtlik/backup.sql If you have any way how to get original, tell me. If Tom is right and the issue is end-of-line transformation, in theory you might be able to un-mungle newlines. The chances of \r\n occurring naturally in a tiny backup like that are not huge, so any \r\n in the data probably used to be a raw \n. Taking a copy of the DB and performing that substitution might get you a usable backup file. That's replacing all \x0d\x0a sequences with \x0a. Or I might be wrong and it's \x0d. This won't work on a larger backup where some \r\n sequences will occur naturally in compressed binary data. In those you're likely to have a much, much bigger job ahead of you. -- Craig Ringer -- 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 #7592: Installation of PostGresql at c:\Progam files folder does not create right permission on data folder
On 10/10/2012 01:07 PM, devenmtha...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 7592 Logged by: Deven Email address: devenmtha...@gmail.com PostgreSQL version: 9.0.3 Operating system: Windows 2008 R2 WITH SP1 (64 BITS) Description: We are installing our application which internally call postgresql-9.0.3-2-windows_x64.exe to install postgresql under c:\program files folder. But initialization of datbase failed with log that user(administrator) does not have enough permission on data folder. Can anyone help me out to address this issue? That's odd. Is it only on one computer? Or have you tried it on several different computers with the same results? Does the error persist if you run the installer with the same command line directly, not via your installer? Can you show the installer log file? What happens if you use a current installer - at least 9.0.10, preferably 9.2.1. -- Craig Ringer -- 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 #7597: exception 0xC0000005
On 10/11/2012 06:07 PM, Bo Thorbjørn Jensen wrote: Self-contained case attached. No crash here on version() = PostgreSQL 9.1.5 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5), 64-bit
Re: [BUGS] Please could you provide more specific step by step instructions to build this driver psqlodbc-09.01.0200 under Windows.
On 10/02/2012 05:51 PM, Копыченко Павел wrote: Please explain how the compiler can collect ODBC driver psqlodbc-09.01.0200 under Windows. I wont to compile this driver for x86 and x64 Win architecture. I was read next file win32-compilation.html. Follow the exact steps I compile it fails. I tried VS2005 VS72003 VS6. Every time I get a bunch of errors. For example, in Linux I have no problems. Only windose conpilation does not work. Please could you provide more specific step by step instructions to build this driver for windose. This isn't a bug report. Ask on pgsql-odbc or pgsql-general, but be aware that the ODBC folks tend to be very busy and don't get the chance to answer mail much. a bunch of errors and fails tell the reader nothing. If you want help, when you post to a more suitable list make sure you include a LOT more detail - the steps you've followed, the exact text of the error messages, etc etc. Use a pastebin site to paste long errors and just put a link in your email. Please don't reply to me; make a new post on a more suitable list. -- Craig Ringer -- 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 #7556 addition info
On 09/20/2012 01:14 PM, l...@tom.com wrote: plan of http://archives.postgresql.org/pgsql-bugs/2012-09/msg00222.php test=# explain select max(a.info)from sli_test a where a.id not in(select b.id from sli_test2 b where b.id5); QUERY PLAN --- Aggregate (cost=9243466274.00..9243466274.01 rows=1 width=12) - Seq Scan on sli_test a (cost=0.00..9243465024.00 rows=50 width=12) Filter: (NOT (SubPlan 1)) SubPlan 1 - Materialize (cost=0.00..18359.60 rows=50919 width=4) - Seq Scan on sli_test2 b (cost=0.00..17906.00 rows=50919 width=4) Filter: (id 5) That takes about 500ms here, on 9.1. What did you expect? What's the EXPLAIN ANALYZE if your results differ? You've failed to show your NOT EXISTS query and plan for comparison, but I'm guessing: regress=# explain analyze select max(a.info)from sli_test a where not exists (select 1 from sli_test2 b where a.id=b.id and b.id5); QUERY PLAN Aggregate (cost=50256.22..50256.23 rows=1 width=12) (actual time=671.993..671.993 rows=1 loops=1) - Hash Anti Join (cost=18510.11..47877.04 rows=951671 width=12) (actual time=103.048..459.508 rows=950001 loops=1) Hash Cond: (a.id = b.id) - Seq Scan on sli_test a (cost=0.00..16274.00 rows=100 width=16) (actual time=0.016..71.871 rows=100 loops=1) - Hash (cost=17906.00..17906.00 rows=48329 width=4) (actual time=86.948..86.948 rows=4 loops=1) Buckets: 8192 Batches: 1 Memory Usage: 1758kB - Seq Scan on sli_test2 b (cost=0.00..17906.00 rows=48329 width=4) (actual time=0.018..76.489 rows=4 loops=1) Filter: (id 5) Total runtime: 672.379 ms (9 rows) which, if so performs signficiantly worse. I'm struggling to understand what exactly your complaint is. It's kind of hard to work out what the intention of the query is in real-world terms to suggest alternatives, too. -- Craig Ringer -- 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 #7558: Postgres service not starting.
On 09/19/2012 09:21 PM, pathak.anu...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 7558 Logged by: Anurag Email address: pathak.anu...@gmail.com PostgreSQL version: 8.4.13 Operating system: Microsoft 2008 Server Description: Hello, I installed Postgres and tried by populating SHP files form PostGIS pulgin. When I tried to update pg_hba.conf for adding a CIDR addrs. When I connected again It shows following error- ERROR : Error connecting to the server: FATAL: could not load pg_hba.conf after that when I am trying to connect the database by double clicking, it is showing service is not present, start the service first. There is no sign that this is a bug. Try asking on the pgsql-general mailing list or Stack Overflow. Include more detail, in particular check your `pg_log` folder and get the most recent log messages. Also check the Windows event viewer for service messages related to PostgreSQL. Guesses: - Your text editor still has pg_hba.conf open. In Windows that locks the file so PostgreSQL can't open it. - You changed the file permissions when you replaced/edited pg_hba.conf, so PostgreSQL can't open it now. - You edited pg_hba.conf incorrectly, creating syntax errors. Please do not reply to me, post on -general or SO. -- Craig Ringer -- 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 #7556: select not in sub query plan very poor vs not exists
On 09/19/2012 01:48 PM, l...@tom.com wrote: The following bug has been logged on the website: Bug reference: 7556 Logged by: lt Email address: l...@tom.com PostgreSQL version: 9.2.0 Operating system: windows xp Description: create table sli_test (id int primary key,info varchar(20)); insert into sli_test select generate_series(1,100),'digoal'||generate_series(1,100); analyze verbose sli_test; create table sli_test2 (id int not null,info varchar(20)); insert into sli_test2 select generate_series(1,100),'dbase'||generate_series(1,100); analyze verbose sli_test2; explain select max(a.info)from sli_test a where a.id not in(select b.id from sli_test2 b where b.id5); QUERY PLAN --- Aggregate (cost=9241443774.00..9241443774.01 rows=1 width=12) Here's what I get on 9.1: regress=# explain select max(a.info)from sli_test a where a.id not in(select regress(# b.id from sli_test2 b where b.id5); QUERY PLAN - Aggregate (cost=38050.82..38050.83 rows=1 width=12) - Seq Scan on sli_test a (cost=18026.82..36800.82 rows=50 width=12) Filter: (NOT (hashed SubPlan 1)) SubPlan 1 - Seq Scan on sli_test2 b (cost=0.00..17906.00 rows=48329 width=4) Filter: (id 5) (6 rows) It runs in about 500ms here. You don't appear to have posted the full query plan, so it's hard to compare. In general, `NOT IN` is a poor formulation for a query; you're better off with a JOIN or with `NOT EXISTS`. See eg http://stackoverflow.com/questions/12444142/postgresql-how-to-figure-out-missing-numbers-in-a-column-using-generate-series/12444165#12444165 -- Craig Ringer -- 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 #7549: max_connections check should query master when starting standby
On 09/18/2012 07:57 AM, Fujii Masao wrote: If you change the max_connections on the master, you need to take a fresh backup from the master and start the standby from it. WTF, really? What else breaks the replication and forces a re-clone? -- Craig Ringer -- 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 #7554: save image into database using jsp and servlet
On 09/18/2012 08:26 PM, kamalnity...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 7554 Logged by: KAMAL Email address: kamalnity...@gmail.com PostgreSQL version: 8.3.0 Operating system: windows-7 Description: i want jsp and servlet code for save image.i found problem binary data but size 0kb. This is not a bug report. Please ask on pgsql-general or Stack Overflow after reading this: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems Also, UPGRADE URGENTLY. You are running a dangerously ancient version of the 8.3 series that is missing lots of bug fixes. The latest 8.3 is 8.3.20 and has more than two years of fixes in it. Back up your database then get 8.3.20 here: http://www.enterprisedb.com/products-services-training/pgdownload#windows and install it. You don't need to dump and reload. Also, note that Windows 7 doesn't explain much. You need to be specific, eg Windows 7 Professional x64 Service Pack 1. -- Craig Ringer -- 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 JDBC-hibernate Problem
On 09/19/2012 03:46 AM, Freddie Burgess wrote: The Employee ingest behaves a bit differently - it handles transactions programmatically, for example: Transaction tx = session.beginTransaction(); session.save(Employee); tx.commit(); Could it be possible that if an exception is thrown by the session.save() method that the transaction might not be rolled back or closed, although no errors pertaining to this scenario were recorded in the PostgreSQL log. It's possible; I don't use Spring, so I can't really say. I know that in EJB 3.1 container managed transactions with JTA data sources the guarantees are strong: - If the exception thrown is annotated @ApplicationException then rollback is controlled by that annotation; otherwise: - If it's an unchecked exception, the transaction is rolled back; and - If it's a checked exception that's properly declared the transaction is NOT rolled back I don't know what Spring's rules are. It's all a bit localized and specific to your code, so it's difficult to offer any useful advice at this point. If there's any chance you can cook it down to a small, runnable, self-contained test-case that'd be very useful. In my experience when I've done so I have, in the process, often found a bug in my code that was the cause of the problem. When I don't find an issue in my code I usually have something clear that demonstrates a problem and helps isolate which project(s) the problem is in. -- Craig Ringer -- 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 JDBC-hibernate Problem
On 09/18/2012 01:23 AM, Freddie Burgess wrote: Thanks Craig, We were able to make the necessary adjustments to the way Hibernate manages the data types differently in version 4.1.6, so we got pass this error. Now we have to tackle the a problem with the hibernate 4.1.6 batcher process no longer allowing us to ingest data into the database. We are getting the nested transactions not supported error, even though the java developers are telling me that they have only a single commit at the end of their logical transaction. Look at the PostgreSQL logs and see. It's easier to trace if you set log_line_prefix to something like: log_line_prefix = 'a=%a,u=%u,db=%d,pid=%p,vtx=%v,tx=%x,cmd=%i' which produces significantly more verbose logs but makes it easier to, using the pid and txix/vtxid info, work out how different logged statements fit into transactions. -- Craig Ringer -- 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 #7526: An error occured executing the Microsoft VC++ runtime installer
On 09/09/2012 06:38 PM, s3n_...@yahoo.com wrote: The following bug has been logged on the website: Bug reference: 7526 Logged by: Dan Email address: s3n_...@yahoo.com PostgreSQL version: 8.4.7 Operating system: Windows Vista Home Premium Description: Please help me with this error, i tried everything i found for this issue but didn't work for me , See: http://wiki.postgresql.org/wiki/Running_%26_Installing_PostgreSQL_On_Native_Windows#Common_installation_errors The error you're getting suggests that your VBScript runtime is misregistered. If i try to install the latest version 9.1.5 i will get another error : unable to write inside TEMP environment variable path Can you post the installation log for that one too? Sounds like your system setup is a bit wonky. Do you have antivirus software running? If so, disable or uninstall it then try again. Again, see http://wiki.postgresql.org/wiki/Running_%26_Installing_PostgreSQL_On_Native_Windows#Common_installation_errors and http://wiki.postgresql.org/wiki/Troubleshooting_Installation -- Craig Ringer -- 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 #7527: PgAdmin 1.14.3 fails
On 09/09/2012 11:54 PM, rona...@gpiti.com.br wrote: The following bug has been logged on the website: Bug reference: 7527 Logged by: Ronaldo Souza Email address: rona...@gpiti.com.br PostgreSQL version: 9.0.6 Operating system: Windows XP Description: I'd like to debug postgresql functions, set postgresql.conf with shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll' and run pldbgapi.sql, restarded BD, but the debugger doesn't work, after i input the parameters function it show me the message: an error has occurred! and then the PgAdmin 1.14.3 close. Do you have any idea what can i do? What is the EXACT TEXT of the error message when PgAdmin-III exits? Does updating to 9.0.9 have any effect? You can do this without a dump and reload or anything, just install the new version from http://www.enterprisedb.com/products-services-training/pgdownload#windows -- Craig Ringer -- 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 JDBC-hibernate Problem
On 09/12/2012 12:18 AM, Freddie Burgess wrote: We have upgraded from PostgreSQL 8.4.3 to PostgreSQL 9.1.4 and we are getting the following errors when attempting to auto-gen schema DDL. You've changed quite a bit at once, so it's a bit hard to narrow down. Does the error occur when you run with the new PgJDBC and PostGIS libraries against the *old* database server? What about if you run with the old libraries against the new database server? This might not work for other reasons, but is worth trying. If it works, that suggests a regression in PgJDBC or PostGIS's client library. -- Craig Ringer -- 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 #7537: Server will not start up from Windows Service Manager
On 09/14/2012 06:50 AM, dfisupp...@docfocus.ca wrote: The following bug has been logged on the website: Bug reference: 7537 Logged by: Owen Sleep Email address: dfisupp...@docfocus.ca PostgreSQL version: 9.0.8 Operating system: Windows Server 2003 Service Pack 2 Description: PostgreSQL service was running successfully for a month now. Restarted the machine and then the service will not start up from the service manager. I get the message Timed out waiting for server startup in the Windows event log. There is no log in the pg_log folder so unfortunately I have no starting point for troubleshooting. Have a look in the Windows event viewer, and see if you can find anything for the PostgreSQL service there. -- Craig Ringer -- 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 #7540: Hello. Need Help!
On 09/14/2012 05:33 PM, grandl...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 7540 Logged by: Gl Email address: grandl...@gmail.com PostgreSQL version: 9.0.1 Wow, that's a very old point release. You should be installing 9.0.9, the latest point release in the series. It's binary compatible with 9.0.x databases and is a drop-in replacement. Your subject line was very uninformative, so if you got no responses that's probably why. It tells nobody anything about your question. Good day. I have a folder Data. PG versioned postgresql-9.0.1-1.1C (x64). Have installed the same version of Postgres. Substitute for the Data then Postgres server does not start. Check the PostgreSQL error logs in the `pg_log` directory. Also check the windows Event Viewer for messages relating to the PostgreSQL service. At a guess, you failed to set the permissions on the data directory to allow the postgres user full control or failed to apply them recursively. -- Craig Ringer -- 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 #7513: Cluster install failed
On 08/31/2012 11:49 PM, grav...@smartronix.com wrote: The following bug has been logged on the website: Bug reference: 7513 Logged by: Larry Email address: grav...@smartronix.com PostgreSQL version: 8.4.0 Operating system: win server 2003 SP2 Description: Post-Installation failed(Cluster install failed). I have gotten this error every time I have attempted to install PostgreSQL 8.4. Do you really mean 8.4.0? That has plenty of known bugs and should not ever be a new install. Download the latest in the 8.4 series, 8.4.13, from here: http://www.enterprisedb.com/products-services-training/pgdownload#windows and try again. If you still get errors, please read: http://wiki.postgresql.org/wiki/Running_%26_Installing_PostgreSQL_On_Native_Windows#Common_installation_errors and try the steps therein. If problems continue, read: http://wiki.postgresql.org/wiki/Troubleshooting_Installation and send your installer log file. Please reply to pgsql-bugs@postgresql.org not directly to me. -- Craig Ringer -- 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] PostGreSQL pgdac - C++ Builder 2007
On 08/30/2012 12:08 AM, lacm...@sapo.pt wrote: Hi, I am working with c++ Builder 2007, and try to work also with PostGreSQL. Is that Borland/Embarcadero C++ builder? If so, I have to ask: *why*? I have downloaded the following exe, http://www.devart.com/pgdac/pgdac11.exe Which is http://www.devart.com/pgdac/ , apparently the PostgreSQL Data Access Components for C++ builder and various other mostly RAD tools. I've never seen or heard of it before, but I don't use these tools. It doesn't come up on the mailing lists. [Linker Error] Unresolved external 'WSAIoctl' referenced from C:\PROGRAM FILES (X86)\CODEGEAR\RAD STUDIO\5.0\LIB\DAC105.LIB|CRVioTcp Does someone know what this could be? Nothing to do with Pg. You're better off asking somewhere specific to C++Builder or specific to this pgdac tool. -- Craig Ringer -- 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] PostGreSQL pgdac - C++ Builder 2007
On 08/30/2012 12:08 AM, lacm...@sapo.pt wrote: Does someone know what this could be? Also, this is *clearly* not a PostgreSQL bug, just to make that explicit. It's an issue in: - most likely your code or build systems; or - pgdac - C++builder - a compatibility issue between the two - something funky in your OS/system setup If you were reporting a PostgreSQL bug, you'd want to include things like *version* *numbers*. See: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -- Craig Ringer -- 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 #7499 additional comments
On 08/23/2012 04:12 AM, Denis Kolesnik wrote:
Suppose a person who has basic SQL knowledges would learn on praxis
how would result a query if a person adds the clause limit 1 to it
Then they just got bitten by not learning enough and not testing their
code well enough; they were probably programming by recipe and
copy-and-paste, not by learning the platform they're working with.
http://www.postgresql.org/docs/9.1/static/sql-select.html#SQL-ORDERBY
The ORDER BY clause causes the result rows to be sorted according to
the specified expression(s). If two rows are equal according to the
leftmost expression, they are compared according to the next expression
and so on. If they are equal according to all specified expressions,
they are returned in an implementation-dependent order.
It'd be really nice if every programming language and tool could be
completely safe and easy, with no undefined, implementation-defined or
inconsistent behaviour. Unfortunately, in the real world that doesn't
happen because perfectly specified platforms are (a) really hard to
actually write and (b) usually hard to optimise and thus slow.
Suppose a person with basic C knowledge wrote this (utterly wrong and
dangerous, do not use for anything) program:
#include stdio.h
#include string.h
#include malloc.h
int main() {
char * blah = (char*)malloc(10);
strcpy(blah,1234567890);
printf(%s\n, blah);
}
This program has *at* *least* one bug that'll cause it to run most of
the time, but fail unpredictably, especially when used as part of a
larger program rather than standalone. Failure will depend on platform,
C library, kernel, compiler settings, and the contents of uninitialized
memory.
Is the platform responsible for the user shooting themselves in the foot
because they didn't learn about null termination of strings, buffer
over-runs, the dangers of using strcpy(), etc? To me it's a bug in the
user's code, not the platform.
Sure, the platform could be easier to use. It could add lots of bounds
checks, prohibit raw memory access, use garbage collection instead of
explicit pointer-based memory management, etc. Then you'd have a new
platform called Java, which is very useful - but not really something
you can use to write tiny programs that take microseconds to run, or
high-performance operating system kernels.
Even Java has plenty of traps and confusing characteristics. Anything to
do with threads. finalize() methods. try {} catch {} finally {}
constructs. Double-checked locking. Plenty more. That's in a language
that was designed to be an easier and safer alternative to C.
Everything is a compromise, including the SQL language and
implementations of it. If Pg made underspecified sorts an error then
lots of other people would scream bug! because pretty much every other
database system lets you do this so it'd be a portability problem - and
because it's a really useful behaviour for some purposes. If Pg's query
planner always ensured that sorts were stable and always did the same
sorts, people wouldn't use Pg because it'd be too slow.
More importantly, PostgreSQL has no way of *knowing* for sure that the
sort is underspecified. It can't know that the column you've specified
isn't unique, or at least unique within the subset of data you're
working with. It trusts you to know what you want.
The trick is to read the documentation, learn, and test your code well.
That's true of every language, even those that try to protect the
programmer from their mistakes as much as possible.
--
Craig Ringer
--
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] additional message to the bug #7499
On 08/22/2012 08:36 AM, Denis Kolesnik wrote: I have now VERY strong argument to consider it is as a bug: if there a understandable for SQL language sequence which sorts in other fashion when adding LIMIT. Underspecified sorts can have unstable results, that's allowed by the spec and is a reasonable performance optimisation. If you want stable sorts you have to provide a fully defined ordering. To say this is a bug is a bit like saying that undefined behaviour in C is a bug. It isn't, the language and compiler are giving you what they're supposed to, just not what you want. http://en.wikipedia.org/wiki/Undefined_behavior Unstable sorts are a common optimisation http://en.wikipedia.org/wiki/Sorting_algorithm#Stability and a very useful one. Not allowing Pg to use unstable sorts, or use different sorts for different query plans, would slow correct queries down to make an incorrect query like yours run how you expect. -- Craig Ringer -- 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 #7485: 9.2 beta3 libxml2 can't be loaded on Windows
On 08/14/2012 11:42 PM, Rikard Pavelic wrote: On 8.8.2012. 13:30, Craig Ringer wrote: On 08/08/2012 06:24 PM, rikard.pave...@zg.htnet.hr wrote: The following bug has been logged on the website: Bug reference: 7485 Logged by: Rikard Pavelic Email address: rikard.pave...@zg.htnet.hr PostgreSQL version: 9.2 beta3 Operating system: Windows Description: This is still an issue as reported in http://archives.postgresql.org/pgsql-bugs/2012-05/msg00231.php - How you installed PostgeSQL (ie the EnterpriseDB installer, from source, .zip install) I've used EnterpriseDB installer (9.2 beta2 with this bug, and now 9.2 beta3) - The error message you are getting and the command(s) that cause it ERROR: could not set up XML error handler SQL state: 0A000 Hint: This probably indicates that the version of libxml2 being used is not compatible with the libxml2 header files that PostgreSQL was built with. I'm calling function with type that has an XML attribute. I can provide a test case, but since this is just a warning of the old bug I didn't. OK, I get you. Given the context of the old report this sounds like it could be an installation/packaging issue. I'll ping the EDB folks. Which Windows is it exactly? And did you use the 32-bit or 64-bit installer? -- Craig Ringer -- 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 #6722: Debugger broken?
On 08/13/2012 07:19 PM, Heikki Linnakangas wrote: I tried to drop and recreate the branch, but the server would not let me push that change, as it's a non-fast-forward update. Someone needs to temporarily remove the check for that from the git server - I don't think I have access to do that. Do you? pushing with --force didn't work? git push --force origin mybranch -- Craig Ringer -- 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 #7484: while restore database backup error is raised
On 08/08/2012 02:06 PM, sudhir...@hotmail.com wrote: The following bug has been logged on the website: Bug reference: 7484 Logged by: sudhir Email address: sudhir...@hotmail.com PostgreSQL version: 9.1.4 Operating system: centos Description: pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 832; 1255 1816123 FUNCTION ad_column_identifier_ref_sql(character varying, character varying, character varying, character varying, character varying) tad pg_restore: [archiver (db)] could not execute query: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. Please examine the PostgreSQL server logs for error details. I think they're in /var/lib/pgsql/data/pg_log on CentOS, as that's where they are on Fedora. It'd help to know your CentOS version, how you installed PostgreSQL, etc. Are you using any extensions? PostGIS? -- Craig Ringer -- 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 #7484: while restore database backup error is raised
On 08/08/2012 02:54 PM, John R Pierce wrote: On 08/07/12 11:10 PM, Craig Ringer wrote: Please examine the PostgreSQL server logs for error details. I think they're in /var/lib/pgsql/data/pg_log on CentOS, as that's where they are on Fedora. the PGDG rpm/yum repo of 9.1 defaults logs to /var/lib/pgsql/9.1/data/pg_log other things of potential interest in this bug report would be any unusual or exceptionally large settings in postgresql.conf, is this a 32 bit or 64 bit install Good point. Please show: SELECT version() and the output of this query: http://wiki.postgresql.org/wiki/Server_Configuration -- Craig Ringer
Re: [BUGS] BUG #7485: 9.2 beta3 libxml2 can't be loaded on Windows
On 08/08/2012 06:24 PM, rikard.pave...@zg.htnet.hr wrote: The following bug has been logged on the website: Bug reference: 7485 Logged by: Rikard Pavelic Email address: rikard.pave...@zg.htnet.hr PostgreSQL version: Unsupported/Unknown Operating system: Windows Description: This is still an issue as reported in http://archives.postgresql.org/pgsql-bugs/2012-05/msg00231.php While on topic of XML is there any workaround for this? CREATE TABLE data (id int, x xml); SELECT t FROM data t GROUP BY t; I'm not really sure what operator to create. I'm fine with xml being compared like text Your report confuses me somewhat. You've linked to an issue that is extremely specific to one particular PostgreSQL version without providing the version you are using or details about your OS. You then mention the need to create an operator, which seems to have nothing to do with the problem you linked to. Please follow up with: - Your PostgreSQL version - How you installed PostgeSQL (ie the EnterpriseDB installer, from source, .zip install) - The error message you are getting and the command(s) that cause it - A description of the problem you are having -- Craig Ringer -- 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 #7485: 9.2 beta3 libxml2 can't be loaded on Windows
Argh. Disregard the version comments in my post, I totally failed to notice the version in the subject line. -- Craig Ringer -- 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] Small bug in psqlodbc-09.01 prevents interoperability with LISTSERV
On 08/04/2012 11:43 PM, Eric Thomas wrote: Because we have customers who think Excel is an RDBMS, our product LISTSERV religiously queries ODBC capabilities at startup and prints warnings as appropriate. A customer tried to use PostgreSQL on Windows and got the following (these are our messages not yours, I am pasting them to show all the version numbers): Hi As there's been no response on -bugs I've passed your report on to the pgsql-odbc mailing list. There seems to be little activity on the ODBC driver these days. It might well be worth your time to grab the psqlODBC sources, patch them to resolve your issues, and post the patch as a proposed change on the pgsql-odbc list. I don't work with ODBC (or Windows very much) so I'm not sure I can be of much direct help. -- Craig Ringer
Re: [BUGS] BUG #7479: SERVICE NOT START
On 08/03/2012 08:04 PM, diego.olive...@bentonisa.com wrote: The following bug has been logged on the website: Bug reference: 7479 Logged by: DIEGO DE OLIVEIRA CORDEIRO Email address: diego.olive...@bentonisa.com PostgreSQL version: 8.3.0 Operating system: FEDORA LINUX Description: DO NOT START THE SERVICE, DATABASE IS OK, WHAT CAN WE DO? You need to post a lot more detail for anybody to be able to help you. http://wiki.postgresql.org/wiki/Guide_to_reporting_problems There's no sign this is a bug, so I recommend you post a question to the pgsql-general mailing list, where there are many more people. Make sure you explain: - What went wrong, ie what caused it to go from working to non-working - What, if anything ,you have tried to do to fix it already - Any recent changes or events and include: - The full PostgreSQL version. (You really can't be running 8.3.0, right? It should be 8.3.something.) - The full Fedora version - information about your hardware - Your PostgreSQL server logs - Your kernel dmesg -- Craig Ringer
Re: [BUGS] Mac OS X Lion issues editing pg_hba.conf and permissions (was: Bug)
On 08/03/2012 07:00 AM, Nayef wrote: In Mac Lion Mountin: when i modify pg_hba.cfg file, or just open it and close it the database not work next time. also when change the (Data) directory privileges, database not work next time. Hi You really need to provide more information if you wish to treat this as a bug report. http://wiki.postgresql.org/wiki/Guide_to_reporting_problems For both the cases you report, the contents of the PostgreSQL error logs are required. You should also specify how you installed PostgreSQL, what version it is, exactly what pg_hba.conf looked like before and after your edits, *what* permissions you changed on the datadir, etc. -- Craig Ringer
Re: [BUGS] Error on pg_settings.bytea_output for pg9.1
On 07/31/2012 01:50 PM, Guillaume Lelarge wrote: Check the PgAdmin-III preferences; there may be an option to control its preferred bytea format. There's no option to control this. Thanks for confirming that. Is it really best for PgAdmin-III to have a different default than Pg its self? -- Craig Ringer -- 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 #6751: usage flaws in pg_restore
On 07/24/2012 08:45 PM, pilum...@uni-muenster.de wrote: The following bug has been logged on the website: Bug reference: 6751 Logged by: Arne Scheffer Email address: pilum...@uni-muenster.de PostgreSQL version: 9.1.4 Operating system: Unix (RHEL 6) Description: We've been using PostgreSQL for years now. It's great. Only the usage of pg_restore is annoying Yeah. pg_restore really needs some usability love. I posted a big rant about it a while ago. It's all about finding the time to actually do something about it. -- Craig Ringer -- 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 on pg_settings.bytea_output for pg9.1
On 07/30/2012 11:49 AM, Emcisc (JinWei) Zhao wrote: 5.Run the SQL query: SELECT setting FROM pg_settings WHERE name = 'bytea_output'; in pgAdmin3. It will show you the value 'escape'. 6.Run the client application 'psql' to connect to the same DB server and database with the same user account. And in psql interactive terminal, run the same SQL: SELECT setting FROM pg_settings WHERE name = 'bytea_output'; . It will show you the value 'hex', NOT the previous value 'escape'. 7.That means, the same environment, the same SQL query, but different output. And I don't touch the file postgresql.conf any more ever before. Is this a bug of pgAdmin3? I don't know if it's a bug as such, but it's certainly a curious decision if what you describe is the intended behaviour. It sounds like PgAdmin-III might be sending a SET bytea_output = 'escape' query during connection setup. bytea_output is a per-session parameter. Each session (connection) to PostgreSQL can have a different value, and it can be changed within the session. Check the PgAdmin-III preferences; there may be an option to control its preferred bytea format. It may also be worth turning on log_statement = 'all' in postgresql.conf, starting PgAdmin-III, then looking at the PostgreSQL logs to see if PgAdmin-III is in fact sending a `SET bytea_output` command. -- Craig Ringer
Re: [BUGS] BUG #6768: Failure in OBDC
On 07/31/2012 07:31 AM, Fábio Hentz Lunkes wrote: Sorry, all right. It was my mistake. No worries - thanks for writing back to confirm. That way anyone else having the issue later will have some idea where to look (or not look at least). -- Craig Ringer
Re: [BUGS] BUG #6763: Severe memory leak with arrays and hstore
On 07/27/2012 10:31 AM, Craig Ringer wrote: Ouch. Sure looks like a leak to me, yeah. ... but it turns out I'm not thinking very straight. I forgot to check the size of your `shared_buffers' or `work_mem' and forgot to get you to report `free -m' output after each run to measure _real_ memory use. During testing I did got a backend crash when running an INSERT - which I didn't expect given that I have only 20MB of work_mem and 256MB of shared_buffers. I was surprised by that as I would not have expected that query to require a huge gob of RAM. I didn't dig much further as I'm on a swapless system with overcommit enabled ( 'cos the Java VM does't work with overcommit off ) which isn't exactly a recommended Pg configuration. -- Craig Ringer -- 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 #6763: Severe memory leak with arrays and hstore
On 07/27/2012 07:52 PM, luben karavelov wrote: It's good that the bug is not in HEAD. I was testing on 9.1.4. So was I, and while I thought I'd reproduced it I now suspect I was just seeing shared_buffers touching. Are you able to produce a self-contained SQL test that demonstrates the leak? Does the test program I posted behave differently on your system? -- Craig Ringer -- 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 #6768: Failure in OBDC
On 07/27/2012 07:52 AM, fabio.lun...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 6768 Logged by: Fábio Hentz Lunkes Email address: fabio.lun...@gmail.com PostgreSQL version: 9.1.0 Operating system: Windows 7 Description: Hellow. My teste to developer application with Microssoft Access, ODBC and Postgres. With grant selet in one field, other fields is revoke permissions, access in table with Microsoft Access is not possible. Failure is generate, to permission denied. In Microsoft MS Query, no error. I think you'll need to explain this in a bit more detail, with: - Table definitions - The EXACT commands you ran - The EXACT error messages As far as I know, running: GRANT SELECT on tablename(column) TO user; shouldn't in any way restrict their existing rights, and the documentation backs that up: http://www.postgresql.org/docs/9.1/static/sql-grant.html A user may performSELECT,INSERT, etc. on a column if he holds that privilege for either the specific column or its whole table. Granting the privilege at the table level and then revoking it for one column will not do what you might wish: the table-level grant is unaffected by a column-level operation. ... so I think you might need to show what's happening in a bit more detail. Beware that there isn't a big Microsoft Access community here. -- Craig Ringer
Re: [BUGS] BUG #6763: Severe memory leak with arrays and hstore
On 07/26/2012 09:32 AM, karave...@mail.bg wrote:
Finally I have managed to migrate it in batches of 100-200k user ids and
disconnecting after each query in order to free the backend and leaked
memory.
If you do it in batches, but you do NOT disconnect and reconnect, does
the backend continue to grow?
What's the output of:
SELECT count(sub.user_id), to_char(AVG(sub.n_prefs), '9.99') FROM (
SELECT user_id, count(name) AS n_prefs FROM old_prefs GROUP BY user_id)
AS sub;
and
SELECT pg_size_pretty(pg_total_relation_size('old_prefs'));
?
--
Craig Ringer
--
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] primary and hot standby database don' work now
On 07/22/2012 02:00 PM, leo xu wrote: hello everyone: my pg version is 9.1.2 running on red hat 5.4 x64 servers.one day,i found all database indexes can't work,reindex database,it can work,but some table has primary key,found exists the same two records in table. When did this start happening? At random? After a server crash or power loss? After an administrative action? Are you running with fsync=off or using storage that has write caching enabled? -- Craig Ringer -- 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 #6763: Severe memory leak with arrays and hstore
Hi all Here's a fully self contained, automated test case that demonstrates the leak. Example output on my system, pasted as quote to stop Thunderbird mangling it: $ ./hstore-leak-demo.sh NOTICE: extension hstore already exists, skipping CREATE EXTENSION DROP TABLE CREATE TABLE CREATE TABLE INSERT 0 10 INSERT 0 80175 INSERT 0 72267 INSERT 0 50649 INSERT 0 30430 avg | max +- 3.33521000 | 20 (1 row) Backend PID is: 3167 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND postgres 3167 0.0 0.0 504276 4368 ?Ss 10:29 0:00 postgres: craig regress [local] idle USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND postgres 3167 91.0 13.0 2163384 1055652 ? Ss 10:29 0:00 postgres: craig regress [local] idle USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND postgres 3167 77.5 13.2 2163408 1071496 ? Ss 10:29 0:01 postgres: craig regress [local] idle USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND postgres 3167 108 13.4 2163408 1084056 ? Ss 10:29 0:02 postgres: craig regress [local] idle USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND postgres 3167 93.0 13.5 2163408 1092244 ? Ss 10:29 0:02 postgres: craig regress [local] idle USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND postgres 3167 86.0 13.6 2163408 1100444 ? Ss 10:29 0:03 postgres: craig regress [local] idle USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND postgres 3167 101 13.7 2163408 1108704 ? Ss 10:29 0:04 postgres: craig regress [local] idle USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND postgres 3167 93.8 13.8 2163408 1116896 ? Ss 10:29 0:04 postgres: craig regress [local] idle USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND postgres 3167 88.8 13.9 2163408 1125048 ? Ss 10:29 0:05 postgres: craig regress [local] idle USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND postgres 3167 99.1 14.0 2163408 1133228 ? Ss 10:29 0:05 postgres: craig regress [local] idle hstore-leak-demo.sh Description: application/shellscript -- 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 #6763: Severe memory leak with arrays and hstore
On 07/26/2012 09:55 PM, luben karavelov wrote: Ok, I will do the procedure again with taking notes on each step. Thankyou for taking the time to do this in detail. First, here are the results of the queries you asked: count | to_char -+--- 1257262 | 2.26 pg_size_pretty 264 MB OK, none of that looks obviously insanely huge to me. That's a lot of hstores, but with your query I wouldn't expect them to all sit around in memory, and nothing individually is particularly huge. Also there are max of 34 rows per user_id in old_prefs Thanks, I forgot to ask that. Again, nothing particularly big. USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND postgres 19121 0.0 0.0 2266944 3448 ?Ss 15:23 0:00 postgres: pg pg 10.0.2.71(51734) idle postgres 19121 0.8 7.1 3081772 582712 ? Ss 15:23 0:02 postgres: pg pg 10.0.2.71(51734) idle postgres 19121 1.1 8.5 3176164 697444 ? Ss 15:23 0:05 postgres: pg pg 10.0.2.71(51734) idle postgres 19121 0.7 9.6 3210224 791404 ? Ss 15:23 0:08 postgres: pg pg 10.0.2.71(51734) idle postgres 19121 0.9 10.8 3277412 889860 ? Ss 15:23 0:11 postgres: pg pg 10.0.2.71(51734) idle postgres 19121 0.9 11.5 3277412 945560 ? Ss 15:23 0:15 postgres: pg pg 10.0.2.71(51734) idle postgres 19121 1.2 16.2 3736968 1331796 ? Ss 15:23 0:20 postgres: pg pg 10.0.2.71(51734) idle 1. Backend does not free allocated memory between transactions. 2. Rolled back transactions also leak memory. 3. Leaked memory is not linear to work done - 2 transactions with 200k keys will leak less than 1 transaction with 400k keys Ouch. Sure looks like a leak to me, yeah. Thankyou for taking the time to do this. It's common to see leaks reported here that are really just queries that require lots of memory, so the first response tends to be somewhat cautious. This doesn't look like one of those reports. I don't know if I can be much use with the actual tracking down of the leak, but there certainly appears to be one, and you've provided a pretty clear illustration of it. -- Craig Ringer -- 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 #6763: Severe memory leak with arrays and hstore
On 07/27/2012 10:30 AM, Craig Ringer wrote: Hi all Here's a fully self contained, automated test case that demonstrates the leak. Gah. Except it doesn't now, as shown by the text I pasted. WTF? I was *definitely* seeing this on my system. What's changed? Will follow up. -- 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 #6763: Severe memory leak with arrays and hstore
OK, it's certainly leaking, but not in the same drastic way I was able to reproduce manually a couple of times earlier. Self-contained test case attached. $ bash hstore-leak-demo.sh NOTICE: extension hstore already exists, skipping CREATE EXTENSION DROP TABLE CREATE TABLE CREATE TABLE INSERT 0 10 INSERT 0 80014 INSERT 0 72434 INSERT 0 50340 INSERT 0 30077 avg | max +- 3.32865000 | 21 (1 row) Backend PID is: 4823 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND Before first postgres 4823 0.0 0.0 504276 4312 ? Ss 11:19 0:00 postgres: craig regress [local] idle Iteration 1 postgres 4823 0.0 0.3 536908 25416 ? Rs 11:19 0:00 postgres: craig regress [local] INSERT Iteration 2 postgres 4823 33.0 13.1 2163384 1056560 ? Rs 11:19 0:00 postgres: craig regress [local] INSERT Iteration 3 postgres 4823 56.0 13.3 2163408 1072300 ? Rs 11:19 0:01 postgres: craig regress [local] INSERT Iteration 4 postgres 4823 58.7 13.4 2163408 1084936 ? Rs 11:19 0:02 postgres: craig regress [local] INSERT Iteration 20 postgres 4823 85.3 14.3 2173776 1156784 ? Rs 11:19 0:13 postgres: craig regress [local] INSERT Iteration 40 postgres 4823 92.0 16.3 2176848 1314700 ? Rs 11:19 0:28 postgres: craig regress [local] INSERT Iteration 60 postgres 4823 94.1 16.4 2173776 1322208 ? Rs 11:19 0:43 postgres: craig regress [local] INSERT Iteration 80 postgres 4823 96.0 16.4 2173776 1323768 ? Rs 11:19 0:58 postgres: craig regress [local] INSERT Iteration 100postgres 4823 95.7 16.5 2176848 1329880 ? Rs 11:19 1:14 postgres: craig regress [local] INSERT Iteration 120postgres 4823 97.1 16.4 2176848 1329132 ? Rs 11:19 1:31 postgres: craig regress [local] INSERT Iteration 140postgres 4823 96.8 16.4 2176848 1329524 ? Rs 11:19 1:48 postgres: craig regress [local] INSERT hstore-leak-demo.sh Description: application/shellscript -- 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 #6763: Severe memory leak with arrays and hstore
On 07/27/2012 01:47 PM, Tom Lane wrote: Craig Ringer ring...@ringerc.id.au writes: OK, it's certainly leaking, but not in the same drastic way I was able to reproduce manually a couple of times earlier. Self-contained test case attached. Using HEAD with stock parameters, I don't see any significant change in allocated address space (VSZ): it sits right around 170MB. The reported resident set size (RSS) starts from very little and rises to about 140MB, but I think that's just an artifact of the process touching more and more of the shared-buffers array as it runs. Gah. I should know better than that. Sorry. This makes me wonder if the leak-like pattern I saw earlier was just a similar growth in shared_buffers, and carried on more steeply rather than tapering off because I was working with a smaller data set. -- Craig Ringer -- 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 #6746: feature request
On 07/21/2012 03:28 AM, blastofftopl...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 6746 Logged by: ram Email address: blastofftopl...@gmail.com PostgreSQL version: 9.1.4 Operating system: linux mint maya Description: Please add built in feature in postgresql for setting size of individual table in terms of bytes ,megabyes etc. so that user wont be concerned about the data flooding out of disk. This is not a bug report. Maybe you should post a fleshed out proposal with details on what you want and what problems it would solve to the pgsql-general mailing list? It sounds like what you are talking about is table quotas. Try searching the mailing lists for prior discussion on the topic. -- Craig Ringer -- 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] main log encoding problem
On 07/19/2012 03:24 PM, Tatsuo Ishii wrote: BTW, I'm not stick with mule-internal encoding. What we need here is a super encoding which could include any existing encodings without information loss. For this purpose, I think we can even invent a new encoding(maybe something like very first prposal of ISO/IEC 10646?). However, using UTF-8 for this purpose seems to be just a disaster to me. Good point re unified chars. That was always a bad idea, and that's just one of the issues it causes. I think these difficult encodings are where logging to dedicated file per-database is useful. I'm not convinced that a weird and uncommon encoding is the answer. I guess as an alternative for people for whom it's useful if it's low cost in terms of complexity/maintenance/etc... -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [GENERAL] [BUGS] main log encoding problem
On 07/19/2012 04:58 PM, Alban Hertroys wrote: On 19 July 2012 10:40, Alexander Law exclus...@gmail.com wrote: Ok, maybe the time of real universal encoding has not yet come. Then we maybe just should add a new parameter log_encoding (UTF-8 by default) to postgresql.conf. And to use this encoding consistently within logging_collector. If this encoding is not available then fall back to 7-bit ASCII. What do you mean by not available? Sorry, it was inaccurate phrase. I mean if the conversion to this encoding is not avaliable. For example, when we have database in EUC_JP and log_encoding set to Latin1. I think that we can even fall back to UTF-8 as we can convert all encodings to it (with some exceptions that you noticed). I like Craig's idea of adding the client encoding to the log lines. Nonono! Log *file* *names* when one-file-per-database is in use. Encoding as a log line prefix is a terrible idea for all sorts of reasons. -- Craig Ringer -- 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] main log encoding problem
On 07/18/2012 11:16 PM, Alexander Law wrote: Hello! May I to propose a solution and to step up? I've read a discussion of the bug #5800 and here is my 2 cents. To make things clear let me give an example. I am a PostgreSQL hosting provider and I let my customers to create any databases they wish. I have clients all over the world (so they can create databases with different encoding). The question is - what I (as admin) want to see in my postgresql log, containing errors from all the databases? IMHO we should consider two requirements for the log. First, The file should be readable with a generic text viewer. Second, It should be useful and complete as possible. Now I see following solutions. A. We have different logfiles for each database with different encodings. Then all our logs will be readable, but we have to look at them one by onе and it's inconvenient at least. Moreover, our log reader should understand what encoding to use for each file. B. We have one logfile with the operating system encoding. First downside is that the logs can be different for different OSes. The second is that Windows has non-Unicode system encoding. And such an encoding can't represent all the national characters. So at best I will get ??? in the log. C. We have one logfile with UTF-8. Pros: Log messages of all our clients can fit in it. We can use any generic editor/viewer to open it. Nothing changes for Linux (and other OSes with UTF-8 encoding). Cons: All the strings written to log file should go through some conversation function. I think that the last solution is the solution. What is your opinion? Implementing any of these isn't trivial - especially making sure messages emitted to stderr from things like segfaults and dynamic linker messages are always correct. Ensuring that the logging collector knows when setlocale() has been called to change the encoding and translation of system messages, handling the different logging output methods, etc - it's going to be fiddly. I have some performance concerns about the transcoding required for (b) or (c), but realistically it's already the norm to convert all the data sent to and from clients. Conversion for logging should not be a significant additional burden. Conversion can be short-circuited out when source and destination encodings are the same for the common case of logging in utf-8 or to a dedicated file. I suspect the eventual choice will be all of the above: - Default to (b) or (c), both have pros and cons. I favour (c) with a UTF-8 BOM to warn editors, but (b) is nice for people whose DBs are all in the system locale. - Allow (a) for people who have many different DBs in many different encodings, do high volume logging, and want to avoid conversion overhead. Let them deal with the mess, just provide an additional % code for the encoding so they can name their per-DB log files to indicate the encoding. The main issue is just that code needs to be prototyped, cleaned up, and submitted. So far nobody's cared enough to design it, build it, and get it through patch review. I've just foolishly volunteered myself to work on an automated crash-test system for virtual plug-pull testing, so I'm not stepping up. -- Craig Ringer -- 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 #6735: PANIC: 42501: could not open control file global/pg_control: Permission denied
On 07/16/2012 07:54 PM, Petros Tsialiamanis wrote: Sorry for the misunderstanding. When I said that I reproduced the error in 9.1 version, I mean that I created the PGDATA with 9.1 postgresql server as 'local system' user and after that I tried to start the postgresql server as 'pss-svc' user and I took the error message which I sent with my previous mail. So there isn't any incompatibility problem with PGDATA. OK, that helps explain that. Thanks for following up with a current version, then. I have a Windows VM on this machine so I'll see if I can reproduce that issue. I need a bit more information to do so. Specifically I need to know how the user 'pss-svc' was created, what its group memberships are and what its rights are (can interact with desktop, login as service, etc). As 'pss-svc' user I can open, read and write to the pg_control file ( I took backup of this file first ). Open, read and write using what command(s) or programs? Is there a UAC prompt? Did you run the CACLS command you were given by John? I have exactly the same problem when I try to start progresql server as Administrator instead of 'pss-svc' user If 'pss-svc' user is a member of Administrators or Local Admins, remove the user from those groups. Pg is quite insistent about not being run as admin. That shouldn't be the cause of these issues, as it's quite explicit about it when that's the case, but it's a good idea anyway. Personally I think Pg should let this up to the user, but that's the way it is for now. -- Craig Ringer -- 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 #6697: postgres.exe crashed
On 07/13/2012 05:19 PM, Mirko Mittmann wrote: Hello, the message from the event viewer says the following things: anwendungsname postgres.exe fehlermodulname SSLEAY32.dll fehlermodulversion 6.0.6002.18541 Please reply to pgsql-bugs@postgresql.org not directly to me. Sorry, I forgot to set Reply-to. I've cc'd the list. -- Craig Ringer -- 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 #6735: PANIC: 42501: could not open control file global/pg_control: Permission denied
On 07/13/2012 09:00 PM, tsial...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 6735 Logged by: Petros Tsialiamanis Email address: tsial...@gmail.com PostgreSQL version: 8.3.5 Operating system: WinXP Pro SP3 Description: Hi, The first time I started the postgresql server as 'Local System' user and I created the PGDATA. Now I am trying to start the postgresql server again as 'pss-svc' user which is member of Administrators group and I take the following error message (I've changed the debug log level) The server shouldn't crash at the end, but otherwise this is all misconfiguration of your system. If you change the service account, you need to change the permissions on the PostgreSQL data directory to match the new service account credentials. DEBUG: 0: mapped win32 error code 5 to 13 LOCATION: _dosmaperr, .\src\port\win32error.c:182 PANIC: 42501: could not open control file global/pg_control: Permission denied LOCATION: ReadControlFile, .\src\backend\access\transam\xlog.c:3904 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. server starting I'm not sure why it's crashing here, but you're running such an ancient version that it's hard to care. If you can reproduce the crash with the latest 8.3 point release it might be worth a look. -- Craig Ringer -- 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 #6735: PANIC: 42501: could not open control file global/pg_control: Permission denied
On 07/14/2012 12:18 AM, Petros Tsialiamanis wrote: Thank you very much for your reply. Thanks for coming back and re-testing with a modern PostgreSQL. PostgreSQL 9.1 isn't compatible with databases from 8.3, so you can't actually run Pg 9.1 directly against a datadir from 8.3; that's why I suggested the latest 8.3 point release. However, your startup should be failing with a message telling you this, not with a permissions error then (more importantly) a crash. Is there any antivirus software on this computer? If so, what is it? Does excluding the PostgreSQL data directory, PostgreSQL executable directory, and (if the AV supports it) adding process exclusions for postmaster.exe and postgres.exe have any effect? The 'pss-svc' user is member of the administrators group and has full permissions for PostgreSQL data directory. It clearly doesn't, because PostgreSQL is getting permission denied from the OS when accessing global/pg_control. Maybe you need to apply permissions recursively? Remember that on Win7, membership of the Administrators group doesn't grant the ability to perform file operations as administrator directly. It grants the ability to create privileged processes that can then perform those operations using implicit or explicit run as administrator functionality. I can't off the top of my head think of a safe way on Windows to test if a file is writable as a given user without potentially changing its contents. On Linux I'd say run touch /path/name but there's no touch command on Windows. global\pg_control is a binary file so you can't just open it and save it in notepad (DO NOT DO THIS) as it'll corrupt it hopelessly, and Windows doesn't come with a binary-safe editor. I reproduced the crash with PostgreSQL version 9.1.4.12152 with the following output : [snip] LOCATION: _dosmaperr, .\src\port\win32error.c:186 PANIC: 42501: could not open control file global/pg_control: Permission denied LOCATION: ReadControlFile, .\src\backend\access\transam\xlog.c:4687 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. ** OK, that's not very nice behaviour - it should be doing a clean exit after it fails to read global/pg_control . Hmm. I'm not sure off the top of my head how to tackle tracking that down without a debugger. I don't really have time at the moment to set up a test environment under Windows and see if I can reproduce it. Ideas anyone? Can someone with a Windows box use pg_ctl to try to start a new Pg instance against a datadir with an unwritable pg_control ? -- Craig Ringer -- 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 #6727: Column does not exist exception has no error code
On 07/12/2012 02:24 AM, Patrick Tucker wrote: BTW I'm using postgresql-9.1-901.jdbc4.jar Thanks again, A self-contained test case - a small Java program that connects to a test DB, runs a query, and reports the result vs what you expected the result to be - would be helpful. -- Craig ringer
Re: [BUGS] BUG #6717: bad file
On 07/04/2012 11:02 PM, ste...@nfn.ca wrote: The following bug has been logged on the website: Bug reference: 6717 Logged by: Steve Commanda Email address: ste...@nfn.ca PostgreSQL version: 9.1.4 Operating system: suse 11.4 Description: downloaded latest version. opened it up and some game came up. You didn't download it from PostgreSQL.org or EnterpriseDB, then. If you did, it got intercepted by malware on your computer. Please provide the URL you downloaded PostgreSQL from and the installer file name and size. -- Craig Ringer -- 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 #6718: Cannot delete, create or check existence of extension
On 07/05/2012 02:05 AM, gary.ha...@gmail.com wrote: development=# create extension hstore; ERROR: type hstore already exists development=# drop extension hstore; ERROR: extension hstore does not exist development=# CREATE EXTENSION IF NOT EXISTS hstore; ERROR: type hstore already exists First, thanks for the info in the report. At a guess, it has the hstore data type in it from before the extension system exists. You need to follow the upgrade instructions to convert it to an extension. This isn't a bug in that Pg is working as designed, though it's certainly not very nice user interface. See: http://www.postgresql.org/docs/9.1/static/sql-createextension.html specifically the FROM old_version clause, eg: CREATE EXTENSION hstore FROM unpackaged; (I think that's right; I haven't used the extension system in an upgrade). If you need more help please ask on pgsql-general as this doesn't appear to be a bug from the information supplied. However, I think CREATE EXTENSION should emit a HINT for already-exists errors, guiding people to info on how to upgrade the extension. I'm assuming the database development was loaded from a dump from an older version or was binary-upgraded from an older version. If it was created anew on 9.1, how did the hstore type get loaded? -- Craig Ringer -- 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 #6718: Cannot delete, create or check existence of extension
On 07/05/2012 09:06 PM, Gary Haran wrote: I installed it using an hstore.sql file that comes with the home brew (https://github.com/mxcl/homebrew/) version of postgresql on OS X. Maybe we missed a step or something in the whole installation process. We most likely upgraded our pg version at some point (we try to stay with the times). If you upgrade an existing database to 9.1 and that database has contrib modules loaded in it, you must convert them to extensions using the syntax I gave previously. It's right there in the release notes under Migrating to version 9.1: http://www.postgresql.org/docs/9.1/static/release-9-1.html#AEN107367 This is a bit of a wart, in that it'd be much nicer to be able to transparently re-package pre-extension contrib modules into extensions. I know Dimitri and Tom tried to get this working, but it clearly wasn't possible to make it work simply and reliably. Since it's a one-off migration during upgrade, it isn't that big a deal. If you need help doing this or you have further questions, please ask for help on the pgsql-general mailing list. -- Craig Ringer
Re: [BUGS] BUG #6718: Cannot delete, create or check existence of extension
On 07/05/2012 10:18 PM, Jaime Casanova wrote: On Thu, Jul 5, 2012 at 1:56 AM, Craig Ringer ring...@ringerc.id.au wrote: On 07/05/2012 02:05 AM, gary.ha...@gmail.com wrote: development=# create extension hstore; ERROR: type hstore already exists First, thanks for the info in the report. At a guess, it has the hstore data type in it from before the extension system exists. You need to follow the upgrade instructions to convert it to an extension. what about adding a HINT there? something like you probably need to use CREATE EXTENSION ... FROM unpackaged Yeah, I suggested that. It's not trivial to make sure that this is really because of the extension and not because the user just happened to create their own type called hstore (or whatever the type(s)/function(s) the ext provides) are, but I guess with a hint you don't have to. I'm assuming if it were simple it would've been done as part of extension implementation. It's certainly way beyond me. -- Craig Ringer -- 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] Problem with pg_upgrade
On 07/05/2012 11:20 PM, Payal Singh wrote: Hello, I am trying to use pg_upgrade to upgrade data from 9.1.4 to 9.2beta2. Although the upgrade completed successfully, vacuumdb --all --analyze-only gives an error. I tried upgrading two binary backups of the same production database from different days, and both returned the exact same error . The output I got for both trials is as follows: Just out of interest, if you try to use pg_ctl to start a 9.1 server from those backups, do they work? Can they be vaccuumed then? If you start 9.1 on a copy of the backup then cleanly stop it again, does pg_upgrade then run? -- Craig Ringer
Re: [BUGS] BUG #6720: Its often disconnecting
On 07/06/2012 03:57 AM, balaj...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 6720 Logged by: balaji Email address: balaj...@gmail.com PostgreSQL version: Unsupported/Unknown Operating system: Windows Xp Description: Error is PGADMIN 111 has encountered a problem and need to close.we are sorry for the inconvenience.Please advise me. PgAdmin-III is crashing. With the amount of information you have provided it is impossible to guess why. You haven't said what you're doing when it crashes, whether you can make it crash at the same point every time, etc. Honestly, for PgAdmin you're probably better off seeking help on their mailing list: http://www.pgadmin.org/support/list.php as I'm not sure how many of the PgAdmin folks read pgsql-bugs. -- Craig Ringer
Re: [BUGS] BUG #6720: Its often disconnecting
On 07/06/2012 12:19 PM, Balaji A wrote: Thanks for replying and PFA screenshot and let me know if you need more information on this. Please re-read my reply, which explained to you what more information would be needed and included a link to where you should follow this up. I will repeat it below. If you do not understand what I am saying that is OK, but you need to tell me that so I can explain it a different way. PgAdmin-III is crashing. With the amount of information you have provided it is impossible to guess why. You haven't said what you're doing when it crashes, whether you can make it crash at the same point every time, etc. Honestly, for PgAdmin you're probably better off seeking help on their mailing list: http://www.pgadmin.org/support/list.php as I'm not sure how many of the PgAdmin folks read pgsql-bugs. -- Craig Ringer
Re: [BUGS] BUG #6705: 32 bit
On 06/26/2012 06:26 PM, Dave Page wrote: Any ideas for a one-liner to add? I'm struggling to find nice wording, that doesn't invite people to report issues without investigating themselves first: * If you need help, please review http://xx before seeking further assistance. The positive wording is good. Maybe even: Guidance for resolving installation issues can be found at http:// ... where that provides the common-issues list, a pointer to look at the installation log, then a report template for cases where it wasn't one of the common quick-fixes. I'm happy to work on the docs side, possibly even do a quick JavaScript+form report template to ensure fields like detailed OS version, exact Pg version, etc are supplied. Which reminds me, I need to find out how to detect whether a Windows box is on a domain with non-default group policy, and how/if antivirus can be detected. -- Craig Ringer -- 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 #6705: 32 bit
On 06/27/2012 02:33 PM, Magnus Hagander wrote: ... where that provides the common-issues list, a pointer to look at the installation log, then a report template for cases where it wasn't one of the common quick-fixes. I'm happy to work on the docs side, possibly even do a quick JavaScript+form report template to ensure fields like detailed OS version, exact Pg version, etc are supplied. Which reminds me, I need to find out how to detect whether a Windows box is on a domain with non-default group policy, and how/if antivirus can be detected. From the browser? Pretty sure that's impossible, and for very good reasons... No, not from the browser. What a horrible thought. No, just run this command or look here or copy this registry key stuff. (It is possible to collect this stuff from the browser, but you'd have to use an ActiveX control or an Java Web Start application, and the security implications are absolutely horrific. I'd never, ever, ever, ever want to go there.) Maybe eventually I'd be able to put together a little script to run to collect info; if it's not bundled in the installer it doesn't have the same necessity to be absolutely robust and correct in all situations and can be easily updated to collect more. It can also collect stuff like installed-program lists, environment data, etc because the user would be _knowingly_ and _explicitly_ submitting the report with that info and have a chance to redact portions if desired. For now, though, all I'm talking about is a helping-hand web form with hints about how to find out the exact Windows version, architecture, antivirus in use, etc. Nothing but a web page with some jQuery code. -- Craig Ringer -- 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 #6705: 32 bit
On 06/27/2012 02:49 PM, Magnus Hagander wrote: There are some easy api to get whether the box is on a domain or not, and it's easily accessible from wsh as well. And it ought to be trivial in power shell... Good to know. Since it's a troubleshooting tool there's no real problem with saying First, go install powershell - but it'd be better not to need to if it's available via wsh. Ick ick ick. I've kept away from this stuff and been happy about it, why do I keep volunteering myself for horrid Windows guts stuff? As for the av, I'm less sure. Maybe it's better to just dump a list of installed programs? I'd expect all av to be installed by installers that register them. There's no guarantee they won't try to hide, though. AV software vendors may think it's a good idea to make it hard for software on the machine to tell what AV is running. I'm hoping not, but it's quite possible. The other idea would be to find out if there is an api corresponding to the your computer is at risk is warning bubble, and just use it backwards. I have non idea if there is though, I've never done any work in that area at all. That's what I'm hoping is possible, but like you haven't dug into it yet. -- Craig Ringer -- 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] How to run query by command prompt in Postgres
On 06/27/2012 07:15 PM, Kapil Kr. Khandelwal wrote: Dear Team I want to a favour from your side. I want to know, how to run sql query by command prompt in postgres sql. psql http://www.postgresql.org/docs/9.1/static/app-psql.html -- Craig Ringer
Re: [BUGS] BUG #6705: 32 bit
On 06/25/2012 04:19 AM, gj19861...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 6705 Logged by: Jimmy Creeks Email address: gj19861...@gmail.com PostgreSQL version: 9.1.4 Operating system: Windows 7 Description: Hi, I cannot install 8.3, 9.0, or 9.1 version of postgreSQL. I also try shutting down windows firewall. Here is the bug report Please see: http://wiki.postgresql.org/wiki/Troubleshooting_Installation At minimum we need your installation log, the exact version of windows eg Windows 7 Professional 64-bit, whether you're on a Windows corporate domain, and what/any antivirus software you have running. Please reply to pgsql-bugs@postgresql.org, not to me. Dave: Is there any chance the installers link to that page from their error dialogs, or a static-and-sanitised version of it in docs? If you're ok updating the installer messages I'll collect up a sanitized version that doesn't link to other wiki pages (or make it clear they're external) and convert it for the docs. -- Craig Ringer
Re: [BUGS] BUG #5823: launchd execution
On 06/21/2012 02:45 AM, Leif Halvorsen wrote: Craig, I have got it running again, sort of. Please reply to the list (pgsql-bugs@postgresql.org) , not to me. Sorry, should've set reply-to. Do you know where the PostgreSQL hkwebentrepreneurs configuration came from on your system? Did you install a package they'd produced? If they're packaging Pg, it sounds like they need to change the paths so it doesn't tread on the standard installation. -- Craig Ringer
Re: [BUGS] BUG #5823: launchd execution
On 06/19/2012 07:43 AM, Leif Halvorsen wrote: Ronald, Did you ever find a solution to this bug? I'm fairly new to PostgreSQL and I've been fighting with this for weeks. I think I'm going to be forced to use MySQL instead even though I'd rather not. 6/18/12 7:42:35.188 PM com.apple.launchd: (com.edb.launchd.postgresql-9.1[3736]) Exited with code: 1 6/18/12 7:42:24.985 PM com.apple.launchd: (com.edb.launchd.postgresql-9.1) Throttling respawn: Will start in 10 seconds What's in the system logs (Console.app) ? The PostgreSQL logs? -- Craig Ringer
Re: [BUGS] BUG #6697: postgres.exe crashed
On 06/18/2012 09:15 PM, m.mittm...@gala3000.de wrote: The following bug has been logged on the website: Bug reference: 6697 Logged by: Mirko Mittmann Email address: m.mittm...@gala3000.de PostgreSQL version: 9.1.4 Operating system: Windows Small Business Server 2008 Description: While registering the Postgre service no problem appears. If i wanna start the registered service, there appears a windows message that the postgres.exe had been crashed. I tried to take another version of postgresql but same problem. Before using 9.1.4 i used version 9.0.2. Are there known windows small business server 2008 problems? No known issues. Please examine the event viewer to see why the service failed to start, and post the logs from the data\pg_log folder in your PostgreSQL install directory. -- Craig Ringer -- 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 #6697: postgres.exe crashed
On 06/18/2012 09:15 PM, m.mittm...@gala3000.de wrote: The following bug has been logged on the website: Bug reference: 6697 Logged by: Mirko Mittmann Email address: m.mittm...@gala3000.de PostgreSQL version: 9.1.4 Operating system: Windows Small Business Server 2008 Description: While registering the Postgre service no problem appears. If i wanna start the registered service, there appears a windows message that the postgres.exe had been crashed. I tried to take another version of postgresql but same problem. Before using 9.1.4 i used version 9.0.2. Are there known windows small business server 2008 problems? No known issues with SBS 2008 exist. It should be like any other Windows server. Please examine the event viewer to see why the service failed to start, and post the logs from the data\pg_log folder in your PostgreSQL install directory. -- Craig Ringer -- 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 #6685: Concurrency fault in create table
On 06/10/2012 06:25 PM, mthorn...@optrak.com wrote: The following bug has been logged on the website: Bug reference: 6685 Logged by: Mark Thornton Email address: mthorn...@optrak.com PostgreSQL version: 9.1.4 Operating system: Ubuntu 12.04 Description: Executing create table child_a () inherits (parent) create table child_b () inherits (parent) concurrently (two separate connections) results in an error concurrent tuple update. Please copy and paste the full error message. Which application are you using? psql directly? Something else? -- Craig Ringer -- 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 #6683: dropping a table with a serial column from an extension needs to explicitely drop the associated seq
On 06/10/2012 06:14 AM, Tom Lane wrote: phb.e...@free.fr writes: When a table having a seial column has been created by a CREATE EXTENSION, and when this table is later dropped from the extension, the associated sequence must be also explicitely dropped from the extension. This doesn't really seem like a bug to me. The sequence is a somewhat independent object. I disagree; it is inconsistent with the expectation established in normal operations that the sequence created to serve a SERIAL column is owned by that table/column and is dropped when it is. regress=# create table test (x serial primary key); NOTICE: CREATE TABLE will create implicit sequence test_x_seq for serial column test.x NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index test_pkey for table test CREATE TABLE regress=# \d List of relations Schema |Name| Type | Owner ++--+--- public | test | table| craig public | test_x_seq | sequence | craig (2 rows) regress=# drop table test; DROP TABLE regress=# \d No relations found. regress=# create table test (x serial primary key); NOTICE: CREATE TABLE will create implicit sequence test_x_seq for serial column test.x NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index test_pkey for table test CREATE TABLE regress=# alter table test drop column x; ALTER TABLE regress=# \d List of relations Schema | Name | Type | Owner +--+---+--- public | test | table | craig (1 row) -- Craig Ringer -- 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 #6678: error in connecting to Pgadmin
On 06/08/2012 05:08 PM, renjib...@ymail.com wrote: The following bug has been logged on the website: Bug reference: 6678 Logged by: Renji Email address: renjib...@ymail.com PostgreSQL version: 9.1.0 There's your first problem. Why use such an old release? If you're reporting a bug, you should test with the latest version. Operating system: windows 7 Windows 7 **WHAT**? Windows 7 Professional Service Pack 1 x64 ? Also, is the machine joined to a corporate domain? Is there a virus scanner or other security software installed? But when I shutdown and tried to start the service again, it is showing as the service is connected and if I try to connect to database it's giving the following message: If you do start-run (or hold the windows key and press the R key) then enter services.msc, does the PostgreSQL service show up as started there? If you examine the PostgreSQL error logs in the pg_log directory under the PostgreSQL data directory (by default, inside the PostgreSQL program install directory in program files) are there any messages there? If there are, paste them. Examine the windows Event Viewer (you can find it in the Start Menu by searching for Event Viewer) do you see anything related to the PostgreSQL service? Search for postgres. In the process list in Proces Explorer or Task Manager, does the postgres.exe process appear? There should be several of them. -- Craig Ringer -- 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 #6679: Can't connect via JDBC Driver
On 06/08/2012 06:55 PM, mitz...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 6679 Logged by: Mihai Email address: mitz...@gmail.com PostgreSQL version: 9.1.4 Operating system: WIn 7 Description: I'm using a database management tool that uses a JDBC driver i think this issue is JDBC related. Your report lacks pretty much every important detail, and there's no sign from what you have posted that there is a bug in PgJDBC. Most likely your code has an issue or your environment is misconfigured. There is no way to tell, or to help you, from the amount of information you have provided. Please post a more complete question to pgsql-j...@lists.postgresql.org after reading this: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems In particular, you should show: - Your version of Windows, in detail, like Windows 7 Professional Service Pack x64. - Your code, or if you're using a premade tool the name and version of the tool - The PgJDBC version you're using - The version of the Java Runtime Environment you're using - Whether your server is configured to use SSL - Whether your connection is configured to use SSL - Whether your server is requesting a client certificate - Whether you're trying to provide a client certificate - The context that surrounded those error messages -- Craig Ringer
Re: [BUGS] BUG #6625: not sufficient privileges to start system service
On 05/04/2012 06:46 AM, milen_laza...@yahoo.com wrote: The following bug has been logged on the website: Bug reference: 6625 Logged by: Milen Email address: milen_laza...@yahoo.com PostgreSQL version: 8.3.0 Operating system: windows xp Description: i can't complete the installation process as i have persisting problem. it gives me the following error message: Service pgsql 8.3 failed to start. Verify that you have sufficient privileges to start system service. where's the problem? Try a current version. Uninstall PostgreSQL. Delete the system service. Delete the `postgres` user account using Administrative Tools from the Control Panel. Install PostgreSQL 9.1. If you still have problems, check to see if (a) you are an administrators group member, (b) your computer has no domain-imposed Group Policy, and (c) your computer doesn't have any kind of security software like an antivirus suite that might be screwing things up. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
