| From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
|---|---|
| To: | Rui DeSousa <rui(dot)desousa(at)icloud(dot)com> |
| Cc: | Dianne Skoll <dfs(at)roaringpenguin(dot)com>, pgsql-admin(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Reliable WAL file shipping over unreliable network |
| Date: | 2018-03-01 05:32:11 |
| Message-ID: | 3bc99165-0e03-b12c-7335-c5592e08e0bd@catalyst.net.nz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On 01/03/18 18:18, Rui DeSousa wrote:
> I can tell you this; it’s not ZFS or it’s quotas. I know that Postgres has no problems with ZFS and quotas; I have seen Postgres development environments run out of quota space on ZFS and Postgres never got corrupted — it would just crash and end up in a crash/restore loop. Just increase the quota and Postgres recovers without issue exiting the crash/restore loop, cleanup the rouge space usage, and reduce the quota back down. It makes recovering from out of space issues very quick.
>
>
So enabling quotas on the same ext4 filesystem I reliably getting 'quota
exceeded' and 11 return code from rsync. This is on Ubuntu 17.10 (not
sure what you are on)...but to me it points the finger at a ZFS bug.
Also as has just been pointed out - typically people enable monitoring
and provision so as to specifically avoid the weird edge cases for out
of disk/quota etc.
regards
Mark
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ibrahim Edib Kokdemir | 2018-03-01 06:25:30 | Re: Separate log for a specfic database |
| Previous Message | scott ribe | 2018-03-01 05:21:11 | Re: Reliable WAL file shipping over unreliable network |