Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Sun, Feb 13, 2011 at 10:18 PM, Fujii Masao masao.fu...@gmail.com wrote: Thanks for the review! On Thu, Feb 10, 2011 at 11:25 PM, Magnus Hagander mag...@hagander.net wrote: I see that the docs part of the patch removes the mentioning of reporting servers - is that intentional, or a mistake? Seems that usecase still remains, no? It was intentional, but I agree with you. I re-added the mention to the reporting servers. On Thu, Feb 10, 2011 at 11:30 PM, Magnus Hagander mag...@hagander.net wrote: Also, the patch no longer applies, since it conflicts with faa0550572583f51dba25611ab0f1d1c31de559b. Since you (Fujii-san) wrote both of them, feel like rebasing it properly for current master? Yeah, I rebased the patch to the current git master and attached it. Committed with minor tweaks to comments and documentation. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Wed, Feb 16, 2011 at 11:30 AM, Robert Haas robertmh...@gmail.com wrote: Committed with minor tweaks to comments and documentation. Thanks a lot! Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
Thanks for the review! On Thu, Feb 10, 2011 at 11:25 PM, Magnus Hagander mag...@hagander.net wrote: I see that the docs part of the patch removes the mentioning of reporting servers - is that intentional, or a mistake? Seems that usecase still remains, no? It was intentional, but I agree with you. I re-added the mention to the reporting servers. On Thu, Feb 10, 2011 at 11:30 PM, Magnus Hagander mag...@hagander.net wrote: Also, the patch no longer applies, since it conflicts with faa0550572583f51dba25611ab0f1d1c31de559b. Since you (Fujii-san) wrote both of them, feel like rebasing it properly for current master? Yeah, I rebased the patch to the current git master and attached it. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center pg_ctl_promote_v4.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Tue, Feb 8, 2011 at 05:24, Robert Haas robertmh...@gmail.com wrote: On Wed, Jan 19, 2011 at 1:01 AM, Fujii Masao masao.fu...@gmail.com wrote: On Thu, Jan 13, 2011 at 9:08 PM, Fujii Masao masao.fu...@gmail.com wrote: I did s/failover/promote. Here is the updated patch. I rebased the patch to current git master. This patch looks fine to me. I will mark it Ready for Committer. (Someone else please feel free to pick it up for the actual commit, if you have cycles.) I see that the docs part of the patch removes the mentioning of reporting servers - is that intentional, or a mistake? Seems that usecase still remains, no? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Thu, Feb 10, 2011 at 15:25, Magnus Hagander mag...@hagander.net wrote: On Tue, Feb 8, 2011 at 05:24, Robert Haas robertmh...@gmail.com wrote: On Wed, Jan 19, 2011 at 1:01 AM, Fujii Masao masao.fu...@gmail.com wrote: On Thu, Jan 13, 2011 at 9:08 PM, Fujii Masao masao.fu...@gmail.com wrote: I did s/failover/promote. Here is the updated patch. I rebased the patch to current git master. This patch looks fine to me. I will mark it Ready for Committer. (Someone else please feel free to pick it up for the actual commit, if you have cycles.) I see that the docs part of the patch removes the mentioning of reporting servers - is that intentional, or a mistake? Seems that usecase still remains, no? Also, the patch no longer applies, since it conflicts with faa0550572583f51dba25611ab0f1d1c31de559b. Since you (Fujii-san) wrote both of them, feel like rebasing it properly for current master? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Wed, Jan 19, 2011 at 1:01 AM, Fujii Masao masao.fu...@gmail.com wrote: On Thu, Jan 13, 2011 at 9:08 PM, Fujii Masao masao.fu...@gmail.com wrote: I did s/failover/promote. Here is the updated patch. I rebased the patch to current git master. This patch looks fine to me. I will mark it Ready for Committer. (Someone else please feel free to pick it up for the actual commit, if you have cycles.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Sat, Jan 29, 2011 at 1:11 AM, Tatsuo Ishii is...@postgresql.org wrote: Ok. I will write a C user function and add to pgpool source tree. I think it will be fairly easy to create a trigger file in the function. If the pg_ctl promote patch will have been committed, I recommend that the C function should send the signal to the startup process rather than creating the trigger file. Because the trigger file is checked every for 5s, which would lengthen the failover time by an average 2.5s. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
If the pg_ctl promote patch will have been committed, I recommend that the C function should send the signal to the startup process rather than creating the trigger file. Because the trigger file is checked every for 5s, which would lengthen the failover time by an average 2.5s. Ok, probably I could make the function smart enough to signal or not by looking at the PostgreSQL version. BTW is it possible to export following variable in xlog.c? static char *TriggerFile = NULL; That would make coding of the C function lot easier. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Mon, Jan 31, 2011 at 11:52, Fujii Masao masao.fu...@gmail.com wrote: On Sat, Jan 29, 2011 at 1:11 AM, Tatsuo Ishii is...@postgresql.org wrote: Ok. I will write a C user function and add to pgpool source tree. I think it will be fairly easy to create a trigger file in the function. If the pg_ctl promote patch will have been committed, I recommend that the C function should send the signal to the startup process rather than creating the trigger file. The C function needs to create a trigger file in $PGDATA/promote before sending signals, no?system(pg_ctl promote) seems the easiest way if you use an external module. -- Itagaki Takahiro -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Mon, Jan 31, 2011 at 12:31 PM, Itagaki Takahiro itagaki.takah...@gmail.com wrote: The C function needs to create a trigger file in $PGDATA/promote before sending signals, no? No. At least in the current patch, just receipt of SIGUSR2 causes the startup process to end a recovery. The startup process doesn't check the existence of $PGDATA/promote, though postmaster does. system(pg_ctl promote) seems the easiest way if you use an external module. Yeah, that's true. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Mon, Jan 31, 2011 at 12:35 PM, Tatsuo Ishii is...@postgresql.org wrote: If the pg_ctl promote patch will have been committed, I recommend that the C function should send the signal to the startup process rather than creating the trigger file. Because the trigger file is checked every for 5s, which would lengthen the failover time by an average 2.5s. Ok, probably I could make the function smart enough to signal or not by looking at the PostgreSQL version. BTW is it possible to export following variable in xlog.c? static char *TriggerFile = NULL; That would make coding of the C function lot easier. If you change the function so that it sends the signal or call system(pg_ctl promote), exporting that variable seems to be unnecessary. Because pg_ctl promote can promote the server even if trigger_file is not supplied. You don't need to check whether trigger_file is set or not, in the C function. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Mon, Jan 31, 2011 at 12:35 PM, Tatsuo Ishii is...@postgresql.org wrote: If the pg_ctl promote patch will have been committed, I recommend that the C function should send the signal to the startup process rather than creating the trigger file. Because the trigger file is checked every for 5s, which would lengthen the failover time by an average 2.5s. Ok, probably I could make the function smart enough to signal or not by looking at the PostgreSQL version. BTW is it possible to export following variable in xlog.c? static char *TriggerFile = NULL; That would make coding of the C function lot easier. If you change the function so that it sends the signal or call system(pg_ctl promote), exporting that variable seems to be unnecessary. Because pg_ctl promote can promote the server even if trigger_file is not supplied. You don't need to check whether trigger_file is set or not, in the C function. True. BTW for 9.0, perhaps copypaste parseRecoveryCommandFileLine() from xlog.c into the C function is the only way to go. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Fri, Jan 28, 2011 at 08:44, Tatsuo Ishii is...@postgresql.org wrote: I did s/failover/promote. Here is the updated patch. I rebased the patch to current git master. I'm thinking about implementing a function which does a promotion for the standby. It will make pgpool lot easier to control the promotion since it allow to fire the promotion operation (either creating a trigger file or sending a signal) via SQL, not ssh etc. I agree that having this available via SQL would be useful in a number of cases. pgpool or such being one, but also for example pgadmin. If there's enough interest, I will propose such a function for next CF. Just as a reminder, remember that next CF means 9.2. Oh, I meant current CF (has started in January) -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Fri, Jan 28, 2011 at 4:57 PM, Magnus Hagander mag...@hagander.net wrote: On Fri, Jan 28, 2011 at 08:44, Tatsuo Ishii is...@postgresql.org wrote: I did s/failover/promote. Here is the updated patch. I rebased the patch to current git master. I'm thinking about implementing a function which does a promotion for the standby. It will make pgpool lot easier to control the promotion since it allow to fire the promotion operation (either creating a trigger file or sending a signal) via SQL, not ssh etc. I agree that having this available via SQL would be useful in a number of cases. pgpool or such being one, but also for example pgadmin. Agreed. I submitted the patch before, but I forgot to update it and add it to CF. http://archives.postgresql.org/message-id/aanlktimuhbxbum+zlkaex3adqseimue3xb4ww1qts...@mail.gmail.com Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Fri, Jan 28, 2011 at 4:57 PM, Magnus Hagander mag...@hagander.net wrote: On Fri, Jan 28, 2011 at 08:44, Tatsuo Ishii is...@postgresql.org wrote: I did s/failover/promote. Here is the updated patch. I rebased the patch to current git master. I'm thinking about implementing a function which does a promotion for the standby. It will make pgpool lot easier to control the promotion since it allow to fire the promotion operation (either creating a trigger file or sending a signal) via SQL, not ssh etc. I agree that having this available via SQL would be useful in a number of cases. pgpool or such being one, but also for example pgadmin. Agreed. I submitted the patch before, but I forgot to update it and add it to CF. http://archives.postgresql.org/message-id/aanlktimuhbxbum+zlkaex3adqseimue3xb4ww1qts...@mail.gmail.com Great! -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Fri, Jan 28, 2011 at 3:40 AM, Tatsuo Ishii is...@postgresql.org wrote: On Fri, Jan 28, 2011 at 4:57 PM, Magnus Hagander mag...@hagander.net wrote: On Fri, Jan 28, 2011 at 08:44, Tatsuo Ishii is...@postgresql.org wrote: I did s/failover/promote. Here is the updated patch. I rebased the patch to current git master. I'm thinking about implementing a function which does a promotion for the standby. It will make pgpool lot easier to control the promotion since it allow to fire the promotion operation (either creating a trigger file or sending a signal) via SQL, not ssh etc. I agree that having this available via SQL would be useful in a number of cases. pgpool or such being one, but also for example pgadmin. Agreed. I submitted the patch before, but I forgot to update it and add it to CF. http://archives.postgresql.org/message-id/aanlktimuhbxbum+zlkaex3adqseimue3xb4ww1qts...@mail.gmail.com Great! I hate to be a wet blanket, but the number of patches in this CF is going the wrong direction. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
Robert Haas robertmh...@gmail.com writes: On Fri, Jan 28, 2011 at 3:40 AM, Tatsuo Ishii is...@postgresql.org wrote: Agreed. I submitted the patch before, but I forgot to update it and add it to CF. http://archives.postgresql.org/message-id/aanlktimuhbxbum+zlkaex3adqseimue3xb4ww1qts...@mail.gmail.com Great! I hate to be a wet blanket, but the number of patches in this CF is going the wrong direction. Yes. I'm not sure that the fact that something was discussed months ago entitles the submitter to a free exemption from the requirement to meet the CF submission deadline. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
I did s/failover/promote. Here is the updated patch. I rebased the patch to current git master. I'm thinking about implementing a function which does a promotion for the standby. It will make pgpool lot easier to control the promotion since it allow to fire the promotion operation (either creating a trigger file or sending a signal) via SQL, not ssh etc. I agree that having this available via SQL would be useful in a number of cases. pgpool or such being one, but also for example pgadmin. If there's enough interest, I will propose such a function for next CF. Just as a reminder, remember that next CF means 9.2. Ok. I will write a C user function and add to pgpool source tree. I think it will be fairly easy to create a trigger file in the function. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
I did s/failover/promote. Here is the updated patch. I rebased the patch to current git master. I'm thinking about implementing a function which does a promotion for the standby. It will make pgpool lot easier to control the promotion since it allow to fire the promotion operation (either creating a trigger file or sending a signal) via SQL, not ssh etc. If there's enough interest, I will propose such a function for next CF. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Fri, Jan 28, 2011 at 08:44, Tatsuo Ishii is...@postgresql.org wrote: I did s/failover/promote. Here is the updated patch. I rebased the patch to current git master. I'm thinking about implementing a function which does a promotion for the standby. It will make pgpool lot easier to control the promotion since it allow to fire the promotion operation (either creating a trigger file or sending a signal) via SQL, not ssh etc. I agree that having this available via SQL would be useful in a number of cases. pgpool or such being one, but also for example pgadmin. If there's enough interest, I will propose such a function for next CF. Just as a reminder, remember that next CF means 9.2. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Thu, Jan 13, 2011 at 9:08 PM, Fujii Masao masao.fu...@gmail.com wrote: I did s/failover/promote. Here is the updated patch. I rebased the patch to current git master. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center pg_ctl_promote_v3.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On 13.01.2011 04:29, Itagaki Takahiro wrote: On Thu, Jan 13, 2011 at 00:14, Fujii Masaomasao.fu...@gmail.com wrote: pg_ctl failover ? At the moment, the location of the trigger file is configurable, but if we accept a constant location like $PGDATA/failover pg_ctl could do the whole thing, create the file and send signal. pg_ctl on Window already knows how to send the signal via the named pipe signal emulation. The attached patch implements the above-mentioned pg_ctl failover. I have three comments: - Will we call it failover? We will use the command also in switchover operations. pg_ctl promote might be more neutral, but users might be hard to imagine replication feature from promote. I agree that failover or even switchover is too specific. You might want promote a server even if you keep the old master still running, if you're creating a temporary copy of the master repository for testing purposes etc. +1 for promote. People unfamiliar with the replication stuff might not immediately understand that it's related to replication, but they wouldn't have any use for the option anyway. It should be clear to anyone who needs it. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.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: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Thu, Jan 13, 2011 at 5:00 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 13.01.2011 04:29, Itagaki Takahiro wrote: On Thu, Jan 13, 2011 at 00:14, Fujii Masaomasao.fu...@gmail.com wrote: pg_ctl failover ? At the moment, the location of the trigger file is configurable, but if we accept a constant location like $PGDATA/failover pg_ctl could do the whole thing, create the file and send signal. pg_ctl on Window already knows how to send the signal via the named pipe signal emulation. The attached patch implements the above-mentioned pg_ctl failover. I have three comments: - Will we call it failover? We will use the command also in switchover operations. pg_ctl promote might be more neutral, but users might be hard to imagine replication feature from promote. I agree that failover or even switchover is too specific. You might want promote a server even if you keep the old master still running, if you're creating a temporary copy of the master repository for testing purposes etc. +1 for promote. People unfamiliar with the replication stuff might not immediately understand that it's related to replication, but they wouldn't have any use for the option anyway. It should be clear to anyone who needs it. I agree. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Thu, Jan 13, 2011 at 7:00 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: +1 for promote. People unfamiliar with the replication stuff might not immediately understand that it's related to replication, but they wouldn't have any use for the option anyway. It should be clear to anyone who needs it. I did s/failover/promote. Here is the updated patch. - pg_ctl should unlink failover_files when it failed to send failover signals. Done. And, I changed some descriptions about trigger in high-availability.sgml and recovery-config.sgml. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center pg_ctl_failover_v2.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Wed, Sep 15, 2010 at 11:14 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 15/09/10 16:55, Tom Lane wrote: So I'm wondering if we couldn't eliminate the five-second sleep requirement here too. It's problematic anyhow, since somebody looking for energy efficiency will still feel it's too short, while somebody concerned about fast failover will feel it's too long. Yep. Could the standby triggering protocol be modified so that it involves sending a signal, not just creating a file? Seems reasonable, at least if we still provide an option for more frequent polling and no need to send signal. (One issue is that it's not clear what that'd translate to on Windows.) pg_ctl failover ? At the moment, the location of the trigger file is configurable, but if we accept a constant location like $PGDATA/failover pg_ctl could do the whole thing, create the file and send signal. pg_ctl on Window already knows how to send the signal via the named pipe signal emulation. The attached patch implements the above-mentioned pg_ctl failover. Comments? Objections? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center pg_ctl_failover_v1.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Thu, Jan 13, 2011 at 00:14, Fujii Masao masao.fu...@gmail.com wrote: pg_ctl failover ? At the moment, the location of the trigger file is configurable, but if we accept a constant location like $PGDATA/failover pg_ctl could do the whole thing, create the file and send signal. pg_ctl on Window already knows how to send the signal via the named pipe signal emulation. The attached patch implements the above-mentioned pg_ctl failover. I have three comments: - Will we call it failover? We will use the command also in switchover operations. pg_ctl promote might be more neutral, but users might be hard to imagine replication feature from promote. - pg_ctl should unlink failover_files when it failed to send failover signals. - standby_triggered variable might be renamed to failover_triggered or so. -- Itagaki Takahiro -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting
On Thu, Jan 13, 2011 at 11:29 AM, Itagaki Takahiro itagaki.takah...@gmail.com wrote: On Thu, Jan 13, 2011 at 00:14, Fujii Masao masao.fu...@gmail.com wrote: pg_ctl failover ? At the moment, the location of the trigger file is configurable, but if we accept a constant location like $PGDATA/failover pg_ctl could do the whole thing, create the file and send signal. pg_ctl on Window already knows how to send the signal via the named pipe signal emulation. The attached patch implements the above-mentioned pg_ctl failover. I have three comments: Thanks for the review! - Will we call it failover? We will use the command also in switchover operations. pg_ctl promote might be more neutral, but users might be hard to imagine replication feature from promote. OK. Similarly, I should also change the word failover used in function and variable names to the promote? For example, #define PROMOTE_SIGNAL_FILE promote rather than #define FAILOVER_SIGNAL_FILE failover? - pg_ctl should unlink failover_files when it failed to send failover signals. Good catch. - standby_triggered variable might be renamed to failover_triggered or so. Furthermore, failover_triggered should be renamed to promote_triggered? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
