Re: Re: We have got a serious problem with pg_clog/WAL synchronization
От | Kenneth Marshall |
---|---|
Тема | Re: Re: We have got a serious problem with pg_clog/WAL synchronization |
Дата | |
Msg-id | 20040812182517.GB11862@it.is.rice.edu обсуждение исходный текст |
Ответ на | Re: Re: We have got a serious problem with pg_clog/WAL synchronization (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: We have got a serious problem with pg_clog/WAL synchronization
|
Список | pgsql-hackers |
On Thu, Aug 12, 2004 at 01:13:46PM -0400, Tom Lane wrote: > Kenneth Marshall <ktm@is.rice.edu> writes: > > On Thu, Aug 12, 2004 at 09:58:56AM -0400, Tom Lane wrote: > >> How would a read-only action work to block out the checkpoint? > > > The latch+version number is use by the checkpoint process. The > > other processes can do a read of the latch to determine if it has > > been set. This does not cause a cache invalidation hit. If the > > latch is set, the competing processes read until it has been > > cleared and the version updated. This makes the general case of > > no checkpoint not incur a write and the consequent cache-line > > invalidation and reload by all processors on an SMP system. > > Except that reading the latch and finding it clear offers no guarantee > that a checkpoint isn't about to start. The problem is that we are > performing two separate actions (write a COMMIT xlog record and update > transaction status in clog) and we have to prevent a checkpoint from > starting in between those actions. I don't see that there's any way to > do that with a read-only latch. > > regards, tom lane Yes, you are correct. I missed that part of the previous thread. When I saw "exclusive lock" I thought latch since that is what I am investigating to solve other performance issues that I am addressing. Ken
В списке pgsql-hackers по дате отправления: