On Sun, 18 Jun 2006, paolo romano wrote:
> Anyway, again in theory, if one wanted to minimize logging overhead for
> shared locks, one might adopt a different treatment for (i) regular
> shared locks (i.e. locks due to plain reads not requiring durability in
> case of 2PC) and (ii) shared locks held because some SQL command is
> referencing a tuple via a FK, which have to be persisted until the 2-nd
> 2PC phase (There is no any other scenario in which you *must* persist
> shared locks, is there?)
There is no "regular shared locks" in postgres in that sense. Shared locks
are only used for maintaining FK integrity. Or by manually issuing a
SELECT FOR SHARE, but that's also for maintaining integrity. MVCC
rules take care of the "plain reads". If you're not familiar with MVCC,
it's explained in chapter 12 of the manual.
The source code in heapam.c also mentions Point In Time Recovery to
require logging the locks, though I'm not sure why.
> By the way, postgresql is detailedly logging *every* single shared
> lock, even though this is actually needed only if (i) the transaction
> turns out to be a distributed one (i.e. prepare is issued on that
> transactions), AND (ii) the shared lock is due to ensure validity of a
> FK. AFAICS, in most practical workloads (i) local transactions dominate
> distributed ones and (ii) shared locks due to plain reads dominate locks
> due to FK, so the current implementaion does not seem to be optimizing
> the most frequent scenario.
The problem with is that we don't know beforehand if a transaction is a
distributed one or not.
Feel free to write a benchmark to see how much difference the logging
makes! If it's significant, I'm sure we can figure out ways to improve it.
- Heikki
