| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Summary and Plan for Hot Standby |
| Date: | 2009-11-25 06:54:06 |
| Message-ID: | 1259132046.27757.11288.camel@ebony |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2009-11-19 at 10:13 +0200, Heikki Linnakangas wrote:
> At backend start, we normally take
> RowExclusiveLock on the database in postinit.c, but you had to modify
> to acquire AccessShareLock instead in standby mode.
The consensus from earlier discussion was that allowing users to grab
RowExclusiveLock during read only transactions was not a problem, since
it allowed PREPARE. So there seems no need to prevent it in other
places.
So I suggest removing most of the changes in postinit.c, and changing
the lock restrictions in lock.c to be
+ if (RecoveryInProgress() &&
+ (locktag->locktag_type == LOCKTAG_OBJECT ||
+ locktag->locktag_type == LOCKTAG_RELATION ) &&
+ lockmode > RowExclusiveLock)
then ERROR
lockcmds.c would also be changed to allow LOCK TABLE of up to
RowExclusiveLock.
--
Simon Riggs www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2009-11-25 06:59:04 | LockDatabaseObject() |
| Previous Message | Fujii Masao | 2009-11-25 06:48:15 | Re: Architecture of walreceiver (Streaming Replication) |