Robert Haas wrote:
Well, I guess I'm still of the opinion that the real question is
whether the particular lint checks that Pavel's implemented are good
and useful things. Has anyone spent any time looking at *that*?
Actually, I did when I reviewed the patch the first time round.
I think that
On Thu, Mar 8, 2012 at 02:45, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Mar 8, 2012 at 10:36 AM, Thom Brown t...@linux.com wrote:
I've just tried using pg_basebackup to take a backup of a standby with
-x stream but it never finishes.
Thanks for the report! This is the same problem as I
On 8 March 2012 01:45, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Mar 8, 2012 at 10:36 AM, Thom Brown t...@linux.com wrote:
I've just tried using pg_basebackup to take a backup of a standby with
-x stream but it never finishes.
Thanks for the report! This is the same problem as I
On 03/08/2012 08:35 AM, Pavel Stehule wrote:
Here is updated patch (with regress tests, with documentation).
I removed a CHECK FUNCTION and CHECK TRIGGER statements and replaced
it by pg_check_function and pg_check_trigger like Tom proposed.
The core of this patch is same - plpgsql checker,
Hi guys,
sorry, I'm stuck in an unfamiliar webmail.
I checked the patch Petr just posted.
http://archives.postgresql.org/pgsql-hackers/2012-03/msg00482.php
I have two comments. First, I notice that the documentation changes
has two places that describe the columns that a function checker
On Tue, Mar 6, 2012 at 10:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Applied with minor editorialization (mainly just improving the
comments).
Thanks and kudos to all the reviewers!
regards,
Martin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Wed, Mar 7, 2012 at 9:59 PM, Fujii Masao masao.fu...@gmail.com wrote:
I'd like to have the planning time in a number of other places as
well, such as EXPLAIN, and maybe statistics views.
+1 for EXPLAIN. But which statistics views are in your mind?
I don't know. I'm not sure if it's
On Fri, Feb 24, 2012 at 9:01 PM, Noah Misch n...@leadboat.com wrote:
I consider these the core changes needed to reach Ready for Committer:
- Fix crash in array_replace(arr, null, null).
- Don't look through the domain before calling can_coerce_type().
- Compare operator family of pfeqop and
On Thu, Jan 26, 2012 at 12:40 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
So I'm going to prepare the next version of the patch with this design:
Considering that this constitutes a major redesign and that the
updated patch hasn't been posted over a month later, it seems past
time to mark
On Tue, Feb 28, 2012 at 5:34 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
Quickly reviewed the patch and found some issues.
- There are some mixture of pg_extension_feature and pg_extension_features
- The doc says pg_extension_features has four columns but it's not true.
- Line 608 is bad.
On Sat, Jan 28, 2012 at 8:57 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Jan 26, 2012 at 5:27 AM, Fujii Masao masao.fu...@gmail.com wrote:
One thing I would like to ask is that why you think walreceiver is more
appropriate for writing XLOG_END_OF_RECOVERY record than startup
process.
On Sun, Feb 12, 2012 at 9:19 PM, Greg Smith g...@2ndquadrant.com wrote:
The smaller step of automatically stripping the specified suffix from the
input file name, when it matches the one we've told the program to expect,
seems like a usability improvement unlikely to lead to bad things though.
On 8 March 2012 13:09, Robert Haas robertmh...@gmail.com wrote:
Then again, considering that gettimeofday is kinda
expensive, I suppose that would have to be optional if we were to have
it at all.
+1. I'm not opposed to having such a mechanism, but it really ought to
impose exactly no overhead
On Mar 7, 2012, at 11:39 PM, Bruce Momjian wrote:
On Thu, Mar 01, 2012 at 09:06:10PM -0500, Bruce Momjian wrote:
OK, combining your and Robert's ideas, how about I have pg_upgrade write
the server log to a file, and the pg_dump output to a file (with its
stderr), and if pg_upgrade fails, I
On Wed, Feb 29, 2012 at 9:39 PM, Fujii Masao masao.fu...@gmail.com wrote:
Do we have an updated patch? Fujii?
No. I believe that the author Jim will submit the updated version.
Jim, are you going to submit an updated version?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
Robert Haas robertmh...@gmail.com writes:
Dimitri, are you going to post an updated patch for this CF?
Yes, I intend to do that. Not sure about diverting from the command
trigger patch while Thom is full speed on reviewing and helping me write
the full covering test cases, though.
Regards,
--
Peter Geoghegan pe...@2ndquadrant.com writes:
On 8 March 2012 13:09, Robert Haas robertmh...@gmail.com wrote:
Then again, considering that gettimeofday is kinda
expensive, I suppose that would have to be optional if we were to have
it at all.
+1. I'm not opposed to having such a mechanism,
On Thu, Mar 08, 2012 at 08:34:53AM -0500, A.M. wrote:
On Mar 7, 2012, at 11:39 PM, Bruce Momjian wrote:
On Thu, Mar 01, 2012 at 09:06:10PM -0500, Bruce Momjian wrote:
OK, combining your and Robert's ideas, how about I have pg_upgrade write
the server log to a file, and the pg_dump
On Mar 8, 2012, at 10:00 AM, Bruce Momjian wrote:
Yes. I was afraid that continually appending to a log file on every run
would be too confusing. I could do only appends, or number the log
files, that those seemed confusing.
the /tmp directory so that one can compare results if the
On Wed, Mar 07, 2012 at 04:57:12PM -0500, Robert Haas wrote:
On Sat, Feb 25, 2012 at 12:57 AM, Noah Misch n...@leadboat.com wrote:
Thanks. ?While testing a crashing function, I noticed that my above patch
added some noise to psql output when the server crashes:
[local] test=# select
Bruce Momjian br...@momjian.us writes:
On Thu, Mar 08, 2012 at 08:34:53AM -0500, A.M. wrote:
It looks like the patch will overwrite the logs in the current working
directory, for example, if pg_upgrade is run twice in the same place. Is
that intentional? I had imagined that the logs would have
On Fri, Mar 02, 2012 at 03:45:38PM -0500, Robert Haas wrote:
SELECT SUM(1) FROM (SELECT * FROM randomtext ORDER BY t) x;
On unpatched master, this takes about 416 ms (plus or minus a few).
With the attached patch, it takes about 389 ms (plus or minus a very
few), a speedup of about 7%.
I
On Wed, Mar 07, 2012 at 07:51:42PM -0500, Tom Lane wrote:
Alexander Korotkov aekorot...@gmail.com writes:
True. If (max count - min count + 1) is small, enumerating of frequencies
is both more compact and more precise representation. Simultaneously,
if (max count - min count + 1) is large,
Hello
there are other version related to your last comments. I removed magic
constants.
This is not merged with Peter's changes. I'll do it tomorrow. Probably
there will be some bigger changes in header files, but this can be
next step.
Regards
Pavel
2012/3/8 Alvaro Herrera
Robert Haas robertmh...@gmail.com writes:
Considering that this constitutes a major redesign and that the
updated patch hasn't been posted over a month later, it seems past
time to mark this Returned with Feedback. So I've done that.
I was hoping to be able to code that while the CF is
Shigeru Hanada shigeru.han...@gmail.com writes:
[ pgsql_fdw_v15.patch ]
I've been looking at this patch a little bit over the past day or so.
I'm pretty unhappy with deparse.c --- it seems like a real kluge,
inefficient and full of corner-case bugs. After some thought I believe
that you're
On Thu, Mar 01, 2012 at 08:45:26AM -0500, Robert Haas wrote:
On Wed, Feb 29, 2012 at 6:02 PM, Bruce Momjian br...@momjian.us wrote:
Any ideas about improving the error reporting more generally, so that
when reloading the dump fails, the user can easily see what went
belly-up, even if they
Noah Misch n...@leadboat.com wrote:
On Fri, Mar 02, 2012 at 03:45:38PM -0500, Robert Haas wrote:
SELECT SUM(1) FROM (SELECT * FROM randomtext ORDER BY t) x;
[13% faster with patch for C collation; 7% faster for UTF8]
I had hoped for more like a 15-20% gain from this approach, but
it
Noah Misch n...@leadboat.com writes:
On Wed, Mar 07, 2012 at 07:51:42PM -0500, Tom Lane wrote:
On reflection my idea above is wrong; for example assume that we have a
column with 900 arrays of length 1 and 100 arrays of length 2. Going by
what I said, we'd reduce the histogram to {1,2}, which
On 8 March 2012 14:44, Tom Lane t...@sss.pgh.pa.us wrote:
I thought the proposal was to add it to (1) pg_stat_statement and (2)
EXPLAIN, both of which are not in the normal code execution path.
pg_stat_statement is already a drag on a machine with slow gettimeofday,
but it's not clear why
Hi list,
This patch enables a simple optimization in
eval_const_expressions_mutator. If we know that one argument to
DistinctExpr is NULL then we can optimize it to a NullTest, which can
be an indexable expression.
For example the query:
EXPLAIN (costs off) SELECT * FROM foo WHERE j IS NOT
Marti Raudsepp ma...@juffo.org writes:
This patch enables a simple optimization in
eval_const_expressions_mutator. If we know that one argument to
DistinctExpr is NULL then we can optimize it to a NullTest, which can
be an indexable expression.
Uh ... how much do we care about that? I can't
On Thu, Mar 8, 2012 at 19:35, Tom Lane t...@sss.pgh.pa.us wrote:
Uh ... how much do we care about that? I can't say that I've heard many
people complain about the fact that IS [NOT] DISTINCT FROM is poorly
optimized -- which it is, in general, and this patch chips away at that
only a tiny
I have just found, after an hour or two of frustration, that pg_regress'
--inputdir and --outputdir options don't play nicely with the
convert_sourcefiles routines. In effect these options are ignored as
destinations for converted files, and the destination for converted
files is apparently
I think I've complained about this before, but:
When you are preparing a patch, fixing the comments is JUST AS IMPORTANT
AS FIXING THE CODE. Obsolete comments are worse than useless. Look to
see if you've invalidated something in the head-of-file comments about
the module you're changing. Look
On Mar 7, 2012, at 8:23 PM, Tom Lane wrote:
You have not told the system that your operator is equality for the
datatype. It's just a random operator that happens to be named =.
We try to avoid depending on operator names as cues to semantics.
You need to incorporate it into a default hash
David E. Wheeler da...@justatheory.com writes:
CREATE OPERATOR CLASS json_ops
DEFAULT FOR TYPE JSON USING btree AS
OPERATOR3 = (json, json),
FUNCTION1 json_cmp(json, json);
This seems to work.
Urk. You really ought to provide the whole opclass (all 5
On Thu, Mar 08, 2012 at 11:30:52AM -0500, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
On Wed, Mar 07, 2012 at 07:51:42PM -0500, Tom Lane wrote:
On reflection my idea above is wrong; for example assume that we have a
column with 900 arrays of length 1 and 100 arrays of length 2.
On 03/08/2012 02:16 PM, Tom Lane wrote:
David E. Wheelerda...@justatheory.com writes:
CREATE OPERATOR CLASS json_ops
DEFAULT FOR TYPE JSON USING btree AS
OPERATOR3 = (json, json),
FUNCTION1 json_cmp(json, json);
This seems to work.
Urk. You really ought to
On Mar 8, 2012, at 11:16 AM, Tom Lane wrote:
This seems to work.
Urk. You really ought to provide the whole opclass (all 5 operators).
I'm not sure what will blow up if you leave it like that, but it won't
be pretty.
Yes, I expect to have to fill in gaps as I go. These are just for unit
On Mar 8, 2012, at 11:27 AM, Andrew Dunstan wrote:
Yeah. Note too that this is at best dubious:
CREATE OR REPLACE FUNCTION json_cmp(
json,
json
) RETURNS INTEGER LANGUAGE SQL STRICT IMMUTABLE AS $$
SELECT bttextcmp($1::text, $2::text);
$$;
Two pieces of
On Mar 8, 2012, at 10:22 AM, Andrew Dunstan wrote:
This seems like an outright bug. I don't recall any discussion on it. Maybe
nobody's come across it before. ISTM the correct behaviour would be to put
converted sql files in $inputdir/sql and converted results files in
$outputdir/expected.
On 03/08/2012 02:59 PM, David E. Wheeler wrote:
On Mar 8, 2012, at 10:22 AM, Andrew Dunstan wrote:
This seems like an outright bug. I don't recall any discussion on it. Maybe
nobody's come across it before. ISTM the correct behaviour would be to put
converted sql files in $inputdir/sql and
On Mar 8, 2012, at 12:20 PM, Andrew Dunstan wrote:
It works fine if you don't need to do any file conversions (i.e. if you don't
have input or output directories). But file_textarray_fdw does.
Here's a patch that I think fixes the problem.
While you’re there, an issue I noticed is that the
I wasted a few minutes today tracking down what a couple comments
really meant to say. t_natts no longer exists as a separate field;
the equivalent value is now pulled from t_infomask2 using a macro.
Small patch to correct the comments is attached.
-Kevin
***
On 7 March 2012 20:56, Bruce Momjian br...@momjian.us wrote:
Yep, good summary. Giving ourselves a few months to think about it and
consider other failure cases will make this a great 9.3 addition.
Recent Intel processors that support SSE 4.2, including those based on
the core
David E. Wheeler da...@justatheory.com writes:
While youre there, an issue I noticed is that the MODULE_PATHNAME
substitutions do not work if you have your SQL files in a
subdirectory.
Huh? MODULE_PATHNAME is not substituted by pg_regress at all (anymore
anyway). There's still some
On 8 March 2012 20:55, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 7 March 2012 20:56, Bruce Momjian br...@momjian.us wrote:
Yep, good summary. Giving ourselves a few months to think about it and
consider other failure cases will make this a great 9.3 addition.
Recent Intel processors
Marti Raudsepp ma...@juffo.org writes:
But I don't feel strongly about this, maybe it's not worth
complicating this big function further. :)
Yeah, that was kind of what I felt about it. If this patch were part of
a grand plan to make IS DISTINCT FROM smarter, that would be one thing.
But if we
On Mar 8, 2012, at 12:59 PM, Tom Lane wrote:
Huh? MODULE_PATHNAME is not substituted by pg_regress at all (anymore
anyway).
Yeah, sorry, I meant `make`.
There's still some vestigial support for it in pgxs.mk, but
the future of that code is to vanish, not get improved. You should
not be
On tor, 2012-03-08 at 10:06 -0500, A.M. wrote:
The only reason I truncate them on start is that I am appending to
them
in many places in the code, and it was easier to just truncate them
on
start rather than to remember where I first write to them.
mktemps?
I don't want to see some
On Mar 8, 2012, at 4:37 PM, Peter Eisentraut wrote:
On tor, 2012-03-08 at 10:06 -0500, A.M. wrote:
The only reason I truncate them on start is that I am appending to
them
in many places in the code, and it was easier to just truncate them
on
start rather than to remember where I first
On 03/08/2012 04:33 PM, David E. Wheeler wrote:
On Mar 8, 2012, at 12:59 PM, Tom Lane wrote:
Huh? MODULE_PATHNAME is not substituted by pg_regress at all (anymore
anyway).
Yeah, sorry, I meant `make`.
There's still some vestigial support for it in pgxs.mk, but
the future of that code is to
On Mar 8, 2012, at 1:45 PM, Andrew Dunstan wrote:
So perhaps DATA_built is to be removed from pgxs.mk? And if so, is the idea
then that one should just put the module name in the .sql file, rather than
MODULE_PATHNAME in a .sql.in file?
Extensions (unlike non-extension modules) should not
On ons, 2012-03-07 at 12:31 -0500, Robert Haas wrote:
I might agree with you if we had more than one checker function, but
right now we are proposing to implement this for PL/pgsql and only
PL/pgsql. It seems to me that we can add that when and if a second
checker function shows up, if it
On tor, 2012-03-08 at 10:49 +0100, Albe Laurenz wrote:
Actually, I did when I reviewed the patch the first time round.
I think that the checks implemented are clearly good and useful,
since any problem reported will lead to an error at runtime if
a certain code path in the function is taken.
2012/3/8 Peter Eisentraut pete...@gmx.net:
On tor, 2012-03-08 at 10:49 +0100, Albe Laurenz wrote:
Actually, I did when I reviewed the patch the first time round.
I think that the checks implemented are clearly good and useful,
since any problem reported will lead to an error at runtime if
a
On tor, 2012-03-08 at 16:44 -0500, A.M. wrote:
The point of writing temp files to the /tmp/ directory is that they
don't need to be cleaned up.
I don't think so. If everyone just left their junk lying around
in /tmp, it would fill up just like any other partition.
--
Sent via pgsql-hackers
On ons, 2012-03-07 at 21:39 +0200, Marti Raudsepp wrote:
Is there any reason that pgxs ignores SHLIB_LINK when building
MODULES?
No, it's just never been needed.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
2012/3/8 Peter Eisentraut pete...@gmx.net:
On ons, 2012-03-07 at 12:31 -0500, Robert Haas wrote:
I might agree with you if we had more than one checker function, but
right now we are proposing to implement this for PL/pgsql and only
PL/pgsql. It seems to me that we can add that when and if a
Hi,
Thom Brown t...@linux.com writes:
The message returned by creating a command trigger after create index
is still problematic:
Fixed. I'm attaching an incremental patch here, the github branch is
updated too.
CREATE VIEW doesn't return schema:
Fixed, and as an added bonus I fixed the
On Thu, Mar 8, 2012 at 4:54 PM, Peter Eisentraut pete...@gmx.net wrote:
* It's not terribly important to me to be able to run checkers
separately. If I wanted to do that, I would just disable or
remove the checker.
Does this requirement mean that you want to essentially
On 8 March 2012 22:24, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
We're getting there. :)
Hi,
Thom Brown t...@linux.com writes:
The message returned by creating a command trigger after create index
is still problematic:
Fixed. I'm attaching an incremental patch here, the github
On Thu, Mar 08, 2012 at 10:19:05AM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Mar 08, 2012 at 08:34:53AM -0500, A.M. wrote:
It looks like the patch will overwrite the logs in the current working
directory, for example, if pg_upgrade is run twice in the same place.
On Thu, Mar 08, 2012 at 11:59:59PM +0200, Peter Eisentraut wrote:
On tor, 2012-03-08 at 16:44 -0500, A.M. wrote:
The point of writing temp files to the /tmp/ directory is that they
don't need to be cleaned up.
I don't think so. If everyone just left their junk lying around
in /tmp, it
On Wed, Mar 7, 2012 at 5:41 PM, Simon Riggs si...@2ndquadrant.com wrote:
Case #2 is certainly a problem for FrozenXID as well, because anything
that's marked with FrozenXID is going to look visible to everybody,
including our older snapshots. And I gather you're saying it's also a
problem for
It's been bugging me for a while now that we don't have a prewarming
utility, for a couple of reasons, including:
1. Our customers look at me funny when I suggest that they use
pg_relation_filepath() and /bin/dd for this purpose.
2. Sometimes when I'm benchmarking stuff, I want to get all the
On Thu, Mar 8, 2012 at 11:13 PM, Robert Haas robertmh...@gmail.com wrote:
It's been bugging me for a while now that we don't have a prewarming
utility, for a couple of reasons, including:
1. Our customers look at me funny when I suggest that they use
pg_relation_filepath() and /bin/dd for
I wrote:
There are a couple of other points that make me think we need to revisit
the PlanForeignScan API definition some more, too. ...
So we need to break down what PlanForeignScan currently does into three
separate steps. The first idea that comes to mind is to call them
On Thu, Mar 8, 2012 at 8:25 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Feb 12, 2012 at 9:19 PM, Greg Smith g...@2ndquadrant.com wrote:
The smaller step of automatically stripping the specified suffix from the
input file name, when it matches the one we've told the program to expect,
On Fri, Mar 9, 2012 at 12:46 AM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Thu, Mar 8, 2012 at 8:25 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Feb 12, 2012 at 9:19 PM, Greg Smith g...@2ndquadrant.com wrote:
The smaller step of automatically stripping the specified suffix from the
On 08.03.2012 22:33, Kevin Grittner wrote:
I wasted a few minutes today tracking down what a couple comments
really meant to say. t_natts no longer exists as a separate field;
the equivalent value is now pulled from t_infomask2 using a macro.
Small patch to correct the comments is attached.
On Wed, Feb 22, 2012 at 12:27 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Feb 14, 2012 at 02:04:26AM -0500, Jaime Casanova wrote:
1) pgstattuple-gin_spgist.patch
This first patch adds gin and spgist support to pgstattuple, also
makes pgstattuple use a ring buffer when reading tables or
73 matches
Mail list logo
