recovery_connections cannot start
in [PgSql]
|
From: Dimitri Fontaine on 26 Apr 2010 04:41 Tom Lane <tgl(a)sss.pgh.pa.us> 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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 26 Apr 2010 06:08 On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote: > Tom Lane <tgl(a)sss.pgh.pa.us> 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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 26 Apr 2010 06:29 On Mon, Apr 26, 2010 at 6:08 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote: >> Tom Lane <tgl(a)sss.pgh.pa.us> 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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 27 Apr 2010 04:07 Robert Haas <robertmhaas(a)gmail.com> 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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 27 Apr 2010 07:11 On Tue, Apr 27, 2010 at 4:07 AM, Dimitri Fontaine <dfontaine(a)hi-media.com> wrote: > Robert Haas <robertmhaas(a)gmail.com> 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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 Prev: standbycheck was:(Re: [HACKERS] testing hot standby Next: CIText and pattern_ops |