Re: Hard limit on WAL space used (because PANIC sucks)

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Hard limit on WAL space used (because PANIC sucks)
Date: 2013-06-08 19:17:27
Message-ID: CAMkU=1y8Tx-8S5JEPgfKFbup9sFVnvW_Wt3qHzgv5tafgRUNBg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jun 8, 2013 at 11:15 AM, Joshua D. Drake <jd(at)commandprompt(dot)com>wrote:

>
> On 06/06/2013 07:52 AM, Heikki Linnakangas wrote:
>
>> I think it can be made fairly robust otherwise, and the performance
>> impact should be pretty easy to measure with e.g pgbench.
>>
>
> Once upon a time in a land far, far away, we expected users to manage
> their own systems. We had things like soft and hard quotas on disks and
> last log to find out who was logging into the system. Alas, as far as I
> know soft and hard quotas are kind of a thing of the past but that doesn't
> mean that their usefulness has ended.
>
> The idea that we PANIC is not just awful, it is stupid. I don't think
> anyone is going to disagree with that. However, there is a question of what
> to do instead. I think the idea of sprinkling checks into the higher level
> code before specific operations is not invalid but I also don't think it is
> necessary.
>

Given that the system is going to become unusable, I don't see why PANIC is
an awful, stupid way of doing it. And if it can only be used for things
that don't generate WAL, that is pretty much unusable, as even read only
transactions often need to do clean-up tasks that generate WAL.

Cheers,

Jeff

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2013-06-08 19:31:13 Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
Previous Message Tom Lane 2013-06-08 19:13:51 Re: Proposed patch: remove hard-coded limit MAX_ALLOCATED_DESCS