Re: [HACKERS] Why isn't stats_temp_directory automatically created?
Hi, On Wed, Apr 15, 2009 at 5:37 PM, Magnus Hagander wrote: > This does not take into account the effect of symlinks as mentioned by > Itakagi Takahiro. I haven't looked at the details, but I don't think it > would be that much more work to deal with it - and as he mentions, this > is a very common usecase. Okey, I'll revise the patch; create also the directory which is referenced by symlink if not present. > Also, wouldn't it be better to isolate this to the first time when we > try to create the file - then we don't have to export the symbol? You mean having assign_pgstat_temp_directory() create the directory instead of pgstat_start()? In this case, the directory is created automatically not only at the beginning but also when a configuration file is reloaded. This seems to be better behavior. One problem of this is that some directories may be created unexpectedly if stats_temp_directory is specified at multiple locations. It's because assign_hook is called for each setting. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] [GENERAL] Performance of full outer join in 8.3
On Wed, 2009-04-15 at 20:58 -0400, Robert Haas wrote: > On Wed, Apr 15, 2009 at 7:39 PM, Tom Lane wrote: > > The output of EXPLAIN is nowhere near stable enough to use within the > > current exact-match regression test framework. I'm not sure it would > > be stable even if we suppressed the rowcount and cost figures. Those > > figures vary across platforms (because of alignment effects and probably > > other things) and are also sensitive to the timing of autovacuums. It > > is known that a nontrivial fraction of the existing regression test > > cases do suffer from uninteresting plan changes across platforms or > > as a result of various phase-of-the-moon effects; that's why we keep > > having to add "ORDER BY" clauses now and then. > > Interesting. I suppose you could insulate yourself from this somewhat > by populating pg_statistic with a particular set of values rather than > relying on ANALYZE to gather them, but this would have the substantial > downside of being way more work to maintain, especially if anyone ever > changed pg_statistic. > > On a more practical level, I do think we need to give real > consideration to some kind of options syntax for EXPLAIN, maybe > something as simple as: > > EXPLAIN (option_name, ...) query > > Or maybe: > > EXPLAIN (option_name = value, ...) query > > It may or may not be the case that generating a useful regression test > suite for the planner is too much work for anyone to bother, but they > certainly won't if the tools aren't available. It seems we get at > least one request a month for some kind of explain-output option: > suppress row counts, suppress costs, gather I/O statistics, show > outputs, show # of batches for a hash join, and on and on and on. I > think we should implement a very basic version that maybe does nothing > more than let you optionally suppress some of the existing output, but > which provides an extensible syntax for others to build on. I think the way to do this is to introduce plan output in XML (that matches the node structure of the plan). We can then filter away any junk we don't want to see for regression tests, or better still augment the exact-match framework with a fuzzy-match spec that allows us to specify a range of values. The skill would be in constructing a set of tests that was not sensitive to minor changes. The OP's join for example had a huge cost range difference that would have clearly shown up in a regression test. This will only move forward if it adds value directly for Tom, so if it's worth doing then he needs to specify it and ask for someone to do it. There will be someone available if the task is well defined. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] Unicode string literals versus the world
> > >>> I still stand on my proposal, how about extending E'' strings with
> > >>> unicode escapes (eg. \u)? The E'' strings are already more
> > >>> clearly defined than '' and they are our "own", we don't need to
> > >>> consider random standards, but can consider our sanity.
> > >>>
> > >> I suspect there would be lots more support in the user community, where
> > >> \u is well understood in a number of contexts (Java and ECMAScript,
> > >> for example). It's also tolerably sane.
> > >>
> > >
> > > By the way, that's an example of how to do it wrong, there are more
> > > than 2^16 unicode characters, you want to be able to support the full
> > > 21-bit range if you're going to do it right.
> > >
> > > FWIW, I prefer the perl syntax which simply extends \x: \x{1344}, which
> > > makes it clear it's hex and doesn't make assumptions as to how many
> > > characters are used.
> > >
> >
> > I could live with either. Wikipedia says: "The characters outside the
> > first plane usually have very specialized or rare use." For years we
> > rejected all characters beyond the first plane, and while that's fixed
> > now, the volume of complaints wasn't huge.
>
> I you mean "first plane" as BMP (i.e. 16bit range), above is not true
> for PostgreSQL 7.3 or later at least.
Oops. I meant 8.2 or later.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
--
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] Unicode string literals versus the world
> >>> I still stand on my proposal, how about extending E'' strings with
> >>> unicode escapes (eg. \u)? The E'' strings are already more
> >>> clearly defined than '' and they are our "own", we don't need to
> >>> consider random standards, but can consider our sanity.
> >>>
> >> I suspect there would be lots more support in the user community, where
> >> \u is well understood in a number of contexts (Java and ECMAScript,
> >> for example). It's also tolerably sane.
> >>
> >
> > By the way, that's an example of how to do it wrong, there are more
> > than 2^16 unicode characters, you want to be able to support the full
> > 21-bit range if you're going to do it right.
> >
> > FWIW, I prefer the perl syntax which simply extends \x: \x{1344}, which
> > makes it clear it's hex and doesn't make assumptions as to how many
> > characters are used.
> >
>
> I could live with either. Wikipedia says: "The characters outside the
> first plane usually have very specialized or rare use." For years we
> rejected all characters beyond the first plane, and while that's fixed
> now, the volume of complaints wasn't huge.
I you mean "first plane" as BMP (i.e. 16bit range), above is not true
for PostgreSQL 7.3 or later at least.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
--
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] NOTIFY / LISTEN silently parses and discards schema-ish portion of notification name ...
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Considered unexpected behavior, or at least in its undocumented form. > If value given to NOTIFY seems schema-qualified, the schema > qualification is eroded by the time it is presented to the listener -- See: http://archives.postgresql.org//pgsql-patches/2007-02/msg00437.php Pretty sure 8.4 will not use "relation". - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200904152332 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAknmpxMACgkQvJuQZxSWSsgifwCggRQSGppTLQ8zYCVsUUjI3ItR s0kAnRnpWhmU4AYdQzmEaM5pfEhsfv4z =FJc+ -END PGP SIGNATURE- -- 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] psql with "Function Type" in \df
David Fetter wrote: > On Wed, Apr 15, 2009 at 08:54:10PM -0400, Alvaro Herrera wrote: > > The "translator: " comment needs to be in the line just above the > > string. > > Is this any better? Yeah, this one is good (as far as this very minor detail is concerned anyway) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] NOTIFY / LISTEN silently parses and discards schema-ish portion of notification name ...
Considered unexpected behavior, or at least in its undocumented form. If value given to NOTIFY seems schema-qualified, the schema qualification is eroded by the time it is presented to the listener -- the [ nonexistent ] schema-ish-looking 'foo.' portion of 'foo.bar' is not presented at all to the listening end -- just 'bar' - $ psql Welcome to psql 8.2.11, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit social=# listen foo.bar; LISTEN social=# notify foo.bar; NOTIFY Asynchronous notification "bar" received from server process with PID 5663. social=# \q --- I expect this behavior is for the benefit of notify / listen users who happen to pass table name values over and / or when postgres became schema aware -- are listen condition names implicitly separated by schemas [ but if so, why would a listen for a schema-qualified name 'foo.bar' succeed when schema 'foo' does not exist? Create table certainly wouldn't. ] The docs for listen / notify don't mention any sort of parsing / value filtering of the notification signal value if it smelt schema qualified, just that a common use is for it to hold a table name. I wandered into this surprise by holding a dotted constant shared between my notifier and my listener [ who listens for a few different types of events, separated by notification names ], but the listener didn't receive the expected string with schema qualification, it got the eroded value instead -- easily worked around by not using constants containing dotted strings, but this was found to be surprising. Aah -- gram.y shows LISTEN / NOTIFY taking a qualified_name production as their argument, and it seems to split up a dotted name into schema / relname subcomponents. Probably least effort to have the docs mention listen / notify values containing periods are eroded to their relname portion, and that > 2 dots == death: social=# listen foo.bar.blat.blam; ERROR: improper qualified name (too many dotted names): foo.bar.blat.blam Thanks! James Robinson Socialserve.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] HashJoin w/option to unique-ify inner rel
On Sun, Apr 12, 2009 at 12:00 AM, Robert Haas wrote: > On Thu, Feb 19, 2009 at 5:53 PM, Tom Lane wrote: >> Greg Stark writes: >>> It's tempting to have Hash cheat and just peek at the node beneath it >>> to see if it's a HashAggregate, in which case it could call a special >>> method to request the whole hash. But it would have to know that it's >>> just a plain uniquify and not implementing a GROUP BY. >> >> More to the point, it would have to check if it's unique-ifying on the >> same columns and with the same operators as the upper hash is using. >> If we were going to do something like this, making it a real option to >> the Hash node and teaching the planner about that would be *much* >> easier, and would also allow saner cost estimation. > > I've been thinking about this some more and would like someone else to > check my work. > > The goal here is to handle a semi-join implemented as a hash join by > unique-ifying the inner rel as we are building the hash table, rather > than as a separate step. [long discussion of implementation methodology] > > Does anyone see a hole in this logic? Upon further review, it appears that a big part of this problem is that cost_hashjoin() doesn't understand that it needs cost semi-joins differently from inner or left joins. The bogus logic looks to be right here: /* * The number of tuple comparisons needed is the number of outer tuples * times the typical number of tuples in a hash bucket, which is the inner * relation size times its bucketsize fraction. At each one, we need to * evaluate the hashjoin quals. But actually, charging the full qual eval * cost at each tuple is pessimistic, since we don't evaluate the quals * unless the hash values match exactly. For lack of a better idea, halve * the cost estimate to allow for that. */ startup_cost += hash_qual_cost.startup; run_cost += hash_qual_cost.per_tuple * outer_path_rows * clamp_row_est(inner_path_rows * innerbucketsize) * 0.5; Of course, when the join type is JOIN_SEMI, we're going to stop looking after we find the first match, so this estimate is really far off. rhaas=# explain analyze select * from a where i in (select b.i from b); QUERY PLAN Hash Join (cost=174.72..2095.53 rows=10 width=4) (actual time=33.274..285.627 rows=10 loops=1) Hash Cond: (a.i = b.i) -> Seq Scan on a (cost=0.00..1443.00 rows=10 width=4) (actual time=0.023..125.307 rows=10 loops=1) -> Hash (cost=174.60..174.60 rows=10 width=4) (actual time=33.209..33.209 rows=10 loops=1) -> HashAggregate (cost=174.50..174.60 rows=10 width=4) (actual time=33.161..33.175 rows=10 loops=1) -> Seq Scan on b (cost=0.00..148.80 rows=10280 width=4) (actual time=0.015..15.304 rows=10280 loops=1) Total runtime: 285.743 ms (7 rows) rhaas=# set enable_hashagg to false; set enable_sort to false; SET SET rhaas=# explain analyze select * from a where i in (select b.i from b); QUERY PLAN -- Hash Semi Join (cost=277.30..130573.10 rows=10 width=4) (actual time=31.447..292.823 rows=10 loops=1) Hash Cond: (a.i = b.i) -> Seq Scan on a (cost=0.00..1443.00 rows=10 width=4) (actual time=0.022..125.300 rows=10 loops=1) -> Hash (cost=148.80..148.80 rows=10280 width=4) (actual time=31.392..31.392 rows=10280 loops=1) -> Seq Scan on b (cost=0.00..148.80 rows=10280 width=4) (actual time=0.014..14.958 rows=10280 loops=1) Total runtime: 293.154 ms (6 rows) The planner costs the semi-join as two orders of magnitude more expensive than the hash-join-over-hash-aggregate, but in reality the semi join is only marginally slower. The planner thinks we're going to end up wasting a lot of time walking down long hash chains and it's just not true. b contains lots of duplicates but they all hash to the same buckets, and when an a-value hashes to that bucket it's probably because we've got a match, and because it's a semi-join, finding one match is a sufficient excuse to skip the rest of the bucket.. ...Robert -- 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] psql with "Function Type" in \df
On Wed, Apr 15, 2009 at 08:54:10PM -0400, Alvaro Herrera wrote:
> David Fetter wrote:
>
> > > > I think it's good to have them translatable. As for using "aggregate"
> > > > instead of "agg" I don't think it's that great an idea. If you need to
> > > > notify translators that "agg" stands for "aggregate", add a
> > > > /* translator: */ comment.
>
> The "translator: " comment needs to be in the line just above the
> string. Right now the PO file looks like this:
>
> #: describe.c:243 describe.c:288 describe.c:304
> msgid "agg"
> msgstr ""
>
> #. translator: "agg" is short for "aggregate"
> #: describe.c:244
> msgid "window"
> msgstr ""
>
>
> Note really what we want ...
Is this any better?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 10d42ca..5224440 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -1043,14 +1043,19 @@ testdb=>
Lists available functions, together with their argument and
-return types. If pattern
-is specified, only functions whose names match the pattern are shown.
-If the form \df+ is used, additional information
about
-each function, including volatility, language, source code and
description, is shown.
-By default, only user-created objects are shown; supply a
-pattern or the S modifier to include system
-objects.
+return types and their function type: 'normal', 'agg',
+'trigger', and 'window'. If pattern is specified, only
+functions whose names match the pattern are shown. If the
+form \df+ is used, additional information
+about each function, including volatility, language, source
+code and description, is shown. By default, only user-created
+objects are shown; supply a pattern or the
+S modifier to include system objects. To
+include aggregates in the result set, use \dfa, normal
+functions, \dfn, trigger functions, \dft, windowing functions,
+\dfw. You may freely mix and match the +, S, a, n, t and w
+options.
@@ -1064,7 +1069,6 @@ testdb=>
-
\dF[+] [ pattern ]
diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml
index fc56c3d..09ba686 100644
--- a/doc/src/sgml/release.sgml
+++ b/doc/src/sgml/release.sgml
@@ -183,6 +183,15 @@ do it for earlier branch release files.
+
+
+ In psql, \df now shows which type of function (normal,
+ aggregate, trigger, or window) it is. You can also specify
+ mix-and-match options. To get aggregates and windowing
+ functions, including system ones, for example, invoke \dfwaS+
+
+
+
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index b39466d..1dc3cc3 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -365,8 +365,22 @@ exec_command(const char *cmd,
case 'D':
success = listDomains(pattern, show_system);
break;
- case 'f':
- success = describeFunctions(pattern,
show_verbose, show_system);
+ case 'f': /* function subsystem */
+ switch (cmd[2])
+ {
+ case '\0':
+ case '+':
+ case 'S':
+ case 'a':
+ case 'n':
+ case 't':
+ case 'w':
+ success =
describeFunctions(&cmd[2], pattern, show_verbose, show_system);
+ break;
+ default:
+ status = PSQL_CMD_UNKNOWN;
+ break;
+ }
break;
case 'g':
/* no longer distinct from \du */
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 731baf8..4ea41af 100644
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -183,15 +183,43 @@ describeTablespaces(const char *pattern, bool verbose)
/* \df
- * Takes an optional regexp to select particular functions
+ * Takes an optional regexp to select particular functions.
+ *
+ * As with \d, you can specify the kinds of function
Re: [HACKERS] [GENERAL] Performance of full outer join in 8.3
On Wed, Apr 15, 2009 at 7:39 PM, Tom Lane wrote: > Robert Haas writes: >> We could add some regression tests that create a sample data set, >> ANALYZE it, and then EXPLAIN various things. The results should be >> deterministic, > > Sorry, you're wrong. > > The output of EXPLAIN is nowhere near stable enough to use within the > current exact-match regression test framework. I'm not sure it would > be stable even if we suppressed the rowcount and cost figures. Those > figures vary across platforms (because of alignment effects and probably > other things) and are also sensitive to the timing of autovacuums. It > is known that a nontrivial fraction of the existing regression test > cases do suffer from uninteresting plan changes across platforms or > as a result of various phase-of-the-moon effects; that's why we keep > having to add "ORDER BY" clauses now and then. Interesting. I suppose you could insulate yourself from this somewhat by populating pg_statistic with a particular set of values rather than relying on ANALYZE to gather them, but this would have the substantial downside of being way more work to maintain, especially if anyone ever changed pg_statistic. On a more practical level, I do think we need to give real consideration to some kind of options syntax for EXPLAIN, maybe something as simple as: EXPLAIN (option_name, ...) query Or maybe: EXPLAIN (option_name = value, ...) query It may or may not be the case that generating a useful regression test suite for the planner is too much work for anyone to bother, but they certainly won't if the tools aren't available. It seems we get at least one request a month for some kind of explain-output option: suppress row counts, suppress costs, gather I/O statistics, show outputs, show # of batches for a hash join, and on and on and on. I think we should implement a very basic version that maybe does nothing more than let you optionally suppress some of the existing output, but which provides an extensible syntax for others to build on. Would you support such a change? > The other problem with any large set of such tests is that any time you > intentionally change the optimizer, a great deal of careful analysis > would be needed to determine if the resulting EXPLAIN changes were good, > bad, or indifferent; not to mention whether the change *should* have > changed some plans that did not change. Arguably it would be a good thing to examine planner changes with this level of scrutiny, but I agree that the prospect is pretty intimidating. > There might be net value in maintaining such a test suite, but it would > be a lot of work with no certain benefit, and I don't see anyone > stepping up to do it. ...Robert -- 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] psql with "Function Type" in \df
David Fetter wrote: > > > I think it's good to have them translatable. As for using "aggregate" > > > instead of "agg" I don't think it's that great an idea. If you need to > > > notify translators that "agg" stands for "aggregate", add a > > > /* translator: */ comment. The "translator: " comment needs to be in the line just above the string. Right now the PO file looks like this: #: describe.c:243 describe.c:288 describe.c:304 msgid "agg" msgstr "" #. translator: "agg" is short for "aggregate" #: describe.c:244 msgid "window" msgstr "" Note really what we want ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] psql with "Function Type" in \df
On Tue, Apr 14, 2009 at 03:18:06PM -0700, David Fetter wrote:
> On Tue, Apr 14, 2009 at 02:52:32PM -0400, Alvaro Herrera wrote:
> > Tom Lane wrote:
> >
> > > I had a second thought about that: presumably we should make the
> > > function type names translatable. If we do that, it might be better
> > > to make the aggregate case be "aggregate" and take the width hit.
> > > Otherwise translators are going to be puzzled when they come across
> > > "agg" as a translatable phrase.
> >
> > I think it's good to have them translatable. As for using "aggregate"
> > instead of "agg" I don't think it's that great an idea. If you need to
> > notify translators that "agg" stands for "aggregate", add a
> > /* translator: */ comment.
>
> Here's the next revision :)
This time, with less-Byzantine logic, and no egregious whitespace
changes. :)
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 10d42ca..5224440 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -1043,14 +1043,19 @@ testdb=>
Lists available functions, together with their argument and
-return types. If pattern
-is specified, only functions whose names match the pattern are shown.
-If the form \df+ is used, additional information
about
-each function, including volatility, language, source code and
description, is shown.
-By default, only user-created objects are shown; supply a
-pattern or the S modifier to include system
-objects.
+return types and their function type: 'normal', 'agg',
+'trigger', and 'window'. If pattern is specified, only
+functions whose names match the pattern are shown. If the
+form \df+ is used, additional information
+about each function, including volatility, language, source
+code and description, is shown. By default, only user-created
+objects are shown; supply a pattern or the
+S modifier to include system objects. To
+include aggregates in the result set, use \dfa, normal
+functions, \dfn, trigger functions, \dft, windowing functions,
+\dfw. You may freely mix and match the +, S, a, n, t and w
+options.
@@ -1064,7 +1069,6 @@ testdb=>
-
\dF[+] [ pattern ]
diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml
index fc56c3d..09ba686 100644
--- a/doc/src/sgml/release.sgml
+++ b/doc/src/sgml/release.sgml
@@ -183,6 +183,15 @@ do it for earlier branch release files.
+
+
+ In psql, \df now shows which type of function (normal,
+ aggregate, trigger, or window) it is. You can also specify
+ mix-and-match options. To get aggregates and windowing
+ functions, including system ones, for example, invoke \dfwaS+
+
+
+
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index b39466d..1dc3cc3 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -365,8 +365,22 @@ exec_command(const char *cmd,
case 'D':
success = listDomains(pattern, show_system);
break;
- case 'f':
- success = describeFunctions(pattern,
show_verbose, show_system);
+ case 'f': /* function subsystem */
+ switch (cmd[2])
+ {
+ case '\0':
+ case '+':
+ case 'S':
+ case 'a':
+ case 'n':
+ case 't':
+ case 'w':
+ success =
describeFunctions(&cmd[2], pattern, show_verbose, show_system);
+ break;
+ default:
+ status = PSQL_CMD_UNKNOWN;
+ break;
+ }
break;
case 'g':
/* no longer distinct from \du */
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 731baf8..17bcd44 100644
--- a/src/bin/psql/describe.c
+++ b/src/bin/psql/describe.c
@@ -183,15 +183,43 @@ describeTablespaces(const char *pattern, bool verbose)
/* \df
- * Takes an optional regexp to select pa
Re: [HACKERS] GIN versus zero-key queries
Where are we on this? --- Tom Lane wrote: > Teodor Sigaev writes: > >> We have an API definition by which extractQuery can distinguish "all > >> match" from "no match". If we just legislate that "some match" isn't > >> a valid behavior for zero-key queries, then the code is correct and the > > > Right now I don't see an example with zero keys and "some match", > > consistent > > method will not have any information about indexed tuple and hence it could > > not > > produce any reasonable result. It seems to me, that paragraph should be > > removed > > at all. > > Well, we still have to document the fact that GIN fails when presented > with a query that would require a full-index scan. I've updated section > 52.5 as attached. (I removed the claim that multiple matches were a > problem, since this is obviously not true for a bitmap scan, and I > suppose that the plain indexscan code must have had a way to deal with > it too.) > > More generally, though, I find myself quite unhappy with the fact that > GIN doesn't provide reasonable behavior for the no-keys corner cases. > If we are going to provide operator classes that claim to implement > index acceleration of standard operators, it is not okay for them > to not match the exact semantics of those operators. Right now it's > a mess for empty arrays, and it's even more of a mess for arrays > containing nulls. array_contain_compare() considers nulls as never > matching, which means that > > regression=# select array[1,null] <@ array[1,null]; > ?column? > -- > f > (1 row) > > which is entirely bizarre when you compare that result to > > regression=# select array[1,null] = array[1,null]; > ?column? > -- > t > (1 row) > > It's obviously too late to do anything about this for 8.4, but I would > like to have a TODO item to figure out how to do this right. We need to > adjust the behavior of the operators to be consistent, and then we need > to make it possible for GIN to implement them exactly. I wonder whether > we should not change GIN to automatically do something reasonable for > empty indexed values, ie stick them into the index in some special way > denoting "no indexable keys for this item". The dummy-value solution > is not something that operator classes should have to come up with, > and not all data types present a reasonable way to have dummy values > anyway. > > regards, tom lane > > > > GIN doesn't support full index scans. The reason for > this is that extractValue is allowed to return zero keys, > as for example might happen with an empty string or empty array. In such > a case the indexed value will be unrepresented in the index. It is > therefore impossible for GIN to guarantee that a > scan of the index can find every row in the table. > > > > Because of this limitation, when extractQuery returns > nkeys = 0 to indicate that all values match the query, > GIN will emit an error. (If there are multiple ANDed > indexable operators in the query, this happens only if they all return zero > for nkeys.) > > > > It is possible for an operator class to circumvent the restriction against > full index scan. To do that, extractValue must return at least > one (possibly dummy) key for every indexed value, and > extractQuery must convert an unrestricted search into > a partial-match query that will scan the whole index. This is inefficient > but might be necessary to avoid corner-case failures with operators such > as LIKE or subset inclusion. > > > > GIN assumes that indexable operators are strict. > This means that extractValue will not be called at all on > a NULL value (so the value will go unindexed), and > extractQuery will not be called on a NULL comparison > value either (instead, the query is presumed to be unmatchable). > > > > A possibly more serious limitation is that GIN cannot > handle NULL keys — for example, an array containing a NULL cannot > be handled except by ignoring the NULL. > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] libpq is not thread safe
Zdenek Kotala wrote: > When postgreSQL is compiled with --thread-safe that libpq should be > thread safe. But it is not true when somebody call fork(). The problem > is that fork() forks only active threads and some mutex can stay locked > by another thread. We use ssl_config mutex which is global. > > We need implement atfork handlers to fix this. See > http://www.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html > > We should add pthread_atfork into _ini libpq section. > > Another problem with fork is that new process inherit connections and so > on. Which is not also good, but it is happened also on single threaded > application and developer can fix it in own code. Maybe some notice in > documentation should help what application should do after fork. Yep, added to TODO list: Make libpq thread-safe in programs that use fork() This requires the use of pthread_atfork() to release global locks held in libpq * http://archives.postgresql.org/pgsql-hackers/2009-04/msg00747.php -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] [GENERAL] Performance of full outer join in 8.3
Robert Haas writes: > We could add some regression tests that create a sample data set, > ANALYZE it, and then EXPLAIN various things. The results should be > deterministic, Sorry, you're wrong. The output of EXPLAIN is nowhere near stable enough to use within the current exact-match regression test framework. I'm not sure it would be stable even if we suppressed the rowcount and cost figures. Those figures vary across platforms (because of alignment effects and probably other things) and are also sensitive to the timing of autovacuums. It is known that a nontrivial fraction of the existing regression test cases do suffer from uninteresting plan changes across platforms or as a result of various phase-of-the-moon effects; that's why we keep having to add "ORDER BY" clauses now and then. The other problem with any large set of such tests is that any time you intentionally change the optimizer, a great deal of careful analysis would be needed to determine if the resulting EXPLAIN changes were good, bad, or indifferent; not to mention whether the change *should* have changed some plans that did not change. There might be net value in maintaining such a test suite, but it would be a lot of work with no certain benefit, and I don't see anyone stepping up to do it. 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] [GENERAL] Performance of full outer join in 8.3
On Wed, Apr 15, 2009 at 6:04 PM, Tom Lane wrote: > Simon Riggs writes: >> I've always been scared to ask this question, in case the answer is No, >> but: Do we have a set of regression tests for the optimizer anywhere? > > Nothing beyond what is in the standard tests. While that's okay at > catching wrong answers --- and we have memorialized a number of such > issues in the tests --- the framework is not good for catching things > that run slower than they ought. We could add some regression tests that create a sample data set, ANALYZE it, and then EXPLAIN various things. The results should be deterministic, but creating a reasonably comprehensive set of tests might be a fair amount of work, and would likely add significantly to the runtime of the tests. Maybe it would need to be a separate suite just for optimizer testing. ...Robert -- 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] [GENERAL] Performance of full outer join in 8.3
Simon Riggs writes: > I've always been scared to ask this question, in case the answer is No, > but: Do we have a set of regression tests for the optimizer anywhere? Nothing beyond what is in the standard tests. While that's okay at catching wrong answers --- and we have memorialized a number of such issues in the tests --- the framework is not good for catching things that run slower than they ought. 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] [GENERAL] Performance of full outer join in 8.3
On Wed, 2009-04-15 at 12:34 -0400, Tom Lane wrote: > On further review, this did work in 8.3 when released. I think it got > broken here: > > http://archives.postgresql.org/pgsql-committers/2008-06/msg00336.php > > because that change is preventing the "mergedvar = constant" clause from > being seen as an equivalence, when it should be seen as one. Need to > think about a tighter fix for the bug report that prompted that change. I've always been scared to ask this question, in case the answer is No, but: Do we have a set of regression tests for the optimizer anywhere? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] [GENERAL] Performance of full outer join in 8.3
I wrote: > On further review, this did work in 8.3 when released. I think it got > broken here: > http://archives.postgresql.org/pgsql-committers/2008-06/msg00336.php > because that change is preventing the "mergedvar = constant" clause from > being seen as an equivalence, when it should be seen as one. Need to > think about a tighter fix for the bug report that prompted that change. The original bug report involved create_or_index_quals() pulling out an index condition from an OR clause that appeared above an outer join that could null the relation it wanted to indexscan. (In practice this only arises if at least one arm of the OR has an IS NULL clause for the target relation --- if all arms have ordinary strict index clauses then we'd have determined during reduce_outer_joins that the outer join could be simplified to a plain join.) I tried to fix this by altering the meaning of the outerjoin_delayed flag slightly, but what Christian's complaint shows is that that was a bad idea because it breaks valid equivalence deductions. Using outerjoin_delayed in create_or_index_quals() was always pretty much of a crude hack anyway --- there are other cases in which it prevents us from extracting index conditions that *would* be legitimate. In particular, there's no reason why we should not extract an index condition for the outer relation of the same outer join. So I'm thinking the right thing to do is to eliminate outerjoin_delayed from RestrictInfo in favor of storing a bitmapset that shows exactly which relations referenced by the clause are nullable by outer joins that are below the clause. Then create_or_index_quals() could ignore an OR, or not, depending on whether the target relation is nullable below the OR clause. This might permit finer-grain analysis in the other places that currently depend on outerjoin_delayed too, though for the moment I'll just make them check for empty-or-nonempty-set. outerjoin_delayed should revert to its longstanding meaning within distribute_qual_to_rels, but right at the moment there seems no application for preserving it beyond that point. (On the other hand, eliminating it from RestrictInfo isn't going to save any space because of alignment considerations, so maybe we should keep it there in case we need it in future.) The main objection I can see to this is the expansion of RestrictInfo, but it's a pretty large struct already and one more pointer isn't going to make much difference. Comments? 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] Unicode string literals versus the world
On 4/15/09, Tom Lane wrote:
> Marko Kreen writes:
> > As both this and the doubling-\\ way would mean we should have usable
> > alternative in case of stdstr=off also, so in the end we have agreed
> > to accept \u also?
>
> Given Martijn's complaint about more-than-16-bit code points, I think
> the \u proposal is not mature enough to go into 8.4. We can think
> about some version of that later, if there's enough interest.
I think it would be good idea. Basically we should pick one from
couple of pre-existing sane schemes. Here is quick summary
of Python, Perl and Java:
Python [1]:
\u - 16-bit codepoint
\U - 32-bit codepoint
\N{char-name} - Characted by name
Perl [2]:
\x{..} - {} contains hexadecimal codepoint
\N{char-name} - Unicode char name
Java [3]:
\u - 16-bit codepoint
Perl is OK, but the \x makes think of literal hex-decimal, and thats
because they have extented their literal byte-escapes to support unicode.
So I doubt we should promote it more. \u{} would be nicer, but that
would not be an established standard.
Both Python and Java allow using \u to encode higher codepoints with
surrogate pairs. Which sort of makes it standard and Python superset
of Java. (Obviously that does not mean you need to store them
as surrogate pairs.)
Problem with having only \u would be that this would make hard to enter
higher codepoints manually. So \U would also be good to have.
There is no hurry with \N{} but if it would be possible, it would be
main reason to have custom unicode escaping.
So my proposal would be Python escapes without \N{}.
Whether we should have it in 8.4, I don't know. If we will have U&,
but it does not work with stdstr=off, this seems to hint we should have
some other escaping method available in 8.4 for stdstd=off users?
--
marko
[1] http://docs.python.org/reference/lexical_analysis.html#string-literals
[2] http://perldoc.perl.org/perluniintro.html
[3] http://java.sun.com/docs/books/jls/third_edition/html/lexical.html
--
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] Unicode string literals versus the world
Marko Kreen writes: > As both this and the doubling-\\ way would mean we should have usable > alternative in case of stdstr=off also, so in the end we have agreed > to accept \u also? Given Martijn's complaint about more-than-16-bit code points, I think the \u proposal is not mature enough to go into 8.4. We can think about some version of that later, if there's enough interest. 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] Unicode string literals versus the world
Martijn van Oosterhout wrote:
On Tue, Apr 14, 2009 at 08:10:54AM -0400, Andrew Dunstan wrote:
Marko Kreen wrote:
I still stand on my proposal, how about extending E'' strings with
unicode escapes (eg. \u)? The E'' strings are already more
clearly defined than '' and they are our "own", we don't need to
consider random standards, but can consider our sanity.
I suspect there would be lots more support in the user community, where
\u is well understood in a number of contexts (Java and ECMAScript,
for example). It's also tolerably sane.
By the way, that's an example of how to do it wrong, there are more
than 2^16 unicode characters, you want to be able to support the full
21-bit range if you're going to do it right.
FWIW, I prefer the perl syntax which simply extends \x: \x{1344}, which
makes it clear it's hex and doesn't make assumptions as to how many
characters are used.
I could live with either. Wikipedia says: "The characters outside the
first plane usually have very specialized or rare use." For years we
rejected all characters beyond the first plane, and while that's fixed
now, the volume of complaints wasn't huge.
cheers
andrew
Have a nice day,
--
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] Unicode string literals versus the world
On 4/15/09, Tom Lane wrote: > Marko Kreen writes: > > Whats wrong with requiring U& to conform with stdstr=off quoting rules? > > The sole and only excuse for that misbegotten syntax is to be exactly > SQL spec compliant --- otherwise we might as well pick something saner. > So it needs to work like stdstr=on. I thought Peter's proposal of > rejecting it altogether when stdstr=off might be reasonable. The space > sensitivity around the & still sucks, but I have not (yet) thought of > a credible security exploit for that. So the U& syntax is only available if stdstr=on? Sort of makes sense. As both this and the doubling-\\ way would mean we should have usable alternative in case of stdstr=off also, so in the end we have agreed to accept \u also? -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Lawyer jokes...
Magnush asked me about the beer-ware license on crypt-md5.c file. I will spare you for the sagas of fun I have had with lawyers because of the beerware license, you can get them over beer some times. For the record: You are welcome to slap a 2-clause BSD license on the file instead of the beerware. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- 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] Unicode string literals versus the world
Marko Kreen writes: > Whats wrong with requiring U& to conform with stdstr=off quoting rules? The sole and only excuse for that misbegotten syntax is to be exactly SQL spec compliant --- otherwise we might as well pick something saner. So it needs to work like stdstr=on. I thought Peter's proposal of rejecting it altogether when stdstr=off might be reasonable. The space sensitivity around the & still sucks, but I have not (yet) thought of a credible security exploit for that. 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] Unicode string literals versus the world
On 4/15/09, Greg Stark wrote: > On Wed, Apr 15, 2009 at 6:23 PM, Tom Lane wrote: > >> Wouldn't we just then say that U&'' strings are always standard- > >> conforming? > > > > That's exactly what's causing the problem --- they are, but there > > is lots of software that won't know it. > > We could say U&'' escapes only work if you have > standards_conforming_strings set to true. Whats wrong with requiring U& to conform with stdstr=off quoting rules? You can use UESCAPE if you dont want to double backslashes. -- marko -- 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] Unicode string literals versus the world
On Wed, Apr 15, 2009 at 6:52 PM, Greg Stark wrote: > On Wed, Apr 15, 2009 at 6:23 PM, Tom Lane wrote: >>> Wouldn't we just then say that U&'' strings are always standard- >>> conforming? >> >> That's exactly what's causing the problem --- they are, but there >> is lots of software that won't know it. > > > We could say U&'' escapes only work if you have > standards_conforming_strings set to true. Or say that if you have standards_conforming_strings false then any string which contains a literal \ or ' is an error. You shouldn't ever really need either since you could use the unicode escape for either after all. -- greg -- 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] New trigger option of pg_standby
On Wed, 2009-04-15 at 17:02 +0900, Fujii Masao wrote: > On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao wrote: > > I'd like to propose another simple idea; pg_standby deletes the > > trigger file *whenever* the nextWALfile is a timeline history file. > > A timeline history file is restored at the end of recovery, so it's > > guaranteed that the trigger file is deleted whether nextWALfile > > exists or not. > > > > A timeline history file is restored also at the beginning of > > recovery, so the accidentally remaining trigger file is deleted > > in early warm-standby as a side-effect of this idea. > > Here is the revised patch as above. > > If you notice something, please feel free to comment. Deleting the trigger file when we request a history file works in most cases, but not in all. We also request a history file when we switch timelines, so code comments need slight modification. If take a base backup, switchover and then try to regen the primary from the base backup we would need to switch timelines, which could be problematic. That is unlikely, so we should at least very clearly document the actual behaviour, as we do in the code comments. I think your wording that smart mode guarantees no data will be lost is a little strong. I'd say "on successful completion all WAL records will be replayed resulting in zero data loss". -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] Unicode string literals versus the world
On Wed, Apr 15, 2009 at 6:23 PM, Tom Lane wrote: >> Wouldn't we just then say that U&'' strings are always standard- >> conforming? > > That's exactly what's causing the problem --- they are, but there > is lots of software that won't know it. We could say U&'' escapes only work if you have standards_conforming_strings set to true. -- greg -- 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] missing translation marker
Alvaro Herrera writes:
> It seems there's a missing gettext() call in new code in hba.c, per the
> patch below. I don't actually like this, but it seems the alternative
> would be to create a variadic function which I believe to be
> overengineering ...
Hmm ... if the second %s here is meant to be a list of auth method
names:
> ereport(LOG, \
> (errcode(ERRCODE_CONFIG_FILE_ERROR), \
>errmsg("authentication option \"%s\" is only valid for
> authentication methods \"%s\"", \
> - optname, validmethods), \
> + optname, _(validmethods)), \
>errcontext("line %d of configuration file \"%s\"", \
> line_num, HbaFileName))); \
then I argue that putting double quotes around it is wrong, too.
It might be technically correct to quote the individual method names
within the list that's being passed in, but I wouldn't bother.
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] Unicode string literals versus the world
"David E. Wheeler" writes: > Wouldn't we just then say that U&'' strings are always standard- > conforming? That's exactly what's causing the problem --- they are, but there is lots of software that won't know it. 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
[HACKERS] missing translation marker
Hi,
It seems there's a missing gettext() call in new code in hba.c, per the
patch below. I don't actually like this, but it seems the alternative
would be to create a variadic function which I believe to be
overengineering ...
Index: hba.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/libpq/hba.c,v
retrieving revision 1.184
diff -c -p -u -r1.184 hba.c
cvs diff: conflicting specifications of output style
--- hba.c 25 Mar 2009 14:12:02 - 1.184
+++ hba.c 15 Apr 2009 16:50:21 -
@@ -579,7 +579,7 @@ check_db(const char *dbname, const char
ereport(LOG, \
(errcode(ERRCODE_CONFIG_FILE_ERROR), \
errmsg("authentication option \"%s\" is only valid for
authentication methods \"%s\"", \
- optname, validmethods), \
+ optname, _(validmethods)), \
errcontext("line %d of configuration file \"%s\"", \
line_num, HbaFileName))); \
return false; \
@@ -952,7 +952,7 @@ parse_hba_line(List *line, int line_num,
parsedline->auth_method != uaGSS &&
parsedline->auth_method != uaSSPI &&
parsedline->auth_method != uaCert)
- INVALID_AUTH_OPTION("map", "ident,
krb5, gssapi, sspi and cert");
+ INVALID_AUTH_OPTION("map",
gettext_noop("ident, krb5, gssapi, sspi and cert"));
parsedline->usermap = pstrdup(c);
}
else if (strcmp(token, "clientcert") == 0)
@@ -1050,7 +1050,7 @@ parse_hba_line(List *line, int line_num,
if (parsedline->auth_method != uaKrb5 &&
parsedline->auth_method != uaGSS &&
parsedline->auth_method != uaSSPI)
- INVALID_AUTH_OPTION("krb_realm", "krb5,
gssapi and sspi");
+ INVALID_AUTH_OPTION("krb_realm",
gettext_noop("krb5, gssapi and sspi"));
parsedline->krb_realm = pstrdup(c);
}
else if (strcmp(token, "include_realm") == 0)
@@ -1058,7 +1058,7 @@ parse_hba_line(List *line, int line_num,
if (parsedline->auth_method != uaKrb5 &&
parsedline->auth_method != uaGSS &&
parsedline->auth_method != uaSSPI)
- INVALID_AUTH_OPTION("include_realm",
"krb5, gssapi and sspi");
+ INVALID_AUTH_OPTION("include_realm",
gettext_noop("krb5, gssapi and sspi"));
if (strcmp(c, "1") == 0)
parsedline->include_realm = true;
else
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
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] Memory exhaustion during bulk insert
Xin Wang escribió: > However, I do not know much about the code below the heapam layer. Can that > patch solve my problem (the version I use is 8.3.5)? Or could you give me > some suggestion about how to avoid memory exhaustion during bulk insert > (in the meanwhile it must clean up nicely after a transaction abort)? Try 8.3.7. There have been memory leak fixes in XML code lately, which maybe solve your problem. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] [GENERAL] Performance of full outer join in 8.3
I wrote: > =?ISO-8859-1?Q?Christian_Schr=F6der?= writes: >> This is the query: >> select isin from ts_frontend.attachment_isins full OUTER JOIN >> ts_frontend.rec_isins using (attachment,isin) WHERE attachment=2698120 >> GROUP BY isin limit 1000; > Hmm. It seems 8.3 is failing to push the attachment=2698120 condition > down to the input relations. Not sure why. All that code got massively > rewritten in 8.3, but I thought it still understood about pushing > equalities through a full join ... On further review, this did work in 8.3 when released. I think it got broken here: http://archives.postgresql.org/pgsql-committers/2008-06/msg00336.php because that change is preventing the "mergedvar = constant" clause from being seen as an equivalence, when it should be seen as one. Need to think about a tighter fix for the bug report that prompted that 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] Unicode support
On Tue, Apr 14, 2009 at 11:32:57AM -0700, David E. Wheeler wrote: > I've no idea what it would require, but the mapping table must be > pretty substantial. Still, I'd love to have this functionality in the > database. The Unicode tables in ICU outweigh the size of the code by a factor 5 or so. Once Postgres decides it want to do unicode properly and thus imports the tables in some way, it could get the code to work with it for 20% extra. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] Unicode string literals versus the world
On Tue, Apr 14, 2009 at 08:10:54AM -0400, Andrew Dunstan wrote:
> Marko Kreen wrote:
> >I still stand on my proposal, how about extending E'' strings with
> >unicode escapes (eg. \u)? The E'' strings are already more
> >clearly defined than '' and they are our "own", we don't need to
> >consider random standards, but can consider our sanity.
>
> I suspect there would be lots more support in the user community, where
> \u is well understood in a number of contexts (Java and ECMAScript,
> for example). It's also tolerably sane.
By the way, that's an example of how to do it wrong, there are more
than 2^16 unicode characters, you want to be able to support the full
21-bit range if you're going to do it right.
FWIW, I prefer the perl syntax which simply extends \x: \x{1344}, which
makes it clear it's hex and doesn't make assumptions as to how many
characters are used.
Have a nice day,
--
Martijn van Oosterhout http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.
signature.asc
Description: Digital signature
Re: [HACKERS] Replacing plpgsql's lexer
On Wed, 2009-04-15 at 11:45 -0400, Tom Lane wrote: > Andrew Dunstan writes: > > We support back branches for a long time for a reason. > > I think that's really the bottom line here. If we insist on new major > releases always being bug-compatible with prior releases, our ability to > improve the software will go to zero. The solution we have opted for > instead is to support back branches for a long time and to avoid making > that type of change in a back branch. > +1 Joshua D. Drake > regards, tom lane > -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- 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] Unicode string literals versus the world
On Apr 15, 2009, at 4:45 AM, Sam Mason wrote: Doh, yes it does doesn't it. Sorry I searched for a bit and failed to find anything before. Looks as though the signal to noise ratio was far too low as I've just searched again and found a (single) reference to their docs describing the feature[1]. This is ugly, but not completely unpalatable: U&'\0141ód\017A is a city in Poland' U&'c:\\temp' U&'@+01D11E' UESCAPE '@' Wouldn't we just then say that U&'' strings are always standard- conforming? Best, David -- 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] Replacing plpgsql's lexer
Andrew Dunstan writes: > We support back branches for a long time for a reason. I think that's really the bottom line here. If we insist on new major releases always being bug-compatible with prior releases, our ability to improve the software will go to zero. The solution we have opted for instead is to support back branches for a long time and to avoid making that type of change in a back branch. 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] Patch for server-side encoding issues
Hi.
- Original Message -
From: "Itagaki Takahiro"
Here is a WIP patch to solve server-side encoding issues.
It includes "Solution of the file name problem of copy on windows" patch.
http://archives.postgresql.org/message-id/20090413184335.39be.52131...@oss.ntt.co.jp
It could solve the following issues. They are not only in Windows nor
Japan-specific problems. They could also occur if you use databases
with mulitple encodings or database with non-platform-native encoding
even on POSIX platforms.
<1> Non-ascii file paths for database that encoding is different from
platform's encoding (that comes from $LANG or Windows codepage),
especially for COPY TO/FROM.
<2> Use appropriate encoding for non-text server log (console, syslog
and eventlog). The encoding is the same as <1>.
<3> Use appropriate encoding for text server log (stderr and csvlog),
especially database cluster has databases with a variety of encoding.
New GUC parameter 'log_encoding' specifies the encoding in server log.
<4> (incomplete) Avoid encoding conversion error in printing server log
and messages for client. Instead of error, print '?' if there is no
equivalent character in the target encoding.
For <4>, I use PG_TRY and PG_CATCH for now, but it must be a bad manner.
Instead, I'm thinking that convertion procedures will take an optional
argument whether it should raise error or not. However, we need to
modify all of conversion functions to do so.
More research is needed against following situations:
- NLS messages
- Module path for LOAD
- Arguments for system(), including archive_command and restore_command
- Query texts for other database in pg_stat_activity and pg_stat_statements
Comments welcome. Please notify me if I'm missing something.
Although it is redundant, it looks at much help. It is, even if it may not
be welcomed in the country in many single byte areas. Then, they may think
that they are strange. However, I consider helping in the country using
multi-bytes other than Japan. example displayed on below with a server
message is shown. please see,
C:\work>initdb -E UTF-8 --no-locale
データベースシステム内のファイルの所有者は"HIROSHI"ユーザでした。
このユーザがサーバプロセスを所有しなければなりません。
データベースクラスタはロケールCで初期化されます。
デフォルトのテキスト検索設定はenglishに設定されました。
ディレクトリC:/tmp/日本語 dataの権限を設定しています ... ok
サブディレクトリを作成しています ... ok
デフォルトのmax_connectionsを選択しています ... 100
デフォルトの shared_buffers を選択しています ... 32MB
設定ファイルを作成しています ... ok
C:/tmp/日本語 data/base/1にtemplate1データベースを作成しています ... ok
pg_authidを初期化しています ... ok
依存関係を初期化しています ... ok
システムビューを作成しています ... ok
システムオブジェクトの定義をロードしています ... ok
変換を作成しています ... ok
ディレクトリを作成しています ... ok
組み込みオブジェクトに権限を設定しています ... ok
情報スキーマを作成しています ... ok
template1データベースをバキュームしています ... ok
template1からtemplate0へコピーしています ... ok
template1からpostgresへコピーしています ... ok
警告: ローカル接続向けに"trust"認証が有効です。
pg_hba.confを編集する、もしくは、次回initdbを実行する時に-Aオプショ
ンを使用することで変更することができます。
成功しました。以下を使用してデータベースサーバを起動することができます。
"postmaster" -D "C:/tmp/日本語 data"
または
"pg_ctl" -D "C:/tmp/日本語 data" -l logfile start
C:\work>pg_ctl start
サーバは起動中です。
C:\work>LOG: データベースシステムは2009-04-16 00:24:13 JSTにシャットダウンしま
した
LOG: データベースシステムの接続受付準備が整いました。
LOG: 自動バキュームランチャプロセス
C:\work>psql postgres
psql (8.4beta1)
"help" でヘルプを表示します.
postgres=# create table 日本語(きー text);
CREATE TABLE
postgres=# insert into 日本語 values('どうかな');
INSERT 0 1
postgres=# copy 日本語 to 'C:/tmp/日本語 data/ニホンゴutf8.txt';
COPY 1
postgres=# delete from 日本語;
DELETE 1
postgres=# copy 日本語 from 'C:/tmp/日本語 data/ニホンゴutf8.txt';
COPY 1
postgres=# select * from 日本語;
きー
--
どうかな
(1 行)
postgres=# select a;
ERROR: 列"a"は存在しません(文字位置 8)
STATEMENT: select a;
ERROR: 列"a"は存在しません
LINE 1: select a;
^
postgres=# create database eucdb encoding = 'EUC_JP';
CREATE DATABASE
postgres=# \c eucdb
psql (8.4beta1)
データベース "eucdb" に接続しました。.
eucdb=# create table 日本語(きー text);
CREATE TABLE
eucdb=# insert into 日本語 values('どうかな');
INSERT 0 1
eucdb=# copy 日本語 to 'C:/tmp/日本語 data/ニホンゴeucjp.txt';
COPY 1
eucdb=# delete from 日本語;
DELETE 1
eucdb=# copy 日本語 from 'C:/tmp/日本語 data/ニホンゴeucjp.txt';
COPY 1
eucdb=# select * from 日本語;
きー
--
どうかな
(1 行)
eucdb=# select a;
ERROR: 列"a"は存在しません(文字位置 8)
STATEMENT: select a;
ERROR: 列"a"は存在しません
LINE 1: select a;
^
eucdb=# \q
C:\work>pg_ctl stop
LOG: スマートシャットダウン要求を受け取りました
LOG: 自動バキュームランチャを停止しています
サーバ停止処理の完了を待っていますLOG: シャットダウンしています
LOG: データベースシステムはシャットダウンしました
完了
サーバは停止しました
===
Therefore, I vote +1.
Regards,
Hiroshi Saito
--
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] Memory exhaustion during bulk insert
Xin Wang writes: > I searched the mailinglist archive and noticed that a patch to improve > bulk insert performance is committed in Nov 2008. The log message said > "(the patch) keeps the current target buffer pinned and make it work > in a small ring of buffers to avoid having bulk inserts trash the whole > buffer arena." > However, I do not know much about the code below the heapam layer. Can that > patch solve my problem (the version I use is 8.3.5)? No. You have a memory leak to fix. I suspect you need to be paying attention to evaluating the successive tuple values in a short-term memory context that you can reset on each cycle. There are other possibilities though --- looking at the memory map produced on an out-of-memory error would help narrow down the problem. (If the thing "hangs up" without producing such an error, that's the *first* problem to solve. It could be that it's not so much hanging up as going into swap hell; in which case I'd suggest running the postmaster under a more restrictive ulimit, so that it fails before starting to swap.) 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] Replacing plpgsql's lexer
On Wed, Apr 15, 2009 at 5:56 AM, Greg Stark wrote: > On Wed, Apr 15, 2009 at 10:12 AM, Simon Riggs wrote: >> >> How do you know which is the offending function? If we force a full >> application retest we put in place a significant barrier to upgrade. >> That isn't useful for us as developers, nor is it useful for users. > > This is a fundamental conflict, not one that has a single simple answer. > > However this seems like a strange place to pick your battle. Something > as low-level as the lexer is very costly to provide multiple > interfaces to. It's basically impossible short of simply providing two > different plpgsql languages -- something which won't scale at all if > we have to do it every time we make a syntax change to the language. Completely agreed. > I'm actually concerned that we've become *too* conservative. Pretty > much any change that doesn't have Tom's full support and credibility > standing behind it ends up being criticized on the basis that we don't > know precisely what effects it will have in every possible scenario. I think we've become too conservative in some areas and not conservative enough in others. In particular, we're not very conservative AT ALL about changes to the on-disk format - which is like unto a bullet through the head for in-place upgrade. And we sometimes make behavior changes that have potentially catastrophic user consequences (like that one to TRUNCATE... which one, you ask? ah, well, you'd better not use TRUNCATE in 8.4 until you RTFM then), but then we'll have an argument about whether it's OK to make some change where it's difficult to image the user impact being all that severe - like this one, for example (or removing the special case for no %-escapes in log_filename). ...Robert -- 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] Replacing plpgsql's lexer
On Wed, Apr 15, 2009 at 5:56 AM, Greg Stark wrote: > On Wed, Apr 15, 2009 at 10:12 AM, Simon Riggs wrote: >> >> How do you know which is the offending function? If we force a full >> application retest we put in place a significant barrier to upgrade. >> That isn't useful for us as developers, nor is it useful for users. > > This is a fundamental conflict, not one that has a single simple answer. > > However this seems like a strange place to pick your battle. Something > as low-level as the lexer is very costly to provide multiple > interfaces to. It's basically impossible short of simply providing two > different plpgsql languages -- something which won't scale at all if > we have to do it every time we make a syntax change to the language. Completely agreed. > I'm actually concerned that we've become *too* conservative. Pretty > much any change that doesn't have Tom's full support and credibility > standing behind it ends up being criticized on the basis that we don't > know precisely what effects it will have in every possible scenario. I think we've become too conservative in some areas and not conservative enough in others. In particular, we're not very conservative AT ALL about changes to the on-disk format - which is like unto a bullet through the head for in-place upgrade. And we sometimes make behavior changes that have potentially catastrophic user consequences (like that one to TRUNCATE... which one, you ask? ah, well, you'd better not use TRUNCATE in 8.4 until you RTFM then), but then we'll have an argument about whether it's OK to make some change where it's difficult to image the user impact being all that severe, like: - this one - removing the special case for %% in the log_filename - forward-compatible, backward-compatible improvements to CREATE OR REPLACE VIEW - lots of others So it seems that there is no consistent heuristic (other than, as you say, Tom's approval or lack thereof) applied to these changes. ...Robert -- 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] Replacing plpgsql's lexer
Simon Riggs wrote: How do you know which is the offending function? If we force a full application retest we put in place a significant barrier to upgrade. That isn't useful for us as developers, nor is it useful for users. We support back branches for a long time for a reason. Nobody in their right mind should upgrade to a new version without without first extensively testing (and if necessary adjusting) their application on it. This is true regardless of this issue and will be true for every release. 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] Unicode string literals versus the world
On Tue, Apr 14, 2009 at 04:01:48PM +0300, Peter Eisentraut wrote: > On Saturday 11 April 2009 18:20:47 Sam Mason wrote: > > I can't see much support in the other database engines; searched for > > Oracle, MS-SQL, DB2 and Firebird. MySQL has it planned for 7.1, so not > > for a while. > > DB2 supports it, as far as I know. Doh, yes it does doesn't it. Sorry I searched for a bit and failed to find anything before. Looks as though the signal to noise ratio was far too low as I've just searched again and found a (single) reference to their docs describing the feature[1]. I've also just noticed that the MySQL todo item points to several other implementations and how they handle Unicode escape sequences. The most common option (bearing in mind that this is a sample of mainly FOSS databases) seems to be doing some variant of '\u0123', as in the style of Python. This is only supported for literals and no support for identifiers appears to be provided. -- Sam http://samason.me.uk/ [1] http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.sql.ref.doc/doc/r731.html -- 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] Replacing plpgsql's lexer
Simon Riggs wrote: On Tue, 2009-04-14 at 18:29 -0400, Tom Lane wrote: Simon Riggs writes: Potentially changing the behaviour of thousands of functions just to fix a rare bug will not endear us to our users. The bug may be something that people are relying on in some subtle way, ugly as that sounds. That's why I don't want to change it in a minor release. In a major release, however, it's fair game. If we want to make easy upgrades a reality, this is the type of issue we must consider. Not much point having perfect binary upgrades if all your functions start behaving differently after upgrade and then you discover there isn't a binary downgrade path... Rather than come up with specific solutions, let me just ask the question: Is there a workaround for people caught by these changes? Let's plan that alongside the change itself, so we have a reserve 'chute. Extract the source of the offending plpgsql function using e.g pg_dump, modify it so that it works again, and restore the function. There's your workaround. I haven't been following what the issues we have with the current plpgsql lexer are, so I'm not sure what I think of the plan as a whole. Sharing the main lexer seems like a good idea, but it also seems like it's way too late in the release cycle for such changes. But then again, if we have issues that need to be fixed anyway, it might well be the best way to fix them. -- Heikki Linnakangas 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] Replacing plpgsql's lexer
On Wed, Apr 15, 2009 at 11:33 AM, Simon Riggs wrote: > >> This is a fundamental conflict, not one that has a single simple answer. >> >> However this seems like a strange place to pick your battle. > > I think you are right that you perceive a fundamental conflict and most > things I say become battles. That is not my choice and I will withdraw > from further discussion. My point has been made clearly and has not been > made to cause conflict. I've better things to do with my time than that, > though it's a shame you think that of me. Uhm, I didn't intend this as criticism at all, except inasmuch as the judgement about whether the plpgsql lexer was a good choice of place to make this stand. The use of "battle" was only because of the idiom "pick your battle". I think we are in general too conservative about making changes and you are concerned that we're not giving enough thought to the upgrade pain and should be more conservative. We can talk about general policies but ultimately we'll have to debate each change on its merits. In this case it would help if we described the specific kinds of code and consequences users. I'm not sure we're all on the same page. I think changing the lexer to match the SQL lexer will only affect string constants and only if standards_conforming_strings is enabled, and only those instances which are handled internally to plpgsql and not passed to the SQL engine. So the fix will pretty much always be local to the behaviour change. It's possible for an escaped string to need an E'' and for the backslash to migrate to other parts of the code before triggering a bug (or possibly even get stored in the database and cause a problem in other parts of the application). But it should still be pretty straightforward to find the original source of the string and also pretty easy to recognize string constants throughout the source code. As it currently stands a programmer sometimes has to use E'\x' and sometimes has to use '\x' depending on whether the plpgsql is lexing the string or is passing it to the SQL engine unlexed. It's not obvious which parts get handled in which way to a user since some constructs are handled as SQL which don't appear to be SQL and vice versa -- at least it's not obvious to me even having read the source in the past. If I understand things correctly I think the change improves the language for future users by far more than it imposes maintenance costs on existing users, especially considering that anyone depending on '\x' strings with standards_conforming_strings enabled is only probably getting it wrong in some places without realizing it anyways . -- greg -- 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] Why isn't stats_temp_directory automatically created?
Fujii Masao wrote: > Hi, > > On Tue, Apr 14, 2009 at 10:26 PM, Euler Taveira de Oliveira > wrote: >> Fujii Masao escreveu: >>> Is it worth making the patch which creates stats_temp_directory >>> if not present? >>> >> +1. > > Here is the patch. > > This patch should be added to CommitFest-2009-First?, > or committed before 8.4 release? The patch is very small, > so I don't think that it'll block 8.4 release. I think the fix should go into 8.4 - this is a fix for a new feature. However, a couple of comments: This does not take into account the effect of symlinks as mentioned by Itakagi Takahiro. I haven't looked at the details, but I don't think it would be that much more work to deal with it - and as he mentions, this is a very common usecase. Also, wouldn't it be better to isolate this to the first time when we try to create the file - then we don't have to export the symbol? //Magnus -- 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] Replacing plpgsql's lexer
On Wed, 2009-04-15 at 10:56 +0100, Greg Stark wrote: > On Wed, Apr 15, 2009 at 10:12 AM, Simon Riggs wrote: > > > > How do you know which is the offending function? If we force a full > > application retest we put in place a significant barrier to upgrade. > > That isn't useful for us as developers, nor is it useful for users. > > This is a fundamental conflict, not one that has a single simple answer. > > However this seems like a strange place to pick your battle. I think you are right that you perceive a fundamental conflict and most things I say become battles. That is not my choice and I will withdraw from further discussion. My point has been made clearly and has not been made to cause conflict. I've better things to do with my time than that, though it's a shame you think that of me. > As far as I'm concerned commercial support companies can put effort > into developing backwards-compatibility modules which add no long-term > value for their paying customers who need it today while the free > software developers can keep improving the software for new users. We will all doubtless make money from difficult upgrades, though that is not my choice, nor that of my customers. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] Replacing plpgsql's lexer
On Wed, Apr 15, 2009 at 10:12 AM, Simon Riggs wrote: > > How do you know which is the offending function? If we force a full > application retest we put in place a significant barrier to upgrade. > That isn't useful for us as developers, nor is it useful for users. This is a fundamental conflict, not one that has a single simple answer. However this seems like a strange place to pick your battle. Something as low-level as the lexer is very costly to provide multiple interfaces to. It's basically impossible short of simply providing two different plpgsql languages -- something which won't scale at all if we have to do it every time we make a syntax change to the language. I'm actually concerned that we've become *too* conservative. Pretty much any change that doesn't have Tom's full support and credibility standing behind it ends up being criticized on the basis that we don't know precisely what effects it will have in every possible scenario. One of free software's big advantages over commercial software is that it moves so much more quickly. Oracle, AIX, Windows, etc are burdened by hundreds of layers of backwards-compatibility which take up a huge portion of their development and Q/A effort. The reason Linux, Postgres, and others have been able to come up so quickly and overtake them is partly because we don't worry about such things. As far as I'm concerned commercial support companies can put effort into developing backwards-compatibility modules which add no long-term value for their paying customers who need it today while the free software developers can keep improving the software for new users. -- greg -- 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] Replacing plpgsql's lexer
Simon Riggs wrote: On Wed, 2009-04-15 at 11:36 +0300, Heikki Linnakangas wrote: Extract the source of the offending plpgsql function using e.g pg_dump, modify it so that it works again, and restore the function. There's your workaround. Forcing manual re-editing of an unknown number of lines of code is not a useful workaround, its just the default. How do you know which is the offending function? If we force a full application retest we put in place a significant barrier to upgrade. That isn't useful for us as developers, nor is it useful for users. If I understood correctly, the proposed change is not supposed to have any user-visible effects. It doesn't force a full application retest any more than any of the other changes that have gone into 8.4. We're talking about what we'll do or tell the users to do if we missed something. By definition we don't know what we've missed, so I don't think we can come up with a more specific solution than that. -- Heikki Linnakangas 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] Replacing plpgsql's lexer
On Wed, 2009-04-15 at 11:36 +0300, Heikki Linnakangas wrote: > Extract the source of the offending plpgsql function using e.g > pg_dump, modify it so that it works again, and restore the function. > There's your workaround. Forcing manual re-editing of an unknown number of lines of code is not a useful workaround, its just the default. How do you know which is the offending function? If we force a full application retest we put in place a significant barrier to upgrade. That isn't useful for us as developers, nor is it useful for users. I'm happy for Tom to make changes now; delay has no advantage. If we have to add some lines of code/complexity to help our users then it seems a reasonable thing to do rather than keeping our code pure and demanding everybody else make changes. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] New trigger option of pg_standby
Hi, On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao wrote: > I'd like to propose another simple idea; pg_standby deletes the > trigger file *whenever* the nextWALfile is a timeline history file. > A timeline history file is restored at the end of recovery, so it's > guaranteed that the trigger file is deleted whether nextWALfile > exists or not. > > A timeline history file is restored also at the beginning of > recovery, so the accidentally remaining trigger file is deleted > in early warm-standby as a side-effect of this idea. Here is the revised patch as above. If you notice something, please feel free to comment. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center pgstandby_change_trigger_0415.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
