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
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 |