Prev: [HACKERS] pg_stop_backup does not complete
Next: [PATCH] backend: compare word-at-a-time in bcTruelen
From: Heikki Linnakangas on 2 Mar 2010 02:11 Greg Smith wrote: > Fujii Masao wrote: >> We would be easily able to calculate the last archived log file from >> the existence of archive status files. > > Right, but you have to actually scan the whole archive directory to > figure that out, and I'd rather not see that code get duplicated > somewhere else when it's already inside the archive_command logic. If > it just shared that info with the rest of the system instead this would > be trivial to discover. The archiver process is not connected to shared memory, so scanning the directory is the way to do it. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.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: "Joshua D. Drake" on 2 Mar 2010 03:11 On Tue, 2 Mar 2010 15:20:36 +0900, Fujii Masao <masao.fujii(a)gmail.com> wrote: >> Setting archive_mode to a command that does nothing but return true, >> e.g. /bin/true, > > "return true" seems ambiguous for me. How about writing clearly > "return a zero exit status" instead? For the record. I hate the fact that I ever mentioned this and I think it is a terrible hack that we would mention it in the docs. From a professional perspective, I cringe at the idea of telling a customer to do this, not to mention it won't work on w32. Joshua D. Drake -- PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- 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 2 Mar 2010 04:48 On Tue, 2010-03-02 at 15:20 +0900, Fujii Masao wrote: > On Fri, Feb 26, 2010 at 2:47 AM, Bruce Momjian <bruce(a)momjian.us> wrote: > > Postgres 9.0 will be the first release to mention /bin/true as a way of > > turning off archiving in extraordinary circumstances: > > > > http://developer.postgresql.org/pgdocs/postgres/runtime-config-wal.html > > > > Setting archive_mode to a command that does nothing but return true, e.g. /bin/true, > > "return true" seems ambiguous for me. How about writing clearly > "return a zero exit status" instead? Docs are already quite clear on that point. I think we should avoid specifying it twice. -- 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: Greg Stark on 2 Mar 2010 08:13 On Tue, Mar 2, 2010 at 9:48 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: >> > Setting archive_mode to a command that does nothing but return true, e.g. /bin/true, >> >> "return true" seems ambiguous for me. How about writing clearly >> "return a zero exit status" instead? > > Docs are already quite clear on that point. I think we should avoid > specifying it twice. > Why do we disallow turning off archive_mode anyways? I understand not turning it on -- though even that would be nice if it "took effect after the next checkpoint" but turning it off should always be safe, no? -- 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
From: Simon Riggs on 2 Mar 2010 08:19
On Tue, 2010-03-02 at 13:13 +0000, Greg Stark wrote: > On Tue, Mar 2, 2010 at 9:48 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > >> > Setting archive_mode to a command that does nothing but return true, e.g. /bin/true, > >> > >> "return true" seems ambiguous for me. How about writing clearly > >> "return a zero exit status" instead? > > > > Docs are already quite clear on that point. I think we should avoid > > specifying it twice. > > > > Why do we disallow turning off archive_mode anyways? Because it is needed for safety and nobody has got around to coding the idea of turning it on/off during normal running, which is possible, with appropriate care. > I understand not > turning it on -- though even that would be nice if it "took effect > after the next checkpoint" but turning it off should always be safe, > no? We don't support that behaviour in parameters. -- 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 |