Re: Standby corruption after master is restarted

From: Emre Hasegeli <emre(at)hasegeli(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>, gurkan(dot)gur(at)innogames(dot)com, david(dot)pusch(at)innogames(dot)com, patrick(dot)schmidt(at)innogames(dot)com
Subject: Re: Standby corruption after master is restarted
Date: 2018-04-16 08:58:35
Message-ID: CAE2gYzzs9sh0uDjNvMnXx3HeGpAn9BpGXVDFnV+r-k160sJ-oQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

> Also, which process gets killed by the OOM killer? A random backend,
> walsender or some other process?

It was always a SELECT query that was killed. I assume it was because
of the GIN index we have with huge pending list. Postgres was
"terminating other connections because of crash of another server
process".

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tomas Vondra 2018-04-16 13:41:34 Re: Standby corruption after master is restarted
Previous Message Emre Hasegeli 2018-04-16 08:55:13 Re: Standby corruption after master is restarted

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2018-04-16 09:34:11 very slow queries when max_parallel_workers_per_gather is higher than zero
Previous Message Emre Hasegeli 2018-04-16 08:55:13 Re: Standby corruption after master is restarted