Simon Riggs wrote:
> On Wed, 2009-09-30 at 09:33 +0300, Heikki Linnakangas wrote:
>
>> Looking at the changes to StartupMultiXact, you're changing the locking
>> so that both MultiXactOffsetControlLock and MultiXactMemberControlLock
>> are acquire first before changing anything. Why? Looking at the other
>> functions in that file, all others that access both files are happy to
>> acquire one lock at a time, like StartupMultiXact does without the patch.
>
> I think those changes are just paranoia from early versions of patch.
>
> We now know for certain that MultiXact isn't used at the time
> StartupMultiXact() is called. The same isn't true for StartupClog() and
> StartupSubtrans() which need to cope with concurrent callers.
>
> Will remove changes and document that nothing touching it when it runs.
Thanks, I reverted that in my working version already. Comment patch
welcome if you feel it's needed.
Attached is a new batch of changes I've been doing since last batch.
These are again extracted from my git repository. It includes some of
the add-on patches from your repository, the rest I believe have I had
already did myself earlier, or are not necessary anymore for other reasons.
Could you look into these two TODO items you listed on the wiki page:
- Correct SET default_transaction_read_only and SET
transaction_read_only (Heikki 21/9 Hackers)
- Shutdown checkpoints must not clear locks for prepared transactions
(Heikki 23/9)
And if you could please review the changes I've been doing, just to make
sure I haven't inadvertently introduced new bugs. That has happened
before, as you've rightfully reminded me :-).
There's also the issue that you can't go into hot standby mode after a
shutdown checkpoint. I think that really should be fixed, it's just
weird from a usability point of view if it doesn't work.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com