Jim C. Nasby wrote:
Moving to -hackers.
On Fri, May 11, 2007 at 04:37:44PM +0100, Heikki Linnakangas wrote:
If you know when the checkpoint ended, and you know how long each of the
pieces took, you can reconstruct the other times easily. The way you
describe this it is true--that the summary
Hello
head file uuid.h isn't in subdirectory ossp on Fedora Core 6 (uuid was
installed from uuid and uuid-devel package). I had to change
#include ossp/uuid.h to #include uuid.h
Regards
Pavel Stehule
---(end of broadcast)---
TIP 4: Have you
Andrew Dunstan wrote:
Tom Lane wrote:
The last two runs on baiji have failed at the installcheck stage,
with symptoms that look a heck of a lot like the most recent system
catalog changes haven't taken effect (eg, it doesn't seem to know
about pg_type.typarray). Given that the previous check
Magnus Hagander wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
The last two runs on baiji have failed at the installcheck stage,
with symptoms that look a heck of a lot like the most recent system
catalog changes haven't taken effect (eg, it doesn't seem to know
about pg_type.typarray). Given
Andrew Dunstan wrote:
Magnus Hagander wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
The last two runs on baiji have failed at the installcheck stage,
with symptoms that look a heck of a lot like the most recent system
catalog changes haven't taken effect (eg, it doesn't seem to know
about
Magnus Hagander wrote:
My point was that I can't even investigate how MSVC is working
at all.
So what is it you're looking for, specifically, to help with that?
As a very bare minimum, we need to change the installation procedure to
log its destination.
Unless that has somehow got screwed
Hello
I am trying test pg_stand by. I used archive and restore commands via
README.pg_standby.
recovery finish with notice in log:
Trigger file: not set
Waiting for WAL file: /usr/local/pgsql/archive/0001
WAL file path : 0001
Andrew Dunstan wrote:
Magnus Hagander wrote:
My point was that I can't even investigate how MSVC is working
at all.
So what is it you're looking for, specifically, to help with that?
As a very bare minimum, we need to change the installation procedure to
log its destination.
Unless
Magnus Hagander wrote:
! print Installing for $conf in $target\n;
Looks like a good place to start, sure.
cheers
andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Andrew Dunstan wrote:
Magnus Hagander wrote:
! print Installing for $conf in $target\n;
Looks like a good place to start, sure.
Ok. Applied.
//Magnus
---(end of broadcast)---
TIP 5: don't forget to increase your free space
Heikki Linnakangas wrote:
Yeah, if we have the summary line we don't need the other lines and
vice versa. I have sympathy for parsing log files, I've done that a
lot in the past and I can see what you mean. Having the individual
lines is nice when you're monitoring a running system; you don't
Hello
I understand better it. Second cluster has to be an clone of first
cluster. - don't use initdb for second cluster. Is possible add this
notice to pg_standby's README?
Regards
Pavel Stehule
---(end of broadcast)---
TIP 9: In versions below
Andrew Dunstan [EMAIL PROTECTED] writes:
Unless that has somehow got screwed up I can't see how Tom's theory of a
possibly left over .bki file can stand up.
Well, I tried inserting a .bki file from April 30 into a HEAD
installation, and that made it dump core during bootstrap, so that
offhand
On Sun, May 13, 2007 at 07:54:20AM +0100, Heikki Linnakangas wrote:
Maybe we should improve the stats system so that we can collect events
with timestamps and durations, but in my experience log files actually
are the most reliable and universal way to collect real-time performance
Pavel Stehule wrote:
Hello
head file uuid.h isn't in subdirectory ossp on Fedora Core 6 (uuid was
installed from uuid and uuid-devel package). I had to change
#include ossp/uuid.h to #include uuid.h
Why isn't our setup using uuid-config?
[EMAIL PROTECTED] andrew]# uuid-config
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Unless that has somehow got screwed up I can't see how Tom's theory of a
possibly left over .bki file can stand up.
Well, I tried inserting a .bki file from April 30 into a HEAD
installation, and that made it dump core during
Hi All,
COPY/INSERT are also bottlenecked on record at a time insertion into
heap, and in checking for pre-insert trigger, post-insert trigger and
constraints.
To speed things up, we really need to special case insertions without
triggers and constraints, [probably allow for unique
CK Tan [EMAIL PROTECTED] writes:
COPY/INSERT are also bottlenecked on record at a time insertion into
heap, and in checking for pre-insert trigger, post-insert trigger and
constraints.
To speed things up, we really need to special case insertions without
triggers and constraints,
Sorry, I should have been clearer. I meant because we need to check
for trigger firing pre/post insertion, and the trigger definitions
expect tuples to be inserted one by one, therefore we cannot insert N-
tuples at a time into the heap. Checking for triggers itself is not
taking up much
Hi developers,
Concurrently updating an updatable view seems to cause
an unexpected result. Is it a known issue?
= select version();
version
---
PostgreSQL 8.2.1 on i686-pc-mingw32, compiled
20 matches
Mail list logo
