postgresql01.managed.contegix.com and therefore developer.pgadmin.org
and nagios.pgadmin.org will be going down for maintenance sometime
shortly after 9AM GMT today. Downtime is expected to be around 15 minutes.
Apologies for the short notice.
Regards, Dave
---(end of
Magnus Hagander wrote:
Log Message:
---
New versions of mingw have gettimeofday(), so add an autoconf test
for this.
Can we backport this fix? I'm trying to setup a new windows build
environment and this is currently halting my progress for back branches.
Kris Jurka
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Mark Mielke [EMAIL PROTECTED] writes:
Tom Lane wrote:
My goodness that's a hardware-dependent proposal. Shall we discuss
how many CPUs there are where an integer division is *slower* than
a floating-point op?
Do you have one in mind,
Tom Lane wrote:
On further thought though, that's not the whole story, and in fact
VACUUM itself isn't doing very well at accounting for in-doubt tuples.
The current implementation is that whatever live and dead tuple totals
are arrived at by a VACUUM or ANALYZE are sent to the stats
Gregory Stark wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Looking at the autovacuum log output,
2007-11-13 09:21:19.830 PST 9458 LOG: automatic vacuum of table
specdb.public.txn_log_table: index scans: 1
pages: 11 removed, 105 remain
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
On further thought though, that's not the whole story, and in fact
VACUUM itself isn't doing very well at accounting for in-doubt tuples.
How about this: let's have VACUUM send a message at the start of
processing the table. pgstats
On Mon, 2007-11-19 at 10:38 -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
On further thought though, that's not the whole story, and in fact
VACUUM itself isn't doing very well at accounting for in-doubt tuples.
How about this: let's have VACUUM send a
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2007-11-19 at 10:38 -0500, Tom Lane wrote:
The race conditions are a lot more subtle than that. The stats
collector cannot know when it receives a tabstat message after VACUUM
starts whether VACUUM has/will see the tuples involved, or whether it
On Mon, 2007-11-19 at 13:33 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2007-11-19 at 10:38 -0500, Tom Lane wrote:
The race conditions are a lot more subtle than that. The stats
collector cannot know when it receives a tabstat message after VACUUM
starts whether
Alvaro Herrera a écrit :
Peter Eisentraut wrote:
Do we care to maintain a maximum width for programs' --help output (and
psql's
\?)? I think 79 characters was once a recommendation (or perhaps 72), but
we
have a couple of violations either way, which I'd like to fix, but what to?
79
On Thu, Nov 15, 2007 at 06:56:06PM -0300, Alvaro Herrera wrote:
Peter Eisentraut wrote:
Do we care to maintain a maximum width for programs' --help output (and
psql's
\?)? I think 79 characters was once a recommendation (or perhaps 72), but
we
have a couple of violations either
11 matches
Mail list logo
