On Sat, Jan 23, 2010 at 10:08 PM, Robert Haas wrote:
>
> I was also thinking about the possibility of adding a new option
> called "output" and making that control whether the "Output" line gets
> printed. It's kind of annoying to use EXPLAIN (ANALYZE, VERBOSE)
why not let it go in ANALYZE, just
(2010/01/24 12:29), Robert Haas wrote:
On Sat, Jan 23, 2010 at 1:45 PM, Bernd Helmle wrote:
--On 14. Januar 2010 16:04:17 +0900 KaiGai Kohei
wrote:
This patch adds:
List *find_column_origin(Oid relOid, const char *colName)
It returns the list of relation OIDs which originally defines the g
(2010/01/24 12:16), Robert Haas wrote:
On Sat, Jan 23, 2010 at 10:11 PM, KaiGai Kohei wrote:
If we put the new ATSimplePermissions() with all the needed information
just after gathering them at the execution stage, we don't need to have
some of exceptions which takes additional checks except fo
On Sat, Jan 23, 2010 at 1:45 PM, Bernd Helmle wrote:
> --On 14. Januar 2010 16:04:17 +0900 KaiGai Kohei
> wrote:
>> This patch adds:
>>
>> List *find_column_origin(Oid relOid, const char *colName)
>>
>> It returns the list of relation OIDs which originally defines the given
>> column. In most ca
On Sat, Jan 23, 2010 at 10:11 PM, KaiGai Kohei wrote:
> If we put the new ATSimplePermissions() with all the needed information
> just after gathering them at the execution stage, we don't need to have
> some of exceptions which takes additional checks except for ownership
> on the relation to be
(2010/01/24 11:27), Robert Haas wrote:
On Sat, Jan 23, 2010 at 8:33 PM, KaiGai Kohei wrote:
(2010/01/24 9:08), Robert Haas wrote:
On Sat, Jan 23, 2010 at 2:17 AM, KaiGai Koheiwrote:
However, it is unclear for me whether the revised ATSimplePermissions()
provide cleaner code than current
Per recent discussion on pgsql-performance, and per discussion on
-hackers that it might not be too late for small patches after all,
here is a patch (as yet without documentation) which adds some
additional instrumentation to EXPLAIN for hashes: number of buckets,
number of batches, original numbe
On Sat, Jan 23, 2010 at 7:59 PM, Andrew Dunstan wrote:
> And, BTW, more process and organization can itself consume scarce resources
> as well as annoying some of the people you want to do some of this work.
> There is a sweet spot that we need to aim at.
What, me annoy someone? That never happe
On Sat, Jan 23, 2010 at 8:33 PM, KaiGai Kohei wrote:
> (2010/01/24 9:08), Robert Haas wrote:
>>
>> On Sat, Jan 23, 2010 at 2:17 AM, KaiGai Kohei wrote:
>>>
>>> However, it is unclear for me whether the revised ATSimplePermissions()
>>> provide cleaner code than currently we have, because it also
On Sat, Jan 23, 2010 at 16:16, Tim Bunce wrote:
> On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote:
>> On Thu, Jan 14, 2010 at 09:07, Tim Bunce wrote:
>> I'd vote for use warnings; as well.
>
> I would to, but sadly it's not that simple.
>
> warnings uses Carp and Carp uses eval { ..
On Sat, Jan 23, 2010 at 16:26, Andrew Dunstan wrote:
>
>
> Tim Bunce wrote:
>>>
>>> - } keys %$imports;
>>> + } sort keys %$imports;
>>>
>>
>> Ok, good.
>>
>>
>>>
>>> - my $funcsrc;
>>> - $funcsrc .= qq[ undef *{'$name'}; *{'$name'} = sub { $BEGIN $prolog
>>> $src } ];
>>> - #warn "plper
(2010/01/24 9:08), Robert Haas wrote:
On Sat, Jan 23, 2010 at 2:17 AM, KaiGai Kohei wrote:
However, it is unclear for me whether the revised ATSimplePermissions()
provide cleaner code than currently we have, because it also needs
a big switch ... case statement within.
Am I misunderstanding so
It seems that src/Makefile.shlib has special cases for several
directories that build loadable modules rather than shared libraries.
The contrib/adminpack is one of the special cases, but none of the
other contrib directories are. As a result, they get built as shared
libraries (i.e., as libXXX.so
Robert Haas wrote:
On Sat, Jan 23, 2010 at 12:07 PM, Andrew Dunstan wrote:
Robert Haas wrote:
Perhaps it isn't that five months is outrageous,
but that it doesn't really benefit from an unorganized swarm of
activity by all the developers, and we've not worked out a
reasonable framewo
Greg Smith wrote:
> So why not do that? Developing new features is fun and tends to attract
> sponsorship dollars. Testing a frozen release, finding bugs, and
> resolving them is boring, and no one sponsors it. Therefore, if you let
> both things go on at once, I guarantee you almost all of t
On Sat, Jan 23, 2010 at 9:57 PM, Tom Lane wrote:
> What I find takes up a lot of time is post-commit patch review, fixing
> reported bugs, and documentation cleanup. Now we could doubtless find
> other people to do the purely copy-editing aspects of doc cleanup, like
> fixing less-than-stellar En
Andrew Dunstan wrote:
> The real problem is that we take a long time between the end of the
> development phase and the release. That is often not something you can
> just throw bodies at ("Nine women can't make a baby in a month.").
This is the best anti-analogy I have heard in years.
--
B
On Sat, Jan 23, 2010 at 2:17 AM, KaiGai Kohei wrote:
> However, it is unclear for me whether the revised ATSimplePermissions()
> provide cleaner code than currently we have, because it also needs
> a big switch ... case statement within.
>
> Am I misunderstanding something?
Well, not everyone is
On Sat, Jan 23, 2010 at 12:07 PM, Andrew Dunstan wrote:
> Robert Haas wrote:
>>> Perhaps it isn't that five months is outrageous,
>>> but that it doesn't really benefit from an unorganized swarm of
>>> activity by all the developers, and we've not worked out a
>>> reasonable framework for who shou
Tim Bunce wrote:
- } keys %$imports;
+ } sort keys %$imports;
Ok, good.
- my $funcsrc;
- $funcsrc .= qq[ undef *{'$name'}; *{'$name'} = sub { $BEGIN $prolog $src }
];
- #warn "plperl mkfuncsrc: $funcsrc\n";
- return $funcsrc;
+ return qq[ undef *{'$name'}; *{'$name'}
On Sat, Jan 23, 2010 at 4:57 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Goal being to continue being responsive to authors in a way that will
>> not compromise our stability, but if that means *all* qualified talents
>> of the community get assigned to release management team… I stop seein
On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote:
> On Thu, Jan 14, 2010 at 09:07, Tim Bunce wrote:
> > - Allow (ineffective) use of 'require' in plperl
> > If the required module is not already loaded then it dies.
> > So "use strict;" now works in plperl.
>
> [ BTW I think th
Tom Lane writes:
> There seems to be some weird notion abroad in this thread that the
> primary time sink during beta is unspecified low-skill "release
> management" tasks. There really isn't all that much of that.
I'd have said high-skill, which the following paragraph I parse as
confirming it:
I wrote:
> #4 0x4e85b4 in ExceptionalCondition (
> conditionName=0x1ac4ac "!(nestLevel > 0 && nestLevel <= GUCNestLevel)",
> errorType=0x1abf44 "FailedAssertion", fileName=0x1abee4 "guc.c",
> lineNumber=3907) at assert.c:57
> #5 0x501f48 in AtEOXact_GUC (isCommit=-86 'ª', nestLevel=
Andres Freund writes:
> I find "not talented" enough quite a bit too harsh...
Ok sorry about the term choice: RRR who like me are able to review
patches and help their authors but have yet to submit a patch and have
their code part of PostgreSQL, e.g.
I hope this is more clear stated this way.
-
On Sat, 2010-01-23 at 21:40 +, Greg Stark wrote:
> On Sat, Jan 23, 2010 at 8:28 PM, Simon Riggs wrote:
> > What is your proposed way of handling buffer pin deadlocks? That will be
> > acceptable and working to some extent in the next week?
> >
> > Wait forever isn't always a good idea, anymore
2010/1/23 David E. Wheeler :
> On Jan 23, 2010, at 1:22 PM, Magnus Hagander wrote:
>
>> FYI, the figures for the past month are:
>> 1. postgresql 45,579 10.91%
>> 2. postgres 16,225 3.88%
>> 3. postgre 4,901 1.17%
>> 4. postgresql download
Dimitri Fontaine writes:
> Goal being to continue being responsive to authors in a way that will
> not compromise our stability, but if that means *all* qualified talents
> of the community get assigned to release management team⦠I stop seeing
> the point.
There seems to be some weird notion a
On Sat, Jan 23, 2010 at 8:28 PM, Simon Riggs wrote:
> What is your proposed way of handling buffer pin deadlocks? That will be
> acceptable and working to some extent in the next week?
>
> Wait forever isn't always a good idea, anymore, if it ever was.
I've never said it was always a good idea. B
Andrew Dunstan writes:
> Tom Lane wrote:
>> #5 0x501f48 in AtEOXact_GUC (isCommit=-86 'ª', nestLevel=84) at guc.c:3907
> This looks like maybe a corrupted stack - the args to AtEOXact_GUC at
> that location in xact.c are hardwired.
No, that's just a fairly typical behavior of debugging with -O
On Saturday 23 January 2010 22:24:41 Dimitri Fontaine wrote:
> I was under the illusion than we had some RRR people not talented enough
> to be full-speed contributors to release management that we could have
> this team run one or two ReviewFest while the "serious" guys were
> working.
I find "not
On Jan 23, 2010, at 1:22 PM, Magnus Hagander wrote:
> FYI, the figures for the past month are:
> 1.postgresql 45,579 10.91%
> 2.postgres16,225 3.88%
> 3.postgre 4,901 1.17%
> 4.postgresql download 4,590 1.10%
> 5.
Tom Lane writes:
> There simply isn't a pool of (qualified) talent that can go off and
> do beta testing and stabilization in parallel with new development.
> It's pretty much the same people who do both tasks; so if we try to do
> that, one of two things is going to happen: beta takes even longe
2010/1/23 Robert Treat :
> A yes, and here are those statistics I posted a couple of
> years ago, showing site traffic into our website.
> http://archives.postgresql.org/pgsql-advocacy/2007-09/msg00108.php
> These are for the people who figure it out, I wonder how many people we miss
> out on beca
Robert Treat wrote:
I'm not saying there aren't
downsides, but having a name the community can unify on is a definite plus, and
imho that name has to be Postgres.
Translation: "we'll only be unified if everyone agrees with me."
Sorry, that is quite clearly not going to happen.
Can we
On Friday 22 January 2010 23:44:11 Tom Lane wrote:
> "David E. Wheeler" writes:
> > On Jan 22, 2010, at 4:54 PM, Mark Mielke wrote:
> >> MS SQL, MySQL, SQLite - do they have advocacy problems due to the SQL in
> >> their name? I think it is the opposite. SQL in the name almost grants
> >> legitima
Tom Lane wrote:
#4 0x4e85b4 in ExceptionalCondition (
conditionName=0x1ac4ac "!(nestLevel > 0 && nestLevel <= GUCNestLevel)",
errorType=0x1abf44 "FailedAssertion", fileName=0x1abee4 "guc.c",
lineNumber=3907) at assert.c:57
#5 0x501f48 in AtEOXact_GUC (isCommit=-86 'ª', nestLeve
In a somewhat misguided attempt to test something else, I did this in
CVS HEAD:
do $$begin
for i in 1 .. 1 loop
execute 'create table t' || i::text || ' (f1 int primary key)';
end loop;
end$$;
This ran for awhile and then ran out of lock table space,
On Jan 14, 2010, at 7:08 PM, Greg Smith wrote:
> So more targeted examples like you're considering now would help.
Here's the trigger example which should help reveal some of the advantages of
"native typing". This is a generic trigger that constructs and logs
manipulation statements for simple
On Sat, 2010-01-23 at 17:35 +, Greg Stark wrote:
> On Sat, Jan 23, 2010 at 4:37 PM, Simon Riggs wrote:
> > max_standby_delay = -1 option removed to prevent deadlock.
>
> This seems unacceptable to me. It means it's impossible to configure a
> reporting slave so it doesn't spuriously signal er
Tom Lane wrote:
We already heard a lot of complaints that 8.4 should have gotten more
testing than it did. Proposing to continue development in parallel
with beta is a good way to ensure that that will get worse not better.
Right. If we really want to improve mat
Greg Smith writes:
> ... if you let
> both things go on at once, I guarantee you almost all of the community
> attention will be diverted toward new development during any period
> where both are happening at the same time.
Yes. This is the big problem that would have to be solved before we
c
On Sat, Jan 23, 2010 at 12:42, David E. Wheeler wrote:
> On Jan 23, 2010, at 11:20 AM, Alex Hunsaker wrote:
>
>> Well no, i suppose we could fix that via:
>> $name =~ s/[:|']/_/g;
>>
>> Im betting that was the intent.
>
> Doubtful. In Perl, the package separator is either `::` or `'` (for
> hyste
Boszormenyi Zoltan wrote:
How about "PugSQL"? It's kind of butch, keeps the "pg" part, and we could have
a dog logo.
IIRC, Pug is a little leprechaun in Shakespeare's Midsummer night's dream.
Another logo change opportunity. :-)
I think you've confused "Puck" and "Snug". See
On Jan 23, 2010, at 11:20 AM, Alex Hunsaker wrote:
> Well no, i suppose we could fix that via:
> $name =~ s/[:|']/_/g;
>
> Im betting that was the intent.
Doubtful. In Perl, the package separator is either `::` or `'` (for hysterical
reasons). So the original code was replacing any package sepa
Kevin Grittner wrote:
Does it really take the concerted efforts of the whole community five months to
take things from the
deadline for patch commits (end of last CF) to release?
The idea is that it takes five months of complete lockdown to give the
code enough testing time to hopefully reach
On Sat, Jan 23, 2010 at 11:30, David E. Wheeler wrote:
> On Jan 22, 2010, at 7:59 PM, Alex Hunsaker wrote:
>
>> $name =~ s/::|'/_/g; # avoid package delimiters
>> + $name =~ s/'/\'/g;
>
> Looks to me like ' is already handled in the line above the one you added, no?
Well no, i suppose we cou
David E. Wheeler írta:
> On Jan 23, 2010, at 3:25 AM, Greg Stark wrote:
>
>
>> Actually the original promounciation was mee-ess-cue-ell, "My" is
>> monty's daughter's name and is pronounced like that. People generally
>> pronounced it "my" though so they just made that the official
>> pronouncia
--On 14. Januar 2010 16:04:17 +0900 KaiGai Kohei
wrote:
This patch adds:
List *find_column_origin(Oid relOid, const char *colName)
It returns the list of relation OIDs which originally defines the given
column. In most cases, it returns a list with an element. But, if the
column is inhe
On Jan 23, 2010, at 3:25 AM, Greg Stark wrote:
> Actually the original promounciation was mee-ess-cue-ell, "My" is
> monty's daughter's name and is pronounced like that. People generally
> pronounced it "my" though so they just made that the official
> pronounciation -- but they still don't approv
On Jan 22, 2010, at 7:59 PM, Alex Hunsaker wrote:
>$name =~ s/::|'/_/g; # avoid package delimiters
> + $name =~ s/'/\'/g;
Looks to me like ' is already handled in the line above the one you added, no?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
On lör, 2010-01-23 at 12:42 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > Was there a designed-in reason not to have psql tab completion for
> > COMMIT/ROLLBACK PREPARED ...? It does complete the "PREPARED" but not
> > the transaction identifiers. Maybe it's not a common use case, but
>
On Sat, Jan 23, 2010 at 5:53 PM, Ivan Sergio Borgonovo
wrote:
> That confused me further since it seems a 3rd technique to return
> set of records.
>
The heapfuncs.c example uses get_call_result_type() to get the
tupledesc and calls heap_form_tuple() to construct the return value,
just like the d
On Sat, 23 Jan 2010 15:54:04 +
Greg Stark wrote:
> On Sat, Jan 23, 2010 at 12:56 PM, Ivan Sergio Borgonovo
> wrote:
> > And if I can... how, why and when... because I didn't find any
> > clear example in the source tree that gives me a clue about when
> > I'd use one form or the other.
> >
>
Peter Eisentraut writes:
> Was there a designed-in reason not to have psql tab completion for
> COMMIT/ROLLBACK PREPARED ...? It does complete the "PREPARED" but not
> the transaction identifiers. Maybe it's not a common use case, but
> these transaction identifiers sure can be nontrivial to typ
On Sat, Jan 23, 2010 at 4:37 PM, Simon Riggs wrote:
> max_standby_delay = -1 option removed to prevent deadlock.
This seems unacceptable to me. It means it's impossible to configure a
reporting slave so it doesn't spuriously signal errors if your reports
run too long.
Recall that I am still of t
Was there a designed-in reason not to have psql tab completion for
COMMIT/ROLLBACK PREPARED ...? It does complete the "PREPARED" but not
the transaction identifiers. Maybe it's not a common use case, but
these transaction identifiers sure can be nontrivial to type.
--
Sent via pgsql-hackers ma
Robert Haas wrote:
Perhaps it isn't that five months is outrageous,
but that it doesn't really benefit from an unorganized swarm of
activity by all the developers, and we've not worked out a
reasonable framework for who should do what during that time to best
benefit the project while giving al
KaiGai Kohei writes:
> (2010/01/23 5:12), Tom Lane wrote:
>> Now the argument against that is that it won't scale terribly well
>> to situations with very large numbers of blobs.
> Even if the database contains massive number of large objects, all the
> pg_dump has to manege on RAM is its metadat
"Kevin Grittner" writes:
> ... After a few minutes that left me curious just how big
> the database was, so I tried:
> select pg_size_pretty(pg_database_size('test'));
> I did a Ctrl+C after about five minutes and got:
> Cancel request sent
> but it didn't return for 15 or 20 minutes.
Hm
On Sat, Jan 23, 2010 at 10:47 AM, Kevin Grittner
wrote:
>> What I'd really like is to stop arguing about the number of
>> CommitFests per cycle and the exact charter of each CommitFest and
>> start talking about how we can create an environment where patch
>> authors can get their work committed r
"Kevin Grittner" wrote:
> So I'm not sure whether I can get to a state suitable for starting
> the desired test, but I'll stay with a for a while.
I have other commitments today, so I'm going to leave the VACUUM
ANALYZE running and come back tomorrow morning to try the pg_dump.
-Kevin
--
S
On Sat, Jan 23, 2010 at 12:56 PM, Ivan Sergio Borgonovo
wrote:
> And if I can... how, why and when... because I didn't find any clear
> example in the source tree that gives me a clue about when I'd use
> one form or the other.
>
There are a few contrib modules which make good examples, you could
Robert Haas wrote:
> That means I'd like releases to be reasonably frequent - like
> annually - and I'd like the time for which nobody can get anything
> committed to be relatively short.
Yeah, the current approach seems to be to develop a schedule around
a one-year cycle, with an implicit ass
Bernd Helmle wrote:
--On 22. Januar 2010 15:40:58 +0200 Peter Eisentraut
wrote:
Beta is still the definite cutoff; and the closer we get to
beta, the smaller the acceptable changes become. I think that formula
basically applies throughout the entire cycle.
For someone like me it's har
--On 22. Januar 2010 15:40:58 +0200 Peter Eisentraut
wrote:
Beta is still the definite cutoff; and the closer we get to
beta, the smaller the acceptable changes become. I think that formula
basically applies throughout the entire cycle.
For someone like me it's hard to guess, what "small
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> Do you have the opportunity to try an experiment on hardware
>>> similar to what you're running that on? Create a database with
>>> 7 million tables and see what the dump/restore times are like,
>>> and whether pg_dump/pg_restor
2010/1/23 Dimitri Fontaine :
> Robert Haas writes:
>>> I agree with trying to cut down the submission-to-commit delay, but
>>
>> It seems to me that the CommitFest process is pretty darn effective at
>> reducing the submission-to-commit delay, except when you miss the last
>> one for the release -
Robert Haas writes:
>> I agree with trying to cut down the submission-to-commit delay, but
>
> It seems to me that the CommitFest process is pretty darn effective at
> reducing the submission-to-commit delay, except when you miss the last
> one for the release - then it sucks hard.
Too bad we can
Hi,
I'm trying to write a couple of C function that will:
- return a tsvector as a set of record.
- turn a tsvector into a tsquery
I'm looking at the example function to return set of records
http://www.postgresql.org/docs/8.4/static/xfunc-c.html#AEN44970
and to this:
"There are two ways you can
On Sat, Jan 23, 2010 at 4:44 AM, Tom Lane wrote:
> It's just as unclear whether MySQL is
> to be pronounced my-se-quel or my-ess-cue-ell, but how many people have
> you heard claiming that's a lousy name?
Actually the original promounciation was mee-ess-cue-ell, "My" is
monty's daughter's name a
71 matches
Mail list logo
