Re: BUG #14736: Crash on postgresql server by autovacuum worker process

From: Greg Stark <stark(at)mit(dot)edu>
To: jothiprasath216 <jothiprasath21(at)gmail(dot)com>
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14736: Crash on postgresql server by autovacuum worker process
Date: 2017-07-13 12:16:11
Message-ID: CAM-w4HOD9gLznZDZmBMNZkz46Z3OJHkZ1HDJ_yHpL+kwncnh8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 13 July 2017 at 11:04, jothiprasath216 <jothiprasath21(at)gmail(dot)com> wrote:

> With this configuration, i'm left with only one log file to search for the
> error log, in which i could not find any error specific error logs.
> I have already attached the final logs which are present in the
> corresponding log file.
> That is, no logs after "LOG: autovacuum launcher started"

I suppose we already know there was definitely some kind of I/O error
when writing the transaction log it's not a huge stretch to imagine
the same error may have prevented the log from being written. Possibly
the disk was full briefly and then the condition eased. Or possibly a
hardware fault of some kind. Filesystem errors can cause the
filesystem to be remounted ro which someone perhaps "fixed" or
rebooted the system subsequently?

One thing I was going to mention was to check "df -i" as well which
people often don't think of.

If this is a reoccurring problem you could configure the logs to be
sent remotely to a different system.

--
greg

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Heikki Linnakangas 2017-07-13 16:54:10 Re: [BUGS] BUG #14634: On Windows pg_basebackup should write tar to stdout in binary mode
Previous Message Ashutosh Bapat 2017-07-13 11:24:42 Re: PgFDW connection invalidation by ALTER SERVER/ALTER USER MAPPING