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
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 |