Re: Re: We have got a serious problem with pg_clog/WAL synchronization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Simon(at)2ndquadrant(dot)com" <simon(at)2ndquadrant(dot)com>
Cc: "Kenneth Marshall" <ktm(at)is(dot)rice(dot)edu>, pgsql-hackers(at)postgresql(dot)org, xu(at)cs(dot)wisc(dot)edu
Subject: Re: Re: We have got a serious problem with pg_clog/WAL synchronization
Date: 2004-08-13 23:29:43
Message-ID: 29055.1092439783@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

"Simon(at)2ndquadrant(dot)com" <simon(at)2ndquadrant(dot)com> writes:
> This is not a provably correct state machine

I think the discussion ends right there. You are assuming that the
commit is guaranteed to finish in X amount of time, when it is not
possible to make any such guarantee. We are not putting in an
unreliable commit mechanism in order to save a small amount of lock
contention. (As I tried to point out already, but it doesn't seem
to have sunk in: this newly-added lock is not likely to be that much
more contention added to the commit path, seeing that the path of
control it protects already involves taking at least two exclusive
LWLocks. Those locks will likely each cause as much or more SMP
cache thrashing as this one.)

What we could use is a better way to build LWLocks in general. I do not
know how to do that, though, in the face of SMP machines that seem to
fundamentally not have any cheap locking mechanisms...

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2004-08-13 23:57:59 Re: Index Issues & ReIndex
Previous Message gnari 2004-08-13 23:21:26 Re: Autoincremental value

Browse pgsql-hackers by date

  From Date Subject
Next Message Oliver Jowett 2004-08-13 23:35:15 Re: Calling PL functions with named parameters
Previous Message Oliver Jowett 2004-08-13 23:18:18 Re: Calling PL functions with named parameters