On 9/12/07, Tom Lane [EMAIL PROTECTED] wrote:
VACUUM
--
There is little change to regular vacuum. It removes dead HOT tuples,
like pruning does, and cleans up any redirected dead line pointers.
In lazy vacuum, we must not freeze a tuple that is in the middle of an
update chain. That
On 9/12/07, Tom Lane [EMAIL PROTECTED] wrote:
VACUUM FULL
---
To make vacuum full work, any DEAD tuples in the middle of an update
chain need to be removed (see comments at the top of
heap_prune_hotchain_hard() for details). Vacuum full performs a more
aggressive pruning that not
On 9/11/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
The crucial design
decision for HOT is when to prune and when to defragment the page, so
that when we're doing the UPDATE, there's room in the page.
Right.
For defragmentation, I am still inclined towards doing it when we see
that
Hi
Per my post to the hackers list, here is a patch that renamed
latestCompletedXid to latestCommittedXid, and updates it only
on commits.
greetings, Florian Pflug
latestcommitted.patch.gz
Description: GNU Zip compressed data
---(end of
Florian G. Pflug [EMAIL PROTECTED] writes:
Per my post to the hackers list, here is a patch that renamed
latestCompletedXid to latestCommittedXid, and updates it only
on commits.
This is wrong --- it will break early detection of aborted
subtransactions.
regards, tom
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Per my post to the hackers list, here is a patch that renamed
latestCompletedXid to latestCommittedXid, and updates it only
on commits.
This is wrong --- it will break early detection of aborted
subtransactions.
I don't see how -
Florian G. Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
This is wrong --- it will break early detection of aborted
subtransactions.
I don't see how - TransactionIdIsInProgress doesn't even touch
latestCompletedXid.
Nah, I take that back --- I was worried that XidInMVCCSnapshot might
say
Andrew Dunstan [EMAIL PROTECTED] writes:
addlitchar(unescape_single_char(yytext[1]));
+ if
(IS_HIGHBIT_SET(literalbuf[literallen]))
+ saw_high_bit = true;
Isn't that array
Pavan Deolasee [EMAIL PROTECTED] writes:
On 9/12/07, Tom Lane [EMAIL PROTECTED] wrote:
XXX doesn't the above completely break the anti-wraparound guarantees?
And why couldn't we avoid the problem by pruning the previous tuple,
which is surely dead?
We preserve anti-wraparound guarantees by
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Pavel Stehule wrote:
I would argue that we should likewise not allow them in plpgsql's MOVE,
although this is
Zdenek Kotala wrote:
I would like to inform, that New Zealand changed DST rules and new
timezone files are available. See
http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Daylight-Saving-Daylight-saving-to-be-extended
Patch for head attached. I kept zic.c untouched, but I think it
On 9/12/07, Tom Lane [EMAIL PROTECTED] wrote:
This seems all wrong to me. We'd only be considering freezing a tuple
whose xmin precedes the global xmin. If it has a predecessor, that
predecessor has xmax equal to this one's xmin, therefore also preceding
global xmin, therefore it would be
12 matches
Mail list logo
