Attached patch contains new dtrace probes for memory management. Main
purpose is to analyze memory footprint - for example how many memory
needs transaction, peak memory per context, when memory block is reused
or when it is allocate by malloc and so on.
There are three groups of probes:
1)
Zdenek Kotala zdenek.kot...@sun.com writes:
Attached patch contains new dtrace probes for memory management.
This is a bad idea and I want to reject it outright. No ordinary user
is really going to care about those details, and palloc is a
sufficiently hot hot-spot that even the allegedly
On Fri, 2009-11-13 at 10:12 -0500, Robert Haas wrote:
Keep in mind that
this is a problem that *does not apply to you*. You are a committer.
If no one reviews your patch, you will eventually go ahead and commit
it anyway. If no one reviews my patch, it doesn't go in.
That is the problem.
I
On Fri, 2009-11-13 at 16:06 -0500, Tom Lane wrote:
Zdenek Kotala zdenek.kot...@sun.com writes:
Attached patch contains new dtrace probes for memory management.
This is a bad idea and I want to reject it outright. No ordinary user
is really going to care about those details, and palloc is a
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Yeah. Although the project policy is that we don't require Perl to
build on Unix, there was a bug in the makefiles that made it effectively
required, and nobody noticed for several years. I don't
On Fri, 2009-11-13 at 10:55 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
All the CF manager needs to do is ensure that every patch submitted
chalks up one review. If you think about it, we wouldn't actually need
any rr reviewers at all then, because if we have 20 patches
On Fri, 2009-11-13 at 10:46 -0500, Robert Haas wrote:
To put this another way, if everyone who submitted a patch reviewed a
patch, we could finish up each CommitFest in 2-3 weeks instead of a
whole month
Agreed. That's the idea, lets go with it to see if it works.
--
Simon Riggs
Joshua D. Drake j...@commandprompt.com writes:
On Fri, 2009-11-13 at 16:06 -0500, Tom Lane wrote:
This is a bad idea and I want to reject it outright. No ordinary user
is really going to care about those details, and palloc is a
sufficiently hot hot-spot that even the allegedly negligible
Joshua D. Drake j...@commandprompt.com wrote:
Is it possible to have a set of probes that would only be enabled
with say, --enable-debug compile time option?
But we routinely build with that for normal production use so that if
we get a core dump or need to backtrace a problem process, we
On Fri, 2009-11-13 at 15:22 -0600, Kevin Grittner wrote:
Joshua D. Drake j...@commandprompt.com wrote:
Is it possible to have a set of probes that would only be enabled
with say, --enable-debug compile time option?
But we routinely build with that for normal production use so that if
On Fri, Nov 13, 2009 at 5:16 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I had a look at this some time ago and I must admit that I find it
pretty interesting. The technology choices make it
obviously impossible to merge -- not only the particular Perl modules
used, but the mere fact
Zdenek Kotala wrote:
Attached patch contains new dtrace probes for memory management. Main
purpose is to analyze memory footprint - for example how many memory
needs transaction, peak memory per context, when memory block is reused
or when it is allocate by malloc and so on.
Having had to
Tom Lane píše v pá 13. 11. 2009 v 16:06 -0500:
Zdenek Kotala zdenek.kot...@sun.com writes:
Attached patch contains new dtrace probes for memory management.
This is a bad idea and I want to reject it outright. No ordinary user
is really going to care about those details, and palloc is a
Florian G. Pflug f...@phlo.org writes:
Tom Lane wrote:
Trying to do this in plpgsql is doomed to failure and heartache,
Well, the proposed functions at least allow for some more flexibility in
working with row types, given that you know in advance which types you
will be dealing with (but
Can't you disambiguate it using a column list on beings?
Sure, after I figured out what the real problem was. Maybe I'm a
dope, but when I get an error cursor pointed at an ambiguous column
reference, my thought is oh, I need to qualify that reference - not
oh, some completely unrelated
Alvaro Herrera píše v pá 13. 11. 2009 v 18:34 -0300:
Zdenek Kotala wrote:
Attached patch contains new dtrace probes for memory management. Main
purpose is to analyze memory footprint - for example how many memory
needs transaction, peak memory per context, when memory block is reused
or
I'm apologize about my poor english
I need to a double precision with magniude (ie meters, kilo, dolar,
etc). And can operate with them (ie dolar+dolar=dolar or
dolar/dolar=double precision).
Do you know some pluggin or module to do this?
I can implement it but I need some examples. I try
On Fri, 2009-11-13 at 22:19 +0200, Heikki Linnakangas wrote:
I got the impression earlier that you had some test environment set up
to test hot standby. Can you share any details of what test cases
you've run?
Fair question. The Sep 15 submission happened too quickly for us to
mobilise
On Fri, 2009-11-13 at 12:56 -0500, Greg Smith wrote:
For now, simply telling submitters that the
review of their own patches might be influenced by whether they do a
good job reviewing someone else's has improved things considerably
over past CommitFests, and it's hard to imagine how
On Friday 13 November 2009 18:56:01 Greg Smith wrote:
Take a look at
https://commitfest.postgresql.org/action/commitfest_view?id=4 right
now. I've been suggesting to people that they assign themselves to the
patches they like, and it's nearing completely populated two days before
the
On Fri, Nov 13, 2009 at 4:41 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
Alvaro Herrera píše v pá 13. 11. 2009 v 18:34 -0300:
Zdenek Kotala wrote:
Attached patch contains new dtrace probes for memory management. Main
purpose is to analyze memory footprint - for example how many memory
Alvaro Herrera píše v pá 13. 11. 2009 v 18:34 -0300:
Zdenek Kotala wrote:
Attached patch contains new dtrace probes for memory management. Main
purpose is to analyze memory footprint - for example how many memory
needs transaction, peak memory per context, when memory block is reused
or
On Fri, Nov 13, 2009 at 5:20 PM, Zdenek Kotala zdenek.kot...@sun.com wrote:
Alvaro Herrera píše v pá 13. 11. 2009 v 18:34 -0300:
Zdenek Kotala wrote:
Attached patch contains new dtrace probes for memory management. Main
purpose is to analyze memory footprint - for example how many memory
I attached patch which was already sent on february/april, but it was
lost in time. It is originally from Robert Lor and Theo Schlossnagle.
It contains two DTrace probe groups. One is related to monitoring SLRU
and second is about executor nodes.
I merged it with the head.
Original end of mail
1Emilio Platzer emilio.plat...@ipark.tv writes:
I need to a double precision with magniude (ie meters, kilo, dolar,
etc). And can operate with them (ie dolar+dolar=dolar or
dolar/dolar=double precision).
Do you know some pluggin or module to do this?
Yeah, there's a tagged types module on
Zdenek Kotala zdenek.kot...@sun.com writes:
Attached patch fixed following warning:
../../../src/include/nodes/parsenodes.h, line 487: warning: enumerator
value overflows INT_MAX (2147483647)
The reason is clear, enum is int not unsigned.
I think the compiler is entitled to assume either,
First attempt at a docs patch for aggregate order by.
--
Andrew.
Index: doc/src/sgml/func.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/func.sgml,v
retrieving revision 1.491
diff -c -r1.491 func.sgml
***
On Fri, 2009-11-13 at 23:10 +0100, Andres Freund wrote:
I have to admit that at least for me personally its way much easer to get
started on a patch one finds interesting than when not
I find it much easier to get interested in a patch after I get started
reviewing it ;)
Seriously, that's
Andres Freund and...@anarazel.de wrote:
On Sunday 01 November 2009 16:19:43 Andres Freund wrote:
While playing around/evaluating tsearch I notices that to_tsvector
is obscenely slow for some files. After some profiling I found that
this is due using a seperate TSParser in p_ishost/p_isURLPath
Kevin Grittner wrote:
(Note: I personally would much rather see the performance
penalty addressed this way, and a TODO added for the more invasive
work, than to leave this alone for the next release if there's nobody
willing to tackle the problem at a more fundamental level.)
+1
--
Alvaro
It looks to me like the code in AlterSetting() will allow an ordinary
user to blow away all settings for himself. Even those that are for
SUSET variables and were presumably set for him by a superuser. Isn't
this a security hole? I would expect that an unprivileged user should
not be able to
Josh Berkus wrote:
Payloads are also quite useful even in a lossy environment, where you
understand that LISTEN is not a queue. For example, I'd like to be
using LISTEN/NOTIFY for cache invalidation for some applications; if it
misses a few, or double-counts them, it's not an issue. However,
On Saturday 14 November 2009 01:03:33 Kevin Grittner wrote:
It is in context format, applies cleanly, and passes make check.
Unfortunately the latter is not saying much - I had a bug there and it was not
found by the regression tests. Perhaps I should take a stab and add at least
some more...
--On 13. November 2009 19:08:22 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
It looks to me like the code in AlterSetting() will allow an ordinary
user to blow away all settings for himself. Even those that are for
SUSET variables and were presumably set for him by a superuser. Isn't
this a
Scott Bailey wrote:
Chris Graner wrote:
Hello,
I've been reading over the documentation to find an alternative to
the deprecated xpath_table functionality. I think it may be a
possibility but I'm not seeing a clear alternative.
Thanks,
Chris Graner
The standard is XMLTABLE and is
(I'm not sure I should piping up here, so feel free to ignore, but
perhaps I have something small to offer. I've been following the list
for a while, but try to keep my mouth shut.)
On 13/11/2009 3:07 AM, Selena Deckelmann wrote:
* Distributed revision control as standard for the project
This
Robert Haas wrote:
Anyhow, as Bruce pointed out on another message, in some sense we are
getting sidetracked. Good reviewers opting out of the system *is* a
problem, but lack of a sufficient number of sufficiently involved
committers is a bigger one.
I want to thank everyone for the fine
On Fri, Nov 13, 2009 at 11:06 PM, Bruce Momjian br...@momjian.us wrote:
Having read the discussion and heard people's opinions, I am now
thinking that I need to get more involved in committing patches.
Woot.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Sun, Nov 8, 2009 at 4:41 PM, Jeff Davis pg...@j-davis.com wrote:
On Sat, 2009-11-07 at 10:56 -0800, Jeff Davis wrote:
EXCLUDE probably flows most nicely with the optional USING clause or
without. My only complaint was that it's a transitive verb, so it seems
to impart more meaning than it
101 - 139 of 139 matches
Mail list logo
