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
> > a
On Mon, Mar 19, 2012 at 6:19 PM, Jeff Davis 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 effect 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
>
> [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
> arch
On Sat, Mar 17, 2012 at 8:28 PM, Daniel Farina 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, whereby a sign
On Tue, March 20, 2012 04:04, Joachim Wieland wrote:
> On Mon, Mar 19, 2012 at 9:14 PM, Alvaro Herrera
> 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
>> archive_close_connection and archive_close
> On Mon, Mar 19, 2012 at 6:17 PM, Josh Berkus 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
Greg Stark writes:
> On Mon, Mar 19, 2012 at 7:23 PM, Robert Haas 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
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:
http://www.post
On Mon, Mar 19, 2012 at 6:17 PM, Josh Berkus 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 do in thi
On Mon, Mar 19, 2012 at 9:23 PM, Martijn van Oosterhout
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 information de
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
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 resear
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 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 available.
On Mon, Mar 19, 2012 at 7:23 PM, Robert Haas 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 familiar
http
On Sun, Mar 18, 2012 at 7:35 PM, Peter Geoghegan wrote:
> On 19 March 2012 01:50, Tom Lane 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 onto the test
> suite, since it m
On Mon, Mar 19, 2012 at 2:49 PM, Heikki Linnakangas
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 PL/Java project.Please let
On Mon, Mar 19, 2012 at 12:19:53PM -0400, Robert Haas wrote:
> On Sat, Mar 17, 2012 at 6:58 PM, Greg Stark wrote:
> > On Fri, Mar 2, 2012 at 8:45 PM, Robert Haas wrote:
> >> 12789 28.2686 libc-2.13.so strcoll_l
> >> 6802 15.0350 postgres text_cmp
> >
> > I'm s
On Fri, Mar 16, 2012 at 8:34 PM, Greg Stark wrote:
> On Fri, Mar 16, 2012 at 11:29 PM, Jeff Davis 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 running during initdb.
>
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
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 19 March 2012 19:55, Peter Eisentraut 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 interesting thin
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
> tab-com
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 wor
Peter Eisentraut 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 the time y
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
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 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
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 P
On Sun, Mar 18, 2012 at 11:25 AM, Tom Lane 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 proof is quite tr
On Tue, Mar 20, 2012 at 12:08 AM, Atri Sharma wrote:
> On Mon, Mar 19, 2012 at 11:51 PM, Alvaro Herrera
> 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 ide
On 03/19/2012 02:53 PM, Tom Lane wrote:
Robert Haas 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 for it.
cheers
andrew
Robert Haas 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 list (pgsql-hackers@po
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
brok
On Mon, Mar 19, 2012 at 11:51 PM, Alvaro Herrera
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 on the indivi
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 ma
Robert Haas writes:
> On Mon, Mar 19, 2012 at 12:53 PM, Peter Eisentraut 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 is to delegate this ad
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
> cor
On Mon, Mar 19, 2012 at 12:53 PM, Peter Eisentraut 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 client
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
On Mon, Mar 19, 2012 at 12:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane 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 wea
On Sat, Mar 17, 2012 at 3:58 AM, Peter Eisentraut 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 works more l
Robert Haas writes:
> On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane 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
>> R
On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane 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 for "somethi
On Sun, Mar 18, 2012 at 11:08 AM, Tom Lane 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 bytea. Then compar
On Sat, Mar 17, 2012 at 6:58 PM, Greg Stark wrote:
> On Fri, Mar 2, 2012 at 8:45 PM, Robert Haas 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 strxfrm and sort the
> resultin
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 dev
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 wi
On Mon, Mar 19, 2012 at 1:50 AM, Tom Lane 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 easily run
> t
Thom Brown 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 luck I can post
49 matches
Mail list logo
