On 09/25/2015 01:47 PM, Michael Paquier wrote: > On Fri, Sep 25, 2015 at 5:57 PM, Amir Rohan <amir.ro...@mail.com> wrote: >>
> That's the kind of thing that each serious developer on this mailing > list already has in a rather different shape but with the same final > result: Oh, I guess I'll have to write one then. :) > offer a way to set up a cluster ready for hacking in a single > command, and being able to switch among them easily. I am not sure we > would really find a cross-platform script generic enough to satisfy > all the needs of folks here and integrate it directly in the tree :) > Yes, perl/bash seems to be the standard and both have their shorcomings, in either convenience or familiarity... a static binary + scripts/configuration would be least resistance,and it doesn't actually have to live in the tree, but it needs to be good enough out of the box that someone new will prefer to use/improve it over rolling their own from scratch, and people need to know it's there. Coming back to the recovery testing package... I was investigating some behaviour having to do with recovery and tried your new library to write a repro case. This uncovers some implicit assumptions in the package that can make things diffficult when violated. I had to rewrite nearly every function I used. Major pain points: 1) Lib stores metadata (ports,paths, etc') using ports as keys. -> Assumes ports aren't reused. -> Because assumes server keep running until the tear down. And 2) Behaviour (paths in particular) is hardwired rather then overridable defaults. This is exactly what I needed to test, problems: 3) Can't stop server without clearing its testing data (the maps holding paths and things). But that data might be specifically needed, in particular the backup shouldn't disappear when the server melts down or we have a very low-grade DBA on our hands. 4) Port assignment relies on liveness checks on running servers. If a server is shut down and a new instantiated, the port will get reused, data will get trashed, and various confusing things can happen. 5) Servers are shutdown with -m 'immediate', which can lead to races in the script when archiving is turned on. That may be good for some tests, but there's no control over it. Other issues: 6. Directory structure, used one directory per thing but more logical to place all things related to an instance under a single directory, and name them according to role (57333_backup, and so on). 7. enable_restoring() uses "cp -i" 'archive_command', not a good fit for an automated test. Aside from running the tests, the convenience of writing them needs to be considered. My perl is very weak, it's been at least a decade, but It was difficult to make progress because everything is geared toward a batch "pass/fail" run . Stdout is redirected, and the log files can't be 'tail --retry -f' in another terminal, because they're clobbered at every run. Also: 8. No canned way to output a pprinted overview of the running system (paths, ports, for manual checking). 9. Finding things is difficult, See 6. 10. If a test passes/fails or dies due to a bug, everything is cleaned. Great for testing, bad for postmortem. 11. a canned "server is responding to queries" helper would be convenient. It might be a good idea to: 1) Never reuse ports during a test. Liveness checking is used to avoid collisions, but should not determine order of assignment. 2) Decouple cleanup from server shutdown. Do the cleanup as the end of test only, and allow the user to keep things around. 3) Adjust the directory structure to one top directory per server with (PGDATA, backup, archive) subdirs. 4) Instead of passing ports around as keys, have _explicit functions which can be called directly by the user (I'd like the backup *HERE* please), with the current functions refactored to merely invoke them by interpolating in the values associated with the port they were given. 4b) server shutdown should perheps be "smart" by default, or segmented into calmly_bring_to_a_close(), pull_electric_plug() and drop_down_the_stairs_into_swimming_pool(). Regards, Amir -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
