Re: [BUGS] BUG #8271: Configure warning: sys/ucred.h: present but cannot be compiled
Hi, On 2013-06-30 15:17:20 +0200, Andres Freund wrote: On 2013-06-30 15:11:24 +0300, Emre Hasegeli wrote: 2013/6/30 Andres Freund and...@2ndquadrant.com: On 2013-06-30 10:43:49 +, e...@hasegeli.com wrote: Could you attach config.log? Attached. This seems to be caused by be4585b1c27ac5dbdd0d61740d18f7ad9a00e268. The fault imo lies with openbsd which doesn't include the prerequisite sys/param.h header which defines NGROUPS: http://fxr.watson.org/fxr/source/sys/ucred.h?v=OPENBSD The other BSD flavors seems to get that right. Before that commit the checks for cmsgcred which includes sys/ucred.h happened to include params.h... Patch attached, missing the configure update since I don't have a compatible autoconf on my laptop, to produce a minimal diff. Could somebody apply the fix (including regenerating /configure)? 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 #8271: Configure warning: sys/ucred.h: present but cannot be compiled
Andres Freund and...@2ndquadrant.com writes: Before that commit the checks for cmsgcred which includes sys/ucred.h happened to include params.h... Patch attached, missing the configure update since I don't have a compatible autoconf on my laptop, to produce a minimal diff. Could somebody apply the fix (including regenerating /configure)? The proposed patch seems a bit overcomplicated --- isn't the real problem that I changed the ordering of the header probes in be4585b1c27ac5dbdd0d61740d18f7ad9a00e268? I think I just alphabetized them in a fit of neatnik-ism, not realizing that there were order dependencies on some platforms. 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 #8271: Configure warning: sys/ucred.h: present but cannot be compiled
On 2013-07-25 09:48:31 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: Before that commit the checks for cmsgcred which includes sys/ucred.h happened to include params.h... Patch attached, missing the configure update since I don't have a compatible autoconf on my laptop, to produce a minimal diff. Could somebody apply the fix (including regenerating /configure)? The proposed patch seems a bit overcomplicated --- isn't the real problem that I changed the ordering of the header probes in be4585b1c27ac5dbdd0d61740d18f7ad9a00e268? I think I just alphabetized them in a fit of neatnik-ism, not realizing that there were order dependencies on some platforms. Hm. It very well might be too complicated. I am not exactly a autoconf expert... The problem is that you can't include sys/ucred.h on some platforms (e.g. openbsd) without first including sys/params.h because the resulting file won't compile. Unless I misunderstood what you propose a different order in that AC_CHECK_HEADERS() shouldn't help getting it there? Maybe we could get rid of the two separate tests that now use HAVE_SYS_PARAM_H - I just tried to followed the surrounding patterns. FWIW I have confirmation via private emails that the patch works at least on openbsd... 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 #8271: Configure warning: sys/ucred.h: present but cannot be compiled
Andres Freund and...@2ndquadrant.com writes: On 2013-07-25 09:48:31 -0400, Tom Lane wrote: The proposed patch seems a bit overcomplicated --- isn't the real problem that I changed the ordering of the header probes in be4585b1c27ac5dbdd0d61740d18f7ad9a00e268? I think I just alphabetized them in a fit of neatnik-ism, not realizing that there were order dependencies on some platforms. Hm. It very well might be too complicated. I am not exactly a autoconf expert... Ah, I was thinking that AC_CHECK_HEADERS would include the previously-found headers when checking a particular item, but a bit of research says that's not so. So we do indeed need something like this. Will take care of it. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8271: Configure warning: sys/ucred.h: present but cannot be compiled
On 07/25/2013 09:48 AM, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: Before that commit the checks for cmsgcred which includes sys/ucred.h happened to include params.h... Patch attached, missing the configure update since I don't have a compatible autoconf on my laptop, to produce a minimal diff. Could somebody apply the fix (including regenerating /configure)? The proposed patch seems a bit overcomplicated --- isn't the real problem that I changed the ordering of the header probes in be4585b1c27ac5dbdd0d61740d18f7ad9a00e268? I think I just alphabetized them in a fit of neatnik-ism, not realizing that there were order dependencies on some platforms. It looks to me like you didn't reorder anything, you added a test for sys/ucred.h. I haven't seen the proposed patch, though. cheers andrew -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8330: Accessing Postgres database on iOS Application
The following bug has been logged on the website: Bug reference: 8330 Logged by: Prateek Kansara Email address: prat...@kansara.in PostgreSQL version: 9.2.4 Operating system: iOS Description: Respected Sir/madam, I am working on an application for iPad which will access database from a PostgreSQL Server. I have checked your documentation on PostgreSQL for iOS and even tried with the application. But I get a linker error with the new Xcode 4.6.3 and many more errors. Other errors are just the ARC errors. I want to know if you can help me with the linking problem or if you can provide with the update of this program. so I can use it in my application. Thanks for your help! Please look into my query. -- 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 #8271: Configure warning: sys/ucred.h: present but cannot be compiled
Andres Freund and...@2ndquadrant.com writes: The problem is that you can't include sys/ucred.h on some platforms (e.g. openbsd) without first including sys/params.h because the resulting file won't compile. BTW, after committing this I re-reviewed the thread and realized that actually this problem is strictly cosmetic. The net effect of the configure bug is is that it (1) doesn't set HAVE_SYS_UCRED_H and as a consequence (2) doesn't set HAVE_STRUCT_CMSGCRED. However, that's only examined in one place in libpq, which says: * Note: this is dead code as of Postgres 9.1, because current backends will * never send this challenge. But we must keep it as long as libpq needs to * interoperate with pre-9.1 servers. It is believed to be needed only on * Debian/kFreeBSD (ie, FreeBSD kernel with Linux userland, so that the * getpeereid() function isn't provided by libc). So on an OpenBSD build that code wouldn't be used anyway (not even when talking to a pre-9.1 server, if I'm interpreting the comment correctly). 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
[BUGS] BUG #8333: Conversions from TEXT to range types are not immutable
The following bug has been logged on the website:
Bug reference: 8333
Logged by: Alex Bolenok
Email address: quass...@gmail.com
PostgreSQL version: 9.2.4
Operating system: Fedora 19
Description:
SET lc_messages TO 'en_US.UTF-8';
DROP TABLE IF EXISTS
mytable;
CREATE TABLE
mytable
(
id INT NOT NULL PRIMARY KEY,
vtext TEXT NOT NULL,
vrange INT8RANGE NOT NULL
);
INSERT
INTOmytable
SELECT 1, t, t::INT8RANGE
FROM(
VALUES
('[1, 10]')
) q(t);
CREATE INDEX
ix_mytable_vrange
ON mytable
USING GIST (vrange);
CREATE INDEX
ix_mytable_vtext
ON mytable
USING GIST ((vtext::INT8RANGE));
--
SET
DROP TABLE
psql:stdin:12: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
index mytable_pkey for table mytable
CREATE TABLE
INSERT 0 1
CREATE INDEX
psql:stdin:30: ERROR: functions in index expression must be marked
IMMUTABLE
--
I expected the second index to be created as well.
--
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 #8271: Configure warning: sys/ucred.h: present but cannot be compiled
On 2013-07-25 11:50:47 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: The problem is that you can't include sys/ucred.h on some platforms (e.g. openbsd) without first including sys/params.h because the resulting file won't compile. BTW, after committing this I re-reviewed the thread and realized that actually this problem is strictly cosmetic. The net effect of the configure bug is is that it (1) doesn't set HAVE_SYS_UCRED_H and as a consequence (2) doesn't set HAVE_STRUCT_CMSGCRED. Yes, I've commented on that upthread. The cosmetics are worth fixing though, since I've posted in this thread several people mailed me because they thought this was the cause of actually unrelated problems... The last mail was what reminded me of the patch today ;) So on an OpenBSD build that code wouldn't be used anyway (not even when talking to a pre-9.1 server, if I'm interpreting the comment correctly). As far as I understood it, it wouldn't be used as long as you're not talking to a server on another platform that supports AUTH_REQ_SCM_CREDS serverside. Which is pretty unlikely, I grant you that ;) Not that it really matters, but I am slightly doubtful about the kfreebsd only claim. Given the age of that code relative do kfreebsd there at least had to be some more platforms needing that codepath at some point. 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 #8271: Configure warning: sys/ucred.h: present but cannot be compiled
Andres Freund and...@2ndquadrant.com writes: On 2013-07-25 11:50:47 -0400, Tom Lane wrote: So on an OpenBSD build that code wouldn't be used anyway (not even when talking to a pre-9.1 server, if I'm interpreting the comment correctly). As far as I understood it, it wouldn't be used as long as you're not talking to a server on another platform that supports AUTH_REQ_SCM_CREDS serverside. Which is pretty unlikely, I grant you that ;) But SCM_CREDS is only relevant to Unix-socket connections, so the server has to be under the same kernel as the client. Not that it really matters, but I am slightly doubtful about the kfreebsd only claim. Given the age of that code relative do kfreebsd there at least had to be some more platforms needing that codepath at some point. Of course. There's some historical context in the commit message for be4585b1c27ac5dbdd0d61740d18f7ad9a00e268 --- basically the point is that kfreebsd was the last live platform on which we'd use credentials messages. 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
[BUGS] BUG #8334: Merge Join drops records
The following bug has been logged on the website: Bug reference: 8334 Logged by: Euclid Nikiforov Email address: euc...@yandex-team.ru PostgreSQL version: 9.2.0 Operating system: Linux 3.8.0-11-na Description: Hi all Recently investigating problem in our backend query result, I have found strange behaviour. The exact query was: SELECT r.*, state FROM revision.object_revision r JOIN revision.commit ON id IN (32397,32403,32404) AND commit_id=id WHERE ((commit_id=32397 AND (object_id=279638691 OR object_id=279638692)) OR (commit_id=32403 AND object_id IN (279638118,279638128,279638970)) OR (commit_id=32404 AND object_id=279638966)); It expected to return 6 rows, but returned only 3 when enable_mergejoin is 'on' EXPLAIN ANALYZE shows Merge Join at final stage while with Nested Loop (set enable_mergejoin=off;) everything is fine. Since data is very huge, here is small synthetic way to reproduce the behaviuor In actual environment we don't set any restrictions on planner. If you manipulate enable_mergejoin or enable_sort, you will see how results differ. Seems that merge join fails because of unsorted result from inner loops Regards Euclid -EXAMPLE SET enable_mergejoin=on; SET enable_nestloop=off; SET enable_hashjoin=off; SET enable_seqscan=off; SET enable_sort=off; CREATE TABLE testcase.c ( id bigint NOT NULL UNIQUE, s bigint, CONSTRAINT cpk PRIMARY KEY (id) ); CREATE TABLE testcase.r ( c_id bigint NOT NULL, o_id bigint NOT NULL, CONSTRAINT rpk PRIMARY KEY (c_id, o_id) ); CREATE INDEX rpkc ON testcase.r USING btree (c_id); DELETE FROM testcase.c; INSERT INTO testcase.c values(1,0); INSERT INTO testcase.c values(2,0); INSERT INTO testcase.c values(3,0); DELETE FROM testcase.r; INSERT INTO testcase.r values(1,1); INSERT INTO testcase.r values(2,2); INSERT INTO testcase.r values(2,3); INSERT INTO testcase.r values(3,4); INSERT INTO testcase.r values(3,5); INSERT INTO testcase.r values(3,6); SELECT s, r.* FROM testcase.r r JOIN testcase.c ON id IN (1, 2, 3) AND id=r.c_id WHERE ((c_id=2 AND (o_id=2 OR o_id=3)) OR (c_id=3 AND o_id in (4,5,6)) OR (c_id=1 AND o_id=1)) -- 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 #8334: Merge Join drops records
On Thu, Jul 25, 2013 at 9:46 PM, euc...@yandex-team.ru wrote: The following bug has been logged on the website: Bug reference: 8334 Logged by: Euclid Nikiforov Email address: euc...@yandex-team.ru PostgreSQL version: 9.2.0 Did you try updating to the latest minor release ? I can not reproduce this on the latest minor release of 9.2 branch. There seem to be a fix which could be related to this: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f2366e584aea41b980f23fcf0a2e118efd7fb09b Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee
[BUGS] pgsql 8.4 not + is contained by operators return wrong result
*Description:* By pgsql 8.4 I have the following bug: If the haystack array is null (for example by empty result of array_agg) by is contained by, and you use it with negation, the the result is false instead of true. *Reproduce:* The following query returns nothing, but it should return 1. *SELECT 1 FROM NOT(ARRAY[1] @ NULL**); * *Workaround:* *SELECT 1 FROM (haystack IS NULL OR NOT(ARRAY[1] @ **haystack**)); *
Re: [BUGS] pgsql 8.4 not + is contained by operators return wrong result
=?ISO-8859-1?Q?L=E1szl=F3_Lajos_J=E1nszky?= laszlo.jans...@gmail.com writes: The following query returns nothing, but it should return 1. *SELECT 1 FROM NOT(ARRAY[1] @ NULL**); * I assume you meant SELECT 1 WHERE NOT(ARRAY[1] @ NULL) ? Because what you wrote doesn't parse. This is not a bug. ARRAY[1] @ NULL yields NULL. NOT (NULL) is still NULL. WHERE treats a NULL result as FALSE. It might help you to consider that NULL means unknown. It does not mean empty array. 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
[BUGS] BUG #8335: trim() un-document behaviour
The following bug has been logged on the website: Bug reference: 8335 Logged by: Jov Email address: am...@amutu.com PostgreSQL version: 9.2.4 Operating system: suse 10 linux 64 Description: in the postgresql doc 9.4,I find the trim() function like this: trim([leading | trailing | both] [characters] from string) so the trim should be pass only one argument with some optional prefix。but I find the following calls with two argument is successfull but the results is unexpected and wired： ##first call postgres=# select trim(trailing ‘/’, ‘fasd/’); rtrim ——- (1 row) -!!!note: it return titile is rtrim ## second call postgres=# select trim(‘/’, ‘fasd/’) ; btrim ——- (1 row) -!!!note: it return titile is btrim it seems trim is transform to r、b、l trim internal，but the above call should return error or it may produce un-expect results -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
