Skip site navigation (1) Skip section navigation (2)

Re: max_wal_senders must die

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: max_wal_senders must die
Date: 2010-10-28 15:45:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Excerpts from Tom Lane's message of mié oct 27 19:01:38 -0300 2010:

> I don't know what Simon is thinking, but I think he's nuts.  There is is
> obvious extra overhead in COMMIT:
>         /*
>          * Wake up all walsenders to send WAL up to the COMMIT record
>          * immediately if replication is enabled
>          */
>         if (max_wal_senders > 0)
>             WalSndWakeup();
> which AFAICT is injecting multiple kernel calls into what's not only
> a hot-spot but a critical section (ie, any error -> PANIC).

Hmm, I wonder if that could be moved out of the critical section
somehow.  Obviously the point here is to allow wal senders to react
before we write to clog (which is expensive by itself); but it seems
hard to wake up some other process without incurring exactly the same
cost (which is basically SetLatch) ... the only difference is that it
would be a single one instead of one per walsender.

BTW I note that there are no elog(ERROR) calls in that code path at all,
because syscall errors are ignored, so PANIC is not a concern (as the
code stands currently, at least).  ISTM it would be good to have a
comment on SetLatch stating that it's used inside critical sections,

Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to


pgsql-hackers by date

Next:From: Pavel StehuleDate: 2010-10-28 15:54:10
Subject: Re: plperl arginfo
Previous:From: Pavel StehuleDate: 2010-10-28 15:39:31
Subject: Re: plperl arginfo

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group