From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WAL fsync scheduling |
Date: | 2000-11-18 05:58:54 |
Message-ID: | 200011180558.AAA21746@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Other backend will see they are not the lowest
> > WAIT_ON_FSYNC and will wait for their byte to be set to NOT_IN_COMMIT
> > so they can then continue, knowing their data was synced.
>
> How will they wait? Without a semaphore involved, your answer must
> be either "timed sleep" or "busy-wait loop", neither of which is
> attractive ...
Yes, either timed sleep or busy-wait. One nifty trick would be for each
backend that is not going to do the fsync to just sleep with signals
enabled, and for the fsyncing backend to signal the other backends to
exit their sleep. That way, only one backend does the checking.
This sleep thing was going to be a problem anyway with the old system.
At least this way, they sleep/check only in cases where it is valuable.
Can we use a semaphore for this system?
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-11-18 11:03:13 | Re: location of Unix socket |
Previous Message | Tom Lane | 2000-11-18 05:45:36 | Re: AW: AW: Could turn on -O2 in AIX |