Re: [HACKERS] recovery_connections cannot start
On Apr 27, 2010, at 9:20 AM, Simon Riggs wrote: > On Tue, 2010-04-27 at 15:10 +0200, Dimitri Fontaine wrote: >> Robert Haas writes: >>> Treating the string "true" as a special case seems like a kludge to >>> me. Maybe a robust set of internal commands wouldn't be a kludge, >>> but >>> that's not what's being proposed here. I guess it's just a matter >>> of >>> opinion. >> >> I don't see how to have internal commands without having special >> cases >> for the setting, and I did propose "pg_archive_bypass" as the name. I >> guess the implementation would be what Simon was talking about, >> though. >> >> I don't see "true" as meaningful in the context of an >> archive_command… > > Saying "its a kludge" doesn't really address the issue and goes > nowhere > towards fixing it. If we don't like the proposal, fine, then what is > the > alternative solution? I proposed one upthread. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] recovery_connections cannot start
On Tue, 2010-04-27 at 15:10 +0200, Dimitri Fontaine wrote: > Robert Haas writes: > > Treating the string "true" as a special case seems like a kludge to > > me. Maybe a robust set of internal commands wouldn't be a kludge, but > > that's not what's being proposed here. I guess it's just a matter of > > opinion. > > I don't see how to have internal commands without having special cases > for the setting, and I did propose "pg_archive_bypass" as the name. I > guess the implementation would be what Simon was talking about, though. > > I don't see "true" as meaningful in the context of an archive_command… Saying "its a kludge" doesn't really address the issue and goes nowhere towards fixing it. If we don't like the proposal, fine, then what is the alternative solution? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] recovery_connections cannot start
Robert Haas writes: > Treating the string "true" as a special case seems like a kludge to > me. Maybe a robust set of internal commands wouldn't be a kludge, but > that's not what's being proposed here. I guess it's just a matter of > opinion. I don't see how to have internal commands without having special cases for the setting, and I did propose "pg_archive_bypass" as the name. I guess the implementation would be what Simon was talking about, though. I don't see "true" as meaningful in the context of an archive_command… Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] recovery_connections cannot start
On Tue, Apr 27, 2010 at 4:07 AM, Dimitri Fontaine wrote: > Robert Haas writes: >>> On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote: Would it be possible to have "internal" commands there, as for example cd is in my shell, or test, or time, or some more ? That would allow for providing a portable /usr/bin/true command as far as archiving is concerned (say, pg_archive_bypass), and will allow for providing a default archiving command in the future, like "pg_archive_cp /location" or something. >> >> Separating wal_mode and archive_mode, as we recently discussed, might >> eliminate the need for this kludge, if archive_mode can then be made >> changeable without a restart. > > I don't see my proposal as anything like a kludge at all. Internal > commands are hugely practical and here would allow for PostgreSQL to > provide basic portable archive and restore commands for simple cases, > providing the necessary guarantees and error management. Treating the string "true" as a special case seems like a kludge to me. Maybe a robust set of internal commands wouldn't be a kludge, but that's not what's being proposed here. I guess it's just a matter of opinion. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] recovery_connections cannot start
Robert Haas writes: >> On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote: >>> Would it be possible to have "internal" commands there, as for example >>> cd is in my shell, or test, or time, or some more ? >>> >>> That would allow for providing a portable /usr/bin/true command as far >>> as archiving is concerned (say, pg_archive_bypass), and will allow for >>> providing a default archiving command in the future, like "pg_archive_cp >>> /location" or something. > > Separating wal_mode and archive_mode, as we recently discussed, might > eliminate the need for this kludge, if archive_mode can then be made > changeable without a restart. I don't see my proposal as anything like a kludge at all. Internal commands are hugely practical and here would allow for PostgreSQL to provide basic portable archive and restore commands for simple cases, providing the necessary guarantees and error management. Bypass the archiving is the most obvious flavor and in my mind shouldn't require an external dependency. Make simple things simple and complex one possible, as they say. PostgreSQL is one of the best software I've ever worked with on this point, but the WAL management is still in its infancy there: whatever you want to setup, it's complex. Having "internal" commands will not remove any feature we already have. Users would still be able to hook-in their own solutions for more complex or demanding environments. Please do explain in what sense that proposal is a kludge, I'd like to be able to understand your viewpoint. Or maybe it's just either bad wording on your part or bad reading on mine, nonetheless I felt like having to give some more details here. That's an important point in my mind. Dunno how much it's relevant for 9.0 though, maybe we'll be able to reach a good enough solution without an internal bypass archive command, but having (only this) one does not sound so complex that we should not consider it at all. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] recovery_connections cannot start
On Mon, Apr 26, 2010 at 6:08 AM, Simon Riggs wrote: > On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote: >> Tom Lane writes: >> > The only workable >> > alternative I can see to keeping archive_mode is to tell people to >> > set archive_command to something like /usr/bin/true ... which is not >> > simpler, especially not on Windows. >> >> Would it be possible to have "internal" commands there, as for example >> cd is in my shell, or test, or time, or some more ? >> >> That would allow for providing a portable /usr/bin/true command as far >> as archiving is concerned (say, pg_archive_bypass), and will allow for >> providing a default archiving command in the future, like "pg_archive_cp >> /location" or something. > > I think making a special case here is OK. > > If command string == 'true' then we don't bother to call system(3) at > all, we just assume it worked fine. > > That way we have a simple route on all platforms. Separating wal_mode and archive_mode, as we recently discussed, might eliminate the need for this kludge, if archive_mode can then be made changeable without a restart. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] recovery_connections cannot start
On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote: > Tom Lane writes: > > The only workable > > alternative I can see to keeping archive_mode is to tell people to > > set archive_command to something like /usr/bin/true ... which is not > > simpler, especially not on Windows. > > Would it be possible to have "internal" commands there, as for example > cd is in my shell, or test, or time, or some more ? > > That would allow for providing a portable /usr/bin/true command as far > as archiving is concerned (say, pg_archive_bypass), and will allow for > providing a default archiving command in the future, like "pg_archive_cp > /location" or something. I think making a special case here is OK. If command string == 'true' then we don't bother to call system(3) at all, we just assume it worked fine. That way we have a simple route on all platforms. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] recovery_connections cannot start
Tom Lane writes: > The only workable > alternative I can see to keeping archive_mode is to tell people to > set archive_command to something like /usr/bin/true ... which is not > simpler, especially not on Windows. Would it be possible to have "internal" commands there, as for example cd is in my shell, or test, or time, or some more ? That would allow for providing a portable /usr/bin/true command as far as archiving is concerned (say, pg_archive_bypass), and will allow for providing a default archiving command in the future, like "pg_archive_cp /location" or something. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
