Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> The reason why XLogAsyncCommitFlush() is ugly is that it doesn't
>> actually accomplish a darn thing, as we now see from this failure:
>> it does not guarantee that hint bits will get set, because of the
>> inexac
Gregory Stark <[EMAIL PROTECTED]> writes:
> Incidentally, every time it comes up we recommend using CLUSTER or ALTER
> TABLE. And explaining the syntax for ALTER TABLE is always a bit fiddly. I
> wonder if it would make sense to add a "VACUUM REWRITE" which just did the
> same as the noop ALTER TAB
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>> It would be better to release 8.3 with a new, clean, fast implementation
>> of VF, than to release it with code that we *think* is right, but has so
>> far proved a source of some truly obscure bugs.
> Well bu
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> It would be better to release 8.3 with a new, clean, fast implementation
> of VF, than to release it with code that we *think* is right, but has so
> far proved a source of some truly obscure bugs.
Well building a suitable replacement for VACUUM FULL i
On Fri, 2007-08-10 at 13:47 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Fri, 2007-08-10 at 11:11 -0400, Tom Lane wrote:
> >> If we do that, we don't actually need XLogAsyncCommitFlush() at the start.
> >> I'm inclined to remove it just because it's ugly. Comments?
>
On Fri, Aug 10, 2007 at 07:53:06PM +0100, Gregory Stark wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Another argument is that VACUUM FULL is a dinosaur that should probably
> > go away entirely someday (a view I believe you share); it should
> > therefore not be allowed to drive the de
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Another argument is that VACUUM FULL is a dinosaur that should probably
> go away entirely someday (a view I believe you share); it should
> therefore not be allowed to drive the design of other parts of the
> system.
Incidentally, every time it comes up
"Tom Lane" <[EMAIL PROTECTED]> writes:
> The reason why XLogAsyncCommitFlush() is ugly is that it doesn't
> actually accomplish a darn thing, as we now see from this failure:
> it does not guarantee that hint bits will get set, because of the
> inexact bookkeeping in clog.c. It might marginally
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Fri, 2007-08-10 at 11:11 -0400, Tom Lane wrote:
>> If we do that, we don't actually need XLogAsyncCommitFlush() at the start.
>> I'm inclined to remove it just because it's ugly. Comments?
> I'm not clear why XLogAsyncCommitFlush() is ugly. It's one
On Fri, 2007-08-10 at 11:11 -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Gregory Stark wrote:
> >> I don't think so since it sounds like he's saying to still sync the log and
> >> VACUUM FULL has an exclusive lock on the table. So any committed (or
> >> aborted)
> >>
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> I don't think so since it sounds like he's saying to still sync the log and
>> VACUUM FULL has an exclusive lock on the table. So any committed (or aborted)
>> changes it sees in the table must have been committed or aborted b
Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
>> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>>
>>> ISTM that if we call HeapTupleSatisfiesVacuum() with an additional
>>> boolean parameter, force, we can tell VF to always set the hint bits in
>>> every case, not just HEAP_MOVED_IN
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
>> ISTM that if we call HeapTupleSatisfiesVacuum() with an additional
>> boolean parameter, force, we can tell VF to always set the hint bits in
>> every case, not just HEAP_MOVED_IN and HEAP_MOVED_OUT.
>
> Surel
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Good hunch. I plugged this hole earlier, but on further inspection I can
> see the plug wasn't wide enough. XLogAsyncCommitFlush() is good enough,
> but HeapTupleSatisfiesVacuum() still allowed the inexact bookkeeping to
> sometimes skip hint bit setting,
On Wed, 2007-08-08 at 23:23 -0400, Tom Lane wrote:
> I wrote:
> > ... Since we've whacked the tqual.c logic around recently,
> > the problem might actually lie there...
>
> In fact, I bet this is a result of the async-commit patch. The places
> where vacuum.c bleats "HEAP_MOVED_OFF was expected"
I wrote:
> ... Since we've whacked the tqual.c logic around recently,
> the problem might actually lie there...
In fact, I bet this is a result of the async-commit patch. The places
where vacuum.c bleats "HEAP_MOVED_OFF was expected" are all places where
it is looking at a tuple not marked XMIN_C
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I couldn't reproduce it in a few tries. A reasonable guess is that
>> it's triggered by autovacuum deciding to vacuum the table sometime
>> before the VACUUM FULL starts. Anyone want to try to reproduce it?
> Hum, aren't vacuums sup
Tom Lane wrote:
> This is a bit disturbing:
>
> *** ./expected/vacuum.out Sat Jul 20 00:58:14 2002
> --- ./results/vacuum.out Wed Aug 8 20:16:45 2007
> ***
> *** 50,55
> --- 50,56
>
> DELETE FROM vactst WHERE i != 0;
> VACUUM FULL vactst;
> + ERROR: HEAP_MOV
This is a bit disturbing:
*** ./expected/vacuum.out Sat Jul 20 00:58:14 2002
--- ./results/vacuum.outWed Aug 8 20:16:45 2007
***
*** 50,55
--- 50,56
DELETE FROM vactst WHERE i != 0;
VACUUM FULL vactst;
+ ERROR: HEAP_MOVED_OFF was expected
DELETE FROM
19 matches
Mail list logo
