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] 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] 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] BUG #8441: Recursive function in plpgsql does not seem to handle null values correctly
tv...@davincigroep.nl writes: CREATE OR REPLACE FUNCTION longlevenshtein (string1 character varying (100), string2 character varying (100)) RETURNS integer AS $$ BEGIN IF (length(coalesce($1, '')) = 0 AND length(coalesce($2, '')) = 0) THEN RETURN 0; ELSEIF ($1 IS NULL and $2 IS NOT NULL and length($2) 0) THEN RETURN length($2); ELSEIF ($2 IS NULL and $1 IS NOT NULL and length($1) 0) THEN RETURN length($1); ELSEIF length($1) = 0 AND length(coalesce($2, '')) 0 THEN RETURN length(coalesce($2, '')); ELSEIF length($1) 0 AND (length($2) = 0 or $2 is null) THEN RETURN length(coalesce($1, '')); ELSE RETURN (Levenshtein(SUBSTRING($1 FROM 1 FOR 254), SUBSTRING($2 FROM 1 for 254)) + longlevenshtein(coalesce(SUBSTRING($1 FROM 255), ''), coalesce(SUBSTRING($2 FROM 255), ''))); END IF; END; $$ LANGUAGE plpgsql; When I invoke this function with SELECT longlevenshtein(null, 'foobar') I get a ERROR: stack depth limit exceeded Worksforme. You sure you transcribed the function accurately? Note however that sufficiently long input strings *will* drive this function to stack overrun, if you don't run out of heap memory first (I think the heap consumption will be O(N^2) ...). Consider rewriting it with a loop rather than recursion. 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 #8435: PGAdmin backup: obect list missing objects
marta.mih...@dal.ca writes: Using the backup option (right click on an object) and then selecting the Objects tab: Not all objects appears in the list. This is true for versions 1.14.3 and the most recent version 1.16.1 downloaded today. I have a database called otn with over 100 schema. I wish to back up several tables from one schema, but that schema called pgs does not appear in the list of schema. When I change the name of the schema to psg then it does appear. You should probably report this on the pgadmin mailing list, I'm not sure how many of those folk read the core-server bug list. I would expect PGAdmin to hide schemas beginning with pg_, since those are reserved as system schema names. It sounds like someone got the test wrong and is checking for just pg not pg_. I'm suspicious there's a LIKE test coded as LIKE 'pg_%', which is wrong because _ is a metacharacter in LIKE patterns ... 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 #8436: Heisenbug: random: relation XXX does not exist on 3 tables/views
qwe...@hi.is writes: Just a few days ago we started randomly getting: relation th_thjoderni does not exist You haven't really provided any information about what changed around the time this started happening. What I'd wonder about is concurrent DDL on these tables --- perhaps you added some kind of background maintenance task that wasn't there before? You might try enabling query logging (log_statement = all) to see exactly what's happening at the time you get one of these errors. 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 #8410: out of binary heap slots
Andres Freund and...@2ndquadrant.com writes: No need, found the bug. And I think can build a testcase myself. ExecReScanMergeAppend resets ms_initialized, but doesn't clear the binaryheap. Thus no new elements fit. Sounds like a bug all right, but I'm not convinced it explains Terje's report. The thing this theory doesn't explain is why would Terje be having trouble reproducing the failure? Seems like re-running the same query ought to produce the same failure. 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 #8410: out of binary heap slots
Andres Freund and...@2ndquadrant.com writes: Terje, do you use read committed or repeatable read/serializable? Or even more to the point, can you apply the just-posted patch and see if the problem goes away for you? 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 #8410: out of binary heap slots
Andres Freund and...@2ndquadrant.com writes: On 2013-08-30 23:05:25 +0200, Andres Freund wrote: ExecReScanMergeAppend resets ms_initialized, but doesn't clear the binaryheap. Thus no new elements fit. Ok, patch for that attached. I think the comments need a bit of copy-editing, but looks good otherwise. Will fix and commit. Should we add SELECT (SELECT g.i FROM ((SELECT random()::int ORDER BY 1 OFFSET 0) UNION ALL (SELECT random()::int ORDER BY 1 OFFSET 0)) f(i) ORDER BY f.i LIMIT 1) FROM generate_series(1, 10) g(i); as a regression test? I slightly on the no side... Not sure. It's pretty disturbing that this wasn't caught earlier; it seems to me that means there's no regression coverage that hits ExecReScanMergeAppend. However, I don't much like this specific test case because it seems like hitting the bug could depend on what series of random values you get. 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 #8410: out of binary heap slots
Andres Freund and...@2ndquadrant.com writes: On 2013-08-30 18:55:53 -0400, Tom Lane wrote: Not sure. It's pretty disturbing that this wasn't caught earlier; it seems to me that means there's no regression coverage that hits ExecReScanMergeAppend. However, I don't much like this specific test case because it seems like hitting the bug could depend on what series of random values you get. Hm, that should be fixable. How about: Looks good, applied. 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 #8410: out of binary heap slots
Andres Freund and...@2ndquadrant.com writes: On second thought, it might not be so good looking - the queries results are independent of the data from merge-append. So we only check that we don't crash and not that the results make any sense. How about the attached patch? Good point --- pushed. 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 #8396: Window function results differ when selecting from table and view, with where clause
p...@weotta.com writes: When I select from a view, the where clause in my select statement does not restrict the rows processed by window functions referenced inside the view definition. Thus, if window functions are involved, using a where clause when selecting from a view and using a where clause when selecting directly from the underlying table produces different results. I don't see anything even a little bit surprising about this. A WHERE clause applied to a view should hide some rows that would appear in the view output without it, but it should certainly never change the contents of the rows it does let through. Now, if you put the WHERE clause before the window functions (and WHERE is semantically prior to the evaluation of a SELECT list at the same syntactic level), then the WHERE clause does filter the rows before the window functions see 'em. But a WHERE clause supplied at an outer syntactic level acts after the window functions are processed. Another way to put it is that your query with the view is equivalent to select * from ( select plant_id as plant_id , row_number() over ( partition by city order by plant_id ) as plant_number , count(*) over ( partition by city ) as of_plants_in_city , city as city from plant ) as plant_extend where plant_id = 'FOLSOM' ; which is not at all the same thing as select plant_id as plant_id , row_number() over ( partition by city order by plant_id ) as plant_number , count(*) over ( partition by city ) as of_plants_in_city , city as city from plant where plant_id = 'FOLSOM' ; precisely because the former specifies applying the WHERE filter after the window functions run, while the latter specifies applying it before. The fact that the results do change when you put the WHERE restriction before the window functions is exactly why the optimization discussed in that stackoverflow thread you mention isn't made. In some cases it would theoretically be possible to prove that moving the filtering wouldn't change the results, but Postgres isn't smart enough to do that --- and even if it were, it would not push down the WHERE clause in either this example or the stackoverflow one, because it could/would change the results. Or in short, this isn't a bug, but a counterexample to the stackoverflow discussion. 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 #8393: ERROR: failed to locate grouping columns on grouping by varchar returned from function
postgre...@realityexists.net writes: CREATE OR REPLACE FUNCTION test_group_by() RETURNS TABLE (my_col varchar(5)) AS $BODY$ SELECT 'hello'::varchar(5); $BODY$ LANGUAGE sql STABLE; SELECT my_col FROM test_group_by() GROUP BY 1; ERROR: failed to locate grouping columns Fixed in our git tree; thanks for the report! As a workaround in this particular case, you could just not bother with marking the specific length of the varchar constant. The function definition essentially ignores the length, storing only varchar as the result column type, and it's the discrepancy between that and the declaration of the constant that's tickling the bug. 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 #8387: Error while make of the source code
Heikki Linnakangas hlinnakan...@vmware.com writes: On 19.08.2013 13:33, nitishsaur...@gmail.com wrote: Gives Error while compiling (configure goes well but while running make it gives error) the source code as shown below. Is there any compatibility issue between PostgreSQl 9.2.4 and AIX7.1 ? Not that I'm aware of. Then again, there is no AIX 7.1 box in the buildfarm, the closes thing is grebe running AIX 5.3 (see http://buildfarm.postgresql.org/cgi-bin/show_status.pl). I'm wondering if the OP's configuration doesn't support LWARX mutex hints (see the comment for USE_PPC_LWARX_MUTEX_HINT in pg_config_manual.h). We do have a configure-time check for that, but maybe it's not working for him? Without any info as to the compiler or assembler in use, nor a look at the failing bits of assembly code, we're just guessing. 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 #8385: greek symbols as function name
Kevin Grittner kgri...@ymail.com writes: It occurs to me that the behavior you are seeing would be consistent with 945 being considered an uppercase letter, with 60536 being considered its lowercase form. Normal PostgreSQL case-folding of identifiers would then cause exactly the symptoms you are seeing. Hmm ... identifier case-folding isn't really supposed to do anything to multibyte characters. I wonder if this isn't a variant of the issue recently fixed in commit d535136b5d60b19f7ffa777b97ed301739c15a9d. 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] pg_stat_statements produces multiple entries for a single query with track = 'top'
Peter Geoghegan p...@heroku.com writes: So with this single earthdistance query, there are multiple invocations of the executor, and thus multiple associated pg_stat_statements entries (one with 4 calls). Isn't this just the behavior we decided we wanted for SQL-language functions? At least, if we change pg_stat_statements so it doesn't break out SQL-language functions, I'm sure somebody's gonna complain. 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 #8335: trim() un-document behaviour
Bruce Momjian br...@momjian.us writes: The attached patch swaps the arguments in the parser, and allows your expected behavior: This patch is completely unsafe. It will break stored rules, which may contain calls using the existing argument order (which will be dumped without any of the SQL-spec syntactic sugar). To say nothing of existing applications that may be relying on calling the underlying functions with their existing argument order. The inconsistency in argument order is unfortunate but we're long since stuck with it, I'm afraid. 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 #8375: pg_hba.conf: Include_dir like in postgresql.conf
h...@tbz-pariv.de writes: For easier deployment it would be nice to have an include_dir directive in pg_hba.conf. This doesn't seem like a remarkably good idea from here, mainly because entries in pg_hba.conf are critically order-dependent. Dropping random entries into a conf.d-like directory could produce unexpected results --- and in this case, unexpected result probably means security failure. 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] Reltuples/n_live_tup values wrong
Sebastian Kornehl webmas...@sourcebase.org writes: I'm facing a problem which seems like a bug to me. I'm running: It seems like most of your problem is explained by this: DETAIL: 609299 dead row versions cannot be removed yet. You need to get rid of whatever old open transaction is preventing those rows from getting vacuumed away. Perhaps you have a prepared transaction lying around? 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] Reltuples/n_live_tup values wrong
Sebastian Kornehl webmas...@sourcebase.org writes: You might be right, I found some pg_prepared_xacts from 2013-05-23. This was a test with a XA using application, but the application is already offline. There is also no pid available for the given transaction id's. Do you have any idea how to close these xa transactions without restarting the whole db? Just use ROLLBACK PREPARED with the ID you see in pg_prepared_xacts. 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 #8367: wrong example in 8.17.10
koizumi...@minos.ocn.ne.jp writes: In 8.17.10 Constraints on Ranges of PostgreSQL 9.2.4 Documentation, a constraint will prevent the overlapping values in an example. But in the example, range [2010-01-01 11:30, 2010-01-01 13:00) and range [2010-01-01 14:45, 2010-01-01 15:45) do not overlap. No, but the second one overlaps with the range value shown in 8.17.2. So this is correct if it's understood as a continuation of that example. Still, it's kind of a long way from 8.17.2 to 8.17.10. It might be better if this section were recast to use a standalone example --- Jeff, what do you think? 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 #8355: PL/Python 3 can't convert infinity to PostgreSQL's value
I wrote:
... But it seems like maybe we had better cover the
following cases that we do not cover today:
inf
+inf
-inf
+Infinity
I've committed a patch that makes sure float4in and float8in accept
these spellings even when the underlying strtod(3) function does not.
However, it turns out that this doesn't fix your test case on my HPUX
box, and I'm betting that it won't help on Windows either, because
it's actually Python that's failing. You can reproduce the failure
without any Postgres code involved at all:
$ python
Python 2.5.1 (r251:54863, Jul 12 2007, 23:25:33)
[GCC 2.95.3 20010315 (release)] on hp-ux10
Type help, copyright, credits or license for more information.
a = float('inf')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: invalid literal for float(): inf
Now, I seriously doubt that the Python guys will give a darn about
a 15-year-old version of HPUX, but if you can reproduce the above
on your Windows machine, I'd suggest filing a bug about it with them.
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 #8361: 9.3~beta2-2: Wrong `interval' format with aggregate functions.
jbg...@lug-owl.de writes: I just found intervals that are shown with more than 24 hours in the `hours' field. This is not erroneous. 24 hours is not necessarily equivalent to 1 day, so the interval type doesn't automatically transpose one to the other. If you want that sort of conversion, see the justify_days(), justify_hours(), and justify_interval() functions. 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 #8355: PL/Python 3 can't convert infinity to PostgreSQL's value
gr...@yandex.ru writes:
PL/Python can't convert Python's float with infinity value to PostgreSQL's
float.
The reason is that Python's standard representation of infinity is 'inf'
('Infinity' is accepted as well), but PostgreSQL's representation is
'Infinity' only.
Hmm, I was about to contradict you, because it works fine on my Linux
and OS X machines:
regression=# select 'inf'::float8;
float8
--
Infinity
(1 row)
but further experimentation says that this doesn't work on my ancient
HPUX box; and you're complaining about Windows. So what we've got here
is a platform dependency in the behavior of strtod(). I don't think
we can promise to hide all such dependencies, but maybe it'd be a good
idea to take care of this particular one.
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 #8355: PL/Python 3 can't convert infinity to PostgreSQL's value
I wrote: ... further experimentation says that this doesn't work on my ancient HPUX box; and you're complaining about Windows. So what we've got here is a platform dependency in the behavior of strtod(). I don't think we can promise to hide all such dependencies, but maybe it'd be a good idea to take care of this particular one. I took a look in the C99 standard, and what it has to say about it is actually this: [#3] The expected form of the subject sequence is an optional plus or minus sign, then one of the following: -- a nonempty sequence of decimal digits optionally containing a decimal-point character, then an optional exponent part as defined in 6.4.4.2; -- a 0x or 0X, then a nonempty sequence of hexadecimal digits optionally containing a decimal-point character, then an optional binary-exponent part as defined in 6.4.4.2, where either the decimal-point character or the binary-exponent part is present; -- one of INF or INFINITY, ignoring case -- one of NAN or NAN(n-char-sequence-opt), ignoring case in the NAN part, where: n-char-sequence: digit nondigit n-char-sequence digit n-char-sequence nondigit Current versions of the POSIX standard say the same, though SUS v2 didn't mention any of the non-numeric variants. So what we've got is that Windows and some other (obsolete?) platforms don't accept everything the standard says they should, and that results in a visible cross-platform behavioral difference for us. I'm not at all excited about supporting 0x... constants, nor about the expanded form of NaN. But it seems like maybe we had better cover the following cases that we do not cover today: inf +inf -inf +Infinity We already backstop strtod() for these cases: NaN Infinity -Infinity but the wording of the spec clearly requires +Infinity as well as the forms with just inf. (It also appears to require +/- NaN to be accepted, but I have no idea what that would mean and suspect it to be a thinko.) Barring objections I'll go make this change. 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] Incorrect response code after XA recovery
Ondrej Chaloupka ochal...@redhat.com writes: The OTS specification requires both bottom up and top down recovery to be triggered by the recovering resource. This causes that two rollback calls are done against the DB. DB receives rollback call and does the rollback. Then for the second time it returns the exceptional code. As the DB already rollbacked the transaction and forgot about it the DB returns error that no such transaction exists. But this seems to be against OTS specification. It's not likely that we would consider changing the behavior of ROLLBACK PREPARED. The alternatives we would have are (1) silently accept a ROLLBACK against a non-existent transaction ID, or (2) remember every rolled-back ID forever. Neither seems sane in the least. It seems to me that this is something client-side code, probably the XA manager, would need to deal with. The XA manager already has to track uncommitted 2-phase transactions, and would furthermore have the best idea of when it would be safe to forget about a rolled-back ID. Right offhand it appears to me that that Red Hat bug is filed against the correct component, and you need to push them harder to fix their bug/shortcoming rather than claim it's our problem. 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] Incorrect response code after XA recovery
Tom Jenkinson tom.jenkin...@redhat.com writes: A little bit of information in the linked bugzilla report is that the exception being returned has an XA error code of XAER_RMERR An error occurred in rolling back the transaction branch. The resource manager is free to forget about the branch when returning this error so long as all accessing threads of control have been notified of the branchs state. That does not sound right to me, wouldn't XAER_NOTA The specified XID is not known by the resource manager be more accurate? No idea, but in any case that's outside Postgres' purview. It's barely possible that the Postgres JDBC driver has something to do with that, but it sounds more like the XA manager's turf. 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] Incorrect response code after XA recovery
Tom Jenkinson tom.jenkin...@redhat.com writes: On Mon 29 Jul 2013 15:46:12 BST, Tom Lane wrote: No idea, but in any case that's outside Postgres' purview. It's barely possible that the Postgres JDBC driver has something to do with that, but it sounds more like the XA manager's turf. I am not sure what you mean here as I don't know the structure of how the PostGres project is packaged, all I know is that the PostGres JDBC driver component appears to be returning an XAException with the message Error rolling back prepared transaction and an errorCode of XAException.XAER_RMERR rather than XAER_NOTA. Is there a different component within your bug tracking system we should be using to raise this against the JDBC driver instead? The folk who would fix anything in the JDBC driver tend to read pgsql-jdbc sooner than pgsql-bugs, so cc'ing there for comment. 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
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
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
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
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
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
Re: [BUGS] BUG #8274: Wildly insane boolean selectivity estimates
and...@tao11.riddles.org.uk writes: The handling of freq_null for estimating IS NOT TRUE/FALSE for boolean columns which are all null or almost all null (enough that analyze doesn't find any non-null values to put in MCV) is completely off in the weeds. Doh, definitely a bit of brain fade there :-( Suggested fix at: https://gist.github.com/RhodiumToad/5901567 Seems reasonable, will fix. 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] 9.3beta2 unrecognized node type in join alias vars when retrieving view definition
Feike Steenbergen feikesteenber...@gmail.com writes: the attached dump can be loaded and results in an error message when retrieving the view definitions. Thanks for the test case. It looks like I broke this in commit 2ffa740b, as a result of believing the comment in parsenodes.h that says joinaliasvars lists can only contain Vars or COALESCE expressions :-(. Will fix. 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 #8315: GRANTS allowed on extension functions, but not dumped by pg_dump
j...@pgexperts.com writes: permtest=# create extension dblink; CREATE EXTENSION permtest=# grant EXECUTE on FUNCTION dblink(text) to permtestuser; GRANT I see no bug here. This is not different from any other property-alteration you might do on an extension member object. We allow that (if you have privileges), but it's up to you to keep it in sync with the extension definition file. 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 #8315: GRANTS allowed on extension functions, but not dumped by pg_dump
Jeff Frost j...@pgexperts.com writes: On Jul 18, 2013, at 11:47 AM, Tom Lane t...@sss.pgh.pa.us wrote: I see no bug here. This is not different from any other property-alteration you might do on an extension member object. We allow that (if you have privileges), but it's up to you to keep it in sync with the extension definition file. So, perhaps we could warn users on extension property alterations? Hm, I had thought there already was such a discussion in the docs, but I can't find it now. Do you want to draft some text? 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] COPY process hung in 9.2.x (9.2.4)
mark dvlh...@gmail.com writes: client connection runs through bouncer (session pooling) to a 9.2.4 postgres back end. I have had this problem happen without bouncer in the middle but for this limited debug bouncer is in play. have numerous clinets copying to the same table throughout the day, often concurrently. I wonder whether pgbouncer realizes that it should force-disconnect its database connection if the client disconnects ungracefully. Your backend is evidently waiting for COPY data that won't be forthcoming; the only way to get it out of that is to drop the connection. 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 #8289: pg_stat_statements incorrect query text when executing multiple queries in a single PQexec
potapov.dmi...@gmail.com writes: The testcase runs five UPDATE commands with two PQexec calls. First PQexec call runs: UPDATE t1 SET a=101 WHERE id=0; UPDATE t1 SET a=102 WHERE id=1; UPDATE t1 SET a=103 WHERE id=2 Second PQexec call runs: UPDATE t2 SET b=1 where a=0; UPDATE t2 SET a=2 WHERE b=3 I expect pg_stat_statements to contain three records with following query texts: 1) UPDATE t1 SET a=? WHERE id=? 2) UPDATE t2 SET b=? where a=? 3) UPDATE t2 SET a=? WHERE b=? Instead it contains three records with following query texts: 1) UPDATE t2 SET b=1 where a=0; UPDATE t2 SET a=? WHERE b=? 2) UPDATE t1 SET a=? WHERE id=?; UPDATE t1 SET a=102 WHERE id=1; UPDATE t1 SET a=103 WHERE id=2 3) UPDATE t2 SET b=? where a=?; UPDATE t2 SET a=2 WHERE b=3 Yeah, that's what's going to happen, because there is no infrastructure for determining which portion of the source text string belongs to which query. I suspect there are some other infelicities in pg_stat_statements' behavior for multi-query strings, too. At least for now, that combination is best avoided. 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 #8287: select distinct / select group by - Invalid result
lind...@gmail.com writes: I wanted to report an incorrect execution of the query SELECT DISTINCT... : FWIW, this example doesn't seem to misbehave for me in HEAD or 9.2 branch tip. I suspect that this is a variant of bug #8049, which was fixed recently. It could be though that you're reporting some other problem but there are special circumstances (such as nondefault planner settings) needed to make it manifest. You could try applying this patch to see if the problem goes away for you: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=841c9b6ba151ed5a41733ec345bf9bf32a55f4dc 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] Concurrent CREATE USER MAPPING and DROP SERVER
Ronan Dunklau rdunk...@gmail.com writes: It is possible to create a user mapping on a server and drop said server in two concurrent transactions, and have both succeed. There are lots of hazards of this sort, since we generally don't try to lock database objects other than tables when doing DDL. I can't get particularly excited about this one compared to the rest. We could try to extend the table-locking protocols to apply to all object types ... but from here, the amount of work and complexity involved seems far out of proportion to the benefit. 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 #8275: Updateable View based on inheritance (partition) throws Error on INSERT Statement
Dean Rasheed dean.a.rash...@gmail.com writes: On 2 July 2013 09:30, Dean Rasheed dean.a.rash...@gmail.com wrote: I think the rewritten query should only use inheritance if inheritance was requested in the original query, *and* if inheritance was enabled in the view's query, per attached patch against HEAD. On second thoughts, I think this should only apply to INSERT. UPDATE and DELETE should continue work the same as SELECT, respecting the inheritance flag from the view query regardless of the inheritance flag in the outer query. [ thinks for a bit... ] Yeah, I agree. Attached is an updated patch for HEAD, with regression tests. This should also be applied to the 9.3beta branch. Applied with minor adjustments --- mainly, I took out the inFromCl twiddling, which AFAICS is neither necessary (nothing downstream of this looks at inFromCl) nor clearly correct. 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
Peter Eisentraut pete...@gmx.net writes: On 6/30/13 11:26 AM, Andres Freund wrote: If we would treat that warning as an error unconditionally - and I am not sure how easy that is given the way it's emitted - users encountering them, which usually will be on less common platforms, will have to patch configure.in to make things work for them. Which is a high bar. We could also look into updating Autoconf. Newer versions proceed with the compiler's result. At that point, you can essentially ignore the warning. AFAICT, the result in this case would be that the script comes to the wrong conclusion about whether ucred.h is available. Wouldn't that result in a build failure, or at least missing features? IOW, don't we need to fix this test anyway? However, if newer autoconf versions make only one test per header file and not two, then +1 for updating. Should help a bit with configure's speed problem. 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
Peter Eisentraut pete...@gmx.net writes: On 7/1/13 9:19 AM, Tom Lane wrote: AFAICT, the result in this case would be that the script comes to the wrong conclusion about whether ucred.h is available. Wouldn't that result in a build failure, or at least missing features? IOW, don't we need to fix this test anyway? The test needs to be fixed, but with a newer Autoconf version we would (probably) have been alerted about that by a build failure rather than someone scanning build logs. I think probably we'd have just not compiled the dependent code, and would have found out about it only when somebody complained that peer auth didn't work on OpenBSD. Not sure that's really a more attractive behavior :-( 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
Andrew Dunstan and...@dunslane.net writes: On 2013-06-30 15:17:20 +0200, Andres Freund wrote: Andrew: Could we perhaps check for the Report this to bit in the buildfarm? I'm not sure what you're asking here. I think he's wishing that if configure prints something like configure: WARNING: sys/ucred.h: present but cannot be compiled configure: WARNING: sys/ucred.h: check for missing prerequisite headers? configure: WARNING: sys/ucred.h: see the Autoconf documentation configure: WARNING: sys/ucred.h: section Present But Cannot Be Compiled configure: WARNING: sys/ucred.h: proceeding with the preprocessor's result configure: WARNING: sys/ucred.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ## configure: WARNING: ## ## that that ought to be treated as a failure not a success. I'm not entirely sure that I agree, but it's an arguable position. 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 #8257: Multi-Core Restore fails when containing index comments
Andres Freund and...@2ndquadrant.com writes: The problem is that pg_dump makes the comment depend on the index instead of the constraint: Yeah, I figured that out yesterday, but hadn't gotten to writing a patch yet. ... So what we need to do is to make the comment depend on the constraint instead. Your proposed patch will only fix the problem for dumps created after it ships. In the past, we've tried to deal with this type of issue by having pg_restore fix up the dependencies when reading a dump, so that it would still work on existing dumps. I'm afraid there may be no way to do that in this case --- it doesn't look like there's enough info in the dump to tell where the dependency link should have led. But we should think about it a little before taking the easy way out. 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 #8260: problem with sequence and tablename
daniel.degasp...@r3-gis.com writes: CREATE TABLE t23456789012345678901234567890123456789012345678901 ( t1234_id serial, PRIMARY KEY (t1234_id) ) WITH ( OIDS=FALSE ); This generated the sequence: CREATE SEQUENCE t2345678901234567890123456789012345678901234567890_t1234_id_seq That's operating as designed. The table-part in the sequence name was truncated. Would you rather it failed entirely? You're up against the limit on name length (63 bytes in a standard Postgres build). 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 #8257: Multi-Core Restore fails when containing index comments
Andres Freund and...@2ndquadrant.com writes: On 2013-06-27 10:29:14 -0400, Tom Lane wrote: Your proposed patch will only fix the problem for dumps created after it ships. In the past, we've tried to deal with this type of issue by having pg_restore fix up the dependencies when reading a dump, so that it would still work on existing dumps. Yes :(. On the other hand, it's probably not too common to create comments on indexes that haven't been created explicitly. Perhaps. The lack of previous complaints does suggest this situation isn't so common. I'm afraid there may be no way to do that in this case --- it doesn't look like there's enough info in the dump to tell where the dependency link should have led. But we should think about it a little before taking the easy way out. The only thing I could think of - but which I thought to be too kludgey - was to simply delay the creation of all comments and restore them together with ACLs. I don't like that either, though we may be forced into it if we find more bugs in comment dependencies. Anyway, fixing pg_dump's logic is not wrong; I was just hoping we could also think of a workaround on the pg_restore side. 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 #8257: Multi-Core Restore fails when containing index comments
Andres Freund and...@2ndquadrant.com writes: There is no object 1832 in the dump since that was ommitted in favor of the constraint 1833 which internally creates the index. So what we need to do is to make the comment depend on the constraint instead. With the attached patch we get: [ the right thing ] Applied with minor cosmetic changes. 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] Postgres crash? could not write to log file: No space left on device
Heikki Linnakangas hlinnakan...@vmware.com writes: We've discussed retrying short writes before, and IIRC Tom has argued that it shouldn't be necessary when writing to disk. Nevertheless, I think we should retry in XLogWrite(). It can write much bigger chunks than most write() calls, so there's more room for a short write to happen there if it can happen at all. Secondly, it PANICs on failure, so it would be nice to try a bit harder to avoid that. Seems reasonable. My concern about the idea in general was the impossibility of being sure we'd protected every single write() call. But if we can identify specific call sites that seem at more risk than most, I'm okay with adding extra logic there. 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] Postgres crash? could not write to log file: No spaceleft on device
bricklen brick...@gmail.com writes: Assuming your stats_temp_directory is pg_stat_tmp, where is that directory located? Under $PGDATA? What is the path to $PGDATA? If your stats_temp_directory is located on a small partition, that could be a problem Where is your pg_xlog dir located? The given error message is definitely complaining about being unable to write a pg_xlog file --- stats or other temp files are not relevant. 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] Postgres crash? could not write to log file: No space left on device
Jeff Davis pg...@j-davis.com writes: On Tue, 2013-06-25 at 09:46 -0400, Tom Lane wrote: That's definitely telling you it got ENOSPC from a write in $PGDATA/pg_xlog. Either that, or write() wrote less than expected but did not set errno. Good point. I wonder if he's using a filesystem that is capable of reporting partial writes for other reasons, eg maybe it allows signals to end writes early. (Though if it is, it's not apparent why such failures would only be manifesting on the pg_xlog files and not for anything else.) 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 #8238: duplicate of bug #6372 on panffs
james.e.hug...@boeing.com writes: Upon creating a database on a panfs (Panasas proprietary fs) directory I get: createdb: database creation failed: ERROR: could not fsync file base/16387: Invalid argument This is a duplicate of bug #6372 and is fixed by applying the patch for copydir.c listed in the thread. So we confirm this problem also exists on another fs in addition to CIFS. Thanks for the report. Looking back at the previous thread, it seems we chose not to change the code (to ignore EINVAL for fsync-on-a-directory) on the grounds that CIFS couldn't be considered a supported filesystem anyway. Do you find that panfs works all right for Postgres other than this issue? 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 #8247: Duplicate database names - pg_dump backup fails
paul.macdon...@ssc-spc.gc.ca writes: Postgres version: 7.4.7-6sarge1 Egad. Not only has 7.4 been EOL for years, but the last release in that series was 7.4.30. You are missing many years' worth of bug fixes. You really, really, really need to get off of that PG version ASAP. Issue: pg_dump fails due to unexpected duplication of database name (avipads). Dropdb will remove one instance of the database name, but unable to remove the second instance. I suspect this is evidence of transaction ID wraparound in the pg_database catalog. See if VACUUM FULL pg_database makes things any saner. (Delete the one database that you're able to get rid of first.) 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 #8245: Urgent:Query on slave failing with invalid memory alloc request size 18446744073709537559
kappleg...@apsalar.com writes: One of our queries has started failing randomly on our slaves with invalid memory alloc request size 18446744073709537559 It's hard to say much with that amount of information. Is it always the exact same number? The root cause is probably either corrupted data (that is, a trashed length word for some variable-width field) or some internal logic bug that's causing the server to miscompute how much memory it needs for some transient allocation. You could confirm or refute the corrupt-data hypothesis by seeing if you can pg_dump each of the tables referenced by the failing procedure. If pg_dump fails with the same error then it's corrupt data, else not. If it's a bug, though, we'd still be needing more info to track it down. Don't suppose you'd want to change that specific ERROR to a PANIC so we could get a stack trace :-( 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 #8242: No way to debug subquery must return only one column error
boraldomas...@gmail.com writes: When I get this message I cannot guess from it's description what really causes this error. I would like to see exactly the subquery that returned more than one column and the row where this happened. That's a parse-time error, so it's nonsensical to ask for the row where it happened. AFAICS, the parser should give back a syntax-error pointer for this error; for example, when I try to provoke the error in psql, I get =# select * from table1 where id = any(array(select c1,c2 from table2)); ERROR: subquery must return only one column LINE 1: select * from table1 where id = any(array(select c1,c2 ... ^ which shows me that the problem is associated with the ARRAY() construct not accepting multiple input columns. If you're not seeing such an error pointer, it's the fault of whatever client-side software you're working in. 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 #8237: CASE Expression - Order of expression processing
Andres Freund and...@2ndquadrant.com writes: On 2013-06-18 13:17:14 +, and...@lombardoni.ch wrote: template1=# SELECT CASE WHEN (SELECT 0)=0 THEN 0 ELSE 1/0 END; ERROR: division by zero Hrmpf. This is rather annoying. Annoying, maybe. Bug, no. The manual is pretty clear that you don't have a lot of control over order of evaluation of subexpressions. So it seems we need to stop processing after finding a single WHEN that's not const? That's not an acceptable fix. 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] [ODBC] Segmentation Fault in Postgres server when using psqlODBC
Hiroshi Inoue in...@tpf.co.jp writes: OK I made a test C program which reproduces the crash. The program uses libpq and a hack. Oh, thank you, I was just about to go spend an hour doing that ... 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] [ODBC] Segmentation Fault in Postgres server when using psqlODBC
Hiroshi Inoue in...@tpf.co.jp writes: (2013/06/12 1:26), Andres Freund wrote: I'd guess creating a SQL level WITH HOLD cursor and then fetching that via the extended protocol, outside the transaction, should do the trick. OK I made a test C program which reproduces the crash. The program uses libpq and a hack. I've committed a fix for this. Thanks again for the test case. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8228: Unexpected set-valued function with varchar(n) but not varchar
david.g.johns...@gmail.com writes: The following query results in SQL Error: ERROR: set-valued function called in context that cannot accept a set SELECT *, CASE WHEN id = 2 THEN (regexp_matches(input_string,'^0*([1-9]\d+)$'))[1] ELSE input_string END::varchar(30) AS o_l2_a FROM ( VALUES (1,''), (2,'49404'),(3,'FROM 1000876') ) l0_src (id, input_string) Hm, interesting example. What seems to be happening is that during evaluation of the SELECT list for the first VALUES row, the CASE expression doesn't call regexp_matches() but just returns the ELSE expression. The ExecMakeFunctionResult() call for the cast function then decides that the function's argument expression doesn't return a set, so it changes the node execution pointer so that subsequent executions go through the much simpler ExecMakeFunctionResultNoSets() execution function. And then that spits up when on the next row, the argument expression *does* return a set :-( You could work around that using the trick documented in the regexp_matches documentation to force it to return exactly one row, ie interpose a sub-SELECT: regression=# SELECT *, CASE WHEN id = 2 THEN (select (regexp_matches(input_string,'^0*([1-9]\d+)$'))[1]) ELSE input_string END::varchar(30) AS o_l2_a FROM ( VALUES (1,''), (2,'49404'),(3,'FROM 1000876') ) l0_src (id, input_string); id | input_string | o_l2_a +--+-- 1 | | 2 | 49404| 49404 3 | FROM 1000876 | FROM 1000876 (3 rows) Not sure about non-hack fixes. I guess we need to analyze can-it-return-a-set statically instead of believing the first execution result, but that might add an unpleasant amount of startup overhead. 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 #8228: Unexpected set-valued function with varchar(n) but not varchar
David Johnston david.g.johns...@gmail.com writes: The issue with the regexp_matches call generally is that absence of a g modifier means that the set-returning function will never return a set. It would seem to make more sense to not make that a modifier but instead have one function defined to return a set (i.e., the current definition) and another one defined to return a simply text[]. Well, it does return a set, namely either zero or one row. The point of the sub-SELECT workaround is to transform the zero-row case to a scalar NULL. I tend to agree that this API wasn't that well thought out, but it's really not regexp_matches()'s fault that you're running into this problem --- rather, it's the fact that one arm of the CASE can return a set while the other can't. 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 #8225: logging options don't change after reload
j...@pgexperts.com writes: What happens is that we change various logging options in postgresql.conf, then reload, and every so often, the settings don't seem to take effect even though they are logged as being changed. FWIW, the parameter changed messages are logged when the postmaster process updates its values of the GUCs. The particular options you're complaining of here, though, are not actually checked in the postmaster --- they're used in the checkpointer or syslogger processes respectively. So one theory about this would be that those processes aren't absorbing the GUC updates, perhaps because the SIGHUP signals the postmaster should be sending them are getting lost. I'm not sure how we might track down the cause though. How various are the platforms you're seeing this on? 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 #8225: logging options don't change after reload
Jeff Frost j...@pgexperts.com writes: On Jun 13, 2013, at 4:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: ... So one theory about this would be that those processes aren't absorbing the GUC updates, perhaps because the SIGHUP signals the postmaster should be sending them are getting lost. Interestingly, it will often pick them up if you wait a few seconds and send it another reload. Hmm, that definitely lends some credence to the lost-signal theory, since another reload would cause the postmaster to again signal all its children, and this time the signal might go through. But I still have no idea how we might debug further. You could possibly try something like strace'ing the processes, but it seems fairly likely that the Heisenberg principle would apply if you did. 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 #8225: logging options don't change after reload
Jeff Frost j...@pgexperts.com writes: What I don't understand is the new log file being created from the new log_filename setting but then nothing being logged into it. Is it the postmaster which creates that file? I would've thought it would be the logger process? Hm, I hadn't focused on that --- that *is* pretty bizarre. The postmaster creates the log file initially before forking the syslogger, but subsequent rotations are handled by the syslogger process. Is it possible that your systems are running on the hairy edge of ENFILE limits? I notice that the syslogger will silently fail to rotate if it gets ENFILE while trying to open the new log file. That doesn't look like it'd explain the lack of log_checkpoint activity, though. Also, usually people notice this state because everything else on the box starts to fall over ... 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 #8227: referential integrity problem
g...@antrez.pl writes: Is it ok that we loose referential integrity by locking DELETE on table test_item ? Yes. If you put a trigger on a table involved in an FK constraint, it's your responsibility that the trigger doesn't break FK update operations. 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] Completely broken replica after PANIC: WAL contains references to invalid pages
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. 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] pg_dump is O(N) in DB table count N even if dumping only one table
Gunnlaugur Thor Briem gunnlau...@gmail.com writes: pg_dump takes O(N) time dumping just one table (or a few) explicitly specified with a -t parameter. It thus becomes painfully slow on a database with very many tables. This is not a bug. It needs information about all the tables anyway to deal with dependencies (possible inheritance and similar situations). Having said that, it does look like getTables is pulling back a lot of info that we don't need *yet*, and would never need if we conclude we don't need to dump the table. Possibly some of this work could usefully be postponed to, say, getTableAttrs. OTOH, if that makes the normal dump-everything case noticeably slower, it's unlikely such a patch would get accepted. 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 in Prepared statement with DELETE RETURNING and rule on view
[ got around to looking at this thread finally ] Amit Kapila amit.kap...@huawei.com writes: What happens when you change ON DELETE rule of the view that really deletes elements is that command type after applying rule remains same which means Delete, so it can set the Tag. The point here is that in extended-query mode, we've defined that only the same statement that sets the command tag can return RETURNING rows. In the case at hand, the original DELETE isn't executed at all, being replaced by an UPDATE according to the rule. But we don't change the returned command tag to UPDATE, and we don't let the UPDATE's RETURNING clause return anything to the client. Both of these rules are meant to ensure unsurprising behavior as seen from the client side. We could debate changing them, but I'd be pretty worried about breaking user applications if we did. At the same time, things don't look terribly consistent because in psql (which uses simple query protocol) you *do* see the RETURNING results. That's because simple query protocol doesn't have a restriction that only one resultset can be returned from a single query. So it's a lot more wild-west as to what will really happen, and application code is expected to just deal with that. psql doesn't have a problem with multiple query results because it doesn't particularly care what they are; it's just going to print each one. Apps that are supposed to actually make sense of the data have more of an issue with that. The extended query protocol was explicitly designed to lock things down better so that interactions would be more predictable. The main thing I'm noticing in looking at this is that the documentation doesn't seem to explain anywhere the restriction to getting RETURNING results back from only the primary query. We ought to fix that. 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 #8218: Error when querying an JSON data, 9.3beta
daniel.zla...@gmail.com writes:
CREATE TABLE products (
data JSON
);
INSERT INTO products(data) VALUES('{id: 1, name: shoes, in_stock:
5}');
INSERT INTO products(data) VALUES('[1,2,3,4,5]');
SELECT * FROM products WHERE (data-'in_stock')::integer 0
Output was:
[Err] ERROR: cannot extract field from a non-object
I can understand the reason behind this error(JSON array don't has fields),
but for me it is very logical postgres to exclude this row from the
returning set, rather to throw an error.
Hm. In principle we could allow - to return NULL rather than failing
when there's no such field, but I'm not sure that would represent good
language design. However, this example definitely shows there are some
holes in the current set of JSON manipulation functions. The only way
to avoid a failure here would be to write something like
WHERE (CASE WHEN json_has_field(data, 'in_stock') THEN
(data-'in_stock')::integer ELSE NULL::integer END) 0
but there is no json_has_field test function, nor any nice way to
build one from the provided functions.
It's probably too late to address this for 9.3, but we ought to put it
on the to-do list for 9.4.
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 #8198: ROW() literals not supported in an IN clause
=?UTF-8?Q?Rafa=C5=82_Rzepecki?= divided.m...@gmail.com writes: I'm pretty sure the original intent was to afford some extra checks so that conditions such as ROW(1, 2) IN ((ROW(3, 4), ROW(5, 6, 7)) would get rejected at parsing time (CCing the original author; please confirm). No; the reason it was like that was that when that code was written, make_row_comparison_op was the only way to compare two row values at all. We didn't have record_eq and friends; nor did we have arrays of composites. Since the restriction seems a rather arbitrary (at least I fail to see any reason for it), it can be removed altogether (patch 0002, not tested as well): This is reasonable as far as it goes, but I think it doesn't go far enough --- there's really no reason anymore to reject RowExprs as components of ScalarArrayOpExpr either. I've extended this patch some and committed it. Thanks for the report! 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 #8216: TO_DATE does not support th format provided
sunitha.mudu...@blss.com.au writes:
To_date does not throw an error when an invalid date is provided to it
select to_date('10-30-2012','dd-MM-');
That's not a bug; it's operating as designed. If you want more error
checking, don't use to_date() --- just cast the string to date.
regression=# show datestyle;
DateStyle
---
ISO, MDY
(1 row)
regression=# select '10-30-2012'::date;
date
2012-10-30
(1 row)
regression=# set datestyle = dmy;
SET
regression=# select '10-30-2012'::date;
ERROR: date/time field value out of range: 10-30-2012
LINE 1: select '10-30-2012'::date;
^
HINT: Perhaps you need a different datestyle setting.
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 #8215: pg_dump includes table out of order in SQL dump
ijmor...@uwaterloo.ca writes: My understanding is that pg_dump is supposed to include tables in SQL dumps in alphabetical order by table name. That's the default behavior as long as there are no ordering constraints that would dictate doing something else. You haven't provided enough info to tell whether there's such a constraint in your case ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8211: Syntax error when creating index on expression
aci...@gmail.com writes: CREATE INDEX heuristic ON foos (1 / (a + b)) causes: ERROR: syntax error at or near 1 This is not a bug. You need an extra pair of parentheses around the expression, ie CREATE INDEX heuristic ON foos ((1 / (a + b))) http://www.postgresql.org/docs/9.2/static/sql-createindex.html points this out both in the syntax diagram and the text. 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 #8213: Set-valued function error in union
eric-postgre...@soroos.net writes: -- this fails. I'd expect it to succeed. select id, dt from (select 1 as id, generate_series(now()::date, now()::date + '1 month'::interval, '1 day')::date as dt union select 2, now()::date ) as foo where dt now()+'15 days'::interval; psql:pg_bug_report.sql:13: ERROR: 0A000: set-valued function called in context that cannot accept a set Fascinating. This has been broken at least since 7.4 --- surprising nobody noticed before. We need to fix allpaths.c so it realizes it's unsafe to push down a WHERE condition into a set operation when there are set-returning functions in the tlist of any arm of the set operation. Right now, you're getting this plan: HashAggregate (cost=20.09..30.10 rows=1001 width=0) - Append (cost=0.03..15.09 rows=1001 width=0) - Result (cost=0.03..5.05 rows=1000 width=0) One-Time Filter: ((generate_series(((now())::date)::timestamp without time zone, ((now())::date + '1 mon'::interval), '1 day'::interval))::date (now() + '15 days'::interval)) - Result (cost=0.01..0.03 rows=1 width=0) One-Time Filter: ((now())::date (now() + '15 days'::interval)) and of course trying to evaluate a filter that contains a SRF is pretty nonsensical (or even if you think it could be well-defined, it's not implemented). Shouldn't be too hard to fix though. I'm thinking of moving most of the detection logic for this into subquery_is_pushdown_safe, and having it return an additional flag array that says this output column is unsafe to reference in quals at all. 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] Memory-leak in BackgroundWriter(and Checkpointer)
Stephen Frost sfr...@snowman.net writes: * Andres Freund (and...@2ndquadrant.com) wrote: Seems more consistent with the rest of the code too. But anyway, I am fine with fixing it either way. And this is really the other point- having LogStandbySnapshot() need to clean up after GetRunningTransactionLocks() but not GetRunningTransactionData() would strike me as very odd. Meh. I'm not impressed with permanently allocating an array large enough to hold all the locks GetRunningTransactionLocks might return --- that's potentially much larger than the other array, and in fact I don't think we have a hard limit on its size at all. Besides which, it's not like there is *no* cleanup for GetRunningTransactionData --- it has a lock that has to be released ... I think the proposed fix is fine code-wise; the real problem here is crummy commenting. GetRunningTransactionLocks isn't documented as returning a palloc'd array, and why the heck do we have a long comment about its implementation in LogStandbySnapshot? 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] Memory-leak in BackgroundWriter(and Checkpointer)
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think the proposed fix is fine code-wise; the real problem here is
crummy commenting. GetRunningTransactionLocks isn't documented as
returning a palloc'd array, and why the heck do we have a long comment
about its implementation in LogStandbySnapshot?
Certainly good questions and better comments would have helped here. I
can go back and rework the patch either way.
I'm already working on back-patching the attached.
regards, tom lane
diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index 615278b8ca2adf3057e5f21057c3cedfc66480aa..c704412366d5bc4b6512e9ab673855c46f7d993f 100644
*** a/src/backend/storage/ipc/standby.c
--- b/src/backend/storage/ipc/standby.c
*** LogStandbySnapshot(void)
*** 865,880
/*
* Get details of any AccessExclusiveLocks being held at the moment.
- *
- * XXX GetRunningTransactionLocks() currently holds a lock on all
- * partitions though it is possible to further optimise the locking. By
- * reference counting locks and storing the value on the ProcArray entry
- * for each backend we can easily tell if any locks need recording without
- * trying to acquire the partition locks and scanning the lock table.
*/
locks = GetRunningTransactionLocks(nlocks);
if (nlocks 0)
LogAccessExclusiveLocks(nlocks, locks);
/*
* Log details of all in-progress transactions. This should be the last
--- 865,875
/*
* Get details of any AccessExclusiveLocks being held at the moment.
*/
locks = GetRunningTransactionLocks(nlocks);
if (nlocks 0)
LogAccessExclusiveLocks(nlocks, locks);
+ pfree(locks);
/*
* Log details of all in-progress transactions. This should be the last
diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index 8cd871f4b40d7bfc8b0aaa7650241d5865c79ffe..273c72230274b46ba6a46bb8b295ef5375aaa36d 100644
*** a/src/backend/storage/lmgr/lock.c
--- b/src/backend/storage/lmgr/lock.c
*** GetLockStatusData(void)
*** 3398,3415
}
/*
! * Returns a list of currently held AccessExclusiveLocks, for use
! * by GetRunningTransactionData().
*/
xl_standby_lock *
GetRunningTransactionLocks(int *nlocks)
{
PROCLOCK *proclock;
HASH_SEQ_STATUS seqstat;
int i;
int index;
int els;
- xl_standby_lock *accessExclusiveLocks;
/*
* Acquire lock on the entire shared lock data structure.
--- 3398,3423
}
/*
! * Returns a list of currently held AccessExclusiveLocks, for use by
! * LogStandbySnapshot(). The result is a palloc'd array,
! * with the number of elements returned into *nlocks.
! *
! * XXX This currently takes a lock on all partitions of the lock table,
! * but it's possible to do better. By reference counting locks and storing
! * the value in the ProcArray entry for each backend we could tell if any
! * locks need recording without having to acquire the partition locks and
! * scan the lock table. Whether that's worth the additional overhead
! * is pretty dubious though.
*/
xl_standby_lock *
GetRunningTransactionLocks(int *nlocks)
{
+ xl_standby_lock *accessExclusiveLocks;
PROCLOCK *proclock;
HASH_SEQ_STATUS seqstat;
int i;
int index;
int els;
/*
* Acquire lock on the entire shared lock data structure.
*** GetRunningTransactionLocks(int *nlocks)
*** 3467,3472
--- 3475,3482
}
}
+ Assert(index = els);
+
/*
* And release locks. We do this in reverse order for two reasons: (1)
* Anyone else who needs more than one of the locks will be trying to lock
--
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 #8191: Wrong bit conversion
ger...@hexboss.com writes: SELECT b'1'::bit(64), x'1'::bit(64), 1::bit(64) RESULT: 1000, 0001, 0001 I believe those are all operating as intended. 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 #8191: Wrong bit conversion
Gerald Luger geraldlu...@hexboss.com writes: Shouldn't I expect all results to be 000...0001? Well, no. The SQL spec is pretty clear about the interpretation of this: b'1'::bit(64) You're taking a bit string of length 1 and casting it to bit string of length 64. That's done by appending zeroes on the right, per spec. The x'1' notation isn't in SQL99 AFAICS, but we consider that x'1' means the same as b'0001', and then the conversion from bit(4) to bit(64) is done by padding zeroes on the right. Your last case, 1::bit(64) represents casting an integer to bit(64). This operation isn't in the SQL spec either, unless I missed something. We treat this as conversion of the integer's twos-complement representation to a bit string, presuming big-endian representation of the integer. Now you can quibble with various of the details above, but in the end they are all arbitrary decisions. We've made them that way, and it would take a pretty impressive argument to persuade us to break existing applications by changing them. 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 #8176: problem with the ALTER TYPE name RENAME TO new_name [ CASCADE | RESTRICT ] syntax
Stephen Frost sfr...@snowman.net writes: * maxim.bo...@gmail.com (maxim.bo...@gmail.com) wrote: It seems that documentation wrong or [ CASCADE | RESTRICT ] feature of ALTER TYPE ... RENAME TO isn't implemented. Actually, I'm pretty sure it's implemented but the grammar for it was broken during refactoring to have all the ALTER .. RENAME operations go through the same code paths. Are we sure the documentation's not wrong? A quick test says this syntax isn't accepted in *any* existing release, and I can't say I understand what it should do anyway. 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: [HACKERS] [BUGS] COPY .... (FORMAT binary) syntax doesn't work
Simon Riggs si...@2ndquadrant.com writes: On 26 May 2013 17:10, Tom Lane t...@sss.pgh.pa.us wrote: More readable would be to invent an intermediate nonterminal falling between ColId and ColLabel, whose expansion would be IDENT | unreserved_keyword | col_name_keyword | type_func_name_keyword, and then replace ColId_or_Sconst with whatever-we-call-that_or_Sconst. Any thoughts about a name for that new nonterminal? Do you think complicating the parser in that way is worth the trouble for this case? Could that slow down parsing? It makes the grammar tables a bit larger (1% or so IIRC). There would be some distributed penalty for that, but probably not much. Of course there's always the slippery-slope argument about that. We don't actually have to fix it; clearly not too many people are bothered, since no complaints in 3 years. Documenting 'binary' seems better. Well, my thought is there are other cases. For instance: regression=# create role binary; ERROR: syntax error at or near binary LINE 1: create role binary; ^ regression=# create user cross; ERROR: syntax error at or near cross LINE 1: create user cross; ^ If we don't have to treat type_func_name_keywords as reserved in these situations, shouldn't we avoid doing so? 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: [HACKERS] [BUGS] COPY .... (FORMAT binary) syntax doesn't work
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 26.05.2013 04:31, Simon Riggs wrote:
This new format does not [work:]
COPY pgbench_accounts FROM '/tmp/acc' (FORMAT BINARY);
ERROR: syntax error at or near BINARY at character 47
This seems to work:
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -2528,3 +2528,7 @@ copy_generic_opt_elem:
{
$$ = makeDefElem($1, $2);
}
+ | ColLabel BINARY
+ {
+ $$ = makeDefElem($1, (Node *)
makeString(binary));
+ }
That only fixes things for the specific case of FORMAT BINARY. I think
it would be better to generalize ColId_or_Sconst. This one-liner works,
but it's pretty ugly:
*** gram.y~ Sun May 26 11:58:42 2013
--- gram.y Sun May 26 12:00:03 2013
*** opt_encoding:
*** 1548,1553
--- 1548,1554
ColId_or_Sconst:
ColId
{ $$ = $1; }
+ | type_func_name_keyword
{ $$ = pstrdup($1); }
| Sconst
{ $$ = $1; }
;
More readable would be to invent an intermediate nonterminal falling
between ColId and ColLabel, whose expansion would be IDENT |
unreserved_keyword | col_name_keyword | type_func_name_keyword, and
then replace ColId_or_Sconst with whatever-we-call-that_or_Sconst.
Any thoughts about a name for that new nonterminal?
BTW, I tried just replacing ColId with ColLabel here, and that *almost*
works, but there are some places where we can see either ColId_or_Sconst
or DEFAULT. I don't know of any sane way to express all reserved
keywords except DEFAULT to bison, so the best we can realistically do
is to accept all not-fully-reserved keywords in these places.
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 #8175: Check constraint fails for valid data. ( rounding related? )
dan.li...@gmail.com writes: create table test1 ( val1 numeric(23,8), val2 numeric(23,8), product numeric(23,8) check( product = val1 * val2 ) ); select (2.23567567*3.7000)::numeric(23,8); insert into test1 values ( 3.7000, 2.23567567, 8.2718 ); insert into test1 values ( 3.7000, 2.23567567, 2.23567567*3.7000 ); insert into test1 values ( 3.7000, 2.23567567, (2.23567567*3.7000)::numeric(23,8) ); It's not surprising that these all fail. You'd need to make the check be more like this: check( product = (val1 * val2)::numeric(23,8) ) Otherwise, the check will always fail when the product has more than 8 fractional digits. It's not Postgres' place to decide that that wasn't what you wanted to happen. 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 #8170: alter user does not accept timestamp output format in certain datestyles and timezones.
chris.trav...@gmail.com writes: db=# show timezone; TimeZone -- Asia/Jakarta (1 row) db=# select now(); now - Mon 20 May 11:39:24.273508 2013 WIT (1 row) db=# ALTER USER chris with valid until 'Tue 21 May 11:41:14.58554 2013 WIT'; ERROR: invalid input syntax for type timestamp with time zone: Tue 21 May 11:41:14.58554 2013 WIT This worked before with different timezones with the same datestyle. Why is this failing? You need to add WIT to the timezone abbreviation list to allow it to be used as input: http://www.postgresql.org/docs/9.2/static/datetime-config-files.html Or perhaps better, use the ISO datestyle to eliminate the whole issue of timezone abbreviations. 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 #8169: change in bytea value in postgresql 8.3 and 9.2.4
email4raje...@gmail.com writes: There is a huge change in bytea value in postgresql 8.3 and 9.2.4 Can we convert 9.2.4 bytea value to 8.3 You're probably looking for bytea_output: http://www.postgresql.org/docs/9.2/static/runtime-config-client.html#GUC-BYTEA-OUTPUT 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 #8168: duplicated function signature
Heikki Linnakangas hlinnakan...@vmware.com writes: On 17.05.2013 13:31, vladimir.jovano...@aparteko.com wrote: I noticed that I have two functions with the same signature. sp_get_league_prediction(IN _id bigint, IN _rank integer, IN _log_in_expectence double precision, IN _feathers_gained integer, IN _tokens_all integer, IN _tokens_active integer, IN _score integer) sp_get_league_prediction(_id bigint, _rank integer, _log_in_expectence double precision, _feathers_gained integer, _tokens_all integer, _tokens_active integer, _score integer) In addition to higher-level checks, there is a unique index in the pg_proc catalog that should not let that happen, so to be honest, I find that hard to believe. Are you 100% they have the same signature? Are they in different schemas, perhaps? In psql, what does \df sp_get_league_prediction return? If they are in different schemas, you'd probably need \df *.sp_get_league_prediction to see both. 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 #8167: false EINVAL -22 for opening a file
nel...@monkey.org writes:
RhodiumToad asked me to report pg in PathNameOpenFile / mdopen is
assuming that errno is preserved over calls to free() which is not
required by the spec
Good catch! The proximate problem appears to be this bit in
PathNameOpenFile:
vfdP-fd = BasicOpenFile(fileName, fileFlags, fileMode);
if (vfdP-fd 0)
{
FreeVfd(file);
free(fnamecopy);
return -1;
}
The other code layers in this stack seem to be careful about preserving
errno where needed, but this bit isn't.
I've not really reviewed fd.c for other instances of the same bug,
but I do see some places where there are DO_DB(...) debug calls in
places where errno had better not change. I'm thinking maybe we should
improve that macro to include save/restore errno. Or else rip that
stuff out entirely --- I've sure never built this code with FDDEBUG
set, has anyone else?
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] pg_ctl -D /absolute/path -m fast restart - doesn't work in some cases
Alvaro Herrera alvhe...@2ndquadrant.com writes: Um, if this is a bug introduced during the 9.3 timeframe surely we ought to fix it now instead of waiting for the CF. I think it's been that way all along. Nonetheless, if you feel motivated to review the patch now, there's nothing wrong with that. 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 #8163: simultaneous nearly identical update queries execute extremely slowly
Todd A. Cook tc...@blackducksoftware.com writes: On 05/15/13 13:27, tc...@blackducksoftware.com wrote: When nearly identical update queries arrive simultaneously, the first one to execute runs normally, but subsequent executions run _extremely_ slowly. We've seen this behaviour in production, and the contrived test case below reproduces the issue. I've repeated the test below on a 9.1.9 installation, and it works fine there. Given the reference to EvalPlanQual in your stack trace, I'm thinking the explanation is this 9.0 fix: Author: Tom Lane t...@sss.pgh.pa.us Branch: master Release: REL9_0_BR [9f2ee8f28] 2009-10-26 02:26:45 + Re-implement EvalPlanQual processing to improve its performance and eliminate a lot of strange behaviors that occurred in join cases. We now identify the current row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does. 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 #8163: simultaneous nearly identical update queries execute extremely slowly
Todd A. Cook tc...@blackducksoftware.com writes: On 05/15/13 16:10, Tom Lane wrote: Given the reference to EvalPlanQual in your stack trace, I'm thinking the explanation is this 9.0 fix: Thanks for the explanation. Is there any chance of that fix being backpatched into 8.4? None whatsoever. Aside from the mentioned change in semantics, there were numerous followup fixes, which would be difficult to disentangle from everything else that changed in 9.0. We would not risk destabilizing 8.4 like that. 8.4 is barely more a year from EOL anyway, so you really ought to be thinking about an upgrade. 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] Inconsistency between TO_CHAR() and TO_NUMBER()
Heikki Linnakangas hlinnakan...@vmware.com writes: Would it be possible to be lenient, and also accept . as the decimal separator, when there is no ambiguity? Ie. when . is not the thousands separator. I originally coded it that way, but concluded that it was probably a waste of code space. How many locales can you point to where neither the decimal point nor thousands_sep is .? It certainly wouldn't be enough to noticeably reduce the potential pain from this change, so I decided that it'd be better to keep the behavior straightforward and as-documented. 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 #8154: pg_dump throws error beacause of field called new.
willy...@gmail.com writes:
pg_dump (PostgreSQL) 9.1.9 ends in an error when backing up my db, which
contains a field called new.
Works for me:
regression=# create table new (f1 text, new text);
CREATE TABLE
regression=# insert into new (f1, new) values ('1','2');
INSERT 0 1
regression=# copy new(f1,new) to stdout;
1 2
You sure the server is 9.1?
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 #8152: strange behavior regarding after triggers and inheritance
hcu...@exa.unicen.edu.ar writes: PostgreSQL version: 8.4.17 After statments triggers on child tables are sometimes executed and sometimes are not. As I far as I could see, when the after trigger is defined in only one of the tables it may not get executed, wether when it is defined in every inherited table it does, but which one is undetermined. This test case appears to work the way you're expecting in 9.0 and later. I didn't immediately find a mention of such a change in the commit logs; perhaps it got fixed as a side-effect of the changes that moved trigger processing into ModifyTable plan nodes. Anyway, I doubt we'd consider changing trigger behavior in 8.4.x at this late date. You should update to a newer release series if this is a problem for you. 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 #8150: NULL emements lost when casting result of unnest()
brandstet...@falter.at writes:
SELECT unnest('{1,NULL,4}'::int[])::int8;
i
---
1
4
Hm ... this seems to be a very old oversight in ExecMakeFunctionResult:
when it's dealing with a set-valued function argument, if the function
is strict and the particular input value is NULL, it sets the isDone
flag to ExprEndResult, ie, empty-set result. I think this is the right
thing if the current function returns set; but for a non-set-returning
function, what we ought to get is a scalar NULL result not an empty set.
Various other code paths including ExecMakeTableFunctionResult appear to
get this right.
The attached patch fixes it.
This is another case where I'm not too sure if we ought to back-patch.
The current behavior is clearly wrong, but perhaps some application
out there will be unhappy if we change it in back branches?
regards, tom lane
diff --git a/src/backend/executor/execQual.c b/src/backend/executor/execQual.c
index 4ea0cbadadbc14614d5e8182ec1da0ded631ee0f..c86a8456424df20e304f55c6de2628fa4f89db1f 100644
*** a/src/backend/executor/execQual.c
--- b/src/backend/executor/execQual.c
*** restart:
*** 1801,1812
pgstat_end_function_usage(fcusage,
rsinfo.isDone != ExprMultipleResult);
}
! else
{
result = (Datum) 0;
*isNull = true;
*isDone = ExprEndResult;
}
/* Which protocol does function want to use? */
if (rsinfo.returnMode == SFRM_ValuePerCall)
--- 1801,1820
pgstat_end_function_usage(fcusage,
rsinfo.isDone != ExprMultipleResult);
}
! else if (fcache-func.fn_retset)
{
+ /* for a strict SRF, result is an empty set */
result = (Datum) 0;
*isNull = true;
*isDone = ExprEndResult;
}
+ else
+ {
+ /* for a strict non-SRF, result is a NULL */
+ result = (Datum) 0;
+ *isNull = true;
+ *isDone = ExprSingleResult;
+ }
/* Which protocol does function want to use? */
if (rsinfo.returnMode == SFRM_ValuePerCall)
--
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] Strange time zone +00:53:28
=?ISO-8859-1?Q?Karsten_D=FCsterloh?= pg-bugs...@tal.de writes: Under Pg 8.3, we used the timestamp 0001-01-01 00:00:00+01 as an easy-to-remember marker for 'dunno, but predates any usual business dates' for fields of type timestamp with time zone. Have you considered using '-infinity'? With Pg 9.1, these timestamps now appear as 0001-12-31 23:53:28+00:53:28 BC This is not a bug. I refer you to the IANA timezone database's entry for Europe/Berlin: # Zone NAMEGMTOFF RULES FORMAT [UNTIL] ZoneEurope/Berlin 0:53:28 - LMT 1893 Apr 1:00C-Eur CE%sT 1945 May 24 2:00 1:00 SovietZone CE%sT 1946 1:00Germany CE%sT 1980 1:00EU CE%sT which says that timekeeping before April 1893 was done according to local mean solar time, 53:28 east of Greenwich; so a timestamp specified as midnight GMT+1 comes out as 23:53:28 local time. Now, I agree that it's somewhat debatable to extend that rule clear back to 1 AD; but it's more sensible than believing that local time would ever have been taken as exactly GMT+1 before the days of standardized timezones. The only reason 8.3 and before didn't do what you're seeing is they were incapable of applying timezone rules outside the range of 32-bit time_t (ie, back to about 1901). We fixed that code to be 64-bit, and now it does what the timezone definition says. If you're inextricably wedded to using '0001-01-01 00:00:00+01', you might consider building yourself a custom timezone database that has an entry defined the way you want. But personally I'd recommend changing to something less randomly chosen. 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] Inconsistency between TO_CHAR() and TO_NUMBER()
Patryk Kordylewski p...@fooby.de writes:
SET lc_numeric TO 'de_DE.UTF-8';
SET
SELECT
TO_CHAR(123456789.123, 'FM99G999G999G999G999G999G999D000'),
TO_NUMBER(TO_CHAR(123456789.123, 'FM99G999G999G999G999G999G999D000'),
'FM99G999G999G999G999G999G999D000');
to_char | to_number
-+---
123.456.789,123 | 123.456
(1 row)
I looked into this, and find that the reason it misbehaves is that
NUM_numpart_from_char() will treat a '.' as being a decimal point
*without any regard to locale considerations*. So even if we have
a locale-dependent format string and a locale that says '.' is a
thousands separator, it does the wrong thing.
It's a bit surprising nobody's complained of this before.
I propose the attached patch. I'm slightly worried though about whether
this might break any existing applications that are (incorrectly)
depending on a D format specifier being able to match '.' regardless of
locale. Perhaps we should only apply this to HEAD and not back-patch?
regards, tom lane
diff --git a/src/backend/utils/adt/formatting.c b/src/backend/utils/adt/formatting.c
index db5dfca51d477d3e9b33b8d2c264495b3b2ec433..81e3329ef60ce4f835fedba50208b8d0f4b19d63 100644
*** a/src/backend/utils/adt/formatting.c
--- b/src/backend/utils/adt/formatting.c
*** NUM_numpart_from_char(NUMProc *Np, int i
*** 4131,4137
#endif
/*
! * read digit
*/
if (isdigit((unsigned char) *Np-inout_p))
{
--- 4131,4137
#endif
/*
! * read digit or decimal point
*/
if (isdigit((unsigned char) *Np-inout_p))
{
*** NUM_numpart_from_char(NUMProc *Np, int i
*** 4151,4190
#ifdef DEBUG_TO_FROM_CHAR
elog(DEBUG_elog_output, Read digit (%c), *Np-inout_p);
#endif
-
- /*
- * read decimal point
- */
}
else if (IS_DECIMAL(Np-Num) Np-read_dec == FALSE)
{
#ifdef DEBUG_TO_FROM_CHAR
! elog(DEBUG_elog_output, Try read decimal point (%c), *Np-inout_p);
#endif
! if (*Np-inout_p == '.')
{
*Np-number_p = '.';
Np-number_p++;
Np-read_dec = TRUE;
isread = TRUE;
}
- else
- {
- int x = strlen(Np-decimal);
-
- #ifdef DEBUG_TO_FROM_CHAR
- elog(DEBUG_elog_output, Try read locale point (%c),
- *Np-inout_p);
- #endif
- if (x AMOUNT_TEST(x) strncmp(Np-inout_p, Np-decimal, x) == 0)
- {
- Np-inout_p += x - 1;
- *Np-number_p = '.';
- Np-number_p++;
- Np-read_dec = TRUE;
- isread = TRUE;
- }
- }
}
if (OVERLOAD_TEST)
--- 4151,4178
#ifdef DEBUG_TO_FROM_CHAR
elog(DEBUG_elog_output, Read digit (%c), *Np-inout_p);
#endif
}
else if (IS_DECIMAL(Np-Num) Np-read_dec == FALSE)
{
+ /*
+ * We need not test IS_LDECIMAL(Np-Num) explicitly here, because
+ * Np-decimal is always just . if we don't have a D format token.
+ * So we just unconditionally match to Np-decimal.
+ */
+ int x = strlen(Np-decimal);
+
#ifdef DEBUG_TO_FROM_CHAR
! elog(DEBUG_elog_output, Try read decimal point (%c),
! *Np-inout_p);
#endif
! if (x AMOUNT_TEST(x) strncmp(Np-inout_p, Np-decimal, x) == 0)
{
+ Np-inout_p += x - 1;
*Np-number_p = '.';
Np-number_p++;
Np-read_dec = TRUE;
isread = TRUE;
}
}
if (OVERLOAD_TEST)
--
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 #8143: Backend segmentation fault in pg_trgm
jrol...@rjobrien.com writes: We've come across a specific query and query plan that causes a repeatable segmentation fault on the postgresql backend. Ah, I see it: gistrescan() is trying to preserve the per-scankey fn_extra values to allow caching, but what it's doing does not work if more than one scankey refers to the same consistentFn, ie, the same index column. A bit surprising we've not seen this before, because I think that code has been like that for awhile. Will fix, thanks for the report! 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 #8144: Problem with rank window function and CTEs
m...@bloodnok.com writes: I have a query in which I want to use the result of a window function to isolate the most relevant results. While I was trying to develop and test the query, I discovered what looks like a bug in the results of the rank() function. This has been tried with the same results on 9.1.9 and 9.2.4 Well, you didn't provide enough information for somebody else to reproduce the problem, but just looking at this I see no particular reason to think there's a bug. In the first case, the where ao.org_id = 20150 clause filters rows before the rank() is taken, whereas in the second case it filters after the rank() function. I think the larger rank values indicate that there are other rows with different org_id but the same item_id, which you won't see in the final output in either case --- but in the second query, the rank() function does see them. 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 #8141: multi-column check expression evaluating to NULL
andras.va...@zalando.de writes: Consider the following table with a CHECK constraint: CREATE TABLE check_test ( id integer NOT NULL, col integer, CONSTRAINT unique_with_null_check1 CHECK (col = 1 AND id 20) ); This INSERT statement succeeds: INSERT INTO check_test (id, col) VALUES (1, NULL); While, col being NULL, the whole CHECK condition evaluates to NULL - this is covered in the documentation. But this is refused: INSERT INTO check_test (id, col) VALUES (21, NULL); ERROR: new row for relation check_test violates check constraint unique_with_null_check1 I think this behaviour should be either also mentioned in the docs or cosidered a bug. I see no bug here. In the first case, the col = 1 condition yields NULL while id 20 yields TRUE, so you have NULL AND TRUE which is NULL, which is considered a pass for a CHECK condition per spec. In the second case, col = 1 is still NULL, but id 20 is FALSE, so you have NULL AND FALSE which is FALSE (*not* NULL), and so failure is per spec. Yes, the behavior of AND/OR with NULLs is documented. http://www.postgresql.org/docs/9.1/static/functions-logical.html 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 #8139: initdb: Misleading error message when current user not in /etc/passwd
nico...@marchildon.net writes:
initdb: could not obtain information about current user: Success
The misleading part is the Success. This comes from errno:
pw = getpwuid(geteuid());
if (!pw)
{
fprintf(stderr,
_(%s: could not obtain information about current
user: %s\n),
progname, strerror(errno));
exit(1);
}
The man page says:
RETURN VALUE
The getpwnam() and getpwuid() functions return a pointer to a
passwd
structure, or NULL if the matching entry is not found or an
error
occurs. If an error occurs, errno is set appropriately. If one
wants
to check errno after the call, it should be set to zero before
the
call.
AFAICS, getpwuid is not honoring its specification here: it failed to
set errno. I don't see that suppressing the strerror result would add
anything much.
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
