Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Thu, Jan 12, 2017 at 10:21 AM, Michael Paquier wrote: > On Thu, Jan 12, 2017 at 4:09 AM, Robert Haas wrote: >> On Tue, Jan 10, 2017 at 11:41 PM, Michael Paquier >> wrote: >>> Do you think that expanding the wait

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Mon, Jan 16, 2017 at 10:37 PM, Craig Ringer wrote: > On 16 Jan. 2017 17:09, "Michael Paquier" wrote: > > On Mon, Jan 16, 2017 at 9:40 AM, Thomas Munro > wrote: >> I also have longer term plans to show the

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On 16 Jan. 2017 17:09, "Michael Paquier" wrote: On Mon, Jan 16, 2017 at 9:40 AM, Thomas Munro wrote: > I also have longer term plans to show the first and third of them > running with the read-only transaction moved to a standby server.

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Mon, Jan 16, 2017 at 9:40 AM, Thomas Munro wrote: > I also have longer term plans to show the first and third of them > running with the read-only transaction moved to a standby server. > Kevin Grittner gave me the idea of multi-server isolation tests when I >

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Thu, Jan 12, 2017 at 2:21 PM, Michael Paquier wrote: > On Thu, Jan 12, 2017 at 4:09 AM, Robert Haas wrote: >> On Tue, Jan 10, 2017 at 11:41 PM, Michael Paquier >> wrote: >>> Do you think that expanding the wait

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Thu, Jan 12, 2017 at 4:09 AM, Robert Haas wrote: > On Tue, Jan 10, 2017 at 11:41 PM, Michael Paquier > wrote: >> Do you think that expanding the wait query by default could be >> intrusive for the other tests? I am wondering about such a white

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Tue, Jan 10, 2017 at 11:41 PM, Michael Paquier wrote: > On Thu, Jan 5, 2017 at 6:41 AM, Thomas Munro > wrote: >> It's a bit of a strange case: we're indirectly waiting for other >> backends' transactions to end, but it's not exactly a

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Thu, Jan 5, 2017 at 6:41 AM, Thomas Munro wrote: > It's a bit of a strange case: we're indirectly waiting for other > backends' transactions to end, but it's not exactly a lock or even a > predicate lock: it's waiting for a time when we could run safely with >

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Thu, Jan 5, 2017 at 7:41 AM, Robert Haas wrote: > On Wed, Jan 4, 2017 at 2:17 AM, Michael Paquier > wrote: >> On Wed, Jan 4, 2017 at 12:48 AM, Robert Haas wrote: >>> On Sun, Jan 1, 2017 at 4:38 AM, Thomas Munro >>>

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Wed, Jan 4, 2017 at 2:17 AM, Michael Paquier wrote: > On Wed, Jan 4, 2017 at 12:48 AM, Robert Haas wrote: >> On Sun, Jan 1, 2017 at 4:38 AM, Thomas Munro >> wrote: >>> To be able to do this, the patch modifies

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Wed, Jan 4, 2017 at 12:48 AM, Robert Haas wrote: > On Sun, Jan 1, 2017 at 4:38 AM, Thomas Munro > wrote: >> To be able to do this, the patch modifies the isolation tester so that >> it recognises wait_event SafeSnapshot. > > I'm not going

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Sun, Jan 1, 2017 at 4:38 AM, Thomas Munro wrote: > To be able to do this, the patch modifies the isolation tester so that > it recognises wait_event SafeSnapshot. I'm not going to say that's unacceptable, but it's certainly not beautiful. -- Robert Haas

[HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

Hi hackers, Here is a small patch to add a test exercising SERIALIZABLE READ ONLY DEFERRABLE. It shows a well known example of a serialisation anomaly caused by a read-only transaction under REPEATABLE READ (snapshot isolation), then shows the different ways that SERIALIZABLE and SERIALIZABLE