Re: To Signal The postmaster

Hi,

I want to signal the postmaster (User defined signal) once I created the
trigger file (for switch over).
I want to reduce my switch over time further by signaling the postmaster
once the trigger file is created.

Is this provision already there in the code?
There ate already SIGUSR1 and SIGUSR2 are handled in the postmaster? is it
for the same?

If I handle my own signal using SIGUSR1/SIGUSR2 is it possible without
affecting the other functionality of existing code?

--
Thanks & Regards,

Aaliya Zarrin
(+91)-9160665888

aaliya zarrin escreveu:
> I want to signal the postmaster (User defined signal) once I created the
> trigger file (for switch over).
>
Send a SIGHUP to postmaster. Have in mind that it doesn't work on all
supported platforms.

--
Euler Taveira de Oliveira
http://www.timbira.com/

On Tue, Dec 7, 2010 at 4:22 PM, aaliya zarrin <aaliya(dot)zarrin(at)gmail(dot)com> wrote:
> Is this provision already there in the code?
> There ate already SIGUSR1 and SIGUSR2 are handled in the postmaster? is it
> for the same?

SIGUSR1 is already used. SIGUSR2 is actually unused, but reserved for children
according to the source code comment.

Though I've been thinking about this topic, a good idea doesn't occur to me yet.
http://archives.postgresql.org/pgsql-hackers/2010-09/msg00929.php

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

I can not used SIGHUP, as it is already in use.
I want to wake up the postmaster once the trigger file is generated
and tell it to switch over from standby mode.
Is it possible?

On Wed, Dec 8, 2010 at 9:17 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Tue, Dec 7, 2010 at 4:22 PM, aaliya zarrin <aaliya(dot)zarrin(at)gmail(dot)com>
> wrote:
> > Is this provision already there in the code?
> > There ate already SIGUSR1 and SIGUSR2 are handled in the postmaster? is
> it
> > for the same?
>
> SIGUSR1 is already used. SIGUSR2 is actually unused, but reserved for
> children
> according to the source code comment.
>
> Though I've been thinking about this topic, a good idea doesn't occur to me
> yet.
> http://archives.postgresql.org/pgsql-hackers/2010-09/msg00929.php
>
> Regards,
>
> --
> Fujii Masao
> NIPPON TELEGRAPH AND TELEPHONE CORPORATION
> NTT Open Source Software Center
>

--
Thanks & Regards,

Aaliya Zarrin
(+91)-9160665888

On 08.12.2010 06:12, aaliya zarrin wrote:
> I can not used SIGHUP, as it is already in use.
> I want to wake up the postmaster once the trigger file is generated
> and tell it to switch over from standby mode.
> Is it possible?

SIGHUP works precisely because it is already in use. When you send
SIGHUP, the startup process will wake up immediately, and reload the
configuration file. Reloading the configuration file is unnecessary in
this case, but it will wake it up and it will notice the trigger file.

For 9.1, we should think of a better way to do this, perhaps using
SIGUSR1 to wake up. Maybe we won't even need the trigger file anymore.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Wed, Dec 8, 2010 at 4:59 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> For 9.1, we should think of a better way to do this, perhaps using SIGUSR1
> to wake up. Maybe we won't even need the trigger file anymore.

If we use SIGUSR1, the mechanism to allow the users to specify the event type
seems to be required. For example, we should make the SIGUSR1 handler
check not only the shmem (i.e., PMSignalStat) but also the file?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

On Wed, Dec 8, 2010 at 6:22 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Wed, Dec 8, 2010 at 4:59 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> For 9.1, we should think of a better way to do this, perhaps using SIGUSR1
>> to wake up. Maybe we won't even need the trigger file anymore.
>
> If we use SIGUSR1, the mechanism to allow the users to specify the event type
> seems to be required. For example, we should make the SIGUSR1 handler
> check not only the shmem (i.e., PMSignalStat) but also the file?

What I'm thinking is to make something like "pg_ctl promote" create the event
file specifying the standby promotion in $PGDATA/pg_event or elsewhere,
and send SIGUSR1 to postmaster. OTOH, when SIGUSR1 arrives, postmaster
checks whether that event file exists. If it does, postmaster removes it and
sends the signal to startup process for standby promotion.

Thought?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Hi All,

Can anybody tell after finding the trigger file what steps does postgres
follow?

When and how it will set the postgres recovery mode to false?

On Thu, Dec 9, 2010 at 3:51 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Wed, Dec 8, 2010 at 6:22 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> > On Wed, Dec 8, 2010 at 4:59 PM, Heikki Linnakangas
> > <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> >> For 9.1, we should think of a better way to do this, perhaps using
> SIGUSR1
> >> to wake up. Maybe we won't even need the trigger file anymore.
> >
> > If we use SIGUSR1, the mechanism to allow the users to specify the event
> type
> > seems to be required. For example, we should make the SIGUSR1 handler
> > check not only the shmem (i.e., PMSignalStat) but also the file?
>
> What I'm thinking is to make something like "pg_ctl promote" create the
> event
> file specifying the standby promotion in $PGDATA/pg_event or elsewhere,
> and send SIGUSR1 to postmaster. OTOH, when SIGUSR1 arrives, postmaster
> checks whether that event file exists. If it does, postmaster removes it
> and
> sends the signal to startup process for standby promotion.
>
> Thought?
>
> Regards,
>
> --
> Fujii Masao
> NIPPON TELEGRAPH AND TELEPHONE CORPORATION
> NTT Open Source Software Center
>

--
Thanks & Regards,

Aaliya Zarrin
(+91)-9160665888

On Fri, Dec 10, 2010 at 3:51 PM, aaliya zarrin <aaliya(dot)zarrin(at)gmail(dot)com> wrote:
> Can anybody tell after finding the trigger file what steps does postgres
> follow?

The server applies all the WAL records available, performs checkpoint,
renames recovery.conf, and gets out of recovery mode.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Hi ,
I want to stop the recovery forcefully what shall I do? Rather say,
after finding the trigger file I want postgres to switch over?
Which function shall I call?
Where the flow is transfer exactly after finding the trigger file?

On Fri, Dec 10, 2010 at 2:36 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Fri, Dec 10, 2010 at 3:51 PM, aaliya zarrin <aaliya(dot)zarrin(at)gmail(dot)com>
> wrote:
> > Can anybody tell after finding the trigger file what steps does postgres
> > follow?
>
> The server applies all the WAL records available, performs checkpoint,
> renames recovery.conf, and gets out of recovery mode.
>
> Regards,
>
> --
> Fujii Masao
> NIPPON TELEGRAPH AND TELEPHONE CORPORATION
> NTT Open Source Software Center
>

--
Thanks & Regards,

Aaliya Zarrin
(+91)-9160665888