Re: [CORE] Restore-reliability mode - Mailing list pgsql-hackers
| From | Jeff Janes |
|---|---|
| Subject | Re: [CORE] Restore-reliability mode |
| Date | |
| Msg-id | CAMkU=1wusmcyQkx=SAANz9S8PQu=MsD6T+QNxMvNsPm0UtgSjA@mail.gmail.com Whole thread Raw |
| In response to | Re: [CORE] Restore-reliability mode (Geoff Winkless <pgsqladmin@geoff.dj>) |
| Responses |
Re: [CORE] Restore-reliability mode
(David Gould <daveg@sonic.net>)
|
| List | pgsql-hackers |
On Sat, Jun 6, 2015 at 7:35 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
It's much easier to work into dev/test setups if there are system
packages as it's just a config change to an existing script. Building
from source would require a whole new workflow that I don't have time
to incorporate.Really? You genuinely don't have time to paste, say:mkdir -p ~/src/pgdevelcd ~/src/pgdeveltar xjf postgresql-snapshot.tar.bz2mkdir bldcd bld../postgresql-9.5devel/configure $(pg_config --configure | sed -e 's/\(pg\|postgresql[-\/]\)\(doc-\)\?9\.[0-9]*\(dev\)\?/\1\29.5dev/g')make worldmake checkmake world-install
I think this is rather uncharitable. You don't include yum, zypper, or apt-get anywhere in there, and I vaguely recall it took me quite a bit of time to install all the prereqs in order to get it to compile several years ago when I first started trying to compile it. And then even more time get it to compile with several of the config flags I wanted. And then even more time to get the docs to compile.
And now after I got all of that, when I try your code, it still doesn't work. $(pg_config ....) seems to not quote things the way that configure wants them quoted, or something. And the package from which I was using pg_config uses more config options than I was set up for when compiling myself, so I either have to manually remove the flags, or find more dependencies (pam, xslt, ossp-uuid, tcl, tcl-dev, and counting). This is not very fun, and I didn't even need to get bureaucratic approval to do any of this stuff, like a lot of people do.
And then when I try to install it, it tries to overwrite some of the files which were initially installed by the package manager in /usr/lib. That doesn't seem good.
And how do I, as a hypothetical package manager user, start this puppy up? Where is pg_ctlcluster? How does one do pg_upgrade between a package-controlled data directory and this new binary?
And then when I find a bug, how do I know it is a bug and not me doing something wrong in the build process, and getting the wrong .so to load with the wrong binary or something like that?
and yet you think you have enough time to provide more than a "looks like it's working" report to the developers?
If it isn't working, reports of it isn't working with error messages are pretty helpful and don't take a whole lot of time. If it is working, reports of that probably aren't terribly helpful without putting a lot more work into it. But people might be willing to put a lot of work into, say, performance regression testing it that is their area of expertise, if they don' t also have to put a lot of work into getting the software to compile in the first place, which is not their area.
Now I don't see a lot of evidence of beta testing from the public (i.e. unfamiliar names) on -hackers and -bugs lists. But a lot of hackers report things that "a client" or "someone on IRC" reported to them, so I'm willing to believe that a lot of useful beta testing does go on, even though I don't directly see it, and if there were alpha releases, why wouldn't it extend to that?
(NB the sed for the pg_config line will probably need work, it looks like it should work on the two types of system I have here but I have to admit I changed the config line manually when I built it)
Right, and are the people who use apt-get to install everything likely to know how to do that work?
Cheers,
Jeff
pgsql-hackers by date: