Re: WalSndWakeup() and synchronous_commit=off

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: WalSndWakeup() and synchronous_commit=off
Date: 2012-05-30 23:43:07
Message-ID: 201205310143.07264.andres@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, May 31, 2012 01:33:33 AM Fujii Masao wrote:
> On Wed, May 30, 2012 at 9:46 PM, Andres Freund <andres(at)2ndquadrant(dot)com>
wrote:
> > On Tuesday, May 29, 2012 08:42:43 PM Andres Freund wrote:
> >> Patch attached.
> >
> > Imo this patch should be backported to 9.1, 9.0 doesn't use latches and
> > does not do explicit wakeup of the sender so its not applicable there.
> >
> > I can prepare a patch for 9.1 if people agree, there has been some amount
> > of change that won't make it apply cleanly.
>
> The patch wakes up walsender more frequently than now. Which leads
> walsender to send smaller WAL data packet more frequently, and furthermore
> which leads walreceiver to issue fsync more frequently. So I'm afraid that
> the patch makes the disk more busy and slows down the read-only query
> in the standby. I'm also afraid that frequent fsync calls degrade the
> performance
> of sync replication. So it's better to do benchmark to address the
> concerns.
I couldn't measure any significant difference in #fsyncs or replication speed
in a busy pgbench workload. If anything there were less, but the difference
was small. Both with synchronous_commit=on/off. I did *not* test sync repl.

Why would you expect a change? Walsender is only signalled if XLogWrite
actually flushed data to disk. Thats the point of the exercise. Thats normally
only done if the wal buffers are full or a commit record (+some other stuff)
requires the xlog to be flushed up to some point.

Greetings,

Andres

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2012-05-31 00:00:59 Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Previous Message Noah Misch 2012-05-30 23:34:16 Re: Not quite a security hole: CREATE LANGUAGE for non-superusers