Re: PostgreSQL as a local in-memory cache - Mailing list pgsql-performance

From Bruce Momjian
Subject Re: PostgreSQL as a local in-memory cache
Date
Msg-id 201006291845.o5TIjMh24107@momjian.us
Whole thread Raw
In response to Re: PostgreSQL as a local in-memory cache  (Tom Lane)
Responses Re: PostgreSQL as a local in-memory cache  (Jignesh Shah)
List pgsql-performance
Tom Lane wrote:
> Bruce Momjian <> writes:
> >>> I asked on IRC and was told it is true, and looking at the C code it
> >>> looks true. ?What synchronous_commit = false does is to delay writing
> >>> the wal buffers to disk and fsyncing them, not just fsync, which is
> >>> where the commit loss due to db process crash comes from.
>
> >> Ah, I see.  Thanks.
>
> > I am personally surprised it was designed that way;  I thought we would
> > just delay fsync.
>
> That would require writing and syncing to be separable actions.  If
> you're using O_SYNC or similar, they aren't.

Ah, very good point.  I have added a C comment to clarify why this is
the current behavior;  attached and applied.

--
  Bruce Momjian  <>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + None of us is going to be here forever. +
Index: src/backend/access/transam/xact.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/access/transam/xact.c,v
retrieving revision 1.291
diff -c -c -r1.291 xact.c
*** src/backend/access/transam/xact.c    13 May 2010 11:39:30 -0000    1.291
--- src/backend/access/transam/xact.c    29 Jun 2010 18:33:47 -0000
***************
*** 1028,1034 ****
      if (XactSyncCommit || forceSyncCommit || haveNonTemp)
      {
          /*
!          * Synchronous commit case.
           *
           * Sleep before flush! So we can flush more than one commit records
           * per single fsync.  (The idea is some other backend may do the
--- 1028,1034 ----
      if (XactSyncCommit || forceSyncCommit || haveNonTemp)
      {
          /*
!          * Synchronous commit case:
           *
           * Sleep before flush! So we can flush more than one commit records
           * per single fsync.  (The idea is some other backend may do the
***************
*** 1054,1060 ****
      else
      {
          /*
!          * Asynchronous commit case.
           *
           * Report the latest async commit LSN, so that the WAL writer knows to
           * flush this commit.
--- 1054,1065 ----
      else
      {
          /*
!          * Asynchronous commit case:
!          *
!          * This enables possible committed transaction loss in the case of a
!          * postmaster crash because WAL buffers are left unwritten.
!          * Ideally we could issue the WAL write without the fsync, but
!          * some wal_sync_methods do not allow separate write/fsync.
           *
           * Report the latest async commit LSN, so that the WAL writer knows to
           * flush this commit.

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: PostgreSQL as a local in-memory cache
Next
From: Samuel Gendler
Date:
Subject: ideal storage configuration