On 11/20/2015 08:45 AM, Steve Singer wrote:
> On 11/19/2015 01:09 PM, Tignor, Tom wrote:
>> 	A general question for the group: if we would consider a change like this
>> (as a runtime option or otherwise), what’s the correct way to move it
>> forward? Should I file a bug? Are there specific tests or analysis which
>> should be performed?
> 
> I would use bug 336 for this.
> My gut is to make this a runtime option since I am not confident that
> downgrading the isolation level won't impact someones workload, having
> said that I am open to being convinced otherwise.  I would also be
> inclined to leave the default value unchanged for 2.2.x and then maybe
> consider changing the default in 2.3.   If we actually any concrete
> plans for a 2.3 version I would say just leave the change for 2.3 but I
> don't see a 2.3 release happening soon and I don't want to change the
> default behaviour in a minor release.
> 
> 
> Generally when we make a change like this I try to do lots of runs
> through the disorder/clustertest suite that doesn't cover all types of
> workloads.  Have you tried this change on your workload? Does it
> actually help things?
> 
> It would be great if Jan and Chris were to comment on this thread

Without taking SYNC snapshots in a SERIALIZABLE transaction I believe
that a Slony-I replica could suffer the same inconsistency dangers that
a pg_dump without --serializable-deferrable can suffer. Namely a replica
would not be usable as a source for reporting. From the 9.4 pg_dump docs:

"This option is not beneficial for a dump which is intended only for
disaster recovery. It could be useful for a dump used to load a copy of
the database for reporting or other read-only load sharing while the
original database continues to be updated. Without it the dump may
reflect a state which is not consistent with any serial execution of the
transactions eventually committed. For example, if batch processing
techniques are used, a batch may show as closed in the dump without all
of the items which are in the batch appearing."

Changing the default isolation levels(s) may therefore change, what a
replica can safely be used for and I believe that creating reports is
one of the major use cases. Using options with big, bold, red, flashing
warnings in the documentation would be the only way to go.


Regards, Jan



> 
>>
>> 	Tom    :-)
>>
>>
>> On 11/18/15, 10:35 AM, "Greg Sabino Mullane" <greg at endpoint.com> wrote:
>>
>>> On Wed, Nov 18, 2015 at 02:26:15PM +0000, Tom Tignor wrote:
>>> ...
>>>> Sorry for the delay getting back. Inspired by your questions, I¹ve been
>>>> reading up on SSI, the Cahill paper and slony1 and postgres code.
>>> ...
>>>
>>> It should be pointed out that 9.1 goes EOL (End of Life) in less than
>>> a year (Sep 2016), and transaction handling has changed a *lot* since
>>> then,
>>> so any changes that core Slony makes may not even work for you.
>>>
>>> (FWIW, I think dropping the isolation level in this particular
>>> instance seems safe, however.)
>>>
>>> --
>>> Greg Sabino Mullane greg at endpoint.com
>>> End Point Corporation
>>> PGP Key: 0x14964AC8
>>
>> _______________________________________________
>> Slony1-general mailing list
>> Slony1-general at lists.slony.info
>> http://lists.slony.info/mailman/listinfo/slony1-general
>>
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
> 


-- 
Jan Wieck
Senior Software Engineer
http://slony.info