Hi All,
I am new to postgres.
I want to know how frequently postgres search for trigger file to switch
over.
Can this switch over time be reduced?
Plz let me know where postgres poll for trigger file. I could find it out in
"backend/access/trans/xlog.c" ? am i right?



--
Thanks & Regards,

Aaliya Zarrin
(+91)-9160665888

Search Discussions

  • Heikki Linnakangas at Dec 1, 2010 at 12:23 pm

    On 01.12.2010 13:27, aaliya zarrin wrote:
    I want to know how frequently postgres search for trigger file to switch
    over.
    In 9.0, every 100ms while streaming replication is active and connected.
    5 seconds otherwise. In current git master branch, it's always 5 s.
    Can this switch over time be reduced?
    Not without hacking the sources and compiling.

    Although, on many platforms, Linux included I believe, sending a signal
    to the startup process should wake it up from the sleep and make it
    check the trigger file immediately. "pg_ctl reload" for example should
    do it. So if ýou send a signal to the startup process immediately after
    creating the trigger file, it should take notice sooner.
    Plz let me know where postgres poll for trigger file. I could find it out in
    "backend/access/trans/xlog.c" ? am i right?
    Yes. search for callers of CheckForStandbyTrigger() function.


    --
    Heikki Linnakangas
    EnterpriseDB http://www.enterprisedb.com
  • Euler Taveira de Oliveira at Dec 1, 2010 at 3:16 pm

    Heikki Linnakangas escreveu:
    On 01.12.2010 13:27, aaliya zarrin wrote:
    I want to know how frequently postgres search for trigger file to switch
    over.
    In 9.0, every 100ms while streaming replication is active and connected.
    5 seconds otherwise. In current git master branch, it's always 5 s.
    Can this switch over time be reduced?
    Not without hacking the sources and compiling.

    Although, on many platforms, Linux included I believe, sending a signal
    to the startup process should wake it up from the sleep and make it
    check the trigger file immediately. "pg_ctl reload" for example should
    do it. So if ýou send a signal to the startup process immediately after
    creating the trigger file, it should take notice sooner.
    Isn't it an ugly solution for stopping the replication immediately? At the top
    of my head, I don't remember the reason for not turn the interval for pooling
    trigger file into a configurable option. IMHO, high availability fits into
    those cases (switchover immediately).

    [poking the git history a little...]

    I agree the a short polling interval is not energy efficient [1] but some
    scenarios need this short interval. So if we want to stop the replication
    immediately, we have two options: (i) advertise that we need to signal the
    postmaster after creating a trigger file or (ii) made the pooling interval
    configurable. As you said, there are platforms that a signal doesn't wake up a
    process, so I suggest (ii) but I'm fine to include (i) at docs too.

    Comments?


    [1]
    http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=723d0184e2972f21db0f85feef3d35f0cb9b3298


    --
    Euler Taveira de Oliveira
    http://www.timbira.com/
  • Fujii Masao at Dec 3, 2010 at 1:55 am

    On Thu, Dec 2, 2010 at 12:16 AM, Euler Taveira de Oliveira wrote:
    As you said, there are platforms that a signal doesn't wake up a
    process, so I suggest (ii) but I'm fine to include (i) at docs too.
    Can we use "pg_ctl kill" to send signal on such platforms?

    Regards,

    --
    Fujii Masao
    NIPPON TELEGRAPH AND TELEPHONE CORPORATION
    NTT Open Source Software Center
  • Heikki Linnakangas at Dec 3, 2010 at 8:18 am

    On 03.12.2010 03:55, Fujii Masao wrote:
    On Thu, Dec 2, 2010 at 12:16 AM, Euler Taveira de Oliveira
    wrote:
    As you said, there are platforms that a signal doesn't wake up a
    process, so I suggest (ii) but I'm fine to include (i) at docs too.
    Can we use "pg_ctl kill" to send signal on such platforms?
    It won't make a difference, "pg_ctl kill" sends the signal just like
    regular "kill". Except that "pg_ctl kill" also works on Windows which
    doesn't have the concept of Unix signals.

    --
    Heikki Linnakangas
    EnterpriseDB http://www.enterprisedb.com
  • Aaliya zarrin at Dec 1, 2010 at 5:23 pm
    Thanks for quick response..
    Can I change this 5 second time?
    I have seen the postgres code as well.
    What is the functionality of WaitLatch() function. I could not understand
    completely.
    Plz help..
    On Wed, Dec 1, 2010 at 5:53 PM, Heikki Linnakangas wrote:
    On 01.12.2010 13:27, aaliya zarrin wrote:

    I want to know how frequently postgres search for trigger file to switch
    over.
    In 9.0, every 100ms while streaming replication is active and connected. 5
    seconds otherwise. In current git master branch, it's always 5 s.


    Can this switch over time be reduced?
    Not without hacking the sources and compiling.

    Although, on many platforms, Linux included I believe, sending a signal to
    the startup process should wake it up from the sleep and make it check the
    trigger file immediately. "pg_ctl reload" for example should do it. So if
    ıou send a signal to the startup process immediately after creating the
    trigger file, it should take notice sooner.


    Plz let me know where postgres poll for trigger file. I could find it out
    in
    "backend/access/trans/xlog.c" ? am i right?
    Yes. search for callers of CheckForStandbyTrigger() function.


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


    --
    Thanks & Regards,

    Aaliya Zarrin
    (+91)-9160665888
  • Heikki Linnakangas at Dec 1, 2010 at 7:02 pm

    On 01.12.2010 19:23, aaliya zarrin wrote:
    Thanks for quick response..
    Can I change this 5 second time?
    I have seen the postgres code as well.
    You can, if you don't mind changing the sources.
    What is the functionality of WaitLatch() function. I could not understand
    completely.
    The recoveryWakupLatch latch allows the startup process to wake up
    immediately when new WAL arrives via streaming replication, without
    waiting for the whole five seconds to elapse.

    --
    Heikki Linnakangas
    EnterpriseDB http://www.enterprisedb.com
  • Aaliya zarrin at Dec 2, 2010 at 9:55 am
    Hey!!!!!!!!!1
    I am able to change the switch over time.. Thanks alot..
    2010/12/2 aaliya zarrin <aaliya.zarrin@gmail.com>
    Ok.. Thanks I will try!!!

    2010/12/2 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

    Oh, and there's another value for the case we're polling the archive, not
    streaming from master. Search for "5" in XLogPageRead function to catch them
    all.

    On 02.12.2010 08:21, Heikki Linnakangas wrote:

    It's the 5000000L argument in the WaitLatch call. It's expressed in
    microseconds.
    On 02.12.2010 06:39, aaliya zarrin wrote:

    Where this 5 Seconds time is defined in the code ???



    On Wed, Dec 1, 2010 at 5:53 PM, Heikki Linnakangas<
    heikki.linnakangas@enterprisedb.com> wrote:
    On 01.12.2010 13:27, aaliya zarrin wrote:

    I want to know how frequently postgres search for trigger file to
    switch
    over.
    In 9.0, every 100ms while streaming replication is active and
    connected. 5
    seconds otherwise. In current git master branch, it's always 5 s.


    Can this switch over time be reduced?
    Not without hacking the sources and compiling.

    Although, on many platforms, Linux included I believe, sending a
    signal to
    the startup process should wake it up from the sleep and make it
    check the
    trigger file immediately. "pg_ctl reload" for example should do it.
    So if
    ıou send a signal to the startup process immediately after creating the
    trigger file, it should take notice sooner.


    Plz let me know where postgres poll for trigger file. I could find it
    out
    in
    "backend/access/trans/xlog.c" ? am i right?
    Yes. search for callers of CheckForStandbyTrigger() function.


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


    --
    Thanks & Regards,

    Aaliya Zarrin
    (+91)-9160665888


    --
    Thanks & Regards,

    Aaliya Zarrin
    (+91)-9160665888

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedDec 1, '10 at 11:27a
activeDec 3, '10 at 8:18a
posts8
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase