Skip site navigation (1) Skip section navigation (2)

Re: concurrent snapshots

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: concurrent snapshots
Date: 2011-09-08 15:46:28
Message-ID: 23436.1315496788@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Ants Aasma <ants(dot)aasma(at)eesti(dot)ee> writes:
> On Thu, Sep 8, 2011 at 5:28 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> 1. A backend can have lots of snapshots, potentially requiring an
>> unbounded amount of shared memory. We can't accommodate that.

> If PostgreSQL gets POSIX shared memory capability at some point in the
> future, would it be enough to accommodate snapshots in shared memory?

Don't hold your breath.  Even if we moved over to using mmap() in place
of shmat(), it's a *very* long way from there to being able to
dynamically expand shared memory and have all backends able to access
the additional space.  Doing that in a way that's cheap enough and
transparent enough that we'd actually accept it is even more challenging
--- for instance, it seems hard to impossible to guarantee that all
backends would be able to map the added space at the same addresses.

Most of the interest in mmap is not about any dynamic-expansion ideas,
it's just about getting out from under the ridiculously small limits on
SysV shmem space that are still default on many platforms.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-09-08 15:46:36
Subject: Re: concurrent snapshots
Previous:From: Ants AasmaDate: 2011-09-08 15:33:00
Subject: Re: concurrent snapshots

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group