Re: BUG #14295: Hot standby crash during tsvector rebuild - Mailing list pgsql-bugs

From Spencer Thomason
Subject Re: BUG #14295: Hot standby crash during tsvector rebuild
Date
Msg-id E3ED4BBA-3F20-4624-AE01-F754954EBDB3@whiteskycommunications.com
Whole thread Raw
In response to Re: BUG #14295: Hot standby crash during tsvector rebuild  (Spencer Thomason <spencer@whiteskycommunications.com>)
List pgsql-bugs
Hi Tom,
I have a python script which simulates our production environment and so fa=
r I have been able to replicate the failure on demand.  What is the best wa=
y to make this available?

Also, I can make this sandbox environment available for remote access if th=
at would help.

Thanks!
Spencer


> On Aug 29, 2016, at 10:32 AM, Spencer Thomason <spencer@whiteskycommunica=
tions.com> wrote:
>=20
> Hi Tom,
> I'm working on labbing this up and hopefully I can replicate it outside o=
f our production environment.
>=20
> We have a text column that contains fair amount of text (e.g. generated f=
rom a fax of maybe 10-25 pages) and then a tsvector column of that text wit=
h a gin index.  To improve performance, we delete text on the old records n=
ightly.
>=20
> This appears to be related to number of records updated and the size of t=
he update to the tsvector column.  Hopefully I can provide more details and=
 a test case soon.
>=20
> Thanks,
> Spencer
>=20
>=20
>=20
>> On Aug 26, 2016, at 4:05 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>=20
>> spencer@whiteskycommunications.com writes:
>>> Logs from one of the replicas is below:
>>> 2016-08-26 06:01:50 UTC FATAL:  unexpected GIN leaf action: 0
>>> 2016-08-26 06:01:50 UTC CONTEXT:  xlog redo Insert item, node:
>>> 1663/16387/33108 blkno: 6622 isdata: T isleaf: T 3 segments: 2 (add 0 i=
tems)
>>> 0 unknown action 0 ???
>>=20
>> Hmm, we have seen a couple of reports of that recently but have not been
>> able to track it down.  Can you provide more details about what you're
>> doing that triggers it?  Maybe even a self-contained test case?  It
>> doesn't have to be one that fails every time, as long as it'll fail
>> occasionally.
>>=20
>>             regards, tom lane
>=20

pgsql-bugs by date:

Previous
From: Ralf Wiebicke
Date:
Subject: Re: BUG #14296: weird check constraint clause in pg_constraint
Next
From: amee.sankhesara@quipment.nl
Date:
Subject: BUG #14305: How to reduce WAL files in Point in time recovery