On Fri, Nov 19, 2010 at 9:35 AM, Aidan Van Dyk <aidan@highrise.ca> wrote:
> On Fri, Nov 19, 2010 at 9:31 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> Just a small point of clarification - you need to have both that
>>> unknown archtecture, and that architecture has to have postgres
>>> process running simultaneously on difference CPUs with different
>>> caches that are incoherent to have those problems.
>>
>> Sure you do. But so what? Are you going to compile PostgreSQL and
>> implement TAS as a simple store and read-fence as a simple load? How
>> likely is that to work out well?
>
> If I was trying to "port" PostgreSQL to some strange architecture, and
> my strange architecture didtt' have all the normal TAS and memory
> bariers stuff because it was only a UP system with no cache, then yes,
> and it would work out well ;-)
I get your point, but obviously this case isn't very interesting or
likely in 2010.
> If it was some strange SMP architecture, I wouldn't expect *anything*
> to work out well if the architecture doesn't have some sort of
> TAS/memory barrier/cache-coherency stuff in it ;-)
Well, you'd be pleasantly surprised to find that you could at least
get it to compile using --disable-spinlocks. Yeah, the performance
would probably be lousy and you might run out of semaphores, but at
least for basic stuff it would run. Ripping that out just to avoid an
API change in code we committed two months ago seems a bit extreme,
especially since it's also going to implementing a read-fence
operation on every platform we want to continue supporting. Maybe you
could default the read-fence to just a simple read for platforms that
are not known to have an issue, but all the platforms where TAS is
calling some OS-provided routine that does mysterious magic under the
covers are going to need attention; and I just don't think that
cleaning up everything that's going to break is a very worthwhile
investment of our limited development resources, even if it doesn't
result in needlessly dropping platform support.
If we're going to work on memory primitives, I would much rather see
us put that effort into, say, implementing more efficient LWLock
algorithms to solve the bottlenecks that the MOSBENCH guys found,
rather than spending it on trying to avoid a minor API complication
for the latch facility.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company