Re: Free WAL caches on switching segments - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: Free WAL caches on switching segments
Date
Msg-id 200606141739.k5EHdO206649@candle.pha.pa.us
Whole thread Raw
In response to Re: Free WAL caches on switching segments  (ITAGAKI Takahiro <itagaki.takahiro@lab.ntt.co.jp>)
Responses Re: Free WAL caches on switching segments
List pgsql-patches
I have modified your patch (attached) and will apply soon, unless there
are more community comments.  Thanks.

---------------------------------------------------------------------------

ITAGAKI Takahiro wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> wrote:
>
> > > > > Here is a small patch to prevent undesired WAL file caching by kernel.
> > > > > posix_fadvise(POSIX_FADV_DONTNEED) attempts to free cached pages and
> > > > > the kernel will discard them in preference to other data caches.
> > > >
> > > > On plenty of platforms, this won't even compile ...
> >
> > Yes, but we probably have to have a configure test to see if
> > posix_fadvise exists too.  I will keep this for 8.2.
>
> I think we can use _POSIX_ADVISORY_INFO to test if posix_fadvise exists.
> Also, I added the check on whether WAL archiving is enabled, because
> archivers might use the caches to read the WAL segment.
>
>
> By the way, should we put posix_fadvise on the separated place with renaming
> pg_fadvise? If we use posix_fadvise in other purposes, for example,
> read-ahead control, the separation would be good to keep codes clean.
>
> ---
> ITAGAKI Takahiro
> NTT Cyber Space Laboratories
>

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

--
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: src/backend/access/transam/xlog.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/access/transam/xlog.c,v
retrieving revision 1.237
diff -c -c -r1.237 xlog.c
*** src/backend/access/transam/xlog.c    20 Apr 2006 04:07:38 -0000    1.237
--- src/backend/access/transam/xlog.c    14 Jun 2006 17:38:10 -0000
***************
*** 478,483 ****
--- 478,484 ----
                         bool use_lock);
  static int    XLogFileOpen(uint32 log, uint32 seg);
  static int    XLogFileRead(uint32 log, uint32 seg, int emode);
+ static void    XLogFileClose(void);
  static bool RestoreArchivedFile(char *path, const char *xlogfname,
                      const char *recovername, off_t expectedSize);
  static int    PreallocXlogFiles(XLogRecPtr endptr);
***************
*** 1384,1397 ****
               */
              Assert(npages == 0);
              if (openLogFile >= 0)
!             {
!                 if (close(openLogFile))
!                     ereport(PANIC,
!                             (errcode_for_file_access(),
!                         errmsg("could not close log file %u, segment %u: %m",
!                                openLogId, openLogSeg)));
!                 openLogFile = -1;
!             }
              XLByteToPrevSeg(LogwrtResult.Write, openLogId, openLogSeg);

              /* create/use new log file */
--- 1385,1391 ----
               */
              Assert(npages == 0);
              if (openLogFile >= 0)
!                 XLogFileClose();
              XLByteToPrevSeg(LogwrtResult.Write, openLogId, openLogSeg);

              /* create/use new log file */
***************
*** 1567,1580 ****
          {
              if (openLogFile >= 0 &&
                  !XLByteInPrevSeg(LogwrtResult.Write, openLogId, openLogSeg))
!             {
!                 if (close(openLogFile))
!                     ereport(PANIC,
!                             (errcode_for_file_access(),
!                         errmsg("could not close log file %u, segment %u: %m",
!                                openLogId, openLogSeg)));
!                 openLogFile = -1;
!             }
              if (openLogFile < 0)
              {
                  XLByteToPrevSeg(LogwrtResult.Write, openLogId, openLogSeg);
--- 1561,1567 ----
          {
              if (openLogFile >= 0 &&
                  !XLByteInPrevSeg(LogwrtResult.Write, openLogId, openLogSeg))
!                 XLogFileClose();
              if (openLogFile < 0)
              {
                  XLByteToPrevSeg(LogwrtResult.Write, openLogId, openLogSeg);
***************
*** 2153,2158 ****
--- 2140,2173 ----
  }

  /*
+  * Close the current logfile segment for writing.
+  */
+ static void
+ XLogFileClose(void)
+ {
+     Assert(openLogFile >= 0);
+
+ #ifdef _POSIX_ADVISORY_INFO
+     /*
+      * WAL caches will not be accessed in the future, so we advise OS to
+      * free them. But we will not do so if WAL archiving is active,
+      * because archivers might use the caches to read the WAL segment.
+      * While O_DIRECT works for O_SYNC, posix_fadvise() works for fsync()
+      * and O_SYNC, and some platforms only have posix_fadvise().
+      */
+     if (!XLogArchivingActive())
+         posix_fadvise(openLogFile, 0, 0, POSIX_FADV_DONTNEED);
+ #endif
+
+     if (close(openLogFile))
+         ereport(PANIC,
+             (errcode_for_file_access(),
+             errmsg("could not close log file %u, segment %u: %m",
+                    openLogId, openLogSeg)));
+     openLogFile = -1;
+ }
+
+ /*
   * Attempt to retrieve the specified file from off-line archival storage.
   * If successful, fill "path" with its complete path (note that this will be
   * a temp file name that doesn't follow the normal naming convention), and
***************
*** 5609,5622 ****
                           errmsg("could not fsync log file %u, segment %u: %m",
                                  openLogId, openLogSeg)));
              if (open_sync_bit != new_sync_bit)
!             {
!                 if (close(openLogFile))
!                     ereport(PANIC,
!                             (errcode_for_file_access(),
!                         errmsg("could not close log file %u, segment %u: %m",
!                                openLogId, openLogSeg)));
!                 openLogFile = -1;
!             }
          }
          sync_method = new_sync_method;
          open_sync_bit = new_sync_bit;
--- 5624,5630 ----
                           errmsg("could not fsync log file %u, segment %u: %m",
                                  openLogId, openLogSeg)));
              if (open_sync_bit != new_sync_bit)
!                 XLogFileClose();
          }
          sync_method = new_sync_method;
          open_sync_bit = new_sync_bit;

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Fix Ctrl-C related issues in psql (not for 8.1)
Next
From: Bruce Momjian
Date:
Subject: Re: FW: Win32 unicode vs ICU