Tom Lane wrote:
The only alternative I can see is the one Heikki suggested: don't
truncate clog until the freeze horizon. That's safe (given the planned
change to WAL-log tuple freezing) and clean and simple, but a permanent
requirement of 250MB+ for pg_clog would put the final nail in the coffi
On Mon, Oct 30, 2006 at 07:18:04PM -0500, Neil Conway wrote:
> On Mon, 2006-10-30 at 22:56 +, Simon Riggs wrote:
> > The man pages for VACUUM, CREATE TABLESPACE, CLUSTER and
> > REINDEX DATABASE don't mention they are not allowed inside a transaction
> > block at all
>
> That should be fixed,
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I got another idea. If we make sure that vacuum removes any aborted xid
> older than OldestXmin from the table, we can safely assume that any xid
> < the current clog truncation point we are going to be interested in is
> committed. Vacuum already
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> Ouch! We did discuss that also. Flushing the buffercache is nasty with
>> very large caches, so this makes autovacuum much less friendly - and
>> could take a seriously long time if you enforce the vacuum delay
>> costings.
> Hmm,
It seems that we're converging on the conclusion that not truncating
clog early is the least bad alternative. This has the advantage of
making things a lot simpler --- we won't need to track minxid at all.
Allow me to summarize what I think has to happen:
* VACUUM will determine a freeze cutoff X
On Mon, 2006-10-30 at 20:40 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > That was understood; in the above example I agree you need to flush. If
> > you don't pass a truncation point, you don't need to flush whether or
> > not you actually truncate. So we don't need to flu
"Tom Lane" <[EMAIL PROTECTED]> writes:
> The added WAL volume should be pretty minimal, because only tuples that have
> gone untouched for a long time incur extra work.
That seems like a weak point in the logic. It seems like it would make VACUUM
which is already an i/o hog even more so. Perhaps
Gregory Stark wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > The added WAL volume should be pretty minimal, because only tuples that have
> > gone untouched for a long time incur extra work.
>
> That seems like a weak point in the logic. It seems like it would make VACUUM
> which is alr
I've worked up two alternative patches for the btree deletion bug
discussed here:
http://archives.postgresql.org/pgsql-hackers/2006-10/msg01373.php
The first one doesn't try to do anything about the underlying problem of
index keys becoming out-of-order; it just hacks up _bt_pagedel() to be
able t
On Sun, 2006-10-15 at 16:36 -0400, Tom Lane wrote:
> I'm not entirely sure where to put it, either. Subsection 32.9.1 (Dynamic
> Loading) is pretty basic stuff for first-time C-function authors ---
> this seems off-topic for that section. Maybe a new subsection down near
> the end of 32.9? Anot
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Huh, but the log would not be flushed for each operation that the vacuum
> logs. Only when it's going to commit.
It strikes me that the vacuum cost delay feature omits to consider
generation of WAL records as a cost factor. It may not be a big problem
11 matches
Mail list logo
