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 query by default could be
>>> intrusive for the other tests? I am wondering about
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 first and third of them
>> running with the read-only transaction moved to a standby ser
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.
> Kevin Grittner gave me the idea of multi-server isolation
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
> mentioned my WIP SERIALIZABLE DEFE
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 query by default could be
>>> intrusive for the other tests? I am wondering about
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 list
>> to generate false positives for the existi
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 lock or even a
>> predicate lock: it's waiting for a time w
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
> predicate locking disabled. So it
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
>>> wrote:
To be able to do this, the patch modifies the isolation tester so
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 the isolation tester so that
>>> it recognises wait_event SafeSnapshot.
>>
>> I'm n
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 to say that's unacceptable, but it's certainly not beau
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
EnterpriseDB: http://www.enterprisedb.
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 REA
13 matches
Mail list logo
