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

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.

To me, a more pragmatic approach makes sense. Obviously having some kind
of code that checks the space makes sense but I don't know that it needs
to be around any operation other than we are creating a segment. What do
we care why the segment is being created? If we don't have enough room
to create the segment, the transaction rollsback with some OBVIOUS not
OBTUSE error.

Obviously this could cause a ton of transactions to roll back but I
think keeping the database consistent and rolling back a transaction in
case of error is exactly what we are supposed to do.

Sincerely,

Joshua D. Drake

>
> - Heikki
>
>