Thom Brown t...@linux.com writes:
Will you also be committing the trigger function variable changes
shortly? I don't wish to test anything prior to this as that will
involve a complete re-test from my side anyway.
It's on its way, I had to spend time elsewhere, sorry about that. With
some
On Mon, Mar 19, 2012 at 1:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
For an example in our own
problem space look at mysql, whose regression tests take well over an
hour to run on a fast box. So they must be damn near bug-free right?
Uh, not so much, and I think the fact that developers can't
On Sunday, March 18, 2012 07:29:30 PM Tom Lane wrote:
BTW, I've been looking through how to do what I suggested earlier to get
rid of the coziness and code duplication between CreateTableAs and the
prepare.c code; namely, let CreateTableAs create a DestReceiver and then
call ExecuteQuery with
On Fri, Mar 16, 2012 at 08:11:17PM -0300, Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of vie mar 16 20:06:28 -0300 2012:
Àlvaro told me he got a Spanish-language report that pg_upgrade
failed because it required pg_config, and pg_config is only supplied
with the devel
On Sat, Mar 17, 2012 at 6:58 PM, Greg Stark st...@mit.edu wrote:
On Fri, Mar 2, 2012 at 8:45 PM, Robert Haas robertmh...@gmail.com wrote:
12789 28.2686 libc-2.13.so strcoll_l
6802 15.0350 postgres text_cmp
I'm still curious how it would compare to call
On Sun, Mar 18, 2012 at 11:08 AM, Tom Lane t...@sss.pgh.pa.us wrote:
However, it occurred to me that we could pretty easily jury-rig
something that would give us an idea about the actual benefit available
here. To wit: make a C function that wraps strxfrm, basically
strxfrm(text) returns
On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
that it can enforce that the prepared query is a SELECT. (BTW, maybe
this should be weakened to something that returns tuples, in view of
RETURNING?)
+1
Robert Haas robertmh...@gmail.com writes:
On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
that it can enforce that the prepared query is a SELECT. (BTW, maybe
this should be weakened to something that
On Sat, Mar 17, 2012 at 3:58 AM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2012-03-01 at 19:19 +0200, Peter Eisentraut wrote:
I think the best fix would be to rearrange _PrintFileData() so that it
doesn't use FH at all. Instead, we could define a separate
ArchiveHandle field IF that
On Mon, Mar 19, 2012 at 12:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
that it can enforce that the prepared query
On sön, 2012-03-18 at 21:16 -0400, Tom Lane wrote:
If we were going to change the output at all, I would vote for CREATE
TABLE so as to preserve the rowcount functionality. Keep in
mind though that this would force client-side changes, for instance in
libpq's PQcmdTuples(). Fixing that
On Mon, Mar 19, 2012 at 12:53 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2012-03-18 at 21:16 -0400, Tom Lane wrote:
If we were going to change the output at all, I would vote for CREATE
TABLE so as to preserve the rowcount functionality. Keep in
mind though that this would force
Hi Noah,
thank you again for your thorough review, which is much appreciated.
I think the patch has reached the stage where a committer can review
it without wasting much time on things that might change radically.
So, I'm marking it Ready for Committer. Please still submit an update
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 19, 2012 at 12:53 PM, Peter Eisentraut pete...@gmx.net wrote:
Doesn't seem worth it to me. At least, SELECT makes some sense:
rows were selected. CREATE TABLE means what? tables
were created?
What might make sense
Excerpts from Atri Sharma's message of dom mar 18 01:05:23 -0300 2012:
I am understanding the scenario now. I will take a little of your time to
modify my original idea:
The middle layer still exists, but NOT on the individual client side ,
rather , on the server side. That is, we maintain
On Mon, Mar 19, 2012 at 11:51 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Atri Sharma's message of dom mar 18 01:05:23 -0300 2012:
I am understanding the scenario now. I will take a little of your time to
modify my original idea:
The middle layer still exists, but NOT
I wrote:
One thing I soon found is that it lacks support for EXPLAIN SELECT INTO.
While I'm not particularly excited about fixing PREPARE ... SELECT INTO
or CREATE RULE ... SELECT INTO, I've come to the conclusion that the
EXPLAIN case is a must-fix. Because not only is EXPLAIN SELECT INTO
Robert Haas robertmh...@gmail.com writes:
maybe we should just rip out pg_backup_files/archFiles altogether.
pg_dump is crufty enough without supporting undocumented and obsolete
options for multiple decades.
+1
regards, tom lane
--
Sent via pgsql-hackers mailing
On 03/19/2012 02:53 PM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
maybe we should just rip out pg_backup_files/archFiles altogether.
pg_dump is crufty enough without supporting undocumented and obsolete
options for multiple decades.
+1
Yeah, go
On Tue, Mar 20, 2012 at 12:08 AM, Atri Sharma atri.j...@gmail.com wrote:
On Mon, Mar 19, 2012 at 11:51 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Atri Sharma's message of dom mar 18 01:05:23 -0300 2012:
I am understanding the scenario now. I will take a little of your
On Sun, Mar 18, 2012 at 11:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So has somebody found a hole in the n log n lower bound on the cost of
comparison-based sorting? I thought that had been proven pretty
rigorously.
There's not much danger of anyone finding a way around that bound
since the
Excerpts from Atri Sharma's message of lun mar 19 16:20:09 -0300 2012:
I was just going through PGfoundry and I think I will be able to work
on the PL/Java project.Please let me know If I can proceed further on
ot for GSOC and also,if currently there is any work that needs to be
done on
On fre, 2012-03-16 at 13:47 -0400, Tom Lane wrote:
I'm a bit concerned about whether that's actually going to be useful.
A quick check shows that in the regression database, the proposed patch
produces 3246 possible completions, which suggests that by the time you
get down to a unique match
On mån, 2012-03-19 at 02:35 +, Peter Geoghegan wrote:
I see your point of view. I suppose I can privately hold onto the test
suite, since it might prove useful again.
I would still like to have those tests checked in, but not run by
default, in case someone wants to hack on this particular
On 19.03.2012 21:29, Alvaro Herrera wrote:
Excerpts from Atri Sharma's message of lun mar 19 16:20:09 -0300 2012:
I was just going through PGfoundry and I think I will be able to work
on the PL/Java project.Please let me know If I can proceed further on
ot for GSOC and also,if currently there
Peter Eisentraut pete...@gmx.net writes:
On fre, 2012-03-16 at 13:47 -0400, Tom Lane wrote:
I'm a bit concerned about whether that's actually going to be useful.
A quick check shows that in the regression database, the proposed patch
produces 3246 possible completions, which suggests that by
On mån, 2012-03-19 at 08:59 +, Greg Stark wrote:
The other problem with this approach is that it's hard to keep a huge
test suite 100% clean. Changes inevitably introduce behaviour changes
that cause some of the tests to fail.
I think we are used to that because of the way pg_regress
Excerpts from Tom Lane's message of lun mar 19 16:53:49 -0300 2012:
This connects somewhat to the discussions we've had in the past about
trying to get not-intended-for-public-use functions out of the standard
search path. Not that you want to put a full visibility check into the
On 19 March 2012 19:55, Peter Eisentraut pete...@gmx.net wrote:
If someone wanted to bite the bullet and do the work, I think we could
move to a Perl/TAP-based test suite (not pgTAP, but Perl and some fairly
standard Test::* modules) and reduce that useless reformatting work and
test more
Excerpts from Joachim Wieland's message of dom mar 18 02:24:21 -0300 2012:
There's a double free in the current HEAD's pg_dump. Fix attached.
Thanks, applied.
--
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom
On Fri, Mar 16, 2012 at 8:34 PM, Greg Stark st...@mit.edu wrote:
On Fri, Mar 16, 2012 at 11:29 PM, Jeff Davis pg...@j-davis.com wrote:
There is a lot of difference between those two. In particular, it looks
like the problem you are seeing is coming from the background writer,
which is not
On Mon, Mar 19, 2012 at 12:19:53PM -0400, Robert Haas wrote:
On Sat, Mar 17, 2012 at 6:58 PM, Greg Stark st...@mit.edu wrote:
On Fri, Mar 2, 2012 at 8:45 PM, Robert Haas robertmh...@gmail.com wrote:
12789 28.2686 libc-2.13.so strcoll_l
6802 15.0350 postgres
On Mon, Mar 19, 2012 at 2:49 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 19.03.2012 21:29, Alvaro Herrera wrote:
Excerpts from Atri Sharma's message of lun mar 19 16:20:09 -0300 2012:
I was just going through PGfoundry and I think I will be able to work
on the
On Sun, Mar 18, 2012 at 7:35 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 19 March 2012 01:50, Tom Lane t...@sss.pgh.pa.us wrote:
I am *not* a fan of regression tests that try to microscopically test
every feature in the system.
I see your point of view. I suppose I can privately hold
On Mon, Mar 19, 2012 at 7:23 PM, Robert Haas robertmh...@gmail.com wrote:
There's no real reason why the tuples destined for the next run need
to be maintained in heap order; we could just store them unordered and
heapify the whole lot of them when it's time to start the next run.
This sounded
Excerpts from Joachim Wieland's message of lun mar 19 00:31:47 -0300 2012:
On Wed, Mar 14, 2012 at 2:02 PM, Robert Haas robertmh...@gmail.com wrote:
I think we should somehow unify both functions, the code is not very
consistent in this respect, it also calls exit_horribly() when it has
AH
On 3/18/12 8:11 PM, HuangQi wrote:
The implementation seems to be done quite fully. There is even a patch
file. Why is the implementation not added into the release of Postgres? As
so much has already being done, what could I do in this case for the Gsoc?
That would be good for you to
On Sat, 2012-03-17 at 12:48 +, Simon Riggs wrote:
The problems are as I described them
(1) no account made for sparsity, and other factors leading to an
overestimate of rows (N)
(2) inappropriate assumption of the effect of LIMIT m, which causes a
costly SeqScan to appear better than
On Mon, Mar 19, 2012 at 9:23 PM, Martijn van Oosterhout
klep...@svana.org wrote:
Ouch. I was holding out hope that you could get a meaningful
improvement if we could use the first X bytes of the strxfrm output so
you only need to do a strcoll on strings that actually nearly match.
But with an
On Mon, Mar 19, 2012 at 6:17 PM, Josh Berkus j...@agliodbs.com wrote:
On 3/18/12 8:11 PM, HuangQi wrote:
The implementation seems to be done quite fully. There is even a patch
file. Why is the implementation not added into the release of Postgres? As
so much has already being done, what could
I've applied the CTAS patch after rather heavy editorialization. Don't
know what consequences that will have for Dimitri's patch.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Greg Stark st...@mit.edu writes:
On Mon, Mar 19, 2012 at 7:23 PM, Robert Haas robertmh...@gmail.com wrote:
There's no real reason why the tuples destined for the next run need
to be maintained in heap order; we could just store them unordered and
heapify the whole lot of them when it's time to
On Mon, Mar 19, 2012 at 6:17 PM, Josh Berkus j...@agliodbs.com wrote:
On 3/18/12 8:11 PM, HuangQi wrote:
The implementation seems to be done quite fully. There is even a patch
file. Why is the implementation not added into the release of Postgres? As
so much has already being done, what
On Tue, March 20, 2012 04:04, Joachim Wieland wrote:
On Mon, Mar 19, 2012 at 9:14 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Sounds good to me in general ... my only gripe is this: I wonder if it
would be better to have a central routine that knows about both
On Sat, Mar 17, 2012 at 8:28 PM, Daniel Farina dan...@heroku.com wrote:
This thread evolved out of an attempt to implement
pg_terminate_backend for non-superusers. I thought -- probably
erroneously -- that the major objection to that was the known
possibility of a PID-cycling race condition,
[pg_dump_die_horribly.2.diff ]
In my hands, the patch complains:
In file included from gram.y:13255:0:
scan.c: In function yy_try_NUL_trans:
scan.c:16243:23: warning: unused variable yyg [-Wunused-variable]
pg_backup_archiver.c:3320:1: error: static declaration of
On Mon, Mar 19, 2012 at 09:49:32PM +0200, Peter Eisentraut wrote:
On m??n, 2012-03-19 at 02:35 +, Peter Geoghegan wrote:
I see your point of view. I suppose I can privately hold onto the test
suite, since it might prove useful again.
I would still like to have those tests checked in,
On Mon, Mar 19, 2012 at 6:19 PM, Jeff Davis pg...@j-davis.com wrote:
On Sat, 2012-03-17 at 12:48 +, Simon Riggs wrote:
The problems are as I described them
(1) no account made for sparsity, and other factors leading to an
overestimate of rows (N)
(2) inappropriate assumption of the
On Mon, Mar 19, 2012 at 06:41:39PM +0100, Marco Nenciarini wrote:
Attached is v5, which should address all the remaining issues.
Looks clean to me.
On Fri, Mar 16, 2012 at 11:33:12PM -0400, Noah Misch wrote:
If the cost doesn't exceed O(F log P), where F is the size of the FK table
and
49 matches
Mail list logo
