Any suggestion about how to track down the problem?
What you are describing sounds rather like a use-of-uninitialized-memory
problem, wherein the behavior depends on what happened to be in that
memory previously. If so, using a debug/cassert-enabled build of
Postgres might help to make the behavior more reproducible.
It seems to me, possible reason of that behavior could be an order of table's
scanning. GIN's build algorithm prefers scan from begin to the end of table, but
in 8.3 it's not always true - scan may begin from the middle or end of table
depending on sequence scan's history.
GIN's build algorithm could use bulk insert of ItemPointers if and only if they
should be inserted on rightmost page (exact piece of code - dataPlaceToPage() in
gindatapage.c, lines 407-427)
Is any way to force table's scan from the beginning?
--
Teodor Sigaev E-mail: teodor@xxxxxxxxx
WWW: http://www.sigaev.ru/
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
