"Matthew T. O'Connor" writes:
> I don't know either, but this brings up another question. Stats
> wraparound. The n_tup_ins/upd/del columns in the stats system are
> defined as bigint, what happens when the total number of upd for example
> exceeds the capacity for bigint, or overflows to neg
Alvaro Herrera wrote:
On Sun, Jul 24, 2005 at 02:33:38PM -0400, Tom Lane wrote:
Hmm, I wonder whether the minimum shouldn't be 10. Or even 60.
It's ok with me. What do other people think?
Effectiely, this is going to be the minimum amount of "down time" for
autovacuum between
We have to consider what
happens at stat reset -- AFAICS there's no problem, because as soon as
the table sees some activity, it will be picked up by pgstat.
However, it would be bad if stats are reset right after some heavy
activity on a table. Maybe the only thing we need is documentation.
"Rocco Altier" <[EMAIL PROTECTED]> writes:
> This time I actually have the patches :-)
I've applied the parts of this that add -lm to contrib modules, but not
the parts that add -lpgport. That's because libpgport is not built to
be relocatable, and so including it fails hard on platforms that car
I've wanted for a long time to get rid of the pattern rules in the
port-specific Makefiles that generate shared libraries from single
object files. These patterns duplicate (or, more often, fail to
completely duplicate) the knowledge in Makefile.shlib. So from
a maintenance point of view centrali
On Sun, Jul 24, 2005 at 02:33:38PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > - pg_statistic is completely ignored.
>
> ... pg_statistic still needs vacuuming, surely. It's only ANALYZE
> that you can/should skip for it.
Sorry, yes, it's ignored only for analyze.
>
"Rocco Altier" <[EMAIL PROTECTED]> writes:
>> It seems highly unlikely that this will accomplish anything,
>> given that SHLIB_LINK is not used to construct regress.so.
>>
> I have another patch in queue for this.
Oh, I see, you want to use SHLIB_LINK in the %$(DLSUFFIX): %.o
rule.
> Right now
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> - pg_statistic is completely ignored.
... pg_statistic still needs vacuuming, surely. It's only ANALYZE
that you can/should skip for it.
> - The postmaster's main loop sleeps Min(60, autovacuum_naptime), in
> order to be able to pick naptimes smalle
On Thu, Jul 14, 2005 at 10:52:56AM -0400, Tom Lane wrote:
> I've applied Alvaro's latest integrated-autovacuum patch. There are
> still a number of loose ends to be dealt with before beta, though:
Ok, here's a patch that deals with some of this:
- The stat collector is modified so as to keep sha
This time I actually have the patches :-)
-rocco
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Rocco Altier
> Sent: Sunday, July 24, 2005 1:15 PM
> To: Tom Lane
> Cc: Patches (PostgreSQL)
> Subject: Re: [PATCHES] Regression - GNUmakefile
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: Sunday, July 24, 2005 10:47 AM
> To: Rocco Altier
> Cc: Patches (PostgreSQL)
> Subject: Re: [PATCHES] Regression - GNUmakefile - pg_usleep
>
>
> "Rocco Altier" <[EMAIL PROTECTED]>
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Michael Fuhr wrote:
>> Thanks -- I overlooked that in src/test/regress/README.
> We should probably generalise that section of the README a bit. People
> might skip over it thinking "this isn't a locale difference".
I'm wondering why we still have a R
Michael Fuhr wrote:
On Sun, Jul 24, 2005 at 08:40:42AM -0500, Andrew Dunstan wrote:
This is completely unnecessary - pg_regress has an alternative result
mechanism that doesn't rely on a resultmap file. Just name your alternative
result file foo_n.out instead of foo.out, for some n in [0-9
On Sun, Jul 24, 2005 at 08:40:42AM -0500, Andrew Dunstan wrote:
> This is completely unnecessary - pg_regress has an alternative result
> mechanism that doesn't rely on a resultmap file. Just name your alternative
> result file foo_n.out instead of foo.out, for some n in [0-9]. In this case,
> call
Michael Fuhr <[EMAIL PROTECTED]> writes:
> A problem with this patch is that it assumes a version of Python
> based on the OS, which might clean up the current buildfarm but
> that isn't really correct. Is there a better way to handle this?
Yes --- just let pg_regress deal with it as if it were a
"Rocco Altier" <[EMAIL PROTECTED]> writes:
> Attached patch fixes the SHLIB_LINK to add pgport now that pg_usleep is
> added.
It seems highly unlikely that this will accomplish anything, given that
SHLIB_LINK is not used to construct regress.so.
> This is needed for AIX to resolve symbols at comp
Michael Fuhr said:
> I just built Python 2.3 and it does indeed format the error differently
> than later versions (the format appears to have changed in 2.3.1):
>
[snip]
> I've attached two new files that should go in the plpython directory:
>
> resultmap
> expected/plpython_error_py23.out
>
> A
On Sat, Jul 23, 2005 at 10:38:59PM -0400, Tom Lane wrote:
> Well, if it is just a Python version issue then all we need do is add
> a variant expected-output file to match. I was just expressing a
> desire to know that for sure before we wallpaper over the symptom...
I just built Python 2.3 and i
Bruce Momjian napsal(a):
I am ready to apply this patch. Would you make the additional changes
you suggested? Is there any way to see the limits except to query
pg_authid?
Yes I will - pg_dump is already done (I attached it because it should be
aplied with orginal patch), documentation depen
Tom Lane schrieb:
"Titus von Boxberg" <[EMAIL PROTECTED]> writes:
It works for me if we want to have an "NFIELDS" construct. Personally
I'm still not convinced that we need one --- what's the use-case?
I have removed the NFIELDS construct
I'd prefer arbitrary expression, but I suppose there'
20 matches
Mail list logo
