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 not say
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 touch the
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 =
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
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
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
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
