Re: Dynamic Shared Memory stuff

From: Noah Misch <noah(at)leadboat(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Dynamic Shared Memory stuff
Date: 2014-01-22 15:17:48
Message-ID: 20140122151748.GA1960293@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 22, 2014 at 09:32:09AM -0500, Robert Haas wrote:
> On Tue, Jan 21, 2014 at 2:58 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> >> What do people prefer?
> >
> > I recommend performing cleanup on the control segment named in PGShmemHeader
> > just before shmdt() in PGSharedMemoryCreate(). No new ERROR or WARNING sites
> > are necessary. Have dsm_postmaster_startup() continue to perform a cleanup on
> > the control segment named in the state file.
>
> I think I'm on board with the first two sentences of this, but after
> Fujii Masao's email yesterday, I can't help thinking that what you
> propose the third sentence is a bad idea. He cloned a master to
> create a standby server on the same machine, and the standby startup
> ate the master's dynamic shared memory. We could teach pg_basebackup
> not to copy the state file, but that wouldn't help people who take
> base backups using the file system copy method, which is a lot of
> people.

I agree we should not rely on folks learning to omit the state file from base
backups. Abandoning the state file is one way to resolve that, and the
reasons I outlined for preferring to keep it were not overriding concerns. We
could instead store a postmaster PID in dsm_control_header and only clean if
that PID is dead. We could make DSM startup aware of whether we're using a
backup label, but that would be awkward thanks to StartupXLOG() happening a
good bit later. Yeah, abandoning the state file is looking attractive.

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-01-22 15:26:35 Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it
Previous Message Robert Haas 2014-01-22 15:14:27 Re: Changeset Extraction v7.0 (was logical changeset generation)