| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: New FSM patch |
| Date: | 2008-09-04 01:41:09 |
| Message-ID: | 1220492469.4371.806.camel@ebony.2ndQuadrant |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2008-08-29 at 10:47 +0300, Heikki Linnakangas wrote:
> Here's an updated FSM patch.
Can I check some aspects of this related to Hot Standby? Some of them
sound obvious, but worth double checking.
* There will be no need to read FSM by any normal operation of a
read-only transaction, so locking correctness considerations can
possibly be ignored during recovery. pg_freespacemap exists though:
would we need to prevent that from executing during recovery, or will
the FSM be fully readable? i.e. does redo take appropriate locks already
(I don't see any Cleanup locks being required).
* FSM will be continuously maintained during recovery, so FSM will now
be correct and immediately available when recovery completes?
* There are no cases where a screwed-up FSM will crash either recovery
(FATAL+) or halt normal operation (PANIC)?
* incomplete action cleanup is fairly cheap and doesn't rely on the FSM
being searchable to correct the error? This last is a hard one...
Do we have the concept of a invalid/corrupt FSM? What happens if the
logic goes wrong and we have a corrupt page? Will that mean we can't
complete actions against the heap?
Are there really any changes to these files?
src/include/storage/bufmgr.h
src/include/postmaster/bgwriter.h
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2008-09-04 02:06:42 | Re: hash index improving v3 |
| Previous Message | Greg Smith | 2008-09-04 00:49:25 | Re: [patch] GUC source file and line number] |