Re: Better handling of archive_command problems - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Better handling of archive_command problems
Date
Msg-id CAM3SWZQ1HwokhdGym2_5nfZq6fefPZJVwnA4ti+ESmMZmhxg6Q@mail.gmail.com
Whole thread Raw
In response to Re: Better handling of archive_command problems  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Better handling of archive_command problems  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, May 16, 2013 at 11:16 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> Well, I think it IS a Postgres precept that interrupts should get a
> timely response.  You don't have to agree, but I think that's
> important.

Well, yes, but the fact of the matter is that it is taking high single
digit numbers of seconds to get a response at times, so I don't think
that there is any reasonable expectation that that be almost
instantaneous. I don't want to make that worse, but then it might be
worth it in order to ameliorate a particular pain point for users.

>> There is a setting called zero_damaged_pages, and enabling it causes
>> data loss. I've seen cases where it was enabled within postgresql.conf
>> for years.
>
> That is both true and bad, but it is not a reason to do more bad things.

I don't think it's bad. I think that we shouldn't be paternalistic
towards our users. If anyone enables a setting like zero_damaged_pages
(or, say, wal_write_throttle) within their postgresql.conf
indefinitely for no good reason, then they're incompetent. End of
story.

Would you feel better about it if the setting had a time-out? Say, the
user had to explicitly re-enable it after one hour at the most?

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Better handling of archive_command problems
Next
From: Dean Rasheed
Date:
Subject: [9.3] Automatically updatable views vs writable foreign tables