Re: [GENERAL] pg_xlog on a hot_standby slave filling up

Sent from my iPhone

> On Jun 17, 2015, at 03:22, Christoph Berg <cb@df7cb.de> wrote:
>=20
> Re: Jeff Frost 2015-06-16 <67E2F20A-6A2E-484E-BF97-544F1FC66566@pgexperts.=
com>
>=20
> Yes, SSL, with default settings. I can confirm your
> wal-file-from-before analysis:
>=20
> Jun 16 07:14:59 synthesis postgres[32525]: [8-1] 2015-06-16 07:14:59 GMT L=
OG:  unexpected pageaddr 33/39000000 in log segment 000000010000003300000040=
, offset 0
> Jun 16 07:15:00 synthesis postgres[11514]: [3-1] 2015-06-16 07:15:00 GMT L=
OG:  started streaming WAL from primary at 33/40000000 on timeline 1
>=20
> -rw-------  1 postgres postgres 16777216 Jun 16 09:14 00000001000000330000=
003F
>=20
> Jun 16 17:55:01 synthesis postgres[32525]: [9-1] 2015-06-16 17:55:01 GMT L=
OG:  unexpected pageaddr 33/5A000000 in log segment 000000010000003300000060=
, offset 0
> Jun 16 17:55:02 synthesis postgres[24337]: [3-1] 2015-06-16 17:55:02 GMT L=
OG:  started streaming WAL from primary at 33/60000000 on timeline 1
>=20
> -rw-------  1 postgres postgres 16777216 Jun 16 19:55 00000001000000330000=
005F
>=20
> Jun 17 04:35:02 synthesis postgres[24337]: [4-1] 2015-06-17 04:35:02 GMT FA=
TAL:  could not send data to WAL stream: server closed the connection unexpe=
ctedly
> Jun 17 04:35:02 synthesis postgres[24337]: [4-2]         This probably mea=
ns the server terminated abnormally
> Jun 17 04:35:02 synthesis postgres[24337]: [4-3]         before or while p=
rocessing the request.
> Jun 17 04:35:02 synthesis postgres[24337]: [4-4]
> Jun 17 04:35:04 synthesis postgres[32525]: [10-1] 2015-06-17 04:35:04 GMT L=
OG:  unexpected pageaddr 33/7B000000 in log segment 000000010000003300000080=
, offset 0
> Jun 17 04:35:05 synthesis postgres[4756]: [5-1] 2015-06-17 04:35:05 GMT LO=
G:  started streaming WAL from primary at 33/80000000 on timeline 1
>=20
> -rw-------  1 postgres postgres 16777216 Jun 17 06:35 00000001000000330000=
007F
>=20
> There's a 1:1 correspondence with log and leaked files.

We thought it was related to the ssl renegotiation limit, but reducing it di=
dn't seem to make it happen more often.=20

The problem was that I couldn't seem to make a reproducible test case with p=
gbench and two servers, so it seems there is slightly more at play.=20

I believe setting the ssl renegotiation limit to 0 made it stop. Can you con=
firm?

Have you been able to reproduce synthetically?=