Greg Smith wrote: > Heikki Linnakangas wrote: > > Let's rip out the concept of a delay altogether, and make it a boolean. > > If you really want your query to finish, set it to -1 (using the current > > max_standby_delay nomenclature). If recovery is important to you, set it > > to 0. > > > > So the only user options would be "allow long-running queries to block > WAL application forever" and "always cancel queries on conflict?" That > would be taking away the behavior I was going to suggest as the default > to many customers I work with. I expect a non-trivial subset of people > using this feature will set max_standby_delay to is some small number of > minutes, similarly to how archive_timeout is sized now. Enough time to > get reasonably sized queries executed, not so long as to allow something > that might try to run for hours on the standby to increase failover > catchup time very much. > > The way the behavior works is admittedly limited, and certainly some > people are going to want to set it to either 0 or -1. But taking it > away altogether is going to cripple one category of potential Hot > Standby use in the field. Consider this for a second: do you really > think that Simon would have waded into this coding mess, or that I would > have spent as much energy as I have highlighting issues with its use, if > there wasn't demand for it? If it wouldn't hurt the usefulness of > PostgreSQL 9.0 significantly to cut it, I'd have suggested that myself > two months ago and saved everyone (especially myself) a lot of trouble.
We are not designing in a green field here. We have released beta1 and we are trying to get to 9.0 final in a few months. If this feature could have been designed easily months ago, it would have been done, but it doesn't seem to have any easy solution, and we have run out of time to fix it. As painful as it is, we need to cut our loses and move on. We have already cut features like sync replication and communicating the slave snapshot to the master; I don't see how removing this ability is any worse. We don't have time to develop this for every use case, even if those use cases are significant. If someone wants to suggest that HS is useless if max_standby_delay supports only boolean values, I am ready to suggest we remove HS as well and head to 9.0 because that would suggest that HS itself is going to be useless. The code will not be thrown away; we will bring it back for 9.1. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
