Re: BUG #14295: Hot standby crash during tsvector rebuild

From: Spencer Thomason <spencer(at)whiteskycommunications(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14295: Hot standby crash during tsvector rebuild
Date: 2016-09-01 14:22:33
Message-ID: E3ED4BBA-3F20-4624-AE01-F754954EBDB3@whiteskycommunications.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Tom,
I have a python script which simulates our production environment and so far I have been able to replicate the failure on demand. What is the best way to make this available?

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

Thanks!
Spencer

> On Aug 29, 2016, at 10:32 AM, Spencer Thomason <spencer(at)whiteskycommunications(dot)com> wrote:
>
> Hi Tom,
> I'm working on labbing this up and hopefully I can replicate it outside of our production environment.
>
> We have a text column that contains fair amount of text (e.g. generated from a fax of maybe 10-25 pages) and then a tsvector column of that text with a gin index. To improve performance, we delete text on the old records nightly.
>
> This appears to be related to number of records updated and the size of the update to the tsvector column. Hopefully I can provide more details and a test case soon.
>
> Thanks,
> Spencer
>
>
>
>> On Aug 26, 2016, at 4:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> spencer(at)whiteskycommunications(dot)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 items)
>>> 0 unknown action 0 ???
>>
>> 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.
>>
>> regards, tom lane
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message amee.sankhesara 2016-09-01 14:23:47 BUG #14305: How to reduce WAL files in Point in time recovery
Previous Message Ralf Wiebicke 2016-09-01 12:48:09 Re: BUG #14296: weird check constraint clause in pg_constraint