On Mon, Apr 30, 2012 at 10:26 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
>> Simon Riggs <simon@2ndquadrant.com> wrote:
>
>>> * throw a WARNING if serializable is stated in other cases, and
>>> downgrade the request to repeatable read
>>
>> I think this would be reasonable, but it's still my second choice.
>> The advantage of throwing an ERROR is that someone will presumably
>> be forced to realize that a problem exists and fix it, whereas a
>> WARNING may just generate a combination of log spam and unexpected
>> behavior forever. Also, we currently block cases where you try to
>> set transaction_isolation by throwing an ERROR, so it seems a bit
>> more consistent to do that in other cases as well. Still, it's a
>> reasonable choice, and certainly better than failing an assertion.
>
> I'm not totally clear on your first choice. Are you looking for
> something similar to the patch I posted, except that it would dodge
> all resulting errors at the point where they are promoted to FATAL
> (before HS is really functional)?
That's my vote. Where is that FATAL error coming from? I'm guessing
it's somehow resulting from failure to set up the startup transaction
in InitPostgres(). If that's the case, we ought to be able to work
around it, because surely repeatable read would be fine for the
startup transaction, which doesn't really do anything anyway.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company