Thread

1. Re: [HACKERS] Priorities for 6.6

   Tom Lane <tgl@sss.pgh.pa.us> — 1999-06-07T14:57:26Z

   Bruce Momjian <maillist@candle.pha.pa.us> writes:
   > ... Another idea
   > is to send a signal to each backend that has marked a bit in shared
   > memory saying it has written to a relation, and have the signal handler
   > fsync all its dirty relations, set a finished bit, and have the
   > postmaster then fsync pglog.
   
   I do not think it's practical to expect any useful work to happen inside
   a signal handler.  The signal could come at any moment, such as when
   data structures are being updated and are in a transient invalid state.
   Unless you are willing to do a lot of fooling around with blocking &
   unblocking the signal, about all the handler can safely do is set a flag
   variable that will be examined somewhere in the backend main loop.
   
   However, if enough information is available in shared memory, perhaps
   the postmaster could do this scan/update/flush all by itself?
   
   > Of course, we have to prevent flush of pglog by OS, perhaps by making a
   > copy of the last two pages of pg_log before this and remove it after. 
   > If a backend starts up and sees that pg_log copy file, it puts that in
   > place of the current last two pages of pg_log.
   
   It seems to me that one or so disk writes per transaction is not all
   that big a cost.  Does it take much more than one write to update
   pg_log, and if so why?
   
   			regards, tom lane
   
   

2. Re: [HACKERS] Priorities for 6.6

   Brian E Gallew <geek+@cmu.edu> — 1999-06-07T18:39:32Z

   Bruce Momjian <maillist@candle.pha.pa.us> writes:
   > ... Another idea
   > is to send a signal to each backend that has marked a bit in shared
   > memory saying it has written to a relation, and have the signal handler
   > fsync all its dirty relations, set a finished bit, and have the
   > postmaster then fsync pglog.
   
   One other problem with signals is that things get complicated if
   PostgreSQL ever moves to a multi-threading model.
   
   -- 
   =====================================================================
   | JAVA must have been developed in the wilds of West Virginia.      |
   | After all, why else would it support only single inheritance??    |
   =====================================================================
   | Finger geek@cmu.edu for my public key.                            |
   =====================================================================