ITAGAKI Takahiro wrote:
Attached is an updated DSM patch. I've left the core function of DSM only
and dropped other complicated features in this release.
We discussed it a long time ago already, but I really wished the DSM
wouldn't need a fixed size shared memory area. It's one more thing the
Zoltan Boszormenyi wrote:
On the other hand, marking GENERATED as %right
solves this issue. I hope it's an acceptable solution.
If anything I should have thought it would be marked %nonassoc.
cheers
andrew
---(end of broadcast)---
TIP 1: if p
On Fri, 2007-04-20 at 10:16 +0200, Zeugswetter Andreas ADI SD wrote:
> Your work in this area is extremely valuable and I hope my comments are
> not discouraging.
I think its too late in the day to make the changes suggested by
yourself and Tom. They make the patch more invasive and more likely t
Here's only a part of the reply I should do, but as to I/O error
checking ...
Here's a list of system calls and other external function/library calls
used in pg_lesslog patch series, together with how current patch checks
each errors and how current postgresql source handles the similar calls:
--
Hi,
I agree that pg_compresslog should be aware of all the WAL records'
details so that it can optimize archive log safely. In my patch, I've
examined 8.2's WAL records to make pg_compresslog/pg_decompresslog safe.
Also I agree further pg_compresslog maintenance needs to examine changes
in
Zoltan Boszormenyi írta:
Martijn van Oosterhout írta:
On Thu, Apr 19, 2007 at 11:19:40AM +0200, Zoltan Boszormenyi wrote:
The problem comes from cases like
colname coltype DEFAULT 5! GENERATED ...
Since b_expr allows postfix operators, it takes one more token of
lookahead than we have t
> With DBT-2 benchmark, I've already compared the amount of WAL. The
> result was as follows:
>
> Amount of WAL after 60min. run of DBT-2 benchmark
> wal_add_optimization_info = off (default) 3.13GB
how about wal_fullpage_optimization = on (default)
> wal_add_optimization_info = on (new ca
On 4/19/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
What's the purpose of the "HeapScanHintPagePrune" mechanism in index
builds? I lost track of the discussion on create index, is the it
necessary for correctness?
Its not required strictly for correctness, but it helps us prune the
HOT
Hello
I refreshed Magnus's patch
http://archives.postgresql.org/pgsql-patches/2007-02/msg00275.php from
februar.
Regards
Pavel Stehule
p.s. scrollable cursors in plpgsql need little work still. I forgot for
nonstandard (postgresql extension) direction forward all, forward n,
backward n. F
