This change introduced a compiler warning. Here is a fix for it.
Remove QueryOperand->istrue flag, it was used only in cover ranking
(ts_rank_cd). Use palloc'ed array in ranking instead of flag.
Thank you, committed
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
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
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
This change introduced a compiler warning. Here is a fix for it.
| tsrank.c: In function `calc_rank_cd':
| tsrank.c:710: warning: assignment from incompatible pointer type
Index: src/backend/utils/adt/tsrank.c
===
--- src/backend/util
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 i
Hi
Since we already advance latestCompletedXid on subtransaction and toplevel
transaction aborts, we might as well use the value to rule out surely
in-progress transctions at the top of TransactionIdIsInProgress.
greetings, Florian Pflug
inprogress.patch.gz
Description: GNU Zip compressed da
"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 gu
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 9/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> XXX the above being the case, why should we bother with all this extra
>> mechanism? Seems we could dispense with "not ready for inserts".
> Without this additional step, while we are building the in
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>
> addlitchar(unescape_single_char(yytext[1]));
> + if
> (IS_HIGHBIT_SET(literalbuf[literallen]))
> + saw_high_bit = true;
Isn't that
"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
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:
> 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,
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 broadcast)--
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 se
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
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
16 matches
Mail list logo
