Prev: _bt_parent_deletion_safe() isn't safe
Next: Command to prune archive at restartpoints
From: Greg Stark on 10 Jun 2010 12:00
On Wed, Jun 9, 2010 at 8:01 PM, Alvaro Herrera
<alvherre(a)commandprompt.com> wrote:
> Thanks for clearing the list. �There are only 5 remaining items, which
> is kinda exciting, though Tom's assertion that HS is still bug-ridden is
> a bit off-putting.

It's a big piece of subtle code and it's quite possible it contains
bugs. But people know that and as a result it's received a lot of
testing and careful thought already. The chances it has bugs of its
own are probably lower than for other major projects in the past. On
the other hand it's recovery-related and it shakes me that we have no
regression tests for recovery let alone standby databases.

What's more scary are either of two cases:

1) There are use cases of varying degrees of obscurity which haven't
been explicitly covered where the behaviour is not what people would
expect. We've already fixed a few such cases such as shutdown
semantics and setting up a standby based on an backup of initdb
results before starting up the database. This is the kind of thing we
need lots of users testing their real workloads with and doing test
failovers and so on.

2) There are unrelated areas of the database which have collateral
damage that nobody expected and thought to test for. Hopefully we have
enough regression tests to detect this kind of thing but again as
there are no regression tests for recovery we could have bugs in other
systems that don't turn up until you use those systems on a standby
database or after running the system as a standby database and then
bringing it up.




--
greg

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2 3
Prev: _bt_parent_deletion_safe() isn't safe
Next: Command to prune archive at restartpoints