Re: [BUGS] BUG #8461: PostgreSQL 9.3 pg_dump heap corruptions
On 10/14/13 2:31 PM, Benjamin Wassermann wrote: but the PG_dump.exe cant free memory which is allocated by libpq.dll. To fix this problem the libpq.dll need a new function named deletePQCharPointer() libpq already provides that functionality in PQfreemem(): http://www.postgresql.org/docs/9.3/static/libpq-misc.html. Regards, Marko Tiikkaja -- 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] porting the PostGreSQL on the M68K platform
On 12.10.2013 11:15, Zhang, Hongwei wrote: Dear sir, We are trying to port the PostGreSQL on the m68K platform, we’ve compiled it well, but failed to run it on the 54450 platform. I am wondering who we could refer to for help? Is there any commercial service that we could use for that kind of technical support? I am looking forward to hearing from you. Thanks in advance. PS: I got the information on below page http://www.postgresql.org/docs/9.3/static/supported-platforms.html Hi, I'm not sure what 54450 platform is, but if you think you found a bug on a supported platform then please submit a bug report here with as much detail as possible. What does failed mean, description of the hawdware etc. If you're porting PostgreSQL to a new platform (albeit similar to m68k) then there are probably more suitable lists - for example pgsql-hackers. Again, post as much info as possible. All mailing lists on postgresql.org (incl. pgsql-bugs, pgsql-hackers) are operated by community, with participants from various companies. If you decide you need a commercial support, the best place to start is probably http://www.postgresql.org/support/professional_support/ regards Tomas -- 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] porting the PostGreSQL on the M68K platform
On 10/12/2013 2:49 PM, Tomas Vondra wrote: I'm not sure what 54450 platform is Presumably, the OP is referring to Freescale ColdFire MCF54450, one of an embedded family of 68000 like CPUs (not binary compatible, just assembler source compatible, and missing some parts of the 68000 architecture like BCD support). http://www.freescale.com/files/32bit/doc/prod_brief/MCF54455PB.pdf These are embedded processors with 32kbytes of static ram. that support 8-512MB of external DDR SDRAM. while they are typically targetted at RTOS systems, I guess they can run uCLinux, but I don't believe they have a MMU, so they can't run a 'regular' linux kernel. frankly, these don't seem like good candidates for a relational database server to me. -- john r pierce 37N 122W somewhere on the middle of the left coast -- 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 #8515: Random 'relation ... does not exist'
On 9.10.2013 19:35, nbudu...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 8515 Logged by: Nicolas Buduroi Email address: nbudu...@gmail.com PostgreSQL version: 9.2.4 Operating system: ArchLinux Description: We've recently migrated an application from MySQL to Postgres and I've been experiencing some really strange and random bugs. The application is a pretty simple Rails application and the Postgres setup is the default one provided by ArchLinux. Basically, at some point a query, update or insert will not work and complain about a table not existing, but that table was used without any issue previously. Closing the running connection to the database and reconnecting make that error disappear. Two concurrent connections (one from a console and another from the app) could be contradicting themselves, one giving the error and the other not. This only happen on a development machine which is running version 9.2.4 of Postgres. We've not encountered this error on our production/staging/ci servers which are running Postgres 9.1.9 version. Hi Nicolas, can you check PostgreSQL logs? I'm not familiar with Arch Linux but I guess it might be /var/log/postgresql.log or something like that. Is there anything relevant in the logs? Can you explain what is the application doing? Can you try to prepare a simplified testcase, based on your knowledge of the app? kind regards Tomas -- 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 #8515: Random 'relation ... does not exist'
On 10/9/2013 10:35 AM, nbudu...@gmail.com wrote: Basically, at some point a query, update or insert will not work and complain about a table not existing, but that table was used without any issue previously. Closing the running connection to the database and reconnecting make that error disappear. Two concurrent connections (one from a console and another from the app) could be contradicting themselves, one giving the error and the other not. that sounds like a hardware/platform problem to me more than anything. maybe in memory cache is getting corrupted or something? -- john r pierce 37N 122W somewhere on the middle of the left coast -- 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 #8514: cache lookup failed for relation 421062806
On Thu, Oct 10, 2013 at 1:24 AM, shahtejas2...@gmail.com wrote: my postgresql running file . but sometime i found cache lookup failed for relation 421062806 error in postgresql log. can anyone tell me significant of this error. A relation has disappeared even if the session hold a sufficient lock on it, ensuring that the relation have to be present. -- Michael -- 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] Bit String expand bug
Gabriel Ciubotaru gciubot...@bitdefender.com writes: There's a problem with expanding Bit String data types, it make right padding with 0 instead of left padding , making the bit mask almost useless. You need to show an example of the problem; this report has no details that would let us fix anything. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8516: Calling VOLATILE from STABLE function
Terje Elde te...@elde.net writes: Would it be possible (and make sense) to solve this in a completely different way, not walking the function tree or doing static analysis, but simply setting and checking a bit during execution? While it's possible that we could do something like that, I think it's fairly unlikely that we would. The reason is that it would disable constructs that some people find useful; that is, sometimes it's intentional that a stable function calls a volatile one. A couple of examples: 1. You might want to make some database updates but continue to do queries with a pre-update snapshot. A single function can't accomplish that, but the combination of a stable outer function with a volatile update function can. 2. A security checking function (for use with Veil or the proposed row security feature) might wish to log accesses without denying them. To do that it'd have to be volatile, so if we had a restriction like this the function would fail when invoked within a stable function. You can imagine various ways around such issues, but it would add a lot of complication. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8516: Calling VOLATILE from STABLE function
According to the documentation, f() should be marked VOLATILE also, since calling f() produces side effects. PostgreSQL does not give a warning (or better yet, an error); I think it should. I think the answer is that function authors are required to prevent functions they mark as STABLE from calling VOLATILE functions. -- I understand it's an error (at least usually), my question/issue is why does PostgreSQL NOT give at least a warning when a programmer (probably accidentally) calls a VOLATILE function in one that he has specifically tagged as STABLE? The compiler has all the information to notify the programmer of a mistake, but isn't. This violates a fundamental principle of software engineering--take every opportunity to prevent errors. Dwayne -- 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 #8467: Slightly confusing pgcrypto example in docs
The changes shown below are incorrect, I think. On 10/2/13 12:00 PM, Bruce Momjian wrote: *** gen_salt(type text [, iter_count integer *** 353,359 entry12 years/entry /row row !entryliteralmd5//entry entry2345086/entry entry1 day/entry entry3 years/entry --- 358,364 entry12 years/entry /row row !entryliteralmd5 hash//entry entry2345086/entry entry1 day/entry entry3 years/entry *** gen_salt(type text [, iter_count integer *** 380,386 /listitem listitem para ! literalmd5/ numbers are from mdcrack 1.2. /para /listitem listitem --- 385,391 /listitem listitem para ! literalmd5 hash/ numbers are from mdcrack 1.2. /para /listitem listitem *** gen_random_bytes(count integer) returns *** 1343,1349 entryOpenBSD sys/crypto/entry /row row ! entryMD5 and SHA1/entry entryWIDE Project/entry entryKAME kame/sys/crypto/entry /row --- 1348,1354 entryOpenBSD sys/crypto/entry /row row ! entryMD5 hash and SHA1/entry entryWIDE Project/entry entryKAME kame/sys/crypto/entry /row -- 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 #8517: Problem due to libeay32.dll about ordinal
On 10/10/2013 6:27 AM, s.mech...@gmail.com wrote: I'm trying since yesterday to install a software which needs to install postgreSQL 8.4 aswell. When the installation is finished, a message appears a few times which says The 3873 ordinal can't be find in the LIBEAY32.dll dynamic library (in french) So i suppose i've some corrupted files, but could you maybe light me on about this problem ? I'd contact the distributors or authors of this 'a software', if its got its own postgres 8.4 build bundled with it. I do hope its not 8.4.0, thats VERY obsolete, 8.4 is currently up to 8.4.18. libeay32.dll is, I believe, part of OpenSSL, which is bundled into PostgreSQL to support SSL connections. that error suggests a version mismatch, where something is trying to call an entry point in that library which doesn't exist. this software you're installing, is it tested and supported on win7? p.s please direct replies to pgsql-bugs@postgresql.org and not me personally. -- john r pierce 37N 122W somewhere on the middle of the left coast -- 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 10/10/2013 7:18 AM, Andrius Di wrote:
Hello, how to solve this error (please see attachment)?
what exactly were you doing when you got this error, what Windows
version was this on, etc etc?
the error is pretty explicit, I would inspect the value of your COMSPEC
environment variable. for instance, at a CMD ('dos') prompt, type the
command,
ECHO %COMSPEC%
and you should get something like...
C:\WINDOWS\system32\cmd.exe
p.s please direct replies to pgsql-bugs@postgresql.org and not me
personally.
--
john r pierce 37N 122W
somewhere on the middle of the left coast
--
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] Completely broken replica after PANIC: WAL contains references to invalid pages
On Tue, Jun 11, 2013 at 6:50 AM, Tom Lane t...@sss.pgh.pa.us wrote: Sergey Konoplev gray...@gmail.com writes: Just curious, what is the planned date for the next minor release, and BTW where is it possible to see the roadmap for minor releases? There is no planned date, and certainly no roadmap. We make minor releases when the core team judges that enough (or severe enough) fixes have accumulated since the last time. Historically we've averaged about four minor releases a year, but that's not set in stone anywhere. Could you please give me a hint of how to check if this patch was included in 9.2.5 or not? -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA http://www.linkedin.com/in/grayhemp +1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979 gray...@gmail.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Completely broken replica after PANIC: WAL contains references to invalid pages
Sergey Konoplev escribió: On Tue, Jun 11, 2013 at 6:50 AM, Tom Lane t...@sss.pgh.pa.us wrote: Sergey Konoplev gray...@gmail.com writes: Just curious, what is the planned date for the next minor release, and BTW where is it possible to see the roadmap for minor releases? There is no planned date, and certainly no roadmap. We make minor releases when the core team judges that enough (or severe enough) fixes have accumulated since the last time. Historically we've averaged about four minor releases a year, but that's not set in stone anywhere. Could you please give me a hint of how to check if this patch was included in 9.2.5 or not? Yes, this was committed in June: commit 99ee15b315c187045a95db7b27fd9d866aea93e0 Author: Simon Riggs si...@2ndquadrant.com Date: Sun Jun 23 11:05:02 2013 +0100 -- Álvaro Herrerahttp://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] Completely broken replica after PANIC: WAL contains references to invalid pages
On Thu, Oct 10, 2013 at 2:48 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Could you please give me a hint of how to check if this patch was included in 9.2.5 or not? Yes, this was committed in June: commit 99ee15b315c187045a95db7b27fd9d866aea93e0 Author: Simon Riggs si...@2ndquadrant.com Date: Sun Jun 23 11:05:02 2013 +0100 Good news, thank you. -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA http://www.linkedin.com/in/grayhemp +1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979 gray...@gmail.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8516: Calling VOLATILE from STABLE function
On Wed, Oct 9, 2013 at 08:58:46PM +, dwa...@docketnavigator.com wrote: The following bug has been logged on the website: Bug reference: 8516 Logged by: Dwayne Towell Email address: dwa...@docketnavigator.com PostgreSQL version: 9.2.4 Operating system: CentOS Description: Why doesn't PostgreSQL give a warning when calling a volatile function from a stable function? For example: CREATE TABLE x (val double); CREATE FUNCTION g() RETURNS boolean AS $$ INSERT INTO x SELECT rand() RETURNING val0.5; $$ LANGUAGE SQL VOLATILE; CREATE FUNCTION f() RETURNS boolean AS $$ SELECT g(); -- this is where the stability-violation happens $$ LANGUAGE SQL STABLE; -- this is a lie According to the documentation, f() should be marked VOLATILE also, since calling f() produces side effects. PostgreSQL does not give a warning (or better yet, an error); I think it should. I think the answer is that function authors are required to prevent functions they mark as STABLE from calling VOLATILE functions. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- 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 #8467: Slightly confusing pgcrypto example in docs
On Thu, Oct 10, 2013 at 04:05:50PM -0400, Peter Eisentraut wrote: The changes shown below are incorrect, I think. On 10/2/13 12:00 PM, Bruce Momjian wrote: *** gen_salt(type text [, iter_count integer *** 353,359 entry12 years/entry /row row !entryliteralmd5//entry entry2345086/entry entry1 day/entry entry3 years/entry --- 358,364 entry12 years/entry /row row !entryliteralmd5 hash//entry Uh, the table already has a mention of md5 crypt above: entryliteralcrypt-md5//entry How can the later entry not be MD5 hash? entry2345086/entry entry1 day/entry entry3 years/entry *** gen_salt(type text [, iter_count integer *** 380,386 /listitem listitem para ! literalmd5/ numbers are from mdcrack 1.2. /para /listitem listitem --- 385,391 /listitem listitem para ! literalmd5 hash/ numbers are from mdcrack 1.2. /para /listitem listitem *** gen_random_bytes(count integer) returns *** 1343,1349 entryOpenBSD sys/crypto/entry /row row ! entryMD5 and SHA1/entry entryWIDE Project/entry entryKAME kame/sys/crypto/entry /row --- 1348,1354 entryOpenBSD sys/crypto/entry /row row ! entryMD5 hash and SHA1/entry entryWIDE Project/entry entryKAME kame/sys/crypto/entry /row Again, MD5 crypt is mentioned in the same table above: entryMD5 crypt/entry so how can this not be md5 hash? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- 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 #8516: Calling VOLATILE from STABLE function
On Thu, Oct 10, 2013 at 04:10:35PM -0700, Dwayne Towell wrote: According to the documentation, f() should be marked VOLATILE also, since calling f() produces side effects. PostgreSQL does not give a warning (or better yet, an error); I think it should. I think the answer is that function authors are required to prevent functions they mark as STABLE from calling VOLATILE functions. -- I understand it's an error (at least usually), my question/issue is why does PostgreSQL NOT give at least a warning when a programmer (probably accidentally) calls a VOLATILE function in one that he has specifically tagged as STABLE? The compiler has all the information to notify the programmer of a mistake, but isn't. This violates a fundamental principle of software engineering--take every opportunity to prevent errors. Well, we can't walk the function tree to know all called functions, and those they call, so we don't even try. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- 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 #8467: Slightly confusing pgcrypto example in docs
On Thu, 2013-10-10 at 19:14 -0400, Bruce Momjian wrote: The changes shown below are incorrect, I think. On 10/2/13 12:00 PM, Bruce Momjian wrote: *** gen_salt(type text [, iter_count integer *** 353,359 entry12 years/entry /row row !entryliteralmd5//entry entry2345086/entry entry1 day/entry entry3 years/entry --- 358,364 entry12 years/entry /row row !entryliteralmd5 hash//entry Uh, the table already has a mention of md5 crypt above: entryliteralcrypt-md5//entry How can the later entry not be MD5 hash? Because what you pass to the functions is 'md5', not 'md5 hash', which is what the new text appears to indicate. -- 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 #8467: Slightly confusing pgcrypto example in docs
On Thu, Oct 10, 2013 at 08:22:30PM -0400, Peter Eisentraut wrote: On Thu, 2013-10-10 at 19:14 -0400, Bruce Momjian wrote: The changes shown below are incorrect, I think. On 10/2/13 12:00 PM, Bruce Momjian wrote: *** gen_salt(type text [, iter_count integer *** 353,359 entry12 years/entry /row row !entryliteralmd5//entry entry2345086/entry entry1 day/entry entry3 years/entry --- 358,364 entry12 years/entry /row row !entryliteralmd5 hash//entry Uh, the table already has a mention of md5 crypt above: entryliteralcrypt-md5//entry How can the later entry not be MD5 hash? Because what you pass to the functions is 'md5', not 'md5 hash', which is what the new text appears to indicate. So if we revert, will it still be clear what is MD5 and what is MD5 hash? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- 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 #8467: Slightly confusing pgcrypto example in docs
On Thu, Oct 10, 2013 at 08:32:32PM -0400, Bruce Momjian wrote: How can the later entry not be MD5 hash? Because what you pass to the functions is 'md5', not 'md5 hash', which is what the new text appears to indicate. So if we revert, will it still be clear what is MD5 and what is MD5 hash? I mean, will it be clear what is MD5 crypt and what is MD5 hash? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- 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 #8500: Upgrade to postgis 2.1 breaks existing databases
Hi, I *think* I fixed this problem. We will release updated packages tomorrow, along with the PostgreSQL minor release updates. Please let me know if they still don't work. :) Regards, Devrim On Fri, 2013-10-04 at 13:26 +, kyri...@alumni.princeton.edu wrote: The following bug has been logged on the website: Bug reference: 8500 Logged by: Kriton Kyrimis Email address: kyri...@alumni.princeton.edu PostgreSQL version: 9.2.4 Operating system: Scientific Linux 6.4 Description: The version of postgis, available in the postgresql yum repository for postgis 9.2, was recently upgraded to version 2.1. This breaks existing databases built with postgis 2.0, as queries involving postgis fail with the error message ERROR: could not access file $libdir/postgis-2.0: No such file or directory This includes backing up the databases, so upgrading them to use postgis 2.1 may not even be an option, if a hard upgrade is required. I have downgraded all postgis2_92 packages to version 2.0.4 and excluded them from future upgrades, but I'd recommend reverting to that version in the repositories, as well. At the very least, please ensure that version 2.0.x of the packages remains available in the future. Better still, provide alternative postgis21_92-* packages, for those wishing to use the latest version, without affecting those that use the previous version. -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [BUGS] BUG #8493: Changing file permissions on all files during install
Hi Installer does not change the permissions on all files.. it just changes the permissions on the folders mentioned in the data directory path (except C:\ and C:\Program Files).. It may be because of the inheritance that icacls just scans through all the files.. Anyways, in 9.3.1, by default the installer will just try to grant permissions on the data directory and not the whole path.. If someone wants to enable that check on the complete path, he can do that via command line switch --enable_aclcheck 1 On Mon, Sep 30, 2013 at 7:58 PM, m8...@abc.se wrote: The following bug has been logged on the website: Bug reference: 8493 Logged by: Ronny Email address: m8...@abc.se PostgreSQL version: 9.3.0 Operating system: Win 7 Description: Hi Postgresql install is running this command during install: icacls E:\ /grant NT AUTHORITY\NetworkService:(NP)(RX) The installation took over 1 hour. I install postgresql on C: and the database in E:\database Regards, Ronny -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Sandeep Thakkar Senior Software Engineer Phone: +91.20.30589505 Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb
Re: [BUGS] BUG #8511: some of object dont drop
On 10/8/2013 1:02 AM, shahtejas2...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 8511 Logged by: Tejas Email address: shahtejas2...@gmail.com PostgreSQL version: Unsupported/Unknown Operating system: Linux Description: cache lookup failed for relation 421062806 as far as I know, that error only happens if there is memory or file corruption, which generally points at a hardware or operating system problem. that said, there's hardly any useful information in this bug report. please read http://www.postgresql.org/docs/current/static/bug-reporting.html oh, direct further correspondence to the bug list, pgsql-bugs@postgresql.org and not me personally -- john r pierce 37N 122W somewhere on the middle of the left coast -- 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 #8511: some of object dont drop
On Tue, Oct 8, 2013 at 1:32 PM, shahtejas2...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 8511 Logged by: Tejas Email address: shahtejas2...@gmail.com PostgreSQL version: Unsupported/Unknown Operating system: Linux Description: cache lookup failed for relation 421062806 I am afraid you need to provide a lot more information for anyone to help you. Postgres version you are using and the failing test case at the minimum. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee
Re: [BUGS] Installing/Upgrading PostgreSQL 9.1.6 to 9.3 known bugs?
On Mon, Oct 7, 2013 at 08:07:42AM -0700, fburg...@radiantblue.com wrote: Bruce, Proposed Steps. Do they look feasible? 1.) pg_dump -h localhost -p 5432 -U postgres -Fc -b -v -f /somepath/ testdb.backup testdb 2.) CREATE DATABASE newdb TEMPLATE=template_postgis; 3.) perl ../postgis-postgres/postgis-2.1.1/utils/postgis_restore.pl /somepath/ testdb.backup | psql -h localhost -p 5432 -U postgres newdb 2 errors.txt - this step may run 5-6 days, since our backup runs that long, right? 4.) At this point we will have two 6.1TB databases, so it looks like a prerequisite is to have available double the db size in disk space, right? 5.) then if no critical errors, there will be errors since we have our testdb schema in the public folder 5a.) ALTER DATABASE testdb RENAME TO olddb; 5b.) ALTER DATABASE newdb RENAME TO testdb; 6.) At this point hopefully we should be upgraded from postgis 1.5.3 to postgis 2.1.1, with PostgreSQL 9.1.6 7.) then can we just use pg_upgrade with the hard links option, instead of copying files to the new cluster option to upgrade to PostgreSQL 9.3? Sorry, I have no idea how to upgrade PostGIS. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Installing/Upgrading PostgreSQL 9.1.6 to 9.3 known bugs?
We shouldn't have a problem with using pg_upgrade with the hard link option to upgrade from postgreSQL 9.1.6 after I get the spatial component upgraded to postgis 2.1, then straight to postgreSQL 9.3, Right? thanks Original Message Subject: Re: [BUGS] Installing/Upgrading PostgreSQL 9.1.6 to 9.3 known bugs? From: Bruce Momjian br...@momjian.us Date: Tue, October 08, 2013 6:17 am To: fburg...@radiantblue.com Cc: pgsql-bugs@postgresql.org On Mon, Oct 7, 2013 at 08:07:42AM -0700, fburg...@radiantblue.com wrote: Bruce, Proposed Steps. Do they look feasible? 1.) pg_dump -h localhost -p 5432 -U postgres -Fc -b -v -f "/somepath/ testdb.backup" testdb 2.) CREATE DATABASE newdb TEMPLATE=template_postgis; 3.) perl ../postgis-postgres/postgis-2.1.1/utils/postgis_restore.pl "/somepath/ testdb.backup" | psql -h localhost -p 5432 -U postgres newdb 2 errors.txt - this step may run 5-6 days, since our backup runs that long, right? 4.) At this point we will have two 6.1TB databases, so it looks like a prerequisite is to have available double the db size in disk space, right? 5.) then if no critical errors, there will be errors since we have our testdb schema in the public folder 5a.) ALTER DATABASE testdb RENAME TO olddb; 5b.) ALTER DATABASE newdb RENAME TO testdb; 6.) At this point hopefully we should be upgraded from postgis 1.5.3 to postgis 2.1.1, with PostgreSQL 9.1.6 7.) then can we just use pg_upgrade with the hard links option, instead of copying files to the new cluster option to upgrade to PostgreSQL 9.3? Sorry, I have no idea how to upgrade PostGIS. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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 #8467: Slightly confusing pgcrypto example in docs
On Wed, Oct 2, 2013 at 12:00:44PM -0400, Bruce Momjian wrote: Based on your report, I have developed the attached doc patch which clarifies when MD5 hash is being referenced, and when MD5 crypt is. I have also added your other suggestions. Patch applied, and backpatched to 9.3.X. Thanks for the suggestions. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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 #8512: Can't use columns I can't read in the where clause of a select
* k...@roeckx.be (k...@roeckx.be) wrote: Allows SELECT from any column, or the specific columns listed, of the specified table, view, or sequence. Also allows the use of COPY TO. This privilege is also needed to reference existing column values in UPDATE or DELETE. I read that as SELECT field1 from table where field2 = 1 should work if I have grant select(field1), but not on field2. I'm getting a permission denied. If I remove the where clause it of course works. You have to have SELECT rights on a column to be able to use it in a conditional (eg: with WHERE). I'm not sure if the behaviour is expected or not. Maybe I'm reading the documentation wrong, or maybe the documentation is just wrong. Could someone please clarify? It's expected. The documentation could perhaps be improved, but the second sentence (This privilege is also needed..) is intended to cover the case where the column is being referred to *anywhere* in the query, basically, and that applies to SELECT as much as UPDATE or DELETE. Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] Installing/Upgrading PostgreSQL 9.1.6 to 9.3 known bugs?
Bruce, Proposed Steps. Do they look feasible?1.) pg_dump -h localhost -p 5432 -U postgres -Fc -b -v -f "/somepath/testdb.backup" testdb2.) CREATE DATABASE newdb TEMPLATE=template_postgis;3.) perl ../postgis-postgres/postgis-2.1.1/utils/postgis_restore.pl "/somepath/testdb.backup" | psql -h localhost -p 5432 -U postgres newdb 2 errors.txt - this step may run 5-6 days, since our backup runs that long, right?4.) At this point we will have two 6.1TB databases, so it looks like a prerequisite is to have available double the db size in disk space, right?5.) then if no critical errors, there will be errors since we have our testdb schema in the public folder 5a.) ALTER DATABASE testdb RENAME TO olddb; 5b.) ALTER DATABASE newdb RENAME TO testdb;6.) At this point hopefully we should be upgraded from postgis 1.5.3 to postgis 2.1.1, with PostgreSQL 9.1.67.) then can we just use pg_upgrade with the hard links option, instead of copying files to the new cluster option to upgrade to PostgreSQL 9.3? Original Message ---- Subject: Re: [BUGS] Installing/Upgrading PostgreSQL 9.1.6 to 9.3 known bugs? From: Bruce Momjian br...@momjian.us Date: Wed, October 02, 2013 7:29 am To: John R Pierce pie...@hogranch.com Cc: pgsql-bugs@postgresql.org On Fri, Sep 20, 2013 at 02:00:05PM -0700, John R Pierce wrote: On 9/20/2013 1:51 PM, fburg...@radiantblue.com wrote: 1.) During our prior upgrade process we used pg_upgrade to move from pg 8.4.3 to 9.1.6 using the hard links install option, we also have our data spread across disk storage mediums; fiber, nas. Are there any known issues, bugs with using pg_upgrade to move from 9.1.6 to pg 9.3? having multiple tablespaces on different mount points complicates things. I'm not sure how or if pg_upgrade handles that. pg_upgrade is fine with that. The old/new tablespaces stay in the same mount point as just per-version subdirectories. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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 #8470: 9.3 locking/subtransaction performance regression
Alvaro Herrera wrote: AFAICS the problem here is that this test doesn't use MultiXactIds at all in 9.2, but it does in 9.3. I vaguely recall Noah tried to convince me to put in an optimization which would have avoided this issue; I will give that a thought. I don't think I will be able to get it done for 9.3.1 though. I gave this a deeper look yesterday. Sadly, that optimization would not work here; we give stronger guarantees now than 9.2 and that's the reason for the slowness. Previously, we just overwrote the lock held by the ancestor transaction if a subxact grabbed a stronger lock; we no longer do that, and instead create a multi comprising both of those locks. That way if the subxact rolls back, we don't lose the previous lock we held. It seems that we could avoid creating a new multixact in a few more cases, by reusing an already existing multixact; or, if we're forced to create a new one, omit the member from the old one that is superceded by our own member with the stronger lock. However, there is no way this will affect this test case *at all*. I see another way forward: if an ancestor takes lock of a certain strength, and then subxact takes a stronger lock, we could record this as ancestor taking the stronger lock, so this could be stored as a plain Xid and not a Multi. That way, (1) we do not incur a new multixact, and (2) the lock would not be lost if the subxact aborts. This would come at the cost that if the subxact rolls back, the stronger lock would not be released. Another thing we could look at is whether we can optimize for the case of sub-committed subtransactions, i.e. we know these won't roll back in relation to the current xact. It seems that would apply here because when you finish the BEGIN/EXCEPTION/END block, that automatic subxact is marked sub-committed. It seems to me we could collapse the locks acquired by those subxacts to appear as locks owned by its currently open ancestor. -- Álvaro Herrerahttp://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 #8470: 9.3 locking/subtransaction performance regression
05.10.2013 01:31, Alvaro Herrera kirjoitti: AFAICS the problem here is that this test doesn't use MultiXactIds at all in 9.2, but it does in 9.3. I vaguely recall Noah tried to convince me to put in an optimization which would have avoided this issue; I will give that a thought. I don't think I will be able to get it done for 9.3.1 though. Is the schedule for 9.3.1 visible somewhere? Please reconsider trying to get a fix for this in as it's a pretty big regression from 9.2. My application test case that triggered this ran in roughly 3 seconds with 9.2 but timed out after 3 minutes on 9.3.0. And even without a loop that amplifies this, just a single 'select for update' inside a subtransaction is significantly slower in 9.3. Thanks, Oskari -- 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 #8498: pg_trgm is missing from windows edb package
On Fri, Oct 4, 2013 at 11:36 AM, Paragon Corporation l...@pcorp.us wrote: Disregard my bug complaint. Stupid user error. Btw, the next time you find an error with this installer, you should not use this mailing list for this purpose but contact directly EDB as this installer is maintained by them and not by community. Regards, -- Michael -- 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 #8498: pg_trgm is missing from windows edb package
On 5 Oct 2013, at 13:21, Michael Paquier michael.paqu...@gmail.com wrote: On Fri, Oct 4, 2013 at 11:36 AM, Paragon Corporation l...@pcorp.us wrote: Disregard my bug complaint. Stupid user error. Btw, the next time you find an error with this installer, you should not use this mailing list for this purpose but contact directly EDB as this installer is maintained by them and not by community. EDB (and many of it's staff) are part of the community, just as various other companies and their staff who contribute in other ways are. Further, the PostgreSQL installers are offered as 'official' releases on the community website, so it is quite reasonable for users to report bugs here. -- 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 #8469: Xpath behaviour unintuitive / arguably wrong
On Fri, Oct 4, 2013 at 10:20:46PM +0200, Stefan Kaltenbrunner wrote: http://www.postgresql.org/message-id/201106291934.23089.rsmog...@softperience.eu There are two other similar bug reports on this from February and March of this year: http://www.postgresql.org/message-id/e1u1fkl-0002rd...@wrihigleys.postgresql.org I think that should be: http://www.postgresql.org/message-id/e1u1fkl-0002rd...@wrigleys.postgresql.org http://www.postgresql.org/message-id/e1uhyuw-0001oj...@wrigleys.postgresql.org Someone who knows XML needs to take leadership on this and propose a patch. Added to TODO. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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 #8498: pg_trgm is missing from windows edb package
On Sat, Oct 5, 2013 at 9:38 PM, Dave Page dp...@pgadmin.org wrote: On 5 Oct 2013, at 13:21, Michael Paquier michael.paqu...@gmail.com wrote: On Fri, Oct 4, 2013 at 11:36 AM, Paragon Corporation l...@pcorp.us wrote: Disregard my bug complaint. Stupid user error. Btw, the next time you find an error with this installer, you should not use this mailing list for this purpose but contact directly EDB as this installer is maintained by them and not by community. EDB (and many of it's staff) are part of the community, just as various other companies and their staff who contribute in other ways are. Further, the PostgreSQL installers are offered as 'official' releases on the community website, so it is quite reasonable for users to report bugs here. OK, sorry for my misunderstanding. -- Michael -- 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 #8470: 9.3 locking/subtransaction performance regression
Oskari Saarenmaa wrote: 05.10.2013 01:31, Alvaro Herrera kirjoitti: AFAICS the problem here is that this test doesn't use MultiXactIds at all in 9.2, but it does in 9.3. I vaguely recall Noah tried to convince me to put in an optimization which would have avoided this issue; I will give that a thought. I don't think I will be able to get it done for 9.3.1 though. Is the schedule for 9.3.1 visible somewhere? Not sure. I just happen to know it'll be git-tagged early next week. Please reconsider trying to get a fix for this in as it's a pretty big regression from 9.2. I understand the pressure. Sadly, I have other things scheduled right now that I can't postpone. I might still be able to get to it over the weekend; if someone else has time and can submit and/or test a patch, that would perhaps allow me to get it done in time. -- Álvaro Herrerahttp://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 #8470: 9.3 locking/subtransaction performance regression
Oskari Saarenmaa wrote: 05.10.2013 01:31, Alvaro Herrera kirjoitti: AFAICS the problem here is that this test doesn't use MultiXactIds at all in 9.2, but it does in 9.3. I vaguely recall Noah tried to convince me to put in an optimization which would have avoided this issue; I will give that a thought. I don't think I will be able to get it done for 9.3.1 though. Is the schedule for 9.3.1 visible somewhere? http://www.postgresql.org/message-id/CA+OCxozG4PhbFphbg+ehpJk3TgLFDVyMuzwy+wyf=x1utt-...@mail.gmail.com -- Álvaro Herrerahttp://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 #8496: psqlODBC driver does not work well via Excel
On 02.10.2013 14:57, manindra.sar...@brightnorth.co.uk wrote: Excel does not seem to respond with any data - but does give an idea that it has made some sort of a connection with the database. SQL commands fail from being executed. I'm afraid you'll have to provide a lot more details for anyone to be able to help you. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8496: psqlODBC driver does not work well via Excel
2013/10/4 Heikki Linnakangas hlinnakan...@vmware.com On 02.10.2013 14:57, manindra.sarkar@brightnorth.**co.ukmanindra.sar...@brightnorth.co.ukwrote: Excel does not seem to respond with any data - but does give an idea that it has made some sort of a connection with the database. SQL commands fail from being executed. It is strange - I used pg ODBC driver together with MS Excel without any issue. Regards Pavel I'm afraid you'll have to provide a lot more details for anyone to be able to help you. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/**mailpref/pgsql-bugshttp://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pg_upgrade 9.0-9.2 failure: Mismatch of relation OID in database
Re: Bruce Momjian 2013-10-02 20131002170628.gc5...@momjian.us That is very interesting, and it certainly should not be failing. I am surprised it got an oid that was one less than the desired one, 18803. Is there any mention of 18803 in the SQL file? 18803 wasn't mentioned anywhere, just 18804 like the log says. If you create a cluster with just your schema and no data, can you upgrade that cleanly? I haven't tried that yet. This is on a customer machine we don't have access to except when arranging a remote desktop session. I'll see if I can do some tests there. Mit freundlichen Grüßen, Christoph Berg -- Tel.: +49 (0)21 61 / 46 43-187 credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209 Hohenzollernstr. 133, 41061 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer -- 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 #8434: Why does dead lock occur many times ?
I spent a lot of time looking at this issue. Your problem scenario can
be reduced to the following test case:
CREATE TABLE t (a INT);
INSERT INTO t VALUES (1);
The three sessions need to execute the following commands, in this
sequence:
-- Session 1
/* 1 */ BEGIN;
SELECT * FROM t FOR UPDATE;
-- Session 2
/* 2 */ BEGIN;
UPDATE t SET a = 2; -- blocks waiting on S1
-- Session 3
/* 3 */ BEGIN;
UPDATE t SET a = 3; -- blocks
-- this is waiting on S1, but since S2 is also waiting on S1 and will acquire a
-- conflicting lock first, this session will only be released after S2 releases
-- its own lock.
Session 1
/* 4 */ UPDATE t SET a = 4;
COMMIT; -- releases session 2
BEGIN;
SELECT * FROM t FOR UPDATE; -- blocks waiting on S2 (*)
Session 2:
/* 5 */ COMMIT; -- releases session 1
BEGIN;
UPDATE t SET a = 5; -- blocks waiting on S3
Session 1:
/* 6 */ UPDATE t SET a = 6; -- blocks waiting on S3
At this point, all sessions are blocked on their UPDATE commands, and
deadlock is reported. (For debugging, it's useful to set a very large
deadlock_timeout and examine pg_locks, etc.)
The point at which things started to go wrong was where the session 1's
SELECT FOR UPDATE with the (*) was allowed to continue after session 2
commits. In 9.2 that session remains blocked, and instead we release
session 3.
The problem is the handling of following of the update chain during a
lock command; the question is should sessions be blocked waiting for
locks on future versions of the row? They currently don't block, which
is what leads the SELECT FOR UPDATE to continue; but if we make them
block, other things break. I initially toyed with the following patch,
which removes the deadlock the above report and also your original test
case:
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -4832,15 +4832,12 @@ l4:
xmax = HeapTupleHeaderGetRawXmax(mytup.t_data);
/*
-* If this tuple is updated and the key has been modified (or
-* deleted), what we do depends on the status of the updating
-* transaction: if it's live, we sleep until it finishes; if it
has
-* committed, we have to fail (i.e. return HeapTupleUpdated);
if it
-* aborted, we ignore it. For updates that didn't touch the
key, we
-* can just plough ahead.
+* If this tuple is updated, what we do depends on the status
of the
+* updating transaction: if it's live, we sleep until it
finishes; if
+* it has committed, we have to fail (i.e. return
HeapTupleUpdated); if
+* it aborted, we ignore it.
*/
- if (!(old_infomask HEAP_XMAX_INVALID)
- (mytup.t_data-t_infomask2 HEAP_KEYS_UPDATED))
+ if (!(old_infomask HEAP_XMAX_INVALID))
{
TransactionId update_xid;
However, the differences in behavior this causes (visible by running the
isolation tests) don't look good to me. It's quite possible that there
are other bugs elsewhere.
Sadly, I have to look at other things now and I won't have time to
research this further until after next week's minor releases; so
whatever we decide to do, if anything, will not be in 9.3.1.
Thanks for the report.
--
Álvaro Herrerahttp://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 #8469: Xpath behaviour unintuitive / arguably wrong
On 10/02/2013 06:19 PM, Bruce Momjian wrote:
On Tue, Sep 24, 2013 at 06:43:19PM +, dennis.noord...@helsinki.fi wrote:
The following bug has been logged on the website:
Bug reference: 8469
Logged by: Dennis
Email address: dennis.noord...@helsinki.fi
PostgreSQL version: 9.3.0
Operating system: FreeBSD 9.2-RC4
Description:
Hi,
After upgrading an 8.1 version to 9.3.0 I am suddenly seeing text fields
containing amp; where they are populated from XML. This may be a
coincidence and the problem may have existed earlier, in any case, now I
noticed.
I extract the text content of XML nodes using xpath, from something like:
nameJones amp; Smith/name
The reason I end up with amp; is the IMHO rather odd xpath behaviour:
# select xpath('/a/text()', (select xmlelement(name a, 'A B')));
xpath
---
{A amp; B}
The canonical contents of a is A B. At first search I've found some
rather heated debates about this with bits of name calling; I certainly do
not want to get into that and I apologize in advance to those who feel very
strongly about this.
I've seen one fix describe the problem as:
DESCRIPTION: Submitter invokes following statement:
SELECT (XPATH('/*/text()', 'rootlt;/root'))[1].
He expect (escaped) result lt;, but gets
With respect, this bug makes no sense as this produces in fact the right
result. The actual value of root is , it's just escaped when serialized
to XML. If root were to actually contain lt;, it'd be serialized as
amp;lt;. It should not be possible to be blindly cast to a text type, but
explicitly serialized as such.
At least the reviewer at:
http://www.postgresql.org/message-id/201106291934.23089.rsmog...@softperience.eu
There are two other similar bug reports on this from February and March
of this year:
http://www.postgresql.org/message-id/e1u1fkl-0002rd...@wrihigleys.postgresql.org
I think that should be:
http://www.postgresql.org/message-id/e1u1fkl-0002rd...@wrigleys.postgresql.org
http://www.postgresql.org/message-id/e1uhyuw-0001oj...@wrigleys.postgresql.org
Someone who knows XML needs to take leadership on this and propose a
patch.
agreed
Stefan
--
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] abort()/segfault when starting postgres in inaccessible CWD
Andres Freund and...@2ndquadrant.com writes: Starting postgres with a CWD that's not readable will trigger an Assert and if those are disabled it presumably will segfault. Yeah, we've discussed that before. I'm not sure it's worth fixing, or that it could be counted on to stay fixed even if we removed the current source(s) of trouble. There's a bigger problem with the scenario you show, which is that the postmaster is started with root's environment variables not postgres'. That's likely to lead to assorted surprises that we can't really do anything about, even if we fixed the CWD issue. So I'm inclined to think this scenario is a don't do that. Having said that, though, it seems like a bad idea to be calling set_pglocale_pgservice() before palloc is functional. It's not at all obvious that that function can't be allowed to use palloc. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] abort()/segfault when starting postgres in inaccessible CWD
On 2013-10-03 19:07:37 +0200, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: Starting postgres with a CWD that's not readable will trigger an Assert and if those are disabled it presumably will segfault. Yeah, we've discussed that before. I'm not sure it's worth fixing, or that it could be counted on to stay fixed even if we removed the current source(s) of trouble. There's a bigger problem with the scenario you show, which is that the postmaster is started with root's environment variables not postgres'. That's likely to lead to assorted surprises that we can't really do anything about, even if we fixed the CWD issue. So I'm inclined to think this scenario is a don't do that. I have no problem not supporting the scenario of an inaccessible CWD - I'd just like to have a better error message than a segfault... Having said that, though, it seems like a bad idea to be calling set_pglocale_pgservice() before palloc is functional. It's not at all obvious that that function can't be allowed to use palloc. Yes, and it seems hard to control - as proven here - that it doesn't make any calls to functions using palloc() in some edge cases. Greetings, Andres Freund -- Andres Freund 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 #8498: pg_trgm is missing from windows edb package
Disregard my bug complaint. Stupid user error. Thanks, Regina -- 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] psql \i command with a missing file name doesn't rollback the transaction
On Fri, Sep 20, 2013 at 11:15:01AM +0200, Alexey Klyukin wrote: Hi, We've discovered a surprising behavior of psql \i command. What we sometimes to add new tables to the database is: begin; \i /path/to/table/definitions/table1.sql \i /path/to/table/definitions/table2.sql ... \i /path/to/table/definitions/tableN.sql commit; What we discovered that some files in the /path/to/table/definitions were missing (say, table 2,3), but the table 1, 4... N appeared in the database after executing the transaction. This is quite a catch, since we cannot rely on transaction consistency when using an include directive. The test is simple: begin; \i whatever; select 1; commit; The expected behavior was that select 1 would lead to 'ERROR: current transaction is aborted'. The current behavior is that it is executed, although a message is emitted to a client: whatever: No such file or directory Would it be possible from the client side to generate the rollback to the server on an attempt to include a non-existing file (perhaps only when ON_ERROR_STOP is set to 1?). The problem is how would we decide what psql actions should trigger a rollback, and how would we show the user we did that. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Installing/Upgrading PostgreSQL 9.1.6 to 9.3 known bugs?
On Fri, Sep 20, 2013 at 02:00:05PM -0700, John R Pierce wrote: On 9/20/2013 1:51 PM, fburg...@radiantblue.com wrote: 1.) During our prior upgrade process we used pg_upgrade to move from pg 8.4.3 to 9.1.6 using the hard links install option, we also have our data spread across disk storage mediums; fiber, nas. Are there any known issues, bugs with using pg_upgrade to move from 9.1.6 to pg 9.3? having multiple tablespaces on different mount points complicates things. I'm not sure how or if pg_upgrade handles that. pg_upgrade is fine with that. The old/new tablespaces stay in the same mount point as just per-version subdirectories. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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 #8467: Slightly confusing pgcrypto example in docs
On Tue, Sep 24, 2013 at 11:20:55PM +0100, Richard Neill wrote:
I'm sorry about that: I think I need to correct my proposed
correction! I think I've been writing too much C recently, and so I
foolishly mis-read that as returning pswhash, rather than returning
the truth of the comparison.
What I meant to write, for clarity, was:
SELECT (pswhash = crypt('entered password', pswhash)) AS pswmatch FROM ... ;
which would make it obvious that we're returning the boolean named pswmatch.
[Also, should the default example perhaps use gen_salt('bf'), as opposed to
gen_salt('md5') ?]
This, however, might be a good idea. People should of course always
read the documentation, but having the examples including the best
practice would probably be a good idea.
Incidentally, there are 2 other things that confused me in this section.
1. Table F-18. Supported algorithms for crypt() has a column
labelled max password length. It would perhaps also be useful to
know the size of column needed to store the crypted password (my
original crypt using md5 easily fits in a varchar(70), whereas using
bf needs the column to be varchar(100).)
2. Table F-20. Hash algorithm speeds
What's the difference here between crypt-md5 and md5 ?
If I've rightly read this, the algorithm named md5 in the crypt()
documentation is named crypt-md5 here, whereas Table F20's md5
algorithm seems to refer to something else - probably the normal
version of md5.
If so, it would be clearer to write that the last 2 lines (md5 and
sha1) are for comparison only, and refer to the speed of doing an
ordinary md5/sha1 sum, rather than the md5-variant of crypt().
Anyway, thanks again for your help - Postgres is a wonderful system,
which I've found to be repeatedly useful.
Based on your report, I have developed the attached doc patch which
clarifies when MD5 hash is being referenced, and when MD5 crypt is. I
have also added your other suggestions.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/doc/src/sgml/pgcrypto.sgml b/doc/src/sgml/pgcrypto.sgml
new file mode 100644
index a0eead7..976c7db
*** a/doc/src/sgml/pgcrypto.sgml
--- b/doc/src/sgml/pgcrypto.sgml
*** hmac(data bytea, key text, type text) re
*** 95,102
/para
para
!The algorithms in functioncrypt()/ differ from usual hashing algorithms
!like MD5 or SHA1 in the following respects:
/para
orderedlist
--- 95,102
/para
para
!The algorithms in functioncrypt()/ differ from the usual
!MD5 or SHA1 hashing algorithms in the following respects:
/para
orderedlist
*** hmac(data bytea, key text, type text) re
*** 142,147
--- 142,148
entryMax Password Length/entry
entryAdaptive?/entry
entrySalt Bits/entry
+ entryOutput length/entry
entryDescription/entry
/row
/thead
*** hmac(data bytea, key text, type text) re
*** 151,156
--- 152,158
entry72/entry
entryyes/entry
entry128/entry
+ entry60/entry
entryBlowfish-based, variant 2a/entry
/row
row
*** hmac(data bytea, key text, type text) re
*** 158,163
--- 160,166
entryunlimited/entry
entryno/entry
entry48/entry
+ entry34/entry
entryMD5-based crypt/entry
/row
row
*** hmac(data bytea, key text, type text) re
*** 165,170
--- 168,174
entry8/entry
entryyes/entry
entry24/entry
+ entry20/entry
entryExtended DES/entry
/row
row
*** hmac(data bytea, key text, type text) re
*** 172,177
--- 176,182
entry8/entry
entryno/entry
entry12/entry
+ entry13/entry
entryOriginal UNIX crypt/entry
/row
/tbody
*** UPDATE ... SET pswhash = crypt('new pass
*** 205,211
para
Example of authentication:
programlisting
! SELECT pswhash = crypt('entered password', pswhash) FROM ... ;
/programlisting
This returns literaltrue/ if the entered password is correct.
/para
--- 210,216
para
Example of authentication:
programlisting
! SELECT (pswhash = crypt('entered password', pswhash)) AS pswmatch FROM ... ;
/programlisting
This returns literaltrue/ if the entered password is correct.
/para
*** gen_salt(type text [, iter_count integer
*** 353,359
entry12 years/entry
/row
row
!entryliteralmd5//entry
entry2345086/entry
entry1 day/entry
entry3 years/entry
--- 358,364
entry12 years/entry
/row
row
!entryliteralmd5 hash//entry
entry2345086/entry
entry1 day/entry
entry3
Re: [BUGS] BUG #8469: Xpath behaviour unintuitive / arguably wrong
On Tue, Sep 24, 2013 at 06:43:19PM +, dennis.noord...@helsinki.fi wrote:
The following bug has been logged on the website:
Bug reference: 8469
Logged by: Dennis
Email address: dennis.noord...@helsinki.fi
PostgreSQL version: 9.3.0
Operating system: FreeBSD 9.2-RC4
Description:
Hi,
After upgrading an 8.1 version to 9.3.0 I am suddenly seeing text fields
containing amp; where they are populated from XML. This may be a
coincidence and the problem may have existed earlier, in any case, now I
noticed.
I extract the text content of XML nodes using xpath, from something like:
nameJones amp; Smith/name
The reason I end up with amp; is the IMHO rather odd xpath behaviour:
# select xpath('/a/text()', (select xmlelement(name a, 'A B')));
xpath
---
{A amp; B}
The canonical contents of a is A B. At first search I've found some
rather heated debates about this with bits of name calling; I certainly do
not want to get into that and I apologize in advance to those who feel very
strongly about this.
I've seen one fix describe the problem as:
DESCRIPTION: Submitter invokes following statement:
SELECT (XPATH('/*/text()', 'rootlt;/root'))[1].
He expect (escaped) result lt;, but gets
With respect, this bug makes no sense as this produces in fact the right
result. The actual value of root is , it's just escaped when serialized
to XML. If root were to actually contain lt;, it'd be serialized as
amp;lt;. It should not be possible to be blindly cast to a text type, but
explicitly serialized as such.
At least the reviewer at:
http://www.postgresql.org/message-id/201106291934.23089.rsmog...@softperience.eu
There are two other similar bug reports on this from February and March
of this year:
http://www.postgresql.org/message-id/e1u1fkl-0002rd...@wrihigleys.postgresql.org
http://www.postgresql.org/message-id/e1uhyuw-0001oj...@wrigleys.postgresql.org
Someone who knows XML needs to take leadership on this and propose a
patch.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
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] pg_upgrade 9.0-9.2 failure: Mismatch of relation OID in database
On Thu, Sep 26, 2013 at 02:59:30PM +0200, Christoph Berg wrote:
On upgrading a 9.0 database to 9.2 using pg_upgrade, I got this:
# pg_upgradecluster -m upgrade 9.0 main /psql/data-9.2
[...]
Performing Upgrade
--
[...]
Restoring database schema to new clusterok
Removing support functions from new cluster ok
Copying user relation files
Mismatch of relation OID in database hisrm: old OID 18804, new OID 18803
Failure, exiting
Error: pg_upgrade run failed
This is a cluster that was running with 9.0.12 (compiled locally). For
the upgrade, I installed postgresql-9.0 and -9.2 from
apt.postgresql.org (9.0.13, 9.2.4), so pg_upgrade was using these
versions. OS is Ubuntu 12.04 amd64 now and was 8.04 while the cluster
was still running on 9.0.12.
In the 9.0 cluster, 18804 is the relation oid of glm_lrahm_to_se.
pg_upgrade_dump_all.sql:
--
-- Name: glm_lrahm_to_se; Type: TABLE; Schema: mbs; Owner: fsv; Tablespace:
--
-- For binary upgrade, must preserve pg_type oid
SELECT binary_upgrade.set_next_pg_type_oid('18806'::pg_catalog.oid);
-- For binary upgrade, must preserve pg_type array oid
SELECT binary_upgrade.set_next_array_pg_type_oid('18805'::pg_catalog.oid);
-- For binary upgrade, must preserve pg_class oids
SELECT binary_upgrade.set_next_heap_pg_class_oid('18804'::pg_catalog.oid);
CREATE TABLE glm_lrahm_to_se (
id integer NOT NULL,
lrahm integer NOT NULL,
se integer NOT NULL
);
That is very interesting, and it certainly should not be failing.
I am surprised it got an oid that was one less than the desired one,
18803. Is there any mention of 18803 in the SQL file? If you create a
cluster with just your schema and no data, can you upgrade that cleanly?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
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 #8495: PLSQL PG Terrible performance by using two-dimensional arrays.
Hello 2013/10/1 m.ma...@upm.es The following bug has been logged on the website: Bug reference: 8495 Logged by: Miguel A. Manso Callejo Email address: m.ma...@upm.es PostgreSQL version: 9.1.9 Operating system: Ubuntu 12.04LTS Description: I'm trying to random access to a 2-dimensional array of double precision numbers. When range of the array increase, the performance decrease quickly. A simple function as: CREATE OR REPLACE FUNCTION fill_2d_array( rows integer, cols integer) RETURNS integer AS $BODY$ DECLARE img double precision[][]; i integer; j integer; cont integer; BEGIN img := ARRAY( SELECT 0 FROM generate_series(1, rows * cols) ) ; cont:= 0; For i IN 1..rows LOOP For j IN 1..cols LOOP img[i * cols + j] := (i * cols + j)::double precision; cont := cont + 1; END LOOP; END LOOP; return cont; END; $BODY$ LANGUAGE plpgsql; ALTER FUNCTION fill_2d_array( integer, integer) OWNER TO postgres; when call the function with 700 rows 1200 cols (explain (analyze,buffers) select fill_2d_array(700,1200); ) the time consumed is about 50minutes. What is bad? what i'm doing bad? update a large array is terrible slow due fact, so PostgreSQL arrays are immutable - so any update is same as copy of array. sometimes is better to generate table and build a array from table, but it is not possible for two dimensional array without custom C extension :( if you can, try to use PLPerl instead PL/pgSQL You cannot do much more - for 1D arrays exists some tricks, but it doesn't work for 2D arrays. You can write relative simply C extension, and solve problem there. Regards Pavel Stehule Thank you very much. -- 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 #8494: Cannot Backup / Restore
On 01/10/13 15:17, h...@canwrx.com wrote: a) My version is Postgres Enterprise Manager version 3.0.0, copyright 2002-2012, the pgAdmin Development Team; and Postgres Plus Advanced Server 9.2 Hi - your product is supported by Enterprisedb (http://www.enterprisedb.com/). I think you would be better raising this issue with them! Cheers Mark -- 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 #8455: spanish pgadmin3.mo
On Thu, 2013-09-26 at 21:18 -0400, Bruce Momjian wrote: On Mon, Sep 16, 2013 at 08:40:57AM +, j.rom...@salsa.es wrote: The following bug has been logged on the website: Bug reference: 8455 Logged by: Jesus Romero Email address: j.rom...@salsa.es PostgreSQL version: 9.1.9 Operating system: Ubuntu server 12.04 Description: The actual version of pgadmin3 1.18 includes a wrong file pgadmin3.mo for the spanish languaje. The file included is catalan languaje not the spanish one. You should report this to the pgadmin developers on one of their email lists: http://www.pgadmin.org/support/list.php Actually, this has already been fixed. My fault, my fix :) -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8434: Why does dead lock occur many times ?
Hi, Thanks to your info, otsuka-san. It seems to be related to some changes in the [Improve concurrency of foreign key locking] commit(*). (*) commitid : 0ac5ad5134f2769ccbaefec73844f8504c4d6182 Because I could not reproduce dead lock before the commit. And I'm thinking that also this commit is related to BUG#8470. If so, I hope Alvaro will find the solution for this problem. Maybe I can't take enough time, but I'll investigate this continuously. If someone could reproduce this, please share information. regards, --- NTT Software Corporation Tomonari Katsumata 2013/9/19 OTSUKA Kenji otsuka@gmail.com Hi, This issue occurred even on 9.3.0. I took the following information, and I attached them. pg_locks.txt ... pg_locks during deadlock pg_stat_activity.txt ... pg_stat_activity during deadlock postgresql.log... PostgreSQL log (including LOCK_DEBUG log) The OID of the table is 16459. I run 3 transactions. One transaction of them executes SELECT FOR UPDATE and UPDATE a row. And two transactions of them execute only UPDATE the same line. The results is that all of UPDATE is waiting. I changed a little bit how to reproduce. It is as follows. - Compiling PostgreSQL Add -DLOCK_DEBUG to CFLAGS - Changing postgresql.conf following parameters log_lock_waits = on deadlock_timeout = 1min # for getting information during deadlock debug_deadlocks = on trace_lock_table = 16459 log_line_prefix = '%t [%p] %q(%a) ' logging_collector = on log_filename = 'postgresql.log' log_min_messages = info log_error_verbosity = verbose - Testing 1. Initializing data Executing createdb.sh This creates a table with 2 columns, and insert 1 row. 2. Running the transactions Executing test.sh This runs 3 transactions. 2 transactions of them (tx1) are BEGIN; UPDATE t SET col2 = 'A' WHERE col1 = 1; COMMIT; 1 transaction of them (tx2) is BEGIN; SELECT * FROM t WHERE col1 = 1 FOR UPDATE; UPDATE t SET col2 = 'A' WHERE col1 = 1; COMMIT; regards, 2013/9/4 katsumata.tomon...@po.ntts.co.jp The following bug has been logged on the website: Bug reference: 8434 Logged by: Tomonari Katsumata Email address: katsumata.tomon...@po.ntts.co.jp PostgreSQL version: 9.3rc1 Operating system: RedHatEnterpriseLinux 6.4(x86_64) Description: Hi, I'm testing PostgreSQL 9.3rc1. Many times updates and selects for update become dead lock situation. The reproduce is: 1. initializing data createdb testdb psql testdb -c create table t (col1 int, col2 int, col3 text); psql testdb -c insert into t values (1, 4, 'A'); psql testdb -c insert into t values (2, 5, 'B'); psql testdb -c insert into t values (3, 6, 'C'); 2. executing updates and selects for update (run below script) #!/bin/sh ./tx1 /dev/null ./tx2 /dev/null ./tx3 /dev/null wait tx1 is: #!/bin/sh while : do psql testdb EOF BEGIN; UPDATE t SET col3 = 'c' WHERE col1 = 3 AND col2 = 6; COMMIT; \q EOF done tx2 is: #!/bin/sh while : do psql testdb EOF BEGIN; SELECT col1, col2, col3 FROM t WHERE col1 = 3 AND col2 = 6 FOR UPDATE; UPDATE t SET col3 = 'c' WHERE col1 = 3 AND col2 = 6; COMMIT; \q EOF done tx3 is: #!/bin/sh while : do psql testdb EOF BEGIN; UPDATE t SET col3 = 'c' WHERE col1 = 3 AND col2 = 6; COMMIT; \q EOF done Then, I got below messages. 2013-09-04 15:25:25 JST 29630 5226d254.73be-1 659102 (pgsql, testdb, [local], psql) LOG: 0: process 29630 detected deadlock while waiting for ShareLock on transaction 659103 after 1000.136 ms 2013-09-04 15:25:25 JST 29630 5226d254.73be-2 659102 (pgsql, testdb, [local], psql) LOCATION: ProcSleep, proc.c:1232 2013-09-04 15:25:25 JST 29630 5226d254.73be-3 659102 (pgsql, testdb, [local], psql) STATEMENT: UPDATE t SET col3 = 'c' WHERE col1 = 3 AND col2 = 6; 2013-09-04 15:25:25 JST 29630 5226d254.73be-4 659102 (pgsql, testdb, [local], psql) ERROR: 40P01: deadlock detected 2013-09-04 15:25:25 JST 29630 5226d254.73be-5 659102 (pgsql, testdb, [local], psql) DETAIL: Process 29630 waits for ShareLock on transaction 659103; blocked by process 29631. Process 29631 waits for ExclusiveLock on tuple (0,153) of relation 16385 of database 16384; blocked by process 29630. Process 29630: UPDATE t SET col3 = 'c' WHERE col1 = 3 AND col2 = 6; Process 29631: UPDATE t SET col3 = 'c' WHERE col1 = 3 AND col2 = 6; 2013-09-04 15:25:25 JST 29630 5226d254.73be-6 659102 (pgsql, testdb, [local], psql) HINT: See server log for query details. 2013-09-04 15:25:25 JST 29630 5226d254.73be-7 659102 (pgsql, testdb, [local], psql) LOCATION: DeadLockReport,
Re: [BUGS] BUG #8434: Why does dead lock occur many times ?
Hi, Sorry I hadn't noticed this thread. Tomonari Katsumata escribió: It seems to be related to some changes in the [Improve concurrency of foreign key locking] commit(*). (*) commitid : 0ac5ad5134f2769ccbaefec73844f8504c4d6182 Because I could not reproduce dead lock before the commit. Yes, sounds pretty likely. And I'm thinking that also this commit is related to BUG#8470. Yes, I replied to that thread because I suspect the same. If so, I hope Alvaro will find the solution for this problem. I will take a look at this problem next week. -- Álvaro Herrerahttp://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] select table indicate missing chunk number 0 for toast value 96635 in pg_toast_2619
David Fetter david at fetter.org writes: Upgrade to 9.1.3 and let us know whether that fixes the problem. I've run into this issue as well on postgres 8.4.14. Aside from upgrading to a newer release is there any manual fixup that can be done ? Thanks, David -- 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] select table indicate missing chunk number 0 for toast value 96635 in pg_toast_2619
I have seen this issue on a slave although it was in version 9.2. I ran this select 2619::regclass; regclass -- pg_statistic (1 row) I was able to fix my select issue by running analyze on the database On Thu, Sep 26, 2013 at 11:47 AM, David Rennalls drenna...@gmail.comwrote: David Fetter david at fetter.org writes: Upgrade to 9.1.3 and let us know whether that fixes the problem. I've run into this issue as well on postgres 8.4.14. Aside from upgrading to a newer release is there any manual fixup that can be done ? Thanks, David -- 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] select table indicate missing chunk number 0 for toast value 96635 in pg_toast_2619
On Thu, Sep 26, 2013 at 3:40 PM, Kim Applegate kappleg...@apsalar.com wrote: I have seen this issue on a slave although it was in version 9.2. I ran oh ok. Looks like the issue was fixed in 8.2.23 according to these release notes http://www.postgresql.org/docs/8.2/static/release-8-2-23.html ... o Fix race condition during toast table access from stale syscache entries (Tom Lane) The typical symptom was transient errors like missing chunk number 0 for toast value N in pg_toast_2619, where the cited toast table would always belong to a system catalog. .. but maybe there's a different flavour of this bug ? this select 2619::regclass; regclass -- pg_statistic (1 row) I was able to fix my select issue by running analyze on the database Yes I tried that but didn't seem to help... mydb=# ANALYZE verbose; INFO: analyzing pg_catalog.pg_type INFO: pg_type: scanned 13 of 13 pages, containing 590 live rows and 0 dead rows; 590 rows in sample, 590 estimated total rows INFO: analyzing pg_catalog.pg_attribute INFO: pg_attribute: scanned 78 of 78 pages, containing 4633 live rows and 0 dead rows; 4633 rows in sample, 4633 estimated total rows INFO: analyzing information_schema.sql_features INFO: sql_features: scanned 7 of 7 pages, containing 649 live rows and 0 dead rows; 649 rows in sample, 649 estimated total rows ERROR: missing chunk number 0 for toast value 33255 in pg_toast_2619 - David -- 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] select table indicate missing chunk number 0 for toast value 96635 in pg_toast_2619
On Thu, Sep 26, 2013 at 4:19 PM, David Rennalls drenna...@gmail.com wrote: On Thu, Sep 26, 2013 at 3:40 PM, Kim Applegate kappleg...@apsalar.com wrote: I have seen this issue on a slave although it was in version 9.2. I ran oh ok. Looks like the issue was fixed in 8.2.23 according to these release notes http://www.postgresql.org/docs/8.2/static/release-8-2-23.html ... o Fix race condition during toast table access from stale syscache entries (Tom Lane) The typical symptom was transient errors like missing chunk number 0 for toast value N in pg_toast_2619, where the cited toast table would always belong to a system catalog. .. but maybe there's a different flavour of this bug ? Actually forgot to mention in my case there were filesystem issues... so that might explain it. fsck was run and did some repairs after which the error above started happening. this select 2619::regclass; regclass -- pg_statistic (1 row) I was able to fix my select issue by running analyze on the database Yes I tried that but didn't seem to help... mydb=# ANALYZE verbose; INFO: analyzing pg_catalog.pg_type INFO: pg_type: scanned 13 of 13 pages, containing 590 live rows and 0 dead rows; 590 rows in sample, 590 estimated total rows INFO: analyzing pg_catalog.pg_attribute INFO: pg_attribute: scanned 78 of 78 pages, containing 4633 live rows and 0 dead rows; 4633 rows in sample, 4633 estimated total rows INFO: analyzing information_schema.sql_features INFO: sql_features: scanned 7 of 7 pages, containing 649 live rows and 0 dead rows; 649 rows in sample, 649 estimated total rows ERROR: missing chunk number 0 for toast value 33255 in pg_toast_2619 ..Tried reindexing pg_statistic based on some other posts I saw, but was getting this error... mydb=# REINDEX TABLE pg_statistic; ERROR: could not create unique index pg_statistic_relid_att_index DETAIL: Table contains duplicated values. ..came across this thread http://www.spinics.net/lists/pgsql-admin/msg05911.html and I tried simply deleting all the stuff in pg_statistic, reindex then vacuum and that seems to have worked. mydb=# delete from pg_statistic; DELETE 610 mydb=# reindex table pg_statistic; REINDEX mydb=# vacuum analyze; - David -- 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] Errors during PostgreSQL 9.2 and 9.3 installation
Hi Please send the installation log (install-postgresql.log) from the temp. That will help us to know what went wrong. On Wed, Sep 25, 2013 at 2:44 AM, Volberg, Ovsei ovsei.volb...@scientificgames.com wrote: The error message is attached. The computer was Windows 7, 32-bit machine. Please help. Thank you, *Ovsei Volberg* Video Gaming Senior Software Engineer Scientific Games International *1500 Bluegrass Lakes Parkway | Alpharetta, GA 30004* (() Direct *770.825.4582* (*) *ovsei.volb...@scientificgames.com hank.free...@scientificgames.com* ** This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Sandeep Thakkar
Re: [BUGS] BUG #8468: Create index on type tstzrange fail
On 24.09.2013 14:42, marian.kruc...@gmail.com wrote:
CREATE INDEX ON tstzrange fail on 9.3.0 and 9.2.4 - default postgres
configuration.
It ate whole memory and was killed by oom.
Example:
postgres=# CREATE TABLE range_test AS SELECT tstzrange(t, t+'1min') tr FROM
generate_series('2000-1-1'::TIMESTAMPTZ, '2010-1-1'::TIMESTAMPTZ, '1min') AS
t1(t);
SELECT 5260321
postgres=# CREATE INDEX ON range_test(tr);
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
The connection to the server was lost. Attempting reset: Failed.
A-ha, the comparison function of range datatypes, range_cmp(), detoasts
its arguments, but fails to free the detoasted copies. Functions are
normally not required to free such temporary copies - the memory is
usually leaked into a short-lived memory context that will be quickly
free'd anyway - but B-tree comparison operators are expected to not leak.
Committed a fix, it will appear in the next minor releases. Thanks for
the report!
- Heikki
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8470: 9.3 locking/subtransaction performance regression
o...@ohmu.fi wrote: The following code performs a lot slower on PostgreSQL 9.3.0 than on PostgreSQL 9.2.4: DROP TABLE IF EXISTS tmp; CREATE TABLE tmp (id BIGSERIAL, vals BIGINT[]); DO $$ DECLARE r_id BIGINT; n BIGINT; BEGIN FOR n IN 1..1000 LOOP BEGIN SELECT id INTO r_id FROM tmp WHERE array_length(vals, 1) 100 LIMIT 1 FOR UPDATE NOWAIT; Most likely, this is caused by the new tuple lock code in 9.3. I can't look at this immediately but I will give it a look as soon as I'm able. -- Álvaro Herrerahttp://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 #8450: pg_basebackup blocks until WAL archiving successful
On Mon, Sep 23, 2013 at 3:33 PM, Heikki Linnakangas I can see why you'd want that, but it seems equally problematic to let pg_basebackup return, when the WAL files haven't been archived yet and you therefore don't in fact have valid, restorable backup yet. Have you considered using the --xlog-method=stream option, to include the WAL files in the backup? That will make your backups somewhat larger, as the WAL files are included, but in that mode pg_basebackup won't wait for the archival and the backup will be restorable even if archive_command is failing. I'm supporting PG 9.1 at the moment so cannot rely on --xlog-method=stream. I agree that the current behavior is for most use cases better, and I think that the behavior I want should be explicitly enabled with an option. -- Stuart Bishop stu...@stuartbishop.net http://www.stuartbishop.net/ -- 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 #8467: Slightly confusing pgcrypto example in docs
On Tue, Sep 24, 2013 at 1:11 AM, postgre...@richardneill.org wrote:
The following bug has been logged on the website:
Bug reference: 8467
Logged by: Richard Neill
Email address: postgre...@richardneill.org
PostgreSQL version: 9.3.0
Operating system: Documentation bug
Description:
The documentation for pgcrypto:
http://www.postgresql.org/docs/current/static/pgcrypto.html
(and indeed all versions from 8.3-9.3)
contains the following:
Example of authentication:
SELECT pswhash = crypt('entered password', pswhash) FROM ... ;
This returns true if the entered password is correct.
I found this confusing, because it's using the same name, pswhash in 2
places, one of which is a boolean. It would be, imho, clearer to write the
example query as:
SELECT is_authenticated = crypt('entered password', pswhash) FROM ... ;
That would render the example incorrect. crypt(pwd, hash) returns the
hash. Not a boolean. This hash needs to be compared to the stored one,
as is explained in the instructions above the example. It's the whole
expression, including the pswhash = that returns boolean.
[Also, should the default example perhaps use gen_salt('bf'), as opposed to
gen_salt('md5') ?]
This, however, might be a good idea. People should of course always
read the documentation, but having the examples including the best
practice would probably be a good idea.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8467: Slightly confusing pgcrypto example in docs
Dear Magnus,
Thanks for your reply.
On 24/09/13 18:31, Magnus Hagander wrote:
The following bug has been logged on the website:
Bug reference: 8467
The documentation for pgcrypto:
http://www.postgresql.org/docs/current/static/pgcrypto.html
(and indeed all versions from 8.3-9.3)
contains the following:
---[ ONE] -
Example of authentication:
SELECT pswhash = crypt('entered password', pswhash) FROM ... ;
This returns true if the entered password is correct.
I found this confusing, because it's using the same name, pswhash in 2
places, one of which is a boolean. It would be, imho, clearer to write the
example query as:
[ TWO ]
SELECT is_authenticated = crypt('entered password', pswhash) FROM ... ;
That would render the example incorrect. crypt(pwd, hash) returns the
hash. Not a boolean. This hash needs to be compared to the stored one,
as is explained in the instructions above the example. It's the whole
expression, including the pswhash = that returns boolean.
I'm sorry about that: I think I need to correct my proposed correction!
I think I've been writing too much C recently, and so I foolishly
mis-read that as returning pswhash, rather than returning the truth of
the comparison.
What I meant to write, for clarity, was:
SELECT (pswhash = crypt('entered password', pswhash)) AS pswmatch FROM ... ;
which would make it obvious that we're returning the boolean named pswmatch.
[Also, should the default example perhaps use gen_salt('bf'), as opposed to
gen_salt('md5') ?]
This, however, might be a good idea. People should of course always
read the documentation, but having the examples including the best
practice would probably be a good idea.
Incidentally, there are 2 other things that confused me in this section.
1. Table F-18. Supported algorithms for crypt() has a column labelled
max password length. It would perhaps also be useful to know the size
of column needed to store the crypted password (my original crypt using
md5 easily fits in a varchar(70), whereas using bf needs the column to
be varchar(100).)
2. Table F-20. Hash algorithm speeds
What's the difference here between crypt-md5 and md5 ?
If I've rightly read this, the algorithm named md5 in the crypt()
documentation is named crypt-md5 here, whereas Table F20's md5
algorithm seems to refer to something else - probably the normal
version of md5.
If so, it would be clearer to write that the last 2 lines (md5 and
sha1) are for comparison only, and refer to the speed of doing an
ordinary md5/sha1 sum, rather than the md5-variant of crypt().
Anyway, thanks again for your help - Postgres is a wonderful system,
which I've found to be repeatedly useful.
Best wishes,
Richard
--
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 #8453: uninitialized memory access in pg_receivexlog and other bugs
On 16.09.2013 22:59, Andrew Gierth wrote: Heikki == Heikki Linnakangashlinnakan...@vmware.com writes: Heikki Attached is a patch to fix both of these issues. I'm too Heikki tired right now to thoroughly test it and commit, so I'll get Heikki back to this tomorrow. Meanwhile, please take a look and let Heikki me know if you can see something wrong. A quick eyeball check looks ok; I'll see about reproducing the original scenario with this patch applied. Committed, thanks for the report! If you still have a chance to try it with the original scenario, please do. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8465: major dump/reload problem
On 21.09.2013 20:16, jan.m...@inf-it.com wrote: today I tried to upgrade from 9.2 to 9.3 (pg_upgradecluster 9.2 main) and the upgrade of one of my databases failed with the following error: ERROR: new row for relation ... violates check constraint I created an example to reproduce this bug: http://www.inf-it.com/fixes/postgres-bugreport2/schema.sql The problem is that when the database is dumped with pg_dump and reloaded, the activity table is loaded first, and codebook table second. The check constraint checks that when a row is inserted into activity table, the corresponding row exists in codebook table, which clearly isn't true if the activity table is loaded first and the codebook table is still empty. The system doesn't know about that dependency since it's all implemented in the PL/pgSQL code. With a constraint like that, you would also get an unrestorable dump if you e.g deleted a row from codebook table after loading the activities. Usually you would implement a schema like that using foreign keys. That would be less code, and the system would automatically get the dump order correct. I would recommend that over a check constraint, if possible. As a work-around, you can drop the constraints from the database before upgrading, and restore them afterwards. The problem isn't really related to upgrade per se, BTW. Running pg_dump + restore even on the same version will give you the same error. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8450: pg_basebackup blocks until WAL archiving successful
On 13.09.2013 15:13, stu...@stuartbishop.net wrote: pg_basebackup blocks until all necessary WAL files have been archived by archive_command. This can take a few minutes under normal circumstances, and indefinitely if archive_command is failing. I would like to be able to disable this check, as I am streaming backups to a system that can time out my connection if it does not receive new data for a short while. This makes unattended backups problematic. I can see why you'd want that, but it seems equally problematic to let pg_basebackup return, when the WAL files haven't been archived yet and you therefore don't in fact have valid, restorable backup yet. Have you considered using the --xlog-method=stream option, to include the WAL files in the backup? That will make your backups somewhat larger, as the WAL files are included, but in that mode pg_basebackup won't wait for the archival and the backup will be restorable even if archive_command is failing. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8465: major dump/reload problem
Hi Keikki, it is clear what causes this problem, but pg_upgradecluster is an operation which simply MUST work (if you have several hundred of user databases, it is not an option to check all of them for this kind of error before the cluster upgrade). Database upgrade is performed by the server administrator and a simple check constraint (created by a random database user) CANNOT break it. The real solution is to change the pg_dump result from: CREATE TABLE activity ( _id bigint NOT NULL, name text NOT NULL, country bigint NOT NULL, currency bigint NOT NULL, CONSTRAINT activity_country_check CHECK (codebook_check((1)::bigint, country, false)), CONSTRAINT activity_currency_check CHECK (codebook_check((2)::bigint, currency, false)) ); import data here to CREATE TABLE activity ( _id bigint NOT NULL, name text NOT NULL, country bigint NOT NULL, currency bigint NOT NULL ); import data here ALTER TABLE activity ADD CHECK (codebook_check((1)::bigint, country, false)); ALTER TABLE activity ADD CHECK (codebook_check((2)::bigint, currency, false)); JM On Sep 23, 2013, at 10:05 AM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 21.09.2013 20:16, jan.m...@inf-it.com wrote: today I tried to upgrade from 9.2 to 9.3 (pg_upgradecluster 9.2 main) and the upgrade of one of my databases failed with the following error: ERROR: new row for relation ... violates check constraint I created an example to reproduce this bug: http://www.inf-it.com/fixes/postgres-bugreport2/schema.sql The problem is that when the database is dumped with pg_dump and reloaded, the activity table is loaded first, and codebook table second. The check constraint checks that when a row is inserted into activity table, the corresponding row exists in codebook table, which clearly isn't true if the activity table is loaded first and the codebook table is still empty. The system doesn't know about that dependency since it's all implemented in the PL/pgSQL code. With a constraint like that, you would also get an unrestorable dump if you e.g deleted a row from codebook table after loading the activities. Usually you would implement a schema like that using foreign keys. That would be less code, and the system would automatically get the dump order correct. I would recommend that over a check constraint, if possible. As a work-around, you can drop the constraints from the database before upgrading, and restore them afterwards. The problem isn't really related to upgrade per se, BTW. Running pg_dump + restore even on the same version will give you the same error. - Heikki smime.p7s Description: S/MIME cryptographic signature
Re: [BUGS] BUG #8463: Packaging problem with postgis rpms
Hi, Updated packages will be in the repo in the next hour or so. Apologies for the inconvenience. Regards, Devrim On Wed, 2013-09-18 at 13:56 +, kyri...@alumni.princeton.edu wrote: The following bug has been logged on the website: Bug reference: 8463 Logged by: Kriton Kyrimis Email address: kyri...@alumni.princeton.edu PostgreSQL version: 9.2.4 Operating system: Scientific Linux 6.4 Description: (I am submitting this report here, as I assume that the rpms downloaded from yum.postgresql.org are built by postgresql and not by postgis.) The latest release of the postgis2_92* rpms (version 2.0.4) introduced a new package, postgis2_92-client, containing, among other things, the postgis shared library. This creates the problem that, after updating an existing system, the shared libraries disappear, and postgis stops working, producing the error postgis2_92-client-2.0.4-1 whenever a query involving postgis is executed. At the very least, the postgis2_92 package should depend on the postgis2_92-client package, so that updating the former will also install the latter, thus avoiding breaking existing systems. -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [BUGS] tablefunc extension
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/19/2013 12:24 PM, Carl Clemens wrote: The following query appears to be correct but fails to execute. Your example is incorrect, however it is not clear (to me at least) from your example what you are expecting as output -- please see the documentation: http://www.postgresql.org/docs/9.2/interactive/tablefunc.html If you still have a problem please provide SQL that can be cut and pasted which: 1) create your table 2) insert sample rows Then show us what out put you are trying to acheive as output from that data. Joe - -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, 24x7 Support -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSP3qGAAoJEDfy90M199hljPoP/R/LPHwlkQYtIE9YjNS1FRoJ viivrvUzAeP27zivgo8rIIrfXNyghUTfE8dyBRL1JB934PLcyu83+J9fcfW979xO ogt2J4JJ3pctfOOm0cMdlYDarZPeo4VGXFQMe1K/7qMSZJGLUWbGwlR8pF2o/AGa JdIMxwWuv6DwmU7yt8YnwWYRuyScUPyBFJCqntcrlfIDDlB313fdSUpu55c5/c89 Nq6+OGWScN9hA5AGm6AeucGEs8g3aNuevKN+AA6BN0D1wuo+pvkdK+iI9MlNyYlD cB+i7+oluSb+UkNNcvz+PW0/3D0CJ12/nZfhOFsJCoplYzbuPJbZfI9eA/d9r8E3 YdDbN1/ofVAHLKx8Wy9LKqsGDb0pLFCTxc+jZhRkR87qf9qJ1OAb/DJHj7b9A0EC /xy5LoxAFF61yGZjK9dPllF/asJcJkm3074G+hfCG5NdlJdOzshQ6eSNZqwOSTOM 6TPfQNTkpGmFfuuKRYTQjjAC+rUO6rfD+OIA+02rhYuRA1d7bxQw/tZvhOA9ZwvT GVfpKHNnbG72euY8q9NMuamoImy1ivVdXkt1kkKKQkXi4UGwyRhS08Rf+JVfP5Zz rNNtFp8lAo/eo5C3P5vFGUMr/4hcvjnPV71ZjgN4dG4Gp/HWdUsXn09TUrr1xV27 gcDhB2QFu+vbuP4yG/+N =8/9U -END PGP SIGNATURE- -- 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] tablefunc extension
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/22/2013 04:17 PM, Joe Conway wrote: If you still have a problem please provide SQL that can be cut and pasted which: 1) create your table 2) insert sample rows Then show us what out put you are trying to acheive as output from that data. Oh, and switch to the pgsql-general list, as there is no evidence of any bug here. Joe - -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, 24x7 Support -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSP357AAoJEDfy90M199hlzyAP/1uVXwa9twDS6vB5EKiXbM6J FSrktrUzaQGA47onFZ6JKFjCSy4LIhaY7bev+VIW5m9hxVT5bNXe6uPqf6QT+pdK CevU7M29FUIB/ncF62aNYMIdjsM7yXqh+ppSQjqs2cs4jOWzn2BBxb1QCRezps2K sHwOi5VfqKGcl/7Za/aX6ojzNfssgi9YGWF20c7IHhhhNAlXOlw6ARmnv98lsaS/ tVIUuzibVjAD36f0v80lx3+oOVv9H4IMDKfcRQ/c+V5RlGvo6ZxUiJYxRre5GAcw 1SllJ46kyGXxdhIWkPKBxF8/4E+QMc1rOqlLrUgj3j/1Ymua0YNlIL70M9tBcPIJ idN/z+2jXYa8vHkLtpcjXTZGEhSEppCFOOw1sYEznqaSkVARabGptUsiKdGG8pll D0FvKVzJRQeKWxdP0q5LwTF5BSz9KILT9vKPHcMz0aN9ddf25oDv9B5gyQECRxEf BQYz0nULvz3YPAAaEIQRZehg6HBR7jM82dAu4Hnpm9la50rtmandefr9PliUMlXB N3kkpnFQGvFOJpbOAvpSYsaJ2PxjPErlxe/0R5aJVMnpq/4E+1WDNAzm907sIsyb raPFMY/0gEeqjVsZ2+o/fARj3FT1jlSkAKumo8Td0Q82bdisPgY7Bk6RqB3BDhEv ZERlQeMkTiWESjB46W+f =LUHW -END PGP SIGNATURE- -- 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] installation bug
Hi It seems the data directory was not created. Please send the installation logs from the %TEMP%. On Sat, Sep 21, 2013 at 3:39 PM, Ludvík Adamec ludvaju...@centrum.czwrote: Hello, I have tried to install postgresql many times, but every time i have in instalation error: Problem running post-install step. Installation may not completely correctly Error reading file C:/Program files(x86)/PostgreSQL/8.4/data/postgresql.conf I also tried different version of postgresql...also i tried to install in OpenGeo application pack.nothing works. Can you help me please? Thanks -- Sandeep Thakkar
Re: [BUGS] Known issues for PostgreSQL server 8.1.19
Hi Andres, Thanks for your reply. We can't upgrade to newer version as of now. We just want to know list of known issues on 8.1.19. We will just note them down and do some impact analysis. Regards, Anurag Dashputre -Original Message- From: Andres Freund [mailto:and...@2ndquadrant.com] Sent: Wednesday, September 18, 2013 8:28 PM To: Dashputre, Anurag (GE Healthcare) Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] Known issues for PostgreSQL server 8.1.19 Hi, On 2013-09-18 11:56:36 +, Dashputre, Anurag (GE Healthcare) wrote: We are using PostgreSQL server 8.1.19 in our product and as part of SDLC activities, we would like to know about the Known Issues present in this version. The primary issue - especially regarding lifecycle - is that 8.1 is out of support and thus unmaintained for more than 2 years. Check http://www.postgresql.org/support/versioning/ for details. The also have been several maintenance releases with important fixes in the 8.1 line since then. Greetings, Andres Freund -- Andres Freund 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] Known issues for PostgreSQL server 8.1.19
Dashputre, Anurag (GE Healthcare) wrote on 20.09.2013 08:39: Thanks for your reply. We can't upgrade to newer version as of now. We just want to know list of known issues on 8.1.19. We will just note them down and do some impact analysis. You will need to go through the release notes for every version after 8.1.19 and see what was fixed - those should be the open issues in your release. An upgrade to a new minor version (8.1.19 to 8.1.23) should never be a problem though. -- 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] Known issues for PostgreSQL server 8.1.19
On 9/20/2013 10:05 AM, Thomas Kellerer wrote: Dashputre, Anurag (GE Healthcare) wrote on 20.09.2013 08:39: Thanks for your reply. We can't upgrade to newer version as of now. We just want to know list of known issues on 8.1.19. We will just note them down and do some impact analysis. You will need to go through the release notes for every version after 8.1.19 and see what was fixed - those should be the open issues in your release. An upgrade to a new minor version (8.1.19 to 8.1.23) should never be a problem though. basically, start at E.100 here, http://www.postgresql.org/docs/9.3/static/release.html and read every release note newer than that. 8.1.19 was released in December 2009, about the same time as 8.2.15, 8.3.9, and 8.4.2, so when you did your code freeze on that version, there were already 3 newer major releases. the final 8.1 release, 8.1.23, was released in 2010-12-16 concurrently with 8.2.19, 8.3.13, 8.4.16, and 9.0.2. bug fixes after that date were not applied to 8.1, so you should probably also read all the release notes from 9.0.3 to 9.0.13, filtering them for features that were added after 8.1 (for instance, replication related bugs obviously aren't applicable to 8.1) I really really don't like to see that phrase, we can't upgrade to newer version. do you also run 5 year old operating systems that are unsupported and unpatched?sadly, this is all too common in the embedded world, where no planning consideration is given towards product maintenance and updating. -- john r pierce 37N 122W somewhere on the middle of the left coast -- 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] Installing/Upgrading PostgreSQL 9.1.6 to 9.3 known bugs?
On 9/20/2013 1:51 PM, fburg...@radiantblue.com wrote: 1.) During our prior upgrade process we used pg_upgrade to move from pg 8.4.3 to 9.1.6 using the hard links install option, we also have our data spread across disk storage mediums; fiber, nas. Are there any known issues, bugs with using pg_upgrade to move from 9.1.6 to pg 9.3? having multiple tablespaces on different mount points complicates things. I'm not sure how or if pg_upgrade handles that. -- john r pierce 37N 122W somewhere on the middle of the left coast
Re: [BUGS] Cant start PostgreSQL Using command prompt
On Tue, Sep 17, 2013 at 1:52 AM, Saravanan Nagarajan n.saravana...@gmail.com wrote: In pglog_txt, LOG: could not bind IPv6 socket: No error HINT: Is another postmaster already running on port 33307? If not, wait a few seconds and retry. LOG: could not bind IPv4 socket: No error HINT: Is another postmaster already running on port 33307? If not, wait a few seconds and retry. WARNING: could not create listen socket for localhost FATAL: could not create any TCP/IP sockets But already, i set ipv64 in pg_hba.conf file. My PostgreSQL Version : 9.2.1 This might be caused by something that changed on your Windows environment like the addition of a new software (Anti-virus)? Also, are you sure that your server is not running? Is there any process Postgres.exe listed if you run a simple command tasklist? -- Michael -- 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] Postgis extension bug w/ OpenBSD
On Tue, Sep 17, 2013 at 4:48 PM, Marcelo Bacha dro...@gmail.com wrote: I have an OpenBSD 5.3 server, with PostgreSQL 9.3.0, which seems to work fine. I´m trying to install on it, which always worked fine. Postgres is working fine as you mention, and only PostGIS development failed. Based on the information above which looks to be a library linking problem for your PostGIS installation, this problem is not related to PG. When I try to install the extension for Postgis 2.1.0, I get this error on psql: postgres=# CREATE EXTENSION postgis; ERROR: could not load library /usr/local/pgsql/lib/rtpostgis-2.2.so: dlopen (/usr/local/pgsql/lib/rtpostgis-2.2.so) failed: Cannot load specified object You mention that you are trying to install postgis 2.1, but rtpostgis-2.2.so is part of the PostGIS 2.2 bundle (version currently in development). So which one are you trying to install? The paths seems all to be OK: # ls -l /usr/local/pgsql/lib/*post* -rwxr-xr-x 1 root wheel 1276039 Jul 1 16:50 /usr/local/pgsql/lib/postgis-2.2.so -rwxr-xr-x 1 root wheel 1208861 Jul 1 16:50 /usr/local/pgsql/lib/rtpostgis-2.2.so When I try to preload the rtpostgis shared object setting the LD_PRELOAD environment variable, I get this info on psql: $ psql (...) psql:/usr/local/pgsql/lib/rtpostgis-2.2.so: undefined symbol 'CurrentMemoryContext' psql:/usr/local/pgsql/lib/rtpostgis-2.2.so: undefined symbol 'SPI_tuptable' psql:/usr/local/pgsql/lib/rtpostgis-2.2.so: undefined symbol 'SPI_result' psql:/usr/local/pgsql/lib/rtpostgis-2.2.so: undefined symbol 'InterruptPending' psql:/usr/local/pgsql/lib/rtpostgis-2.2.so: undefined symbol 'SPI_processed' psql (9.2.4) (...) In fact, I´ve been trying to solve this since a long time ago, and with many previous versions of both Postgresql and Postgis, but I´m really stuck Also, what is the output of this command? = ldd /usr/local/pgsql/lib/rtpostgis-2.2.so Are you sure that rtpostgis is linked to the necessary PG libs? -- Michael -- 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 #8452: COPY command pgadmin
On Sat, Sep 14, 2013 at 4:15 PM, kachwa...@hotmail.fr wrote: in short, for pgadmin... This feature request is related to PGAdmin and not Postgres core. You should send such requests to the PGAdmin mailing lists which are listed here: http://www.pgadmin.org/support/list.php Regards, -- Michael -- 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 #8449: ODBC Failure with Access 10
On Thu, Sep 12, 2013 at 10:21 AM, pulsack.he...@gmx.de wrote: Bug reference: 8449 I'm not able to link in Access to the table map. I get an ODBC error and in the table fields are no data, it returns #Name?. Any idea what is wrong ? You should be more precise here: - What is the version of ODBC driver used? - Could you provide a more complete test case or some code that can reproduce this error? Configuration used perhaps? It is going to be difficult to guess what are your problems with such a vague description. Also, this is a problem related to ODBC. So you should send such reports to pgsql-o...@postgresql.org and not this mailing list. Regards, -- Michael -- 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] Cant start PostgreSQL Using command prompt
Hi Michael Team, No anti-virus is running on that machine. I started the DB using Windows service. Its working fine. I am trying to start the DB with different user credentials using command prompt, the DB is not started. I provided full permission for everyone to postgres folder and its sub folder. On 19 September 2013 13:00, Michael Paquier michael.paqu...@gmail.comwrote: On Tue, Sep 17, 2013 at 1:52 AM, Saravanan Nagarajan n.saravana...@gmail.com wrote: In pglog_txt, LOG: could not bind IPv6 socket: No error HINT: Is another postmaster already running on port 33307? If not, wait a few seconds and retry. LOG: could not bind IPv4 socket: No error HINT: Is another postmaster already running on port 33307? If not, wait a few seconds and retry. WARNING: could not create listen socket for localhost FATAL: could not create any TCP/IP sockets But already, i set ipv64 in pg_hba.conf file. My PostgreSQL Version : 9.2.1 This might be caused by something that changed on your Windows environment like the addition of a new software (Anti-virus)? Also, are you sure that your server is not running? Is there any process Postgres.exe listed if you run a simple command tasklist? -- Michael -- Regards Saravanan.N. Ph: +91-9965003321 Twitter : twitter.com/#!/Saravanan221186/http://twitter.com/#%21/Saravanan221186/ First, be unique. Second, remember that 21st century India requires you to ‘work with integrity and succeed with integrity’. Third, the spirit of ‘What Can I Give’ shall replace the attitude of ‘What Can I Take’ — which is what causes greed, leading to problems like corruption, environmental degradation and moral turpitude. - Dr.A.P.J.Abdul Kalam
Re: [BUGS] Known issues for PostgreSQL server 8.1.19
Hi, On 2013-09-18 11:56:36 +, Dashputre, Anurag (GE Healthcare) wrote: We are using PostgreSQL server 8.1.19 in our product and as part of SDLC activities, we would like to know about the Known Issues present in this version. The primary issue - especially regarding lifecycle - is that 8.1 is out of support and thus unmaintained for more than 2 years. Check http://www.postgresql.org/support/versioning/ for details. The also have been several maintenance releases with important fixes in the 8.1 line since then. Greetings, Andres Freund -- Andres Freund 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 #8463: Packaging problem with postgis rpms
Hi, Thanks for the report. I created http://wiki.pgrpms.org/ticket/141 to track this bug. There is another critical ticket pending for RHEL 6 packages, so expect the new package pretty soon. Regards, Devrim On Wed, 2013-09-18 at 13:56 +, kyri...@alumni.princeton.edu wrote: The following bug has been logged on the website: Bug reference: 8463 Logged by: Kriton Kyrimis Email address: kyri...@alumni.princeton.edu PostgreSQL version: 9.2.4 Operating system: Scientific Linux 6.4 Description: (I am submitting this report here, as I assume that the rpms downloaded from yum.postgresql.org are built by postgresql and not by postgis.) The latest release of the postgis2_92* rpms (version 2.0.4) introduced a new package, postgis2_92-client, containing, among other things, the postgis shared library. This creates the problem that, after updating an existing system, the shared libraries disappear, and postgis stops working, producing the error postgis2_92-client-2.0.4-1 whenever a query involving postgis is executed. At the very least, the postgis2_92 package should depend on the postgis2_92-client package, so that updating the former will also install the latter, thus avoiding breaking existing systems. -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [BUGS] BUG #8458: Missing Fedora RPMs
Hi, On Mon, 2013-09-16 at 16:51 +, l...@cert.org wrote: The 9.3 non-RC1 RPMs are missing for Fedora 17 and 18 for i386. My bad, uploaded. If those will not be made available, I'd be happy to rebuild from source once you release the SRPM for 9.3 There are some build issues in Fedora 1718 i686, but SRPM is there, if you want to give it a try. Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [BUGS] Cant start PostgreSQL Using command prompt
In pglog_txt, LOG: could not bind IPv6 socket: No error HINT: Is another postmaster already running on port 33307? If not, wait a few seconds and retry. LOG: could not bind IPv4 socket: No error HINT: Is another postmaster already running on port 33307? If not, wait a few seconds and retry. WARNING: could not create listen socket for localhost FATAL: could not create any TCP/IP sockets But already, i set ipv64 in pg_hba.conf file. My PostgreSQL Version : 9.2.1 -- Saravanan . On 11 September 2013 18:31, Michael Paquier michael.paqu...@gmail.comwrote: On Wed, Sep 11, 2013 at 4:00 AM, Saravanan Nagarajan n.saravana...@gmail.com wrote: Hi, I am using PostgreSQL. If am starting the db with System Account/ any domain account using wrapper, the DB is starting fine. If i am trying to start the PostgreSQL DB using command prompt, [Normal mode or Run as administrator.], It wont start. I provided full permission for everyone in Postgres DB Folder. I didn't find any error in pg_log file. I installed DB in 2008 R2 windows machine. My command : pg_ctl -D ..\data -o -p3306 --log D:\logs\pglog.txt start What is exactly the version of Postgres you are trying to use? What is the output of D:\logs\pglog.txt? -- Michael
Re: [BUGS] BUG #8453: uninitialized memory access in pg_receivexlog and other bugs
On 15.09.2013 15:02, and...@tao11.riddles.org.uk wrote:
The following bug has been logged on the website:
Bug reference: 8453
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: 9.3.0
Operating system: any
Description:
The first snprintf in writeTimeLineHistoryFile in receivelog.c accesses
uninitialized data in the path variable, thus creating the .tmp file in a
random place (usually the current dir, leading to unexpected EXDEV errors on
the rename).
Ouch, that was a silly bug!
Also, receivexlog is ignoring .partial and .history files when determining
which timeline to start streaming from, which means that if there are two
timeline changes that are not separated by a WAL segment switch, it will
fail to operate due to attempting to start from a too-old timeline (for
which xlogs are not available on the server).
There's nothing we can do with .history files here. The point is to find
out how far we have already received WAL, and the presence of a .history
file doesn't tell you anything about that.
There is a comment about .partial files though:
/*
* Check if the filename looks like an xlog file, or a .partial
file.
* Xlog files are always 24 characters, and .partial files are
32
* characters.
*/
if (strlen(dirent-d_name) != 24 ||
strspn(dirent-d_name, 0123456789ABCDEF) != 24)
continue;
The comment says that .partial files are taken into account, but the
code doesn't match the comment.
Attached is a patch to fix both of these issues. I'm too tired right now
to thoroughly test it and commit, so I'll get back to this tomorrow.
Meanwhile, please take a look and let me know if you can see something
wrong.
- Heikki
diff --git a/src/bin/pg_basebackup/pg_receivexlog.c b/src/bin/pg_basebackup/pg_receivexlog.c
index 787a395..ca89438 100644
--- a/src/bin/pg_basebackup/pg_receivexlog.c
+++ b/src/bin/pg_basebackup/pg_receivexlog.c
@@ -121,6 +121,7 @@ FindStreamingStart(uint32 *tli)
struct dirent *dirent;
XLogSegNo high_segno = 0;
uint32 high_tli = 0;
+ bool high_ispartial = false;
dir = opendir(basedir);
if (dir == NULL)
@@ -132,20 +133,33 @@ FindStreamingStart(uint32 *tli)
while ((dirent = readdir(dir)) != NULL)
{
- char fullpath[MAXPGPATH];
- struct stat statbuf;
uint32 tli;
unsigned int log,
seg;
XLogSegNo segno;
+ bool ispartial;
/*
* Check if the filename looks like an xlog file, or a .partial file.
* Xlog files are always 24 characters, and .partial files are 32
* characters.
*/
- if (strlen(dirent-d_name) != 24 ||
- strspn(dirent-d_name, 0123456789ABCDEF) != 24)
+ if (strlen(dirent-d_name) == 24)
+ {
+ if (strspn(dirent-d_name, 0123456789ABCDEF) != 24)
+continue;
+ ispartial = false;
+ }
+ else if (strlen(dirent-d_name) == 32)
+ {
+ if (strspn(dirent-d_name, 0123456789ABCDEF) != 24)
+continue;
+ if (strcmp(dirent-d_name[24], .partial) != 0)
+continue;
+
+ ispartial = true;
+ }
+ else
continue;
/*
@@ -160,31 +174,40 @@ FindStreamingStart(uint32 *tli)
}
segno = ((uint64) log) 32 | seg;
- /* Check if this is a completed segment or not */
- snprintf(fullpath, sizeof(fullpath), %s/%s, basedir, dirent-d_name);
- if (stat(fullpath, statbuf) != 0)
+ /*
+ * Check that the segment has the right size, if it's supposed to be
+ * completed.
+ */
+ if (!ispartial)
{
- fprintf(stderr, _(%s: could not stat file \%s\: %s\n),
- progname, fullpath, strerror(errno));
- disconnect_and_exit(1);
- }
+ struct stat statbuf;
+ char fullpath[MAXPGPATH];
- if (statbuf.st_size == XLOG_SEG_SIZE)
- {
- /* Completed segment */
- if (segno high_segno || (segno == high_segno tli high_tli))
+ snprintf(fullpath, sizeof(fullpath), %s/%s, basedir, dirent-d_name);
+ if (stat(fullpath, statbuf) != 0)
+ {
+fprintf(stderr, _(%s: could not stat file \%s\: %s\n),
+ progname, fullpath, strerror(errno));
+disconnect_and_exit(1);
+ }
+
+ if (statbuf.st_size != XLOG_SEG_SIZE)
{
-high_segno = segno;
-high_tli = tli;
+fprintf(stderr,
+ _(%s: segment file \%s\ has incorrect size %d, skipping\n),
+ progname, dirent-d_name, (int) statbuf.st_size);
continue;
}
}
- else
+
+ /* Looks like a valid segment. Remember that we saw it */
+ if ((segno high_segno) ||
+ (segno == high_segno tli high_tli) ||
+ (segno == high_segno tli == high_tli high_ispartial !ispartial))
{
- fprintf(stderr,
- _(%s: segment file \%s\ has incorrect size %d, skipping\n),
- progname, dirent-d_name, (int) statbuf.st_size);
- continue;
+ high_segno = segno;
+ high_tli = tli;
+ high_ispartial = ispartial;
}
}
@@ -195,10 +218,12 @@ FindStreamingStart(uint32 *tli)
XLogRecPtr high_ptr;
/*
- * Move the starting
Re: [BUGS] BUG #8453: uninitialized memory access in pg_receivexlog and other bugs
Heikki == Heikki Linnakangas hlinnakan...@vmware.com writes: Also, receivexlog is ignoring .partial and .history files when determining which timeline to start streaming from, which means that if there are two timeline changes that are not separated by a WAL segment switch, it will fail to operate due to attempting to start from a too-old timeline (for which xlogs are not available on the server). Heikki There's nothing we can do with .history files here. The point Heikki is to find out how far we have already received WAL, and the Heikki presence of a .history file doesn't tell you anything about Heikki that. I was thinking that the presence of a history file might at least be useful for setting a bound on what TLI we're going to use; but if a possible .partial file is taken into account the issue should be moot anyway I guess. Heikki Attached is a patch to fix both of these issues. I'm too Heikki tired right now to thoroughly test it and commit, so I'll get Heikki back to this tomorrow. Meanwhile, please take a look and let Heikki me know if you can see something wrong. A quick eyeball check looks ok; I'll see about reproducing the original scenario with this patch applied. -- Andrew (irc:RhodiumToad) -- 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 #8451: quantile extension: memory corruption?
On 14.9.2013 14:12, Tomas Vondra wrote: On 13.9.2013 18:07, stephane.wust...@lip6.fr wrote: The following bug has been logged on the website: Bug reference: 8451 Logged by: strexxx Email address: stephane.wust...@lip6.fr PostgreSQL version: 9.1.9 Operating system: Linux 3.8.0-27-generic #40-Ubuntu SMP x86_64 Description: A query such as this one COPY (SELECT e,quantile(EXTRACT(EPOCH FROM(d)),ARRAY[0,0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1]) AS d FROM (SELECT e,max(time)-min(time) AS d FROM bb RIGHT JOIN (SELECT s,e FROM ss RIGHT JOIN (SELECT e FROM ee WHERE h ~* 'blah') AS i0 USING(e)) AS i0 USING (sessionid) GROUP BY e,ei) AS i1 GROUP BY e) TO 'full_path/d.csv' WITH CSV; Hi, this seems like a bug in the quantile extension, which is developed and distributed completely separately from PostgreSQL. So pgsql-bugs is not the right place to report the issue. I reported the issue on github and I'll look into that today/tomorrow https://github.com/tvondra/quantile/issues/4 so far it seems like a trivial bug in handling NULL values. And indeed it was a bug in handling NULL values - the PG_ARGISNULL happened too late. I plan to do few more improvements before pushing new version to pgxn, but you may grab the sources from github directly. Tomas -- 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 #8451: quantile extension: memory corruption?
On 13.9.2013 18:07, stephane.wust...@lip6.fr wrote: The following bug has been logged on the website: Bug reference: 8451 Logged by: strexxx Email address: stephane.wust...@lip6.fr PostgreSQL version: 9.1.9 Operating system: Linux 3.8.0-27-generic #40-Ubuntu SMP x86_64 Description: A query such as this one COPY (SELECT e,quantile(EXTRACT(EPOCH FROM(d)),ARRAY[0,0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1]) AS d FROM (SELECT e,max(time)-min(time) AS d FROM bb RIGHT JOIN (SELECT s,e FROM ss RIGHT JOIN (SELECT e FROM ee WHERE h ~* 'blah') AS i0 USING(e)) AS i0 USING (sessionid) GROUP BY e,ei) AS i1 GROUP BY e) TO 'full_path/d.csv' WITH CSV; Hi, this seems like a bug in the quantile extension, which is developed and distributed completely separately from PostgreSQL. So pgsql-bugs is not the right place to report the issue. I reported the issue on github and I'll look into that today/tomorrow https://github.com/tvondra/quantile/issues/4 so far it seems like a trivial bug in handling NULL values. regards Tomas -- 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] Re: BUG #8444: ERROR: table name tblb specified more than once in subquery
David Johnston pol...@yahoo.com writes: Here is a minimal query that demonstrates the problem. In 9.1 it works: chris=# select * FROM current_user u join (current_user u cross join current_user v) x on true; On 9.3 it fails: ERROR: table name u specified more than once This is an intentional change that came in with the LATERAL feature. The query is illegal per SQL spec but we used to allow it anyway, on the theory that the table name u inside the aliased join x wasn't visible anywhere that the other u was visible, so the duplicate alias name was harmless. But in the presence of LATERAL it's not harmless; consider select * FROM current_user u join (current_user u cross join LATERAL (select u.x) v) x on true; Which instance of u does the lateral reference refer to? (I think there was some discussion of this in the pgsql-hackers list about a year ago, but I couldn't find it in a desultory search.) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Cant start PostgreSQL Using command prompt
John R Pierce, 11.09.2013 19:19: btw, afaik Windows command prompt has no idea what means. No, that's not true. See here for example: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds_shelloverview.mspx?mfr=true -- 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 #8447: With table inheritance, indexes seems to be ignored when looking over indexed fields in base table
stormb...@gmail.com stormb...@gmail.com wrote: [ Seq Scan is used on empty relation, rather than Index Scan ] This is not the expected result. [ ... ] it is still using sequential scan rather than what would be expected: Index Scan This is not a bug. If statistics indicate that all rows can be accessed with one page access (to the heap) why should it use an index? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Cant start PostgreSQL Using command prompt
On Wed, Sep 11, 2013 at 4:00 AM, Saravanan Nagarajan n.saravana...@gmail.com wrote: Hi, I am using PostgreSQL. If am starting the db with System Account/ any domain account using wrapper, the DB is starting fine. If i am trying to start the PostgreSQL DB using command prompt, [Normal mode or Run as administrator.], It wont start. I provided full permission for everyone in Postgres DB Folder. I didn't find any error in pg_log file. I installed DB in 2008 R2 windows machine. My command : pg_ctl -D ..\data -o -p3306 --log D:\logs\pglog.txt start What is exactly the version of Postgres you are trying to use? What is the output of D:\logs\pglog.txt? -- Michael -- 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 by restore a database
On Mon, Sep 9, 2013 at 11:38 PM, Sbis-Partner sbis-part...@mail.ru wrote: Hello! When you restore a database error occurs «Pg_restore: creating TABLE dbschema pg_restore: [archiver (db)] Error from TOC entry 1428; 1259 83487 TABLE dbschema User pg_restore: [archiver (db)] could not execute query: ERROR: role User does not exist Command was: ALTER TABLE public.dbschema OWNER TO User ». User and group information are missing in your dump, this information can be retrieved with pg_dumpall. There are two possibilities in your case: - Use the dump you created previously and complete it with data from pg_dumpall --globals-only containing only user and tablespace information - Use a global dump with pg_dumpall with the user information as well as the database The latter solution is more instinctive IMO, but the former solution will work fine as well. -- Michael -- 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 #8440: sevices not started automatically
On Mon, Sep 9, 2013 at 12:55 AM, sabat.jitendr...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 8440 Logged by: Jitendra Sabat Email address: sabat.jitendr...@gmail.com PostgreSQL version: Unsupported/Unknown Operating system: Window server 2012 Description: Currently i am running postgres8.3 but its services is not started automatically when I start the system. I have tried manually start everyday. But sometime it stopped automatically. Note that 8.3 is EOL since February 2013 and is not actually supported by community anymore. So in your case you should consider an upgrade to the latest minor release of 8.3 (you didn't provide which version you are using exactly), or an upgrade to a latest version. It is however hard to have an idea of what is causing your server to stop if you do not provide more information like the startup logs. -- Michael -- 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 #8443: duplicated oids after dump
On 2013-09-11 12:07:25 +, b.rychtar...@teb-akademia.pl wrote: executed full dump of database without oids: pg_dump -v -a -E UTF8 --disable-dollar-quoting --disable-triggers after restoring database from dump in each table there are rows with duplicated oids So, just to make sure I understand you correctly: You dumped a database in a form that doesn't contain oids, loaded it into a new one where the preexisting schema uses oids in user tables? After loading that data there were duplicate oids? * Do you have a unique constraint over the oid columns? * Was there any preexisting data? * Were there any concurrent inserts? * Are the duplicates rows in the same relation or in different ones? * How many records do exist in the restore you made? Greetings, Andres Freund -- Andres Freund 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] Cant start PostgreSQL Using command prompt
On 9/11/2013 4:00 AM, Saravanan Nagarajan wrote: I am using PostgreSQL. If am starting the db with System Account/ any domain account using wrapper, the DB is starting fine. If i am trying to start the PostgreSQL DB using command prompt, [Normal mode or Run as administrator.], It wont start. I provided full permission for everyone in Postgres DB Folder. I didn't find any error in pg_log file. I installed DB in 2008 R2 windows machine. My command : *pg_ctl -D ..\data -o -p3306 --log D:\logs\pglog.txt start * * * NET START postgres service name btw, afaik Windows command prompt has no idea what means. -- john r pierce 37N 122W somewhere on the middle of the left coast
Re: [BUGS] Error by restore a database
On 9/9/2013 11:38 PM, Sbis-Partner wrote: When you restore a database error occurs «Pg_restore: creating TABLE dbschema pg_restore: [archiver (db)] Error from TOC entry 1428; 1259 83487 TABLE dbschema User pg_restore: [archiver (db)] could not execute query: ERROR: role User does not exist Command was: ALTER TABLE public.dbschema OWNER TO User ». Please help me to solve this problem. users are not stored as part of a single database, they are global to the database cluster. you need to create any users required by a given database before you can restore it. CREATE USER User WITH PASSWORD 'somekindapassword'; Note the same is true for tablespaces, if you use those. -- john r pierce 37N 122W somewhere on the middle of the left coast
