On Thu, May 16, 2013 at 10:05 PM, Peter Geoghegan p...@heroku.com wrote:
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
On Thu, May 16, 2013 at 10:06 PM, Daniel Farina dan...@heroku.com wrote:
Do you have a sketch about mechanism to not encounter that problem?
I didn't until just now, but see my email to Peter. That idea might
be all wet, but off-hand it seems like it might work...
However little it may
On Thu, May 16, 2013 at 9:13 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 16, 2013 at 10:06 PM, Daniel Farina dan...@heroku.com wrote:
Do you have a sketch about mechanism to not encounter that problem?
I didn't until just now, but see my email to Peter. That idea might
be all
On Wed, May 15, 2013 at 6:40 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, May 15, 2013 at 3:46 AM, Robert Haas robertmh...@gmail.com wrote:
One possible objection to this line of attack is that, IIUC, waits to
acquire a LWLock are non-interruptible. If someone tells PostgreSQL
to wait
On Thu, May 16, 2013 at 11:16 AM, Robert Haas robertmh...@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
On Thu, May 16, 2013 at 2:42 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, May 16, 2013 at 11:16 AM, Robert Haas robertmh...@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.
On Thu, May 16, 2013 at 5:43 PM, Robert Haas robertmh...@gmail.com wrote:
At times, like when the system is under really heavy load? Or at
times, like depending on what the backend is doing? We can't do a
whole lot about the fact that it's possible to beat a system to death
so that, at the
On Thu, May 16, 2013 at 5:43 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 16, 2013 at 2:42 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, May 16, 2013 at 11:16 AM, Robert Haas robertmh...@gmail.com wrote:
Well, I think it IS a Postgres precept that interrupts should get a
On Tue, May 14, 2013 at 12:23 AM, Daniel Farina dan...@heroku.com wrote:
On Mon, May 13, 2013 at 3:02 PM, Peter Geoghegan p...@heroku.com wrote:
Has anyone else thought about approaches to mitigating the problems
that arise when an archive_command continually fails, and the DBA must
manually
On Wed, May 15, 2013 at 3:46 AM, Robert Haas robertmh...@gmail.com wrote:
One possible objection to this line of attack is that, IIUC, waits to
acquire a LWLock are non-interruptible. If someone tells PostgreSQL
to wait for some period of time before performing each WAL write,
other backends
The documentation says of continuous archiving:
While designing your archiving setup, consider what will happen if
the archive command fails repeatedly because some aspect requires
operator intervention or the archive runs out of space. For example,
this could occur if you write to tape without
On Mon, May 13, 2013 at 3:02 PM, Peter Geoghegan p...@heroku.com wrote:
Has anyone else thought about approaches to mitigating the problems
that arise when an archive_command continually fails, and the DBA must
manually clean up the mess?
Notably, the most common problem in this vein suffered
12 matches
Mail list logo
