On 10/30/2017 10:56 AM, Peter Geoghegan wrote:
On Mon, Oct 30, 2017 at 9:45 AM, Rob Sargent <robjsargent@xxxxxxxxx> wrote:
Peter, you beat me to the punch. I was just about to say "Having read the
referenced message I thought I would add that we never delete from this
table." In this particular case it was written to record by record, in a
previous execution and at the time of the error it was only being read. (In
case you've been following, the failed execution would have added ~1M
"segments", each which references an entry in the gin'd table "probandsets"
- but like a rookie I'm looking up each probandset(2^16) individually.
Re-working that NOW.)
It's not surprising that only a SELECT statement could see this
problem. I guess that it's possible that only page deletions used for
the pending list are involved here.
I'm not sure how reliably you can recreate the problem, but if it
doesn't take too long then it would be worth seeing what effect
turning off the FASTUPDATE storage parameter for the GIN index has.
That could prevent the problem from recurring, and would support my
theory about what's up here. (It wouldn't fix the corruption, though.)
Of course, what I'd much prefer is a self-contained test case. But if
you can't manage that, or if reproducing the issue takes hours, then
this simpler experiment might be worthwhile.
I can reload the gin'd table repeatedly in a dev environment. Does
select * from <table> order by <gin'd column> expose the corruption or
does the load itself necessarily fail at the moment of corruption?
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
