pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedForcing WAL flush
4+ messages / 3 participants
[nested] [flat]
* Forcing WAL flush
@ 2013-01-07 21:49 james <james@mansionfamily.plus.com>
2013-01-07 21:55 ` Re: Forcing WAL flush François Beausoleil <francois@teksol.info>
2013-01-07 23:56 ` Re: Forcing WAL flush Jeff Janes <jeff.janes@gmail.com>
0 siblings, 2 replies; 4+ messages in thread
From: james @ 2013-01-07 21:49 UTC (permalink / raw)
To: pgsql-performance
Is there a way to force a WAL flush so that async commits (from other
connections) are flushed, short of actually updating a sacrificial row?
Would be nice to do it without generating anything extra, even if it is
something that causes IO in the checkpoint.
Am I right to think that an empty transaction won't do it, and nor will
a transaction that is just a NOTIFY?
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Forcing WAL flush
2013-01-07 21:49 Forcing WAL flush james <james@mansionfamily.plus.com>
@ 2013-01-07 21:55 ` François Beausoleil <francois@teksol.info>
2013-01-07 22:05 ` Re: Forcing WAL flush james <james@mansionfamily.plus.com>
1 sibling, 1 reply; 4+ messages in thread
From: François Beausoleil @ 2013-01-07 21:55 UTC (permalink / raw)
To: james@mansionfamily.plus.com; +Cc: pgsql-performance
Le 2013-01-07 à 16:49, james a écrit :
> Is there a way to force a WAL flush so that async commits (from other connections) are flushed, short of actually updating a sacrificial row?
>
> Would be nice to do it without generating anything extra, even if it is something that causes IO in the checkpoint.
>
> Am I right to think that an empty transaction won't do it, and nor will a transaction that is just a NOTIFY?
Does pg_start_backup() trigger a full WAL flush?
http://www.postgresql.org/docs/9.2/static/continuous-archiving.html#BACKUP-LOWLEVEL-BASE-BACKUP
http://www.postgresql.org/docs/9.2/static/functions-admin.html#FUNCTIONS-ADMIN-BACKUP-TABLE
Bye,
François
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Forcing WAL flush
2013-01-07 21:49 Forcing WAL flush james <james@mansionfamily.plus.com>
2013-01-07 21:55 ` Re: Forcing WAL flush François Beausoleil <francois@teksol.info>
@ 2013-01-07 22:05 ` james <james@mansionfamily.plus.com>
0 siblings, 0 replies; 4+ messages in thread
From: james @ 2013-01-07 22:05 UTC (permalink / raw)
To: François Beausoleil <francois@teksol.info>; +Cc: pgsql-performance
> Le 2013-01-07 à 16:49, james a écrit :
>
>> Is there a way to force a WAL flush so that async commits (from other connections) are flushed, short of actually updating a sacrificial row?
>>
>> Would be nice to do it without generating anything extra, even if it is something that causes IO in the checkpoint.
>>
>> Am I right to think that an empty transaction won't do it, and nor will a transaction that is just a NOTIFY?
>
> Does pg_start_backup() trigger a full WAL flush?
>
> http://www.postgresql.org/docs/9.2/static/continuous-archiving.html#BACKUP-LOWLEVEL-BASE-BACKUP
> http://www.postgresql.org/docs/9.2/static/functions-admin.html#FUNCTIONS-ADMIN-BACKUP-TABLE
>
> Bye,
> François
That sounds rather heavyweight!
I'm looking for something lightweight - I might call this rather often,
as a sort of application-level group commit where I commit async but
defer the ack to the requester (or other externally visible side
effects) slightly until some other thread forces a flush.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Forcing WAL flush
2013-01-07 21:49 Forcing WAL flush james <james@mansionfamily.plus.com>
@ 2013-01-07 23:56 ` Jeff Janes <jeff.janes@gmail.com>
1 sibling, 0 replies; 4+ messages in thread
From: Jeff Janes @ 2013-01-07 23:56 UTC (permalink / raw)
To: james@mansionfamily.plus.com; +Cc: pgsql-performance
On Mon, Jan 7, 2013 at 1:49 PM, james <james@mansionfamily.plus.com> wrote:
> Is there a way to force a WAL flush so that async commits (from other
> connections) are flushed, short of actually updating a sacrificial row?
>
> Would be nice to do it without generating anything extra, even if it is
> something that causes IO in the checkpoint.
>
> Am I right to think that an empty transaction won't do it, and nor will a
> transaction that is just a NOTIFY?
This was discussed in "[HACKERS] Pg_upgrade speed for many tables".
It seemed like turning synchronous_commit back on and then creating an
temp table was the preferred method to force a flush. Although I
wonder if that behavior might be optimized away at some point.
Cheers,
Jeff
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2013-01-07 23:56 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2013-01-07 21:49 Forcing WAL flush james <james@mansionfamily.plus.com>
2013-01-07 21:55 ` François Beausoleil <francois@teksol.info>
2013-01-07 22:05 ` james <james@mansionfamily.plus.com>
2013-01-07 23:56 ` Jeff Janes <jeff.janes@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox