Re: [HACKERS] [PERFORM] In progress INSERT wrecks plans on table
At 2013-07-11 17:47:58 -0700, j...@agliodbs.com wrote: So, where are we with this patch, then? It's ready for committer. -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] XLogInsert scaling, revisited
At 2013-07-08 12:16:34 +0300, hlinnakan...@vmware.com wrote: Ok, I've committed this patch now. Finally, phew! Good. I'd signed up to review this patch, and did spend some considerable time on it, but although I managed to understand what was going on (which was my objective), I didn't find anything useful to say about it beyond what others had brought up already. Sorry. Thanks to everyone involved for the review and testing! And if you can, please review the patch as committed once more. …so I read through the patch as committed again, and it looks good. Thanks. -- Abhijit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] refresh materialized view concurrently
On Tue, Jul 9, 2013 at 12:50 PM, Kevin Grittner kgri...@ymail.com wrote: Thanks again! New patch attached. After a couple of more attempts trying to break it, I mark this as ready to go. One small question: why do we use multiple unique indexes if exist? One index isn't enough? -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] mvcc catalo gsnapshots and TopTransactionContext
Hi, On 2013-07-11 11:53:57 -0700, Jeff Davis wrote: On Thu, 2013-07-11 at 10:28 +0200, Andres Freund wrote: There doesn't seem be an explicitly stated rule that we cannot use the syscaches outside of a transaction - but effectively that's required atm. Aren't there other things that already required that before the MVCC catalog snapshot patch went in? For instance, if you get a syscache miss, you have to load from the catalogs, meaning you need to acquire a lock. There are. Several. I am blaming it on conference induced haze. Or such. On 2013-07-11 15:09:45 -0400, Tom Lane wrote: It never has been, and never will be, allowed to call the catcache code without being in a transaction. What do you think will happen if the requested row isn't in cache? A table access, that's what, and that absolutely requires being in a transaction. Makes sense. I was confused because I thought I saw a get_database_name() and other users outside of a transaction but that turned out not looking closely enough. I'd like to add an Assert like in the attached patch making sure we're in a transaction. Otherwise it's far too easy not to hit an error during development because everything is cached - and syscache usage isn't always obvious from the outside to the naive or the tired. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services diff --git a/src/backend/utils/cache/catcache.c b/src/backend/utils/cache/catcache.c index 7fc205a..7863105 100644 --- a/src/backend/utils/cache/catcache.c +++ b/src/backend/utils/cache/catcache.c @@ -21,6 +21,7 @@ #include access/sysattr.h #include access/tuptoaster.h #include access/valid.h +#include access/xact.h #include catalog/pg_operator.h #include catalog/pg_type.h #include miscadmin.h @@ -1069,6 +1070,9 @@ SearchCatCache(CatCache *cache, SysScanDesc scandesc; HeapTuple ntp; + /* Make sure we're in a xact, even if this ends up being a cache hit */ + Assert(IsTransactionState()); + /* * one-time startup overhead for each cache */ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] docbook-xsl version for release builds
On Thu, Jul 11, 2013 at 8:34 PM, Peter Eisentraut pete...@gmx.net wrote: On 7/11/13 5:55 AM, Magnus Hagander wrote: If it's safe to switch on the old ones as well, it sounds doable. If we need different toolchains, that's going to be a serious pain. Have you verified that it's fine with the old ones as well, or are you jsut assuming? I tested it and it's fine. Second, when you say the latest debian package, you mean grab the one from sid? I didn't see anything in backports, but maybe I'm missing something? Yes, take the sid package. There likely won't be a backport because it's just plain text files in the package. Ok. If it's just that then it shouldn't be a problem wrt updates either - as in, there shouldn't be a security patch to this package ever :) Given that, I'm fine with just bumping the version on borka to that version. Any objections? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] refresh materialized view concurrently
Hitoshi Harada umi.tan...@gmail.com wrote: After a couple of more attempts trying to break it, I mark this as ready to go. Thanks. One small question: why do we use multiple unique indexes if exist? Two reasons. (1) By only matching up rows which test as equal on all columns used in primary keys, we can use UPDATE for the matches rather than DELETE and INSERT without fear of hitting a transient duplicate key error on one of the indexes. Since any update to an indexed column prevents a HOT update, and results in the equivalent of a DELETE and an INSERT anyway, there's no performance loss from letting them not match if *any* column which is part of *any* unique index doesn't match. (2) The planner can use one of the unique indexes to optimize the diff phase. How would we pick the one which is fastest? By comparing for equality on all the columns used in all unique indexes, we let the planner decide. I see no reason to try to second-guess it; just let it do it's thing. One index isn't enough? It would be enough for correctness, yes. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])
On Friday, July 12, 2013 12:02 AM Fujii Masao wrote:
On Fri, Jul 5, 2013 at 2:19 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Wednesday, July 03, 2013 2:58 AM Alvaro Herrera wrote:
Amit Kapila escribió:
I got the following compile warnings.
guc.c:5187: warning: no previous prototype for 'validate_conf_option'
preproc.y:7746.2-31: warning: type clash on default action: str !=
I generally use windows as dev environment, it hasn't shown these warnings.
I shall check in linux and correct the same.
The make installcheck failed when I ran it against the server with
wal_level = hot_standby. The regression.diff is
*** 27,35
(1 row)
show wal_level;
! wal_level
! ---
! minimal
(1 row)
show authentication_timeout;
--- 27,35
(1 row)
show wal_level;
! wal_level
! -
! hot_standby
(1 row)
show authentication_timeout;
The tests in alter_system.sql are dependent on default values of
postgresql.conf, which is okay for make check
but not for installcheck. I shall remove that dependency from testcases.
The regression test of ALTER SYSTEM calls pg_sleep(1) six times.
Those who dislike the regression test patches which were proposed
in this CF might dislike this repeat of pg_sleep(1) because it would
increase the time of regression test.
The sleep is used to ensure the effects of pg_reload_conf() can be visible.
To avoid increasing time of regression tests, we can do one of below:
1) decrease the time for sleep, but not sure how to safely decide how much to
sleep.
2) combine the tests such that only 1 or 2 sleep calls should be used.
what's your opinion?
+ /* skip auto conf temporary file */
+ if (strncmp(de-d_name,
+ PG_AUTOCONF_FILENAME,
+ sizeof(PG_AUTOCONF_FILENAME)) == 0)
+ continue;
Why do we need to exclude the auto conf file from the backup?
I think that it should be included in the backup as well as normal
postgresql.conf.
The original intention was to skip the autoconf temporary file which is
created during AlterSystemSetConfigFile()
for crash safety. I will change to exclude temp autoconf file.
+ autofile = fopen(path, PG_BINARY_W);
+ if (autofile == NULL)
+ {
+ fprintf(stderr, _(%s: could not open file \%s\ for
writing: %s\n),
+ progname, path, strerror(errno));
+ exit_nicely();
+ }
+
+ if (fputs(# Do not edit this file manually! It is overwritten by
the ALTER SYSTEM command \n,
+ autofile) 0)
+ {
+ fprintf(stderr, _(%s: could not write file \%s\: %s\n),
+ progname, path, strerror(errno));
+ exit_nicely();
+ }
+
+ if (fclose(autofile))
+ {
+ fprintf(stderr, _(%s: could not close file \%s\: %s\n),
+ progname, path, strerror(errno));
+ exit_nicely();
+ }
You can simplify the code by using writefile().
Yes, it is better to use writefile(). I shall update the patch for same.
With Regards,
Amit Kapila
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] column b is of type X but expression is of type text
A third party application we use generates SQL queries. Here is query it generated that broke today and for which I have a hard time arguing that the postgres behavior is correct (minimally the error message is confusing): =# create temporary table foo (b double precision ); CREATE TABLE Time: 40.368 ms =# insert into foo select min(NULL); ERROR: column b is of type double precision but expression is of type text LINE 1: insert into foo select min(NULL); ^ HINT: You will need to rewrite or cast the expression. So why does min(NULL) have type text? According to the docs it has the type of the input. The value is itself NULL which is a valid member of all types in SQL isn't it? So what is going on? Thanks, Bene
Re: [HACKERS] column b is of type X but expression is of type text
Benedikt Grundmann wrote A third party application we use generates SQL queries. Here is query it generated that broke today and for which I have a hard time arguing that the postgres behavior is correct (minimally the error message is confusing): =# create temporary table foo (b double precision ); CREATE TABLE Time: 40.368 ms =# insert into foo select min(NULL); ERROR: column b is of type double precision but expression is of type text LINE 1: insert into foo select min(NULL); ^ HINT: You will need to rewrite or cast the expression. So why does min(NULL) have type text? According to the docs it has the type of the input. The value is itself NULL which is a valid member of all types in SQL isn't it? So what is going on? Thanks, Bene Ideally PostgreSQL would be smart enough to recognize that min(NULL) is of an unknown type and thus would use the definition of foo to coerce NULL to the desired type. I cannot explain why it does not do this but from the example it cannot. Using a literal NULL without an explicit type-cast is not recommended as the system cannot always accurately figure out what type you mean for it to use. Being a valid value for all types does not mean it magically switches to fit whatever usage is required. Columns are typed, not values per-se, and so NULL can belong in any column but once it is part of that column it takes on that column's type. The query you show is pretty pointless since the intent of min is to take a column over which to aggregate; not a literal which will only ever return itself. In short the SELECT query is trying its best to execute and so in the presence of an unadorned NULL - and being unable to infer the type from context - it simply uses the default type which is text. The SELECT executes just fine, and outputs a min column of type text which when supplied to the table foo causes the type mis-match for column b on foo. The PostgreSQL behavior is simple because it does not infer the type of NULL from the column in foo but it is not required to do so its failure is not wrong. The error message, given what does occur, makes perfect sense and is easy enough to trace (i.e., what column is feeding foo.b from the SELECT statement; then, why is that column being seen as text). PostgreSQL is in the opinion of some too verbose in its requirement to be explicit regarding types but it does make for less buggy code overall. This particular use-case may be solvable but I'd argue that your example is not likely to convince anyone that it is a serious enough problem worth the effort it would take to do so. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/column-b-is-of-type-X-but-expression-is-of-type-text-tp5763586p5763587.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] column b is of type X but expression is of type text
On Fri, Jul 12, 2013 at 8:47 AM, Benedikt Grundmann bgrundm...@janestreet.com wrote: A third party application we use generates SQL queries. Here is query it generated that broke today and for which I have a hard time arguing that the postgres behavior is correct (minimally the error message is confusing): =# create temporary table foo (b double precision ); CREATE TABLE Time: 40.368 ms =# insert into foo select min(NULL); ERROR: column b is of type double precision but expression is of type text LINE 1: insert into foo select min(NULL); ^ HINT: You will need to rewrite or cast the expression. So why does min(NULL) have type text? According to the docs it has the type of the input. The value is itself NULL which is a valid member of all types in SQL isn't it? So what is going on? This is not a question for -hackers. Postgres is strictly typed -- there is no variant type. So even though some functions can configured to support multiple input types via overloading, 'any' arguments, etc. when stuff actually gets done type coercion has to take place and text is chosen as a type of last resort. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] column b is of type X but expression is of type text
Thanks David, I like the fact that postgres is explicit in it's types. All I'm arguing is that error message is misleading. And that I had a hard time understanding why happened what happened. The part I was missing is that despite supporting an any type the necessary type inference is very very local and quickly resorts to the default type. thanks everyone, Bene On Fri, Jul 12, 2013 at 3:17 PM, David Johnston pol...@yahoo.com wrote: Benedikt Grundmann wrote A third party application we use generates SQL queries. Here is query it generated that broke today and for which I have a hard time arguing that the postgres behavior is correct (minimally the error message is confusing): =# create temporary table foo (b double precision ); CREATE TABLE Time: 40.368 ms =# insert into foo select min(NULL); ERROR: column b is of type double precision but expression is of type text LINE 1: insert into foo select min(NULL); ^ HINT: You will need to rewrite or cast the expression. So why does min(NULL) have type text? According to the docs it has the type of the input. The value is itself NULL which is a valid member of all types in SQL isn't it? So what is going on? Thanks, Bene Ideally PostgreSQL would be smart enough to recognize that min(NULL) is of an unknown type and thus would use the definition of foo to coerce NULL to the desired type. I cannot explain why it does not do this but from the example it cannot. Using a literal NULL without an explicit type-cast is not recommended as the system cannot always accurately figure out what type you mean for it to use. Being a valid value for all types does not mean it magically switches to fit whatever usage is required. Columns are typed, not values per-se, and so NULL can belong in any column but once it is part of that column it takes on that column's type. The query you show is pretty pointless since the intent of min is to take a column over which to aggregate; not a literal which will only ever return itself. In short the SELECT query is trying its best to execute and so in the presence of an unadorned NULL - and being unable to infer the type from context - it simply uses the default type which is text. The SELECT executes just fine, and outputs a min column of type text which when supplied to the table foo causes the type mis-match for column b on foo. The PostgreSQL behavior is simple because it does not infer the type of NULL from the column in foo but it is not required to do so its failure is not wrong. The error message, given what does occur, makes perfect sense and is easy enough to trace (i.e., what column is feeding foo.b from the SELECT statement; then, why is that column being seen as text). PostgreSQL is in the opinion of some too verbose in its requirement to be explicit regarding types but it does make for less buggy code overall. This particular use-case may be solvable but I'd argue that your example is not likely to convince anyone that it is a serious enough problem worth the effort it would take to do so. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/column-b-is-of-type-X-but-expression-is-of-type-text-tp5763586p5763587.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])
On 07/12/2013 09:15 AM, Amit kapila wrote: guc.c:5187: warning: no previous prototype for 'validate_conf_option' preproc.y:7746.2-31: warning: type clash on default action: str != I generally use windows as dev environment, it hasn't shown these warnings. Hackers, please take note. Assertions that nobody uses Windows for development are false. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: simple date constructor from numeric values
There is a small inconsistency: select time '12:30:57.123456789'; gives 12:30:57.123457 but select make_time(12, 30, 57.123456789); gives 12:30:57.123456 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] column b is of type X but expression is of type text
On 07/12/2013 07:28 AM, Benedikt Grundmann wrote:
Thanks David,
I like the fact that postgres is explicit in it's types. All I'm arguing
is that error message is misleading. And that I had a hard time
understanding why happened what happened. The part I was missing is that
despite supporting an any type the necessary type inference is very very
local and quickly resorts to the default type.
No argument that it would be nice to have a more apropos error message.
However, that's harder to achieve than you realize.
Here's a simplified version what happens:
1. you hand PostgreSQL an unadorned NULL. It realizes it doesn't have a
type, and makes it temporarily the default type (text) in hopes that the
next stage will provide a type.
2. you call min(). Min() works for many datatypes. Min() says: can I
work for text? The answer is yes, so at this point the NULL which
was default text becomes *really* text.
3. you try to assign the result of MIN() to a column of type double.
This is when the error is encountered. The planner/executor doesn't
know that the reason min() is emitting text is because you handed it an
unadorned NULL; it just knows that it was expecting a double, and it got
text. At this point, it can't tell the difference between min(NULL) and
min('Josh'::TEXT).
To get a better error message, the query engine would need to reach back
to step (1) when it encounters the error at step (3).
The alternative would be to disallow unadorned NULLs entirely, which
would break thousands of applications.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])
On 07/12/2013 06:15 AM, Amit kapila wrote: I generally use windows as dev environment, it hasn't shown these warnings. I shall check in linux and correct the same. Really? Hey, I'm gonna send you a lot of Windows-specific patches for testing in the future ... -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] LATERAL quals revisited
On 07/04/2013 06:11 PM, Antonin Houska wrote:
On 07/03/2013 08:32 PM, Tom Lane wrote:
Another possibility would be to keep the optimization, but disable it in
queries that use LATERAL. I don't much care for that though --- seems
too Rube Goldbergish, and in any case I have a lot less faith in the
whole concept now than I had before I started digging into this issue.
Thoughts?
I noticed EXPLAIN in some regression tests. So if they all pass after
removal of this optimization, it might indicate that it was really
insignificant. But alternatively it may just be a lack of focus on
this feature in the test queries. Digging for (non-LATERAL) queries or
rather patterns where the ph_may_need optimization clearly appears to
be important sounds to me like a good SQL exercise, but I'm afraid I
won't have time for it in the next few days.
I constructed a query that triggers the optimization - see attachment
with comments. (Note that the relid sets are derived from my current
knowledge of the logic. I haven't figured out how to check them easily
in gdb session.)
The intention was that the top-level OJ references LHS of the join below
rather than the RHS. That should increase the likelihood that the PHV
becomes the only obstacle for join commuting. And therefore the
ph_may_need optimization should unblock some combinations that would be
impossible otherwise.
However I could not see the condition
if (bms_is_subset(phinfo-ph_may_need, min_righthand))
continue;
met for the top-level join even though the supposed ph_may_need did not
contain tab1. Then it struck me that min_righthand can be the problem.
So I changed the join clause to reference RHS of j1, hoping that it
should make min_righthand bigger. And that really triggered the condition.
EXPLAIN shows the same plan with or without the ph_may_need
optimization, but that might be data problem (my tables are empty).
More important is the fact that I could only avoid addition of the PHV's
eval_at to min_righthand at the cost of adding the whole j1 join (i.e.
more than just eval_at).
Although the idea behind ph_may_need is clever, I can now imagine that
other techniques of the planner can substitute for it. There might be
examples showing the opposite but such are beyond my imagination.
// Antonin Houska (Tony)
SELECT tab1.i
FROMtab1
-- The ph_may_need optimization should be effective for the
-- top-level LEFT JOIN. The PHV in sub1 is only referenced below it.
LEFT JOIN
( tab2
LEFT JOIN
( tab3
LEFT JOIN
( SELECT
-- This expression should be wrapped in the PHV
-- That PHV should have eval_at = {tab4, tab5}.
--
-- Join clause of j1 is the highest reference to the PHV.
-- Thus ph_may_need should be {tab2, tab3, tab4, tab5}. Therefore
-- the ph_may_need optimization should avoid addition of eval_at
-- to min_righthand of the top-level join's SpecialJoinInfo.
COALESCE(tab4.l, tab5.m, 1) AS x
FROM tab4
LEFT JOIN
tab5
ON l = m
) AS sub1(x)
ON tab3.k = sub1.x
) AS j2(k, x)
ON tab2.j = j2.x
) AS j1(j, k)
-- This clause references j.k (RHS of the lower join) to keep min_righthand
-- of the top-level join bigger (ph_may_need needs to be its subset).
ON tab1.i = j1.k;
CREATE TABLE tab1(i int);
CREATE TABLE tab2(j int);
CREATE TABLE tab3(k int);
CREATE TABLE tab4(l int);
CREATE TABLE tab5(m int);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [9.4 CF 4] Sudden Death Overtime in 3 days
Hackers, This CF will be officially over in 3 days. On the 16th, we will do the following: (1) Patches still marked waiting on author will become returned with feedback. (2) Patches marked needs review will be examined to see if they received one good review during the CF. If they did, they will be moved to the next CF. If they didn't, they will remain pending. (3) Patches marked ready for committer will wait on the availability of the committers. We still have: Needs Review: 16 Waiting on Author: 17 Ready for Committer: 14 As such, we really appreciate everyone's efforts to wrap up this CF as soon as possible. For anyone keeping track, this has been a high-water-mark for a CF1, with 106 patches to start. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] column b is of type X but expression is of type text
Josh Berkus wrote
On 07/12/2013 07:28 AM, Benedikt Grundmann wrote:
Thanks David,
I like the fact that postgres is explicit in it's types. All I'm arguing
is that error message is misleading. And that I had a hard time
understanding why happened what happened. The part I was missing is that
despite supporting an any type the necessary type inference is very very
local and quickly resorts to the default type.
2. you call min(). Min() works for many datatypes. Min() says: can I
work for text? The answer is yes, so at this point the NULL which
was default text becomes *really* text.
.
.
.
The alternative would be to disallow unadorned NULLs entirely, which
would break thousands of applications.
In the absence of the function call the system is able to delay resolving
the type until later in the query:
SELECT *
FROM (VALUES ('2013-02-01'::date), ('2013-01-01'), (NULL) ) vals (col1);
--works
SELECT *
FROM (VALUES ('2013-02-01'::date), ('2013-01-01'), (min(NULL)) ) vals
(col1); --fails
I have no idea how this mechanism works but ISTM that the planner could, for
anyelement, look at where the result of the function call is used and add
a cast to the function input value to match the desired result type if the
input type is undefined.
I'm curious what you would consider to be a more apropos error message in
this situation; regardless of how difficult it would be to implement.
I am also curious if you can think of a better example of where this
behavior is problematic. The query for this thread is not something that I
would deem to be good SQL.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/column-b-is-of-type-X-but-expression-is-of-type-text-tp5763586p5763615.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Kudos for Reviewers -- wrapping it up
Folks, Well, I didn't get much in the way of poll responses for the straw poll. However, let me sum up: -- two hackers thought that reviewers didn't deserve any credit at all. -- of the majority of respondants, things were about evenly split between people who favored big list at the end and people who favored reviewer next to feature. Notably, those who favored reviewer next to feature also thought that our standards for what constitutes a review should be more stringent. -- reviewers, in general, were unanimous that the only thing which mattered in terms of rewarding reviewers was credit in the release notes, and that other rewards were nice but inconsequential. -- a couple of compromise proposals were made: a) that reviewers who do actual code modification of the patch get credited on the feature, and those who just review it get credited at the bottom of the release notes, or b) that all names move to a web page on www.postgresql.org and come out of the release notes entirely. Speaking as a commitfest manager, I favor compromise proposal (a), personally. Does (a) seem somehow terrible to anyone? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Kudos for Reviewers -- wrapping it up
Josh Berkus wrote: -- a couple of compromise proposals were made: a) that reviewers who do actual code modification of the patch get credited on the feature, and those who just review it get credited at the bottom of the release notes, or b) that all names move to a web page on www.postgresql.org and come out of the release notes entirely. Speaking as a commitfest manager, I favor compromise proposal (a), personally. Does (a) seem somehow terrible to anyone? I like (a) myself, though I'd amend it so that extensive work on the patch is required to qualify as co-author, which may or may not be code. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Kudos for Reviewers -- wrapping it up
On 07/12/2013 01:28 PM, Alvaro Herrera wrote: Josh Berkus wrote: -- a couple of compromise proposals were made: a) that reviewers who do actual code modification of the patch get credited on the feature, and those who just review it get credited at the bottom of the release notes, or b) that all names move to a web page on www.postgresql.org and come out of the release notes entirely. Speaking as a commitfest manager, I favor compromise proposal (a), personally. Does (a) seem somehow terrible to anyone? I like (a) myself, though I'd amend it so that extensive work on the patch is required to qualify as co-author, which may or may not be code. I'd probably say substantial or non-trivial, but otherwise +1 cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] column b is of type X but expression is of type text
David, I have no idea how this mechanism works but ISTM that the planner could, for anyelement, look at where the result of the function call is used and add a cast to the function input value to match the desired result type if the input type is undefined. Well, that's not how anyelement works, actually. And the input type for min() is not anyelement. I'm curious what you would consider to be a more apropos error message in this situation; regardless of how difficult it would be to implement. ERROR: unable to determine appropriate type for 'NULL' But again, don't hold your breath, per above. I am also curious if you can think of a better example of where this behavior is problematic. The query for this thread is not something that I would deem to be good SQL. Yeah, but it gets generated a lot. And per your other example, sometimes it *does* work, so developers/ORM authors start to rely on it. And then it breaks. Mostly the problematic cases are involving function parameters, where adding a new version of a function can suddently cause a call with an unadorned NULL to break, when it used to work. For example, suppose I have only one function dingbat dingbat( timestamptz, text, text, float ) I can easily call it with: SELECT dingbat( '2013-01-01', 'Josh', 'pgsql-hackers', NULL ) But if someone else adds a second function, possibly due to a typo with the version control system: dingbat(timestamptz, text, text, text) ... then the above SELECT call will automatically choose the second function, because NULL defaults to TEXT if unadorned. Among other things, that could make a fun exploit if people have been careless with their SECURITY DEFINER functions. A worse example is the CIText type. A couple versions ago, I attempted to force default case-insensitive comparisons for: 'val'::CITEXT = 'val'::TEXT ... which is what the user would intuitively believe would happen, instead of the case-sensitive comparison, which is what *does* happen. After a long weekend of messy bug-hunting and breaking built-in postgresql functions, I gave up. The root cause of this is that we treat default TEXT the same as real TEXT as a type. Changing that logic, though, would require a massive refactoring and debugging of PostgreSQL. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Kudos for Reviewers -- wrapping it up
On 07/12/2013 10:49 AM, Andrew Dunstan wrote: On 07/12/2013 01:28 PM, Alvaro Herrera wrote: Josh Berkus wrote: -- a couple of compromise proposals were made: a) that reviewers who do actual code modification of the patch get credited on the feature, and those who just review it get credited at the bottom of the release notes, or I'd probably say substantial or non-trivial, but otherwise +1 Right cause if a reviewer ends up writing (or cleaning up) all the docs, I would say they deserve very close to equal credit. As an example. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579 PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc For my dreams of your image that blossoms a rose in the deeps of my heart. - W.B. Yeats -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL renegotiation
Troels Nielsen escribió: Hi, These are the relevant bits from Apache2.4's mod_ssl. [snip] So this is basically the same thing the Pg code is doing. That code supports at least OpenSSL 0.9.7 and later. Some explanation for it can be found here: http://books.google.dk/books?id=IIqwAy4qEl0Cpg=PT184lpg=PT184dq=SSL_do_handshakesource=blots=ma632U4vWvsig=d2qqS0svhu4EwIZZaONdHoTulVIhl=ensa=Xei=xdPdUczoDuf34QSzmoDQDgved=0CIIDEOgBMCo The snippet there is probably the textbook implementation. Ah, thanks for the pointer. I notice this book is from 2002 and documents OpenSSL 0.9.6. So yeah, that's what both mod_ssl and Pg implement. However, reading the text carefully, I see that this snippet is the correct implementation for 0.9.6 and earlier; the same book, speaking about the 0.9.7 release in the future tense, explains that in that release it will be much easier to do renegotiations, without getting into precise details of how exactly is to be done (I suppose the OpenSSL team hadn't finalized the API yet). As far as I can understand, what I propose is the right sequence. Now, should we support the 0.9.6-and-earlier mechanism? My inclination is no; even RHEL 3, the oldest supported Linux distribution, uses 0.9.7 (Heck, even Red Hat Linux 9, released on 2003). To see OpenSSL 0.9.6 you need to go back to Red Hat Linux 7.2, released on 2001 using a Linux kernel 2.4. Surely no one in their right mind would use a current Postgres release on such an ancient animal. So I continue to maintain that we should rip the old mechanism out and replace it with current renegotiation. Now, I've read a bit more of the code and it seems that we should be doing SSL_renegotiate() and then check the SSL_renegotiate_pending() result until it returns that the renegotiation has completed. So the original code looks OK. Perhaps the check on the return code of the first SSL_do_handshake (and SSL_renegotiate) is unnecessary and may lead to unwarranted error messages, though. And it may be wrong to continue the renegotiation if the state is not SSL_ST_OK after the first SSL_do_handshake. If the renegotiation fails, I suppose two things can be done: 1. Quit the connection 2. Carry on pretending nothing happened. I think 2. is correct in the vast majority of cases (as it looks like is being done now). And in that case: not resetting port-count will make for a very slow and awkward connection as new handshakes will be attempted again and again, even if the other party persistently refuse to shake hands. Good point. From a security point of view, it seems that the correct reaction is to close the connection if renegotiation doesn't complete. Along the same lines, it seems to me that accepting SSLv2 (which doesn't support renegotiations at all) when renegotiations have been requested is not a good choice; we should accept only SSLv3 in that case. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bugfix and new feature for PGXS
Le lundi 8 juillet 2013 21:46:39, Andrew Dunstan a écrit : On 07/08/2013 03:40 PM, Josh Berkus wrote: On 07/04/2013 06:18 AM, Andrew Dunstan wrote: On 07/04/2013 09:14 AM, Cédric Villemain wrote: ah yes, good catch, I though .control file were unique per contrib, but there aren't. It's already been fixed. Does it look like this patch will get into committable shape in the next couple of days? I think everything has been committed - as I think the CF app shows. The only thing left in this srea from Cédric is the insallation of headers, which Peter is down to review and is in Waiting on Author status. which is returned with feedback now, I can update if someone really wants it. We are owed a docco patch though. Simple one, attached. I didn't document USE_VPATH, not sure how to explain that clearly. -- Cédric Villemain +33 (0)6 20 30 22 52 http://2ndQuadrant.fr/ PostgreSQL: Support 24x7 - Développement, Expertise et Formation From 1380870e061362b871c375c25517005f82358dc3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?C=C3=A9dric=20Villemain?= ced...@2ndquadrant.fr Date: Fri, 12 Jul 2013 23:39:11 +0200 Subject: [PATCH] add documentation for commit 6697aa2 Document that PGXS offers VPATH build and add a sample like in installation.sgml Also update the part about the PGXS global makefile inclusion. It was suggested to put it at the end, but if the Makefile contains a target before the include of pgxs then the default all: target is removed and the Makefile must define all: itself. --- doc/src/sgml/extend.sgml | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/doc/src/sgml/extend.sgml b/doc/src/sgml/extend.sgml index 60fa1a8..8f082e4 100644 --- a/doc/src/sgml/extend.sgml +++ b/doc/src/sgml/extend.sgml @@ -935,7 +935,7 @@ include $(PGXS) To use the acronymPGXS/acronym infrastructure for your extension, you must write a simple makefile. In the makefile, you need to set some variables -and finally include the global acronymPGXS/acronym makefile. +and include the global acronymPGXS/acronym makefile. Here is an example that builds an extension module named literalisbn_issn/literal, consisting of a shared library containing some C code, an extension control file, a SQL script, and a documentation @@ -1161,6 +1161,19 @@ include $(PGXS) or on the literalmake/literal command line. /para + para +You can also run literalmake/literal in a directory outside the source +tree of your extension, if you want to keep the build directory separate. +This procedure is also called a +indextermprimaryVPATH/primary/indextermfirsttermVPATH/firstterm +build. Here's how: +screen + userinputmkdir build_dir/userinput + userinputcd build_dir/userinput + userinputmake -f /path/to/extension/source/tree/Makefile/userinput + userinputmake -f /path/to/extension/source/tree/Makefile install/userinput +/screen + /para caution para Changing varnamePG_CONFIG/varname only works when building -- 1.7.10.4 signature.asc Description: This is a digitally signed message part.
Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax
Next version:
- cleanup
- regression test
- fix issue reported by johto (invalid values in parallel transactions)
I would like more feedback and comments about the patch, as some parts
may be too hacky.
In particular, is it a problem that I update a pointer to planSlot? In
my patch, it points to tuple after all updates done between planner and
executor (in fact it is not planSlot right now). I don't know whether
the tuple could be deleted in the intervening time and if the pointer
doesn't point to unreserved memory (I mean - memory which may be
overwritten by something meanwhile).
Regards,
Karol
diff --git a/doc/src/sgml/ref/update.sgml b/doc/src/sgml/ref/update.sgml
index 90b9208..eba35f0 100644
--- a/doc/src/sgml/ref/update.sgml
+++ b/doc/src/sgml/ref/update.sgml
@@ -194,12 +194,27 @@ UPDATE [ ONLY ] replaceable class=PARAMETERtable_name/replaceable [ * ] [
termreplaceable class=PARAMETERoutput_expression/replaceable/term
listitem
para
- An expression to be computed and returned by the commandUPDATE/
- command after each row is updated. The expression can use any
- column names of the table named by replaceable class=PARAMETERtable_name/replaceable
- or table(s) listed in literalFROM/.
- Write literal*/ to return all columns.
+ An expression to be computed and returned by the
+ commandUPDATE/ command either before or after (prefixed with
+ literalBEFORE./literal and literalAFTER./literal,
+ respectively) each row is updated. The expression can use any
+ column names of the table named by replaceable
+ class=PARAMETERtable_name/replaceable or table(s) listed in
+ literalFROM/. Write literalAFTER.*/literal to return all
+ columns after the update. Write literalBEFORE.*/literal for all
+ columns before the update. Write literal*/literal to return all
+ columns after update and all triggers fired (these values are in table
+ after command). You may combine BEFORE, AFTER and raw columns in the
+ expression.
/para
+ warningpara
+ Mixing table names or aliases named before or after with the
+ above will result in confusion and suffering. If you happen to
+ have a table called literalbefore/literal or
+ literalafter/literal, alias it to something else when using
+ RETURNING.
+ /para/warning
+
/listitem
/varlistentry
@@ -287,15 +302,16 @@ UPDATE weather SET temp_lo = temp_lo+1, temp_hi = temp_lo+15, prcp = DEFAULT
/para
para
- Perform the same operation and return the updated entries:
+ Perform the same operation and return information on the changed entries:
programlisting
UPDATE weather SET temp_lo = temp_lo+1, temp_hi = temp_lo+15, prcp = DEFAULT
WHERE city = 'San Francisco' AND date = '2003-07-03'
- RETURNING temp_lo, temp_hi, prcp;
+ RETURNING temp_lo AS new_low, temp_hi AS new_high, BEFORE.temp_hi/BEFORE.temp_low AS old_ratio, AFTER.temp_hi/AFTER.temp_low AS new_ratio prcp;
/programlisting
/para
+
para
Use the alternative column-list syntax to do the same update:
programlisting
diff --git a/src/backend/commands/trigger.c b/src/backend/commands/trigger.c
index d86e9ad..fafd311 100644
--- a/src/backend/commands/trigger.c
+++ b/src/backend/commands/trigger.c
@@ -2335,7 +2335,7 @@ ExecASUpdateTriggers(EState *estate, ResultRelInfo *relinfo)
TupleTableSlot *
ExecBRUpdateTriggers(EState *estate, EPQState *epqstate,
ResultRelInfo *relinfo,
- ItemPointer tupleid, TupleTableSlot *slot)
+ ItemPointer tupleid, TupleTableSlot *slot, TupleTableSlot **planSlot)
{
TriggerDesc *trigdesc = relinfo-ri_TrigDesc;
HeapTuple slottuple = ExecMaterializeSlot(slot);
@@ -2381,6 +2381,7 @@ ExecBRUpdateTriggers(EState *estate, EPQState *epqstate,
if (newSlot != NULL)
{
slot = ExecFilterJunk(relinfo-ri_junkFilter, newSlot);
+ *planSlot = newSlot;
slottuple = ExecMaterializeSlot(slot);
newtuple = slottuple;
}
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index e934c7b..27859dd 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -599,7 +599,7 @@ ExecUpdate(ItemPointer tupleid,
resultRelInfo-ri_TrigDesc-trig_update_before_row)
{
slot = ExecBRUpdateTriggers(estate, epqstate, resultRelInfo,
- tupleid, slot);
+ tupleid, slot, planSlot);
if (slot == NULL) /* do nothing */
return NULL;
@@ -733,6 +733,7 @@ lreplace:;
hufd.xmax);
if (!TupIsNull(epqslot))
{
+ planSlot = epqslot;
*tupleid = hufd.ctid;
slot = ExecFilterJunk(resultRelInfo-ri_junkFilter, epqslot);
tuple = ExecMaterializeSlot(slot);
diff --git a/src/backend/nodes/nodeFuncs.c b/src/backend/nodes/nodeFuncs.c
index 42d6621..cc68568 100644
--- a/src/backend/nodes/nodeFuncs.c
+++ b/src/backend/nodes/nodeFuncs.c
@@ -1920,6 +1920,7 @@ range_table_walker(List *rtable,
{
case
Re: [HACKERS] [PERFORM] In progress INSERT wrecks plans on table
On Wed, Jul 10, 2013 at 10:09 PM, Abhijit Menon-Sen a...@2ndquadrant.com wrote: At 2013-07-10 09:47:34 -0700, j...@agliodbs.com wrote: Due to the apparent lack of performance testing, I'm setting this back to needs review. The original submission (i.e. the message linked from the CF page) includes test results that showed a clear performance improvement. I think the reviewer of a performance patch should do some independent testing of the performance, to replicate the author's numbers; and hopefully with a few different scenarios. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [Review] Add SPI_gettypmod() to return a field's typemod from a TupleDesc / audit of [E] TODO items
On Sun, Jul 07, 2013 at 08:15:00PM -0400, Noah Misch wrote: I mildly recommend we reject this patch as such, remove the TODO item, remove the XXX comments this patch removes, and plan not to add more trivial SPI wrappers. Seeing just the one response consistent with that view, done. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Review] Add SPI_gettypmod() to return a field's typemod from a TupleDesc / audit of [E] TODO items
On Jul 12, 2013, at 4:29 PM, Noah Misch n...@leadboat.com wrote: On Sun, Jul 07, 2013 at 08:15:00PM -0400, Noah Misch wrote: I mildly recommend we reject this patch as such, remove the TODO item, remove the XXX comments this patch removes, and plan not to add more trivial SPI wrappers. Seeing just the one response consistent with that view, done. Shucks. :) Thanks for reviewing everyone. Regards, Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SSL renegotiation
On Fri, Jul 12, 2013 at 04:32:52PM -0400, Alvaro Herrera wrote: Now, should we support the 0.9.6-and-earlier mechanism? My inclination is no; even RHEL 3, the oldest supported Linux distribution, uses 0.9.7 (Heck, even Red Hat Linux 9, released on 2003). To see OpenSSL 0.9.6 you need to go back to Red Hat Linux 7.2, released on 2001 using a Linux kernel 2.4. Surely no one in their right mind would use a current Postgres release on such an ancient animal. Agreed. The OpenSSL Project last applied a security fix to 0.9.6 over eight years ago. Compatibility with 0.9.6 has zero or negative value. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] --with-libedit-preferred is bad design
Hackers, So I've been trying to compile PostgreSQL with libedit instead of readline on a linux system, because of a bug in readline (will blog about it later). This took 5 attempts, because of the peculiar nature of our readline options in configure: --without-readline compile without readline *or* libedit --with-libedit-preferred compile with libedit, but if there's an issue with libedit, then silently substitute readline without telling me There's no option where I can say please compile with libedit, and if you can't, throw an error. In fact, if libedit isn't found, that's not even reported in config.log -- your only way to find out you still have readline is to ldd your psql after it's built. For that matter, I find it hard to imagine where I would possibly want the current functionality of --with-libedit-preferred. If I've asked for libedit, then it's pretty darned sure it's because I don't want readline. I think the current --with-libedit-preferred should go away, and be replaced by a --with-libedit option which throws an error if libedit isn't found. Feedback? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] column b is of type X but expression is of type text
Josh Berkus j...@agliodbs.com writes: The root cause of this is that we treat default TEXT the same as real TEXT as a type. No, we do not do that at all. A NULL is initially of type unknown, and that is definitely not the same as text. The type resolution rules treat the two cases differently. The real cause of what David is complaining about is that we resolve expression datatypes bottom up. Once we've determined that we're going to consider foo(NULL) as an invocation of foo(text), that's what it is, and the context won't cause us to go back and change that. Changing that logic, though, would require a massive refactoring and debugging of PostgreSQL. This is true enough; and you forgot to mention all the existing applications that would also need changes if we changed the expression resolution rules. We could possibly make marginal changes without too much pain, but making function resolution context-dependent would hardly be a marginal change. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] --with-libedit-preferred is bad design
Josh Berkus j...@agliodbs.com writes: I think the current --with-libedit-preferred should go away, and be replaced by a --with-libedit option which throws an error if libedit isn't found. I'm not sure that will work well on systems where libedit masquerades as readline... TBH, given the number of bugs we've hit in libedit, encouraging its use isn't something we should put effort into anyway. Or is it just that Apple seems incapable of finding non-broken versions to ship? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgbench patches
Hello Tatsuo, For me, the error message is not quite right, because progress == 0 case is considered error as well in your patch. I sugges you change the error message something like: thread progress delay (-P) must be positive number (%s)\n, Please find attached a new version with an updated message. Thanks. I've been testing on Linux now. Starting from coming Tuesday (Monday is a national holiday in Japan) I will test on Mac OS X and Windows. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] --with-libedit-preferred is bad design
On 07/12/2013 06:31 PM, Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: I think the current --with-libedit-preferred should go away, and be replaced by a --with-libedit option which throws an error if libedit isn't found. I'm not sure that will work well on systems where libedit masquerades as readline... Ah, was that the thinking behind that? In that case, maybe we could put a warning in the config.log that libedit wasn't found? Right now, there's nothing. TBH, given the number of bugs we've hit in libedit, encouraging its use isn't something we should put effort into anyway. Or is it just that Apple seems incapable of finding non-broken versions to ship? That would hardly be only true of libedit, on Apple. It's also broken on some Red Hat versions, last I checked. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])
On Friday, July 12, 2013 10:07 PM Josh Berkus wrote: On 07/12/2013 06:15 AM, Amit kapila wrote: I generally use windows as dev environment, it hasn't shown these warnings. I shall check in linux and correct the same. Really? Yes. Hey, I'm gonna send you a lot of Windows-specific patches for testing in the future ... I would be happy to participate as much as I can. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] --with-libedit-preferred is bad design
On 7/12/2013 7:10 PM, Josh Berkus wrote: That would hardly be only true of libedit, on Apple. It's also broken on some Red Hat versions, last I checked. Last I heard, libedit was completely borked. Here is a report (two years old) of still broken libedit in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442 IMO, we either need to take up the mantle of libedit maintenance or we need to remove it from a configure option, it doesn't work anyway. JD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
