[pgpool-general: 3154] Re: vacuum analyze caused node degeneration

Sean Hogan sean at compusult.net
Wed Sep 10 20:20:25 JST 2014


Thank you.  The real question in my mind was why the two nodes responded 
differently.  But as long as it is possible to avoid the failover I can 
make it work.

Regards,
Sean


On 14-09-09 08:31 PM, Tatsuo Ishii wrote:
> If you Google with "found 0 removable, 0 nonremovable row versions in
> 0 out of 0 pages", you will find lots of search results explaining why
> this happen. Probably you have long running transaction(s) on node 1
> and VACUUMM reclaim dead tuples.
>
> I suggest to run VACUUM without VERBOSE option to suppress the "found
> 0 removal..." message, which should avoid unnecessary failover.
>
> From: Sean Hogan <sean at compusult.net>
> Subject: [pgpool-general: 3152] Re: vacuum analyze caused node degeneration
> Date: Tue, 09 Sep 2014 09:04:30 -0230
> Message-ID: <540EE5C6.2090905 at compusult.net>
>
>> Does anyone have any thought on this?
>>
>> Thanks,
>> Sean
>>
>> On 14-09-02 10:07 AM, Sean Hogan wrote:
>>> Hi,
>>>
>>> Recently during a test event we had an unexpected node degeneration,
>>> and I need to provide some reasonable explanation of why it happened.
>>> Our system is two pgpool-II 3.3.3 nodes fronting two PostgreSQL 9.2.7
>>> nodes.
>>>
>>> We selected a table in pgAdmin3 and ran VACUUM with the ANALYZE
>>> option.  Auto-vacuum is enabled on the database so the manual vacuum
>>> is a bit nonsensical, but I still didn't expect a failure.
>>>
>>> The logging tells the story:
>>>
>>> 2014-08-19 13:56:53 LOG: pid 7375: pool_send_and_wait: Error or notice
>>> message from backend: : DB node id: 0 backend pid: 7404 statement:
>>> VACUUM VERBOSE ANALYZE sch.tbl message: vacuuming "sch.tbl"
>>> 2014-08-19 13:56:53 LOG: pid 7375: pool_send_and_wait: Error or notice
>>> message from backend: : DB node id: 1 backend pid: 314 statement:
>>> VACUUM VERBOSE ANALYZE sch.tbl message: vacuuming "sch.tbl"
>>> 2014-08-19 13:56:53 ERROR: pid 7375: read_kind_from_backend: 1 th kind
>>> C does not match with master or majority connection kind N
>>> 2014-08-19 13:56:53 ERROR: pid 7375: kind mismatch among
>>> backends. Possible last query was: "VACUUM VERBOSE ANALYZE sch.tbl"
>>> kind details are: 0[N: "pg_toast_170592198": found 0 removable, 0
>>> nonremovable row versions in 0 out of 0 pages] 1[C]
>>> 2014-08-19 13:56:53 LOG: pid 7375: degenerate_backend_set: 1 fail over
>>> request from pid 7375
>>>
>>> Web searches for potential causes were not helpful.  Any ideas why
>>> node 1 would just say "command completed" without all the other
>>> information garbage that came from node 0?
>>>
>>> Thanks for any assistance,
>>>
>>> Sean
>>>
>>>
>>> _______________________________________________
>>> pgpool-general mailing list
>>> pgpool-general at pgpool.net
>>> http://www.pgpool.net/mailman/listinfo/pgpool-general

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sean.vcf
Type: text/x-vcard
Size: 275 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20140910/47c4f999/attachment.vcf>


More information about the pgpool-general mailing list