On 5/20/13 7:51 AM, Heikki Linnakangas wrote:
The way that MarkDirty requires this specific underlying storage manager
behavior to work properly strikes me as as a bit of a layering violation
too. I'd like the read and write paths to have a similar API, but here
they don't even operate on the same type of inputs. Addressing that is
probably harder than just throwing a hack on the existing code though.
To be honest, I don't understand what you mean by that. ?
Let's say you were designing a storage layer API from scratch for what
Postgres does. That might take a relation as its input, like ReadBuffer
does. Hiding the details of how that turns into a physical file
operation would be a useful goal of such a layer. I'd then consider it
a problem if that exposed things like the actual mapping of relations
into files to callers.
What we actually have right now is this MarkDirty function that operates
on BufferTag data, which points directly to the underlying file. I see
that as cutting the storage API in half and calling a function in the
middle of the implementation. It strikes me as kind of weird that the
read side and write side are not more symmetrical.
--
Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
