Simon,
> My initial view was that the High Availability goal/role should be the
> default or most likely mode of operation. I would say that the current
> max_standby_delay favours the HA route since it specifically limits the
> amount by which server can fall behind.
I don't understand how Tom's approach would cause the slave to be
further behind than the current max_standy_delay code, and I can see
ways in which it would result in less delay. So, explain?
The main issue with Tom's list which struck me was that
max_standby_delay was linked to the system clock. HS is going to get
used by a lot of PG users who aren't running time sync on their servers,
or who let it get out of whack without fixing it. I'd thought that the
delay was somehow based on transaction timestamps coming from the
master. Keep in mind that there will be a *lot* of people using this
feature, including ones without compentent & available sysadmins.
The lock method appeals to me simply because it would eliminate the
"mass cancel" issues which Greg Smith was reporting every time the timer
runs down. That is, it seems to me that only the oldest queries would
be cancelled and not any new ones. The biggest drawback I can see to
Tom's approach is possible blocking on the slave due to the lock wait
from the recovery process. However, this could be managed with the new
lock-waits GUC, as well as statement timeout.
Overall, I think Tom's proposal gives me what I would prefer, which is
degraded performance on the slave but in ways which users are used to,
rather than a lot of query cancel, which will interfere with user
application porting.
Would the recovery lock show up in pg_locks? That would also be a good
diagnostic tool.
I am happy to test some of this on Amazon or GoGrid, which is what I was
planning on doing anyway.
P.S. can we avoid the "considered harmful" phrase? It carries a lot of
baggage ...
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
