Re: getting to beta

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dan Ports <drkp(at)csail(dot)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: getting to beta
Date: 2011-04-06 16:57:41
Message-ID: 4D9C9B85.2070808@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06.04.2011 17:46, Tom Lane wrote:
> "Kevin Grittner"<Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>>> ... The one I'm most
>>> worried about is "SSI: three different HTABs contend for shared
>>> memory in a free-for-all" - because there's no patch for that yet,
>>> and I am wary of breaking something mucking around with it.
>
>> I haven't seen any objection to Heikki's suggestion for how to
>> handle the shared memory free-for-all:
>
> I confess to not having been reading the discussions about SSI very
> much, but ... do we actually care whether there's a free-for-all?
> What's the downside to letting the remaining shmem get claimed by
> whichever table uses it first?

It's leads to odd behavior. You start the database, and your application
runs fine. Then you restart the database, and now you get "out of shared
memory" errors from transactions that used to work.

It's not the end of the world, but I'd prefer stable, repeatable
behavior, even though having the slack shared memory be grabbed by
whoever needs it first might in theory lead to better utilization of
resources.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2011-04-06 17:01:11 Re: getting to beta
Previous Message Tom Lane 2011-04-06 16:46:23 Re: getting to beta