| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Markus Wanner <markus(at)bluegap(dot)ch> | 
| Cc: | Alexey Klyukin <alexk(at)commandprompt(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: Postgres-R: internal messaging | 
| Date: | 2008-07-23 20:51:42 | 
| Message-ID: | 11514.1216846302@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Markus Wanner <markus(at)bluegap(dot)ch> writes:
> ... crashes are more difficult. IMO the replication 
> manager needs to stay alive during this reinitialization, to keep the 
> GCS connection. However, it can easily detach from shared memory 
> temporarily (the imessages stuff is the only shmem place it touches, 
> IIRC). However, a more difficult aspect is: it must be able to tell if a 
> backend has applied its transaction *before* it died or not. Thus, after 
> all backends have been killed, the postmaster needs to wait with 
> reinitializing shared memory, until the replication manager has consumed 
> all its messages. (Otherwise we would risk "losing" local transactions, 
> probably also remote ones).
I hope you're not expecting the contents of shared memory to still be
trustworthy after a backend crash.  If the manager is working strictly
from its own local memory, then it would be reasonable to operate
as above.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2008-07-23 21:01:18 | Re: [PATCHES] odd output in restore mode | 
| Previous Message | Manoel Henrique | 2008-07-23 20:47:22 | Re: Research/Implementation of Nested Loop Join optimization |