Re: [PATCHES] fix integer datetime division rounding error

2005-07-24 Thread Rocco Altier
This fixes the problem for me. Thanks, -rocco -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: Sunday, July 24, 2005 12:37 AM To: Andrew Dunstan Cc: Patches (PostgreSQL); Rocco Altier Subject: Re: [PATCHES] fix integer datetime division rounding error

Re: [PATCHES] PL/PGSQL: Dynamic Record Introspection

2005-07-24 Thread Titus von Boxberg
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's no

Re: [PATCHES] per user/database connections limit again

2005-07-24 Thread Petr Jelinek
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

Re: [HACKERS] [PATCHES] Patch to fix plpython on OS X

2005-07-24 Thread Michael Fuhr
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 it

Re: [HACKERS] [PATCHES] Patch to fix plpython on OS X

2005-07-24 Thread Andrew Dunstan
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 problem

Re: [PATCHES] Regression - GNUmakefile - pg_usleep

2005-07-24 Thread Tom Lane
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 compile

Re: [HACKERS] [PATCHES] Patch to fix plpython on OS X

2005-07-24 Thread Tom Lane
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

Re: [HACKERS] [PATCHES] Patch to fix plpython on OS X

2005-07-24 Thread Michael Fuhr
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

Re: [HACKERS] [PATCHES] Patch to fix plpython on OS X

2005-07-24 Thread Andrew Dunstan
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

Re: [HACKERS] [PATCHES] Patch to fix plpython on OS X

2005-07-24 Thread Tom Lane
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 README

Re: [PATCHES] Regression - GNUmakefile - pg_usleep

2005-07-24 Thread Rocco Altier
-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] writes:

Re: [PATCHES] Regression - GNUmakefile - pg_usleep

2005-07-24 Thread Rocco Altier
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 -

Re: [PATCHES] [HACKERS] Autovacuum loose ends

2005-07-24 Thread Alvaro Herrera
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

Re: [PATCHES] [HACKERS] Autovacuum loose ends

2005-07-24 Thread Tom Lane
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 smaller

Re: [PATCHES] Regression - GNUmakefile - pg_usleep

2005-07-24 Thread Tom Lane
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 there are 2

Re: [PATCHES] [HACKERS] Autovacuum loose ends

2005-07-24 Thread Alvaro Herrera
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. - The

[PATCHES] Proposed patch to remove .so pattern rules from platform Makefiles

2005-07-24 Thread Tom Lane
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

Re: [PATCHES] Regression - GNUmakefile - pg_usleep

2005-07-24 Thread Tom Lane
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 care:

Re: [PATCHES] [HACKERS] Autovacuum loose ends

2005-07-24 Thread Christopher Kings-Lynne
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

Re: [PATCHES] [HACKERS] Autovacuum loose ends

2005-07-24 Thread Matthew T. O'Connor
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

Re: [PATCHES] [HACKERS] Autovacuum loose ends

2005-07-24 Thread Tom Lane
Matthew T. O'Connor matthew@zeut.net 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