Michael writes:
> On Tue, Jan 16, 2018 at 07:05:19PM +0100, Adam Sjøgren wrote:
>> This sounds very interesting - we are running PostgreSQL 9.3.20.
> Which means that we may be looking at a new bug, 9.3.20 is the latest in
> the 9.3 set as of today.
Yes; unfortunately we have failed to reproduce it outside production.
The fact that the tsvector field is always involved when we see the
error might be of interest (the tsvector field is the most updated in
our database, however).
Just for completeness, the tsvector field has a GIN index on it:
"sequence_fts_idx" gin (fts) WITH (fastupdate=off)
and it is updated by a BEFORE INSERT OR UPDATE trigger.
A new observation is that when we previously were able to get the
"unexpected chunk number" to go away by simply updating the tsvector
field of the offending record, we now have a record where we get "ERROR:
tuple concurrently updated" when we try overwriting the field.
On another record exhibiting the "unexpected chunk number" error, we
could overwrite the fts field, as can we on rows not affected by the
"unexpected chunk number"-error. So it seems the two errors might
somehow be related.
We tried stopping all activity on the database, and still got the
"ERROR: tuple concurrently updated" on the row with "unexpected chunk
number".
Also, the error we are getting is now: "unexpected chunk number 2
(expected 3) for toast value 1498303849 in pg_toast_10919630", where
previously we've only seen "unexpected chunk number 0 (expected 1)".
We are kind of at a loss, so any suggestions on what we could try are
welcome.
>> Did you ever find out exactly what the change that solved the problem
>> between 9.4.8 and 9.4.11 was?
> In this case, I think that you are looking for this thread:
> https://www.postgresql.org/message-id/20160826072658.15676.7628@wrigleys.postgresql.org
> And this commit:
> commit: a694435641faf26a9a4c210d20576ae836e86c48
> author: Tom Lane <tgl@sss.pgh.pa.us>
> date: Sat, 3 Sep 2016 13:28:53 -0400
> Fix corrupt GIN_SEGMENT_ADDITEMS WAL records on big-endian hardware.
>
> Both involved 9.4.8.
We run on x86_64-hardware, so I guess this wouldn't affect us?
Best regards,
Adam
--
"No more than that, but very powerful all the Adam Sjøgren
same; simple things are good." adsj@novozymes.com
