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
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 CPU
"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 constraint
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 constr
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 duri
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 to #include
Why isn't our setup using uuid-config?
[EMAIL PROTECTED] andrew]# uuid-config --includedir
/usr/include
c
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
> infor
"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
offh
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 8
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;
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
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:
>>> 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 destinatio
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:
Waiting for WAL file: /usr/local/pgsql/archive/0001
WAL file path : 0001
Restoring
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 s
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
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.typ
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 previo
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 to #include
Regards
Pavel Stehule
---(end of broadcast)---
TIP 4: Have you searched our list arch
19 matches
Mail list logo
