The text_name function was truncating its input string to the first
NAMEDATALEN-1 bytes, which is wrong if the string has multi-byte
characters. This patch changes it to use pg_mbcliplen, following
the namein function.
diff --git a/src/backend/utils/adt/varlena.c b/src/backend/utils/adt/varlena.c
On Fri, Feb 26, 2010 at 12:36 AM, Gokulakannan Somasundaram <
gokul...@gmail.com> wrote:
> To be a bit more concrete: the typical sort of failure that you could
>> get from broken btree operators is failure of transitivity, that is
>> the comparators report A < B and B < C for some A, B, C, but do
On Thu, Feb 25, 2010 at 3:59 PM, Gokulakannan Somasundaram <
gokul...@gmail.com> wrote:
> I disagree with that, Gokul -- if the ordering operators are volatile or
>> just incorrect, during DELETE, you could set xmax in the wrong IndexTuple.
>> Then there will be another IndexTuple that says it's v
If it's of any interest, I can say something about the hint bits in the
index tuple header. In my implementation, my decision was to use only one
hint bit. It went into the unused 13th bit of the IndexTuple header. When
the hint bit is set, it means that
(xmin is committed OR xmin = InvalidTransac
> The other
>> problem is the extra write load created by needing to update the index's
>> copies of the hint bits; not to mention extra writes to freeze the xids
>> when they get old enough.
>>
> But Tom, i remember that the vacuum was faster when index had visibility
> info, since we need not tou
On Wed, Feb 24, 2010 at 12:53 AM, Gokulakannan Somasundaram <
gokul...@gmail.com> wrote:
>
> Again not to deviate from my initial question, can we make a decision
> regarding unstable/mutable functions / broken data types ?
>
>
I second this question. A year or two ago, Gokul and I both proposed a
Gregory Stark wrote:
(1) & (4) require an UPDATE or DELETE to twiddle the old index tuple. Tom has
noted (in the linked message) that this is not reliable if the index has any
expression-valued columns, because it is not always possible to find the old
index entry. For this reason, the proposed p
Sometime last year, a discussion started about including visibility
metadata to avoid heap fetches during an index scan:
http://archives.postgresql.org/pgsql-patches/2007-10/msg00166.php
http://archives.postgresql.org/pgsql-patches/2008-01/msg00049.php
I think the last discussion on this was in
