On 22 March 2017 at 13:19, David Rowley wrote:
>> Given that, do you agree to me applying assign_aels_against_subxids.v1.patch
>> as well?
>
> Does applying assign_aels_against_subxids.v1.patch still need to keep
> the loop to release the subxacts? Won't this be gone already with the
> subxact co
On 22 March 2017 at 22:27, Simon Riggs wrote:
> On 20 March 2017 at 08:31, David Rowley wrote:
>> 0003:
>>
>> Is intended to be patched atop of 0002 (for master only) and revises
>> this code further to remove the StandbyReleaseLockTree() function. To
>> me it seems better to do this to clear up
On 20 March 2017 at 08:31, David Rowley wrote:
> On 18 March 2017 at 21:59, Simon Riggs wrote:
>> As Amit says, I don't see the gain from adding that to each xact state.
>>
>> I'd suggest refactoring my patch so that the existign
>> MyXactAccessedTempRel becomes MyXactFlags and we can just set a
On 18 March 2017 at 21:59, Simon Riggs wrote:
> As Amit says, I don't see the gain from adding that to each xact state.
>
> I'd suggest refactoring my patch so that the existign
> MyXactAccessedTempRel becomes MyXactFlags and we can just set a flag
> in the two cases (temp rels and has-aels). That
On 17 March 2017 at 00:04, Amit Kapila wrote:
> On Thu, Mar 16, 2017 at 7:22 AM, David Rowley
> wrote:
>> On 16 March 2017 at 13:31, Simon Riggs wrote:
>>>
>>> On 8 March 2017 at 10:02, David Rowley
>>> wrote:
>>> > On 8 March 2017 at 01:13, Simon Riggs wrote:
>>> >> Don't understand this. I'm
On 18 March 2017 at 21:52, Simon Riggs wrote:
> 2. In LogAccessExclusiveLock() we can use GetCurrentTransactionId()
> rather than GetTopTransactionId(), so that we assign the lock to the
> subxid rather than the top xid. That could increase lock traffic, but
> less likely. It also solves the probl
On 16 March 2017 at 09:52, David Rowley wrote:
>> Seemed easier to write it than explain further. Please see what you think.
>
>
> Thanks. I had been looking for some struct to store the flag in. I'd not
> considered just adding a new global variable.
As Amit says, I don't see the gain from addi
On 16 March 2017 at 19:08, Amit Kapila wrote:
> On Thu, Mar 16, 2017 at 6:01 AM, Simon Riggs wrote:
>> On 8 March 2017 at 10:02, David Rowley wrote:
>>> On 8 March 2017 at 01:13, Simon Riggs wrote:
Don't understand this. I'm talking about setting a flag on
commit/abort WAL records, li
On 16 March 2017 at 09:52, David Rowley wrote:
> I was just trying to verify if it was going to do the correct thing in
> regards to subtransactions and I got a little confused at the comments at
> the top of StandbyAcquireAccessExclusiveLock():
>
> * We record the lock against the top-level xid
On Thu, Mar 16, 2017 at 6:01 AM, Simon Riggs wrote:
> On 8 March 2017 at 10:02, David Rowley wrote:
>> On 8 March 2017 at 01:13, Simon Riggs wrote:
>>> Don't understand this. I'm talking about setting a flag on
>>> commit/abort WAL records, like the attached.
>>
>> There's nothing setting a flag
On Thu, Mar 16, 2017 at 7:22 AM, David Rowley
wrote:
> On 16 March 2017 at 13:31, Simon Riggs wrote:
>>
>> On 8 March 2017 at 10:02, David Rowley
>> wrote:
>> > On 8 March 2017 at 01:13, Simon Riggs wrote:
>> >> Don't understand this. I'm talking about setting a flag on
>> >> commit/abort WAL r
On 16 March 2017 at 13:31, Simon Riggs wrote:
> On 8 March 2017 at 10:02, David Rowley
> wrote:
> > On 8 March 2017 at 01:13, Simon Riggs wrote:
> >> Don't understand this. I'm talking about setting a flag on
> >> commit/abort WAL records, like the attached.
> >
> > There's nothing setting a fl
On 8 March 2017 at 10:02, David Rowley wrote:
> On 8 March 2017 at 01:13, Simon Riggs wrote:
>> Don't understand this. I'm talking about setting a flag on
>> commit/abort WAL records, like the attached.
>
> There's nothing setting a flag in the attached. I only see the
> checking of the flag.
Ye
On 8 March 2017 at 01:13, Simon Riggs wrote:
> Don't understand this. I'm talking about setting a flag on
> commit/abort WAL records, like the attached.
There's nothing setting a flag in the attached. I only see the
checking of the flag.
> We just need to track info so we can set the flag at EOX
Hi,
On 2017-03-08 00:15:05 +1300, David Rowley wrote:
> -static List *RecoveryLockList;
> +/*
> + * RecoveryLockTable is a poor man's hash table that allows us to partition
> + * the stored locks. Which partition a lock is stored in is determined by the
> + * xid which the lock belongs to. The has
On 7 March 2017 at 19:22, David Rowley wrote:
>>> That may need tweaking. Likely it could be smaller if we had some sort
>>> of bloom filter to mark if the transaction had obtained any AEL locks,
>>> that way it could skip. Initially I really didn't want to make the
>>> patch too complex. I had t
On 7 March 2017 at 23:20, Simon Riggs wrote:
> On 7 March 2017 at 10:01, David Rowley wrote:
>> On 2 March 2017 at 16:06, Amit Kapila wrote:
>>> On Wed, Mar 1, 2017 at 5:32 PM, David Rowley
>>> wrote:
Hackers,
I've attached a small patch which aims to improve the performance of
>
On 7 March 2017 at 17:31, David Rowley wrote:
> On 2 March 2017 at 16:06, Amit Kapila wrote:
>> Few comments on the patch:
>> 1.
>> +/*
>> + * Number of buckets to split RecoveryLockTable into.
>> + * This must be a power of two.
>> + */
>>
>> +#define RECOVERYLOCKTABLE_SIZE 1024
>>
>> On what ba
On 7 March 2017 at 10:01, David Rowley wrote:
> On 2 March 2017 at 16:06, Amit Kapila wrote:
>> On Wed, Mar 1, 2017 at 5:32 PM, David Rowley
>> wrote:
>>> Hackers,
>>>
>>> I've attached a small patch which aims to improve the performance of
>>> AccessExclusiveLock when there are many AccessExclu
On 2 March 2017 at 16:06, Amit Kapila wrote:
> On Wed, Mar 1, 2017 at 5:32 PM, David Rowley
> wrote:
>> Hackers,
>>
>> I've attached a small patch which aims to improve the performance of
>> AccessExclusiveLock when there are many AccessExclusiveLock stored.
>>
>
> I could see that your idea is q
On Wed, Mar 1, 2017 at 5:32 PM, David Rowley
wrote:
> Hackers,
>
> I've attached a small patch which aims to improve the performance of
> AccessExclusiveLock when there are many AccessExclusiveLock stored.
>
I could see that your idea is quite straightforward to improve
performance (basically, co
21 matches
Mail list logo
