Petr
Jelinek wrote:
This patch fixes pg_stat_database which is
broken since this commit: http://archives.postgresql.org/pgsql-committers/2005-05/msg00126.php
Neilc forgot to add new db entry inicialization to
pgstat_recv_bestart() when he removed it from pgstat_add_backend()
function, which
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What about arranging postmaster's main loop so that it starts the stats
> collector process if one of the options is activated (assuming they were
> all off at start)? Right now you have to restart the server, but I
> don't see why it has to be like tha
yes, i think we can do it in time.
regards,
hans
Bruce Momjian wrote:
Are you working on a updated version of this?
---
Bruce Momjian wrote:
Uh, seems the code has drifted too much and now I can't apply th
Hi!
Peter Eisentraut [2005-06-25 11:29 +0200]:
> Am Samstag, 25. Juni 2005 04:24 schrieb Bruce Momjian:
> > We absolutely want to support multiple installed versions of PostgreSQL.
>
> But we don't support installing multiple versions on top of each other, which
> is the only scenario where this
Hello everyone,
This is my first post to this list.
Sorry if my english it's not so good. It's not my native language.
I'm interested if someone think that having a feature like 'thousands
comma delimited numbers' in psql is a good thing.
I have made a patch for psql that adds this functionality
This patch fixes pg_stat_database which is broken since this commit:
http://archives.postgresql.org/pgsql-committers/2005-05/msg00126.php
Neilc forgot to add new db entry inicialization to pgstat_recv_bestart()
when he removed it from pgstat_add_backend() function, which causes
numbackends in pg
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What about arranging postmaster's main loop so that it starts the stats
> collector process if one of the options is activated (assuming they were
> all off at start)? Right now you have to restart the server, but I
> don't see why it has to be like tha
On Mon, Jun 27, 2005 at 09:13:20PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > > In fact, if it wasn't started from the beginning, we couldn't enable
> > > query strings without restarting the server.
> >
> > That's true -- if you start with the collector disabled, you can't
> > enabl
Alvaro Herrera wrote:
> On Mon, Jun 27, 2005 at 08:51:46PM -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > The following patch removes the GUC stats_start_collector. The stats
> > > > process is now always started.
> > >
> > > WAIT a second!!!
> > >
> > > Tha
On Mon, Jun 27, 2005 at 08:51:46PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > The following patch removes the GUC stats_start_collector. The stats
> > > process is now always started.
> >
> > WAIT a second!!!
> >
> > That was *not* the agenda; the collector is
Tom Lane wrote:
> Bruce Momjian writes:
> > The current default is true, meaning it always started.
>
> *By default* it starts. But you can turn it off, and there was no
> discussion of removing that option.
I thought we agreed that there was little value in allowing someone to
prevent the coll
Bruce Momjian writes:
> The current default is true, meaning it always started.
*By default* it starts. But you can turn it off, and there was no
discussion of removing that option.
regards, tom lane
---(end of broadcast)-
Tom Lane wrote:
> Bruce Momjian writes:
> > The following patch removes the GUC stats_start_collector. The stats
> > process is now always started.
>
> WAIT a second!!!
>
> That was *not* the agenda; the collector is only supposed to start if
> you turn on at least one of the collection options
Tom Lane wrote:
> Bruce Momjian writes:
> > Later such as in a later postmaster start, but personally I would just
> > remove the option completely.
>
> I don't have a problem with removing it as a writable option ... but
> I'm thinking we should leave it as a read-only GUC parameter (like
> the
Bruce Momjian writes:
> The following patch removes the GUC stats_start_collector. The stats
> process is now always started.
WAIT a second!!!
That was *not* the agenda; the collector is only supposed to start if
you turn on at least one of the collection options.
regar
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
At
Andrew Dunstan wrote:
> I'm very glad to see this. But is a nicer name possible? To perl
> programmers at least, "substitute" should make sense.
What is the matter with replace? We already have replace:
test=> \df replace
List of functions
Schema | Name | Result d
Please find attached a patch which adds a day field to the interval
struct so that we can treat INTERVAL '1 day' differently from
INTERVAL '24 hours' in DST-aware situations. It also includes a
function called interval_simplify() which takes an interval argument
and returns an interval wher
Improved words spacing.
--
Victor Y. Yegorov
--- gist.sgml 2005-06-20 17:53:32.0 +0300
+++ gist.sgml.patched 2005-06-27 23:14:57.0 +0300
@@ -31,15 +31,15 @@
Some of the information here is derived from the University of California
at
-Berkeley's GiST Indexing
Luke Lonergan wrote:
Andrew,
You might like to look at running pgindent (see src/tools/pgindent) over
the file before cutting a patch. Since this is usually run over each
file just before a release, the only badness should be things from
recent patches.
I've attached two patches, o
On Sun, 2005-06-26 at 20:52 +0200, Petr Jelínek wrote:
> Alvaro Herrera wrote:
>
> >I don't think this approach is very user-friendly. I'd vote for the
> >catalog approach, I think.
> >
> >
> Ok I am fine with both but catalog changes would mean more hacking of
> ALTER DATABASE and ALTER USER.
Neil Conway <[EMAIL PROTECTED]> writes:
> - when we read in the stats collector's stats file in a normal backend,
> there will be no pgStatDBHash entry for the backend's database.
> Therefore we'll read the beentry for the backend, and when we go to
> increment the n_backends for the correspondi
This patch addresses the problem mentioned in the "process crash
when a plpython function returns unicode" thread:
http://archives.postgresql.org/pgsql-bugs/2005-06/msg00105.php
In several places PL/Python was calling PyObject_Str() and then
PyString_AsString() without checking if the former had
I'm very glad to see this. But is a nicer name possible? To perl
programmers at least, "substitute" should make sense.
cheers
andrew
Atsushi Ogawa wrote:
>I made the patch that implements regexp_replace again.
>The specification of this function is as follows.
>
>regexp_replace(source text, p
On Fri, 2005-06-24 at 22:32 -0400, Bruce Momjian wrote:
> Are you working on a updated version of this?
I will work on new version during this week.
Karel
> ---
>
> Bruce Momjian wrote:
> >
> > Uh, seems the code
I made the patch that implements regexp_replace again.
The specification of this function is as follows.
regexp_replace(source text, pattern text, replacement text, [flags text])
returns text
Replace string that matches to regular expression in source text to
replacement text.
- pattern is r
So now I have it all working including brand new alter database (this
would have to be doublechecked by somebody from core team) and using
proc array to get number of backends per database and per user.
My only concer now is that userid in PGPROC, does anybody have anything
against it ?
And
Luke Lonergan wrote:
Yah - I think I fixed several mis-indented comments. I'm using vim with
tabstop=4. I personally don't like tabs in text and would prefer them
expanded using spaces, but that's a nice way to make small formatting
changes look huge in a cvs diff.
You might like to lo
Tom Lane wrote:
(d) is a performance bug, but if there is a functionality bug I'm not
seeing it.
You must use default config (or atleast turn off everything in stats
thats off by default) to see this bug.
And if you guys want to be more confused then when i'll make that
conenction limit p
29 matches
Mail list logo
