On Thu, Feb 11, 2016 at 11:03 PM, Amit Kapila wrote:
> Attached patch changes the name of some of the existing tranches
> as suggested by you upthread.
Committed. Woohoo!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mai
On Fri, Feb 12, 2016 at 12:39 AM, Robert Haas wrote:
>
> On Thu, Feb 11, 2016 at 12:10 PM, Amit Kapila
wrote:
> > Okay, changed as per suggestion.
>
> Looks good to me; committed.
>
Thanks!
Attached patch changes the name of some of the existing tranches
as suggested by you upthread.
With Re
On Thu, Feb 11, 2016 at 12:10 PM, Amit Kapila wrote:
> Okay, changed as per suggestion.
Looks good to me; committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
On Thu, Feb 11, 2016 at 6:45 PM, Robert Haas wrote:
>
> On Thu, Feb 11, 2016 at 3:15 AM, Amit Kapila
wrote:
> > Sounds sensible, however after changes, CreateLWLocks() started
> > looking unreadable, so moved initialization and registration of tranches
> > to separate functions.
>
> Seems good.
>
On Thu, Feb 11, 2016 at 3:15 AM, Amit Kapila wrote:
> Sounds sensible, however after changes, CreateLWLocks() started
> looking unreadable, so moved initialization and registration of tranches
> to separate functions.
Seems good.
> Increased number of tranches allocated in LWLockTrancheArray, as
On Wed, Feb 10, 2016 at 8:51 PM, Robert Haas wrote:
>
> On Wed, Feb 10, 2016 at 1:32 AM, Amit Kapila
wrote:
> > The reason for using centralized way is that we need to request
> > named tranches before initialization of shared memory and as far as
> > I can see, currently there is no way in the s
On Wed, Feb 10, 2016 at 1:32 AM, Amit Kapila wrote:
> The reason for using centralized way is that we need to request
> named tranches before initialization of shared memory and as far as
> I can see, currently there is no way in the subsystems where they can
> issue such a request, so one possibi
On Tue, Feb 9, 2016 at 11:05 PM, Robert Haas wrote:
>
> On Tue, Feb 9, 2016 at 7:53 AM, Amit Kapila
wrote:
> > On Fri, Feb 5, 2016 at 3:17 AM, Robert Haas
wrote:
> >> I think we ought to move the buffer mapping, lock manager, and
> >> predicate lock manager locks into their own tranches also, pe
On Tue, Feb 9, 2016 at 7:53 AM, Amit Kapila wrote:
> On Fri, Feb 5, 2016 at 3:17 AM, Robert Haas wrote:
>> I think we ought to move the buffer mapping, lock manager, and
>> predicate lock manager locks into their own tranches also, perhaps
>> using this new named-tranche facility.
>
> Makes sense
On Fri, Feb 5, 2016 at 3:17 AM, Robert Haas wrote:
>
>
> I think we ought to move the buffer mapping, lock manager, and
> predicate lock manager locks into their own tranches also, perhaps
> using this new named-tranche facility.
>
Makes sense and attached patch implements it using new named
tran
On Thu, Feb 4, 2016 at 11:30 PM, Amit Kapila wrote:
> On Fri, Feb 5, 2016 at 3:17 AM, Robert Haas wrote:
>>
>> On Thu, Feb 4, 2016 at 7:00 AM, Amit Kapila
>> wrote:
>> > [ new patch ]
>>
>> I've committed this after heavy rewriting. In particular, I merged
>> two loops, used local variables to
On Fri, Feb 5, 2016 at 3:17 AM, Robert Haas wrote:
>
> On Thu, Feb 4, 2016 at 7:00 AM, Amit Kapila
wrote:
> > [ new patch ]
>
> I've committed this after heavy rewriting. In particular, I merged
> two loops, used local variables to get rid of the very long and quite
> repetitive lines, and did v
On Thu, Feb 4, 2016 at 7:00 AM, Amit Kapila wrote:
> [ new patch ]
I've committed this after heavy rewriting. In particular, I merged
two loops, used local variables to get rid of the very long and quite
repetitive lines, and did various cleanup on the documentation and
comments.
I think we oug
On Tue, Feb 2, 2016 at 7:19 PM, Robert Haas wrote:
>
> On Mon, Feb 1, 2016 at 12:27 AM, Amit Kapila
wrote:
> > Fixed.
>
> This patch doesn't build:
>
> ./xfunc.sgml:int lwlock_count = 0;
> Tabs appear in SGML/XML files
>
Changed the documentation and now I am not
On Tue, Feb 2, 2016 at 9:04 AM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> Overall, I think this is on the right track, but it still needs some
>> work to make it cleaner.
>
> We've committed a large number of patches in this item this cycle. I
> think it's fair to mark it as Committed. Can s
Robert Haas wrote:
> Overall, I think this is on the right track, but it still needs some
> work to make it cleaner.
We've committed a large number of patches in this item this cycle. I
think it's fair to mark it as Committed. Can somebody submit a new one
to the next commitfest?
--
Álvaro He
On Mon, Feb 1, 2016 at 12:27 AM, Amit Kapila wrote:
> Fixed.
This patch doesn't build:
./xfunc.sgml:int lwlock_count = 0;
Tabs appear in SGML/XML files
The #define NUM_LWLOCKS 1 just seems totally unnecessary, as does int
lwlock_count = 0. You're only assigning
On Tue, Feb 2, 2016 at 2:54 PM, Robert Haas wrote:
> On Mon, Feb 1, 2016 at 3:47 AM, Alexander Korotkov
> wrote:
> > OK. This one looks good for me too.
>
> All right, I pushed both this and the other one as a single commit,
> since they were so closely related and the second only one line.
>
G
On Tue, Feb 2, 2016 at 5:24 PM, Robert Haas wrote:
>
> On Mon, Feb 1, 2016 at 3:47 AM, Alexander Korotkov
> wrote:
> > OK. This one looks good for me too.
>
> All right, I pushed both this and the other one as a single commit,
> since they were so closely related and the second only one line.
>
On Mon, Feb 1, 2016 at 3:47 AM, Alexander Korotkov
wrote:
> OK. This one looks good for me too.
All right, I pushed both this and the other one as a single commit,
since they were so closely related and the second only one line.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enter
On Mon, Feb 1, 2016 at 10:26 AM, Amit Kapila
wrote:
> On Sat, Jan 30, 2016 at 2:15 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
> >
> > On Sat, Jan 30, 2016 at 10:58 AM, Amit Kapila
> wrote:
> >>
> >> On Fri, Jan 29, 2016 at 6:47 PM, Robert Haas
> wrote:
> >> >
> >> > On Fri, Ja
On Sat, Jan 30, 2016 at 2:15 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
>
> On Sat, Jan 30, 2016 at 10:58 AM, Amit Kapila
wrote:
>>
>> On Fri, Jan 29, 2016 at 6:47 PM, Robert Haas
wrote:
>> >
>> > On Fri, Jan 29, 2016 at 6:59 AM, Alexander Korotkov
>> > wrote:
>> > > On Thu, Jan
On Sat, Jan 30, 2016 at 12:23 PM, Amit Kapila
wrote:
> On Fri, Jan 29, 2016 at 6:55 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>>
>> Also couple of minor comments from me.
>>
>> I think this
>>
>> + StrNCpy(LWLockTrancheRequestArray[LWLockTrancheRequestsCount].tranche_name,
>>>
On Sat, Jan 30, 2016 at 10:58 AM, Amit Kapila
wrote:
> On Fri, Jan 29, 2016 at 6:47 PM, Robert Haas
> wrote:
> >
> > On Fri, Jan 29, 2016 at 6:59 AM, Alexander Korotkov
> > wrote:
> > > On Thu, Jan 21, 2016 at 12:37 AM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > > wrote:
> > >> So far as
On Fri, Jan 29, 2016 at 6:47 PM, Robert Haas wrote:
>
> On Fri, Jan 29, 2016 at 6:59 AM, Alexander Korotkov
> wrote:
> > On Thu, Jan 21, 2016 at 12:37 AM, Alvaro Herrera <
alvhe...@2ndquadrant.com>
> > wrote:
> >> So far as I can tell, there are three patches in flight here:
> >>
> >> * replicati
On Fri, Jan 29, 2016 at 6:55 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
>
> Also couple of minor comments from me.
>
> I think this
>
> + StrNCpy(LWLockTrancheRequestArray[LWLockTrancheRequestsCount].tranche_name,
>> tranche_name, strlen(tranche_name) + 1);
>
>
> should be
>
> + Str
On Fri, Jan 29, 2016 at 6:21 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Mon, Jan 4, 2016 at 5:58 PM, Robert Haas wrote:
>
>> On Mon, Jan 4, 2016 at 1:20 AM, Amit Kapila
>> wrote:
>> > If we do that way, then user of API needs to maintain the interlock
>> > guarantee that the
On Tue, Dec 29, 2015 at 11:56 AM, Amit Kapila
wrote:
> On Wed, Dec 16, 2015 at 12:26 AM, Robert Haas
> wrote:
> >
> >
> > In terms of this project overall, NumLWLocks() now knows about only
> > four categories of stuff: fixed lwlocks, backend locks (proc.c),
> > replication slot locks, and locks
On Tue, Jan 5, 2016 at 4:04 PM, Amit Kapila wrote:
> On Mon, Jan 4, 2016 at 8:28 PM, Robert Haas wrote:
> >
> > On Mon, Jan 4, 2016 at 1:20 AM, Amit Kapila
> wrote:
> > > On Mon, Jan 4, 2016 at 4:49 AM, Robert Haas
> wrote:
> > >> On Thu, Dec 31, 2015 at 3:36 AM, Amit Kapila >
> > >> wrote:
>
On Fri, Jan 29, 2016 at 6:59 AM, Alexander Korotkov
wrote:
> On Thu, Jan 21, 2016 at 12:37 AM, Alvaro Herrera
> wrote:
>> So far as I can tell, there are three patches in flight here:
>>
>> * replication slot IO lwlocks
>> * ability of extensions to request tranches dynamically
>> * PGPROC
>>
>>
On Fri, Jan 8, 2016 at 11:22 PM, Amit Kapila wrote:
> That idea won't work as we need to separately register tranche for
> each process. The other wayout could be to do it in CreateSharedProcArray()
> which will be quite similar to what we do for other tranches and
> it will cover all kind of pro
On Mon, Jan 4, 2016 at 5:58 PM, Robert Haas wrote:
> On Mon, Jan 4, 2016 at 1:20 AM, Amit Kapila
> wrote:
> > If we do that way, then user of API needs to maintain the interlock
> > guarantee that the requested number of locks is same as allocations
> > done from that tranche and also if it is n
On Thu, Jan 21, 2016 at 12:37 AM, Alvaro Herrera
wrote:
> So far as I can tell, there are three patches in flight here:
>
> * replication slot IO lwlocks
> * ability of extensions to request tranches dynamically
> * PGPROC
>
> The first one hasn't been reviewed at all, but the other two have seen
On Thu, Jan 21, 2016 at 3:07 AM, Alvaro Herrera
wrote:
>
> So far as I can tell, there are three patches in flight here:
>
Yes, thats right.
> * replication slot IO lwlocks
> * ability of extensions to request tranches dynamically
> * PGPROC
>
> The first one hasn't been reviewed at all, but the
So far as I can tell, there are three patches in flight here:
* replication slot IO lwlocks
* ability of extensions to request tranches dynamically
* PGPROC
The first one hasn't been reviewed at all, but the other two have seen a
bit of discussion and evolution. Is anyone doing any more reviewin
On Tue, Jan 5, 2016 at 7:24 PM, Jesper Pedersen
wrote:
>
> On 01/05/2016 08:04 AM, Amit Kapila wrote:
>>
>> I am not aware of such cases, however the reason I have kept it was for
>> backward-compatability, but now I have removed it in the attached patch.
>>
>> Apart from that, I have updated the
On Tue, Jan 5, 2016 at 04:53:26PM +0100, Andres Freund wrote:
> On 2016-01-05 10:48:43 -0500, Bruce Momjian wrote:
> > On Tue, Jan 5, 2016 at 04:42:24PM +0100, Andres Freund wrote:
> > > On 2016-01-05 10:40:13 -0500, Bruce Momjian wrote:
> > > > On Tue, Jan 5, 2016 at 04:31:15PM +0100, Andres Fr
On Tue, Jan 5, 2016 at 04:42:24PM +0100, Andres Freund wrote:
> On 2016-01-05 10:40:13 -0500, Bruce Momjian wrote:
> > On Tue, Jan 5, 2016 at 04:31:15PM +0100, Andres Freund wrote:
> > > On 2016-01-05 10:28:25 -0500, Bruce Momjian wrote:
> > > Yes? But it's ok sizewise on the common platforms?
>
On 2016-01-05 10:48:43 -0500, Bruce Momjian wrote:
> On Tue, Jan 5, 2016 at 04:42:24PM +0100, Andres Freund wrote:
> > On 2016-01-05 10:40:13 -0500, Bruce Momjian wrote:
> > > On Tue, Jan 5, 2016 at 04:31:15PM +0100, Andres Freund wrote:
> > > > On 2016-01-05 10:28:25 -0500, Bruce Momjian wrote:
On 2016-01-05 10:40:13 -0500, Bruce Momjian wrote:
> On Tue, Jan 5, 2016 at 04:31:15PM +0100, Andres Freund wrote:
> > On 2016-01-05 10:28:25 -0500, Bruce Momjian wrote:
> > Yes? But it's ok sizewise on the common platforms?
>
> What is the uncommon part? I guess I missed that.
http://archives.
On Tue, Jan 5, 2016 at 04:31:15PM +0100, Andres Freund wrote:
> On 2016-01-05 10:28:25 -0500, Bruce Momjian wrote:
> > On Sun, Dec 13, 2015 at 12:35:34PM +0100, Andres Freund wrote:
> > > > > One thing to call out is that an "oversized" s_lock can now make
> > > > > BufferDesc exceed 64 bytes, rig
On 2016-01-05 10:28:25 -0500, Bruce Momjian wrote:
> On Sun, Dec 13, 2015 at 12:35:34PM +0100, Andres Freund wrote:
> > > > One thing to call out is that an "oversized" s_lock can now make
> > > > BufferDesc exceed 64 bytes, right now that's just the case when it's
> > > > larger than 4 bytes. I'm
On Sun, Dec 13, 2015 at 12:35:34PM +0100, Andres Freund wrote:
> > > One thing to call out is that an "oversized" s_lock can now make
> > > BufferDesc exceed 64 bytes, right now that's just the case when it's
> > > larger than 4 bytes. I'm not sure if that's cause for real concern,
> > > given tha
On Tue, Jan 5, 2016 at 8:54 AM, Jesper Pedersen
wrote:
> LWLock *
> GetLWLockAddinTranche(const char *tranche_name)
>
> would be nicer to work with for extensions IMHO. Not likely worth the
> trouble though.
That change would be easy to make, but would tend to make performance
worse for anyone wh
On 01/05/2016 08:04 AM, Amit Kapila wrote:
I am not aware of such cases, however the reason I have kept it was for
backward-compatability, but now I have removed it in the attached patch.
Apart from that, I have updated the docs to reflect the changes related
to new API's.
xfunc.sgml:
+
On Mon, Jan 4, 2016 at 8:28 PM, Robert Haas wrote:
>
> On Mon, Jan 4, 2016 at 1:20 AM, Amit Kapila
wrote:
> > On Mon, Jan 4, 2016 at 4:49 AM, Robert Haas
wrote:
> >> On Thu, Dec 31, 2015 at 3:36 AM, Amit Kapila
> >> wrote:
> >> > LWLock *LWLockAssignFromTranche(const char *tranche_name) will
>
On Mon, Jan 4, 2016 at 1:20 AM, Amit Kapila wrote:
> On Mon, Jan 4, 2016 at 4:49 AM, Robert Haas wrote:
>> On Thu, Dec 31, 2015 at 3:36 AM, Amit Kapila
>> wrote:
>> > LWLock *LWLockAssignFromTranche(const char *tranche_name) will
>> > assign a lock for the specified tranche. This also ensures t
On Mon, Jan 4, 2016 at 4:49 AM, Robert Haas wrote:
>
> On Thu, Dec 31, 2015 at 3:36 AM, Amit Kapila
wrote:
> > LWLock *LWLockAssignFromTranche(const char *tranche_name) will
> > assign a lock for the specified tranche. This also ensures that no
> > more than requested number of LWLocks can be as
On Thu, Dec 31, 2015 at 3:36 AM, Amit Kapila wrote:
> Going further on this work, I have written a patch for separating the
> tranches for extensions. The basic idea is to expose two new API's,
> first to request a new tranche and second to assign a lock from that
> tranche.
> RequestAddinLWLockT
On Thu, Dec 31, 2015 at 7:42 PM, Jesper Pedersen wrote:
> On 12/31/2015 06:36 AM, Amit Kapila wrote:
>
>> Going further on this work, I have written a patch for separating the
>> tranches for extensions. The basic idea is to expose two new API's,
>> first to request a new tranche and second to a
On 12/31/2015 06:36 AM, Amit Kapila wrote:
Going further on this work, I have written a patch for separating the
tranches for extensions. The basic idea is to expose two new API's,
first to request a new tranche and second to assign a lock from that
tranche.
RequestAddinLWLockTranche(const char
On Thu, Dec 31, 2015 at 5:06 PM, Amit Kapila
wrote:
>
> On Tue, Dec 29, 2015 at 2:26 PM, Amit Kapila
wrote:
>>
>> On Wed, Dec 16, 2015 at 12:26 AM, Robert Haas
wrote:
>> >
>> >
I have moved this patch to new CF as the work is still in
progress.
With Regards,
Amit Kapila.
EnterpriseDB: http://w
On Tue, Dec 29, 2015 at 2:26 PM, Amit Kapila
wrote:
> On Wed, Dec 16, 2015 at 12:26 AM, Robert Haas
> wrote:
> >
> >
> > In terms of this project overall, NumLWLocks() now knows about only
> > four categories of stuff: fixed lwlocks, backend locks (proc.c),
> > replication slot locks, and locks
On Mon, Dec 28, 2015 at 3:17 AM, Amit Kapila wrote:
> 2.
> @@ -213,6 +213,7 @@ typedef enum BuiltinTrancheIds
> LWTRANCHE_WAL_INSERT,
> LWTRANCHE_BUFFER_CONTENT,
> LWTRANCHE_BUFFER_IO_IN_PROGRESS,
> + LWTRANCHE_PROC,
> LWTRANCHE_FIRST_USER_DEFINED
> } BuiltinTrancheIds;
>
> Other tranchei
On Wed, Dec 16, 2015 at 12:26 AM, Robert Haas wrote:
>
>
> In terms of this project overall, NumLWLocks() now knows about only
> four categories of stuff: fixed lwlocks, backend locks (proc.c),
> replication slot locks, and locks needed by extensions. I think it'd
> probably be fine to move the b
On Thu, Dec 24, 2015 at 5:50 PM, Ildus Kurbangaliev <
i.kurbangal...@postgrespro.ru> wrote:
>
> On Tue, 15 Dec 2015 13:56:30 -0500
> Robert Haas wrote:
>
> > On Sun, Dec 13, 2015 at 6:35 AM, and...@anarazel.de
> > wrote:
> > > On 2015-12-12 21:15:52 -0500, Robert Haas wrote:
> > >> On Sat, Dec 12
On Tue, 15 Dec 2015 13:56:30 -0500
Robert Haas wrote:
> On Sun, Dec 13, 2015 at 6:35 AM, and...@anarazel.de
> wrote:
> > On 2015-12-12 21:15:52 -0500, Robert Haas wrote:
> >> On Sat, Dec 12, 2015 at 1:17 PM, and...@anarazel.de
> >> wrote:
> >> > Here's two patches doing that. The first is a
On Sun, Dec 13, 2015 at 6:35 AM, and...@anarazel.de wrote:
> On 2015-12-12 21:15:52 -0500, Robert Haas wrote:
>> On Sat, Dec 12, 2015 at 1:17 PM, and...@anarazel.de
>> wrote:
>> > Here's two patches doing that. The first is an adaption of your
>> > constants patch, using an enum and also convert
On 2015-12-12 21:15:52 -0500, Robert Haas wrote:
> On Sat, Dec 12, 2015 at 1:17 PM, and...@anarazel.de
> wrote:
> > Here's two patches doing that. The first is an adaption of your
> > constants patch, using an enum and also converting xlog.c's locks. The
> > second is the separation into distinct
On Sat, Dec 12, 2015 at 1:17 PM, and...@anarazel.de wrote:
> On 2015-11-15 16:24:24 -0500, Robert Haas wrote:
>> I think what we should do about the buffer locks is polish up this
>> patch and get it applied:
>>
>> http://www.postgresql.org/message-id/20150907175909.gd5...@alap3.anarazel.de
>>
>>
On 2015-11-15 16:24:24 -0500, Robert Haas wrote:
> I think what we should do about the buffer locks is polish up this
> patch and get it applied:
>
> http://www.postgresql.org/message-id/20150907175909.gd5...@alap3.anarazel.de
>
> I think it needs to be adapted to use predefined constants for the
On Mon, 23 Nov 2015 12:12:23 -0500
Robert Haas wrote:
> On Fri, Nov 20, 2015 at 6:53 AM, Ildus Kurbangaliev
> wrote:
> > We keep limited number of LWLocks in base shared memory, why not
> > keep their thanches in shared memory too? Other tranches can be in
> > local memory, we just have to save
On Fri, Nov 20, 2015 at 6:53 AM, Ildus Kurbangaliev
wrote:
> We keep limited number of LWLocks in base shared memory, why not keep
> their thanches in shared memory too? Other tranches can be in local
> memory, we just have to save somewhere highest id of these tranches.
I just don't see it buyin
On Thu, 19 Nov 2015 11:09:38 -0500
Robert Haas wrote:
> On Thu, Nov 19, 2015 at 9:04 AM, Ildus Kurbangaliev
> wrote:
> > The moving base tranches to shared memory has been discussed many
> > times. The point is using them later in pg_stat_activity and other
> > monitoring views.
>
> I'm not i
On Thu, Nov 19, 2015 at 4:26 PM, Andres Freund wrote:
> On 2015-11-19 14:58:05 -0500, Robert Haas wrote:
>> On Thu, Nov 19, 2015 at 11:30 AM, Andres Freund wrote:
>> > It's really not particularly convenient to allocate tranches right
>> > now. You have to store at least the identifier in shared
On 2015-11-19 14:58:05 -0500, Robert Haas wrote:
> On Thu, Nov 19, 2015 at 11:30 AM, Andres Freund wrote:
> > It's really not particularly convenient to allocate tranches right
> > now. You have to store at least the identifier in shared memory and
> > then redo the registration in each process. O
On Thu, Nov 19, 2015 at 11:30 AM, Andres Freund wrote:
> On November 19, 2015 8:09:38 AM PST, Robert Haas
> wrote:
>>On Thu, Nov 19, 2015 at 9:04 AM, Ildus Kurbangaliev
>> wrote:
>>> The moving base tranches to shared memory has been discussed many
>>times.
>>> The point is using them later in p
On November 19, 2015 8:09:38 AM PST, Robert Haas wrote:
>On Thu, Nov 19, 2015 at 9:04 AM, Ildus Kurbangaliev
> wrote:
>> The moving base tranches to shared memory has been discussed many
>times.
>> The point is using them later in pg_stat_activity and other
>monitoring
>> views.
>
>I'm not in agre
On Thu, Nov 19, 2015 at 9:04 AM, Ildus Kurbangaliev
wrote:
> The moving base tranches to shared memory has been discussed many times.
> The point is using them later in pg_stat_activity and other monitoring
> views.
I'm not in agreement with this idea. Actually, I'd prefer that the
tranches live
Thank you for the review. I've made changes according to your comments.
I don't stick on current names in the patch.
I've removed all unnecerrary indirections, and added cache aligning
to LWLock arrays.
On Tue, 17 Nov 2015 19:36:13 +0100
"and...@anarazel.de" wrote:
> On 2015-11-17 14:14:50 +030
On 2015-11-17 14:14:50 +0300, Ildus Kurbangaliev wrote:
> 1) We can avoid constants, and use a standard steps for tranches
> creation.
The constants are actually a bit useful, to easily determine
builtin/non-builtin stuff.
> 2) We have only one global variable (BufferCtl)
Don't see the advantage
On Mon, 16 Nov 2015 18:55:55 -0500
Robert Haas wrote:
> On Mon, Nov 16, 2015 at 7:32 AM, Ildus Kurbangaliev
> wrote:
> > What if just create a control struct in shared memory like in other places?
> > BufferDescriptors
> > and BufferBlocks can be kept there along with tranches definitions
> > a
On Mon, Nov 16, 2015 at 7:32 AM, Ildus Kurbangaliev
wrote:
> What if just create a control struct in shared memory like in other places?
> BufferDescriptors
> and BufferBlocks can be kept there along with tranches definitions
> and lwlocks. Buffer locks that are located in MainLWLockArray by offs
On Sun, Nov 15, 2015 at 7:20 PM, and...@anarazel.de wrote:
>> /*
>> + * We reserve a few predefined tranche IDs. These values will never be
>> + * returned by LWLockNewTrancheId.
>> + */
>> +#define LWTRANCHE_MAIN 0
>> +#define LWTRANCHE_BUFFER_CONTE
On Sun, 15 Nov 2015 16:24:24 -0500
Robert Haas wrote:
> > I have some questions about next steps on other tranches.
> > First of all, I think we can have two API calls, something like:
> >
> > 1) LWLockRequestTranche(char *tranche_name, int locks_count)
> > 2) LWLockGetTranche(char *tranche_name)
On 2015-11-15 16:24:24 -0500, Robert Haas wrote:
> I think it needs to be adapted to use predefined constants for the
> tranche IDs instead of hardcoded values, maybe based on the attached
> tranche-constants.patch.
Yea, that part is clearly not ok. Let me look at the patch.
> Also, I think we sh
On Fri, Nov 13, 2015 at 11:37 AM, Ildus Kurbangaliev
wrote:
> Thanks! That's very inspiring.
Cool. It was great work; I am very happy with how it turned out.
> I have some questions about next steps on other tranches.
> First of all, I think we can have two API calls, something like:
>
> 1) LWL
On Thu, 12 Nov 2015 14:59:59 -0500
Robert Haas wrote:
> On Wed, Nov 11, 2015 at 6:50 AM, Ildus Kurbangaliev
> wrote:
> > Attached a new version of the patch that moves SLRU tranches and LWLocks to
> > SLRU control structs.
> >
> > `buffer_locks` field now contains LWLocks itself, so we have some
On Wed, Nov 11, 2015 at 6:50 AM, Ildus Kurbangaliev
wrote:
> Attached a new version of the patch that moves SLRU tranches and LWLocks to
> SLRU control structs.
>
> `buffer_locks` field now contains LWLocks itself, so we have some economy of
> the memory here. `pstrdup` removed in SimpleLruInit. I
On 11/09/2015 10:32 PM, Ildus Kurbangaliev wrote:
On Nov 9, 2015, at 7:56 PM, Alvaro Herrera wrote:
Ildus Kurbangaliev wrote:
Thanks for the review. I've attached a new version of SLRU patch. I've
removed add_postfix and fixed EXEC_BACKEND case.
Thanks.
Please do not use "committs" in co
> On Nov 9, 2015, at 7:56 PM, Alvaro Herrera wrote:
>
> Ildus Kurbangaliev wrote:
>
>> Thanks for the review. I've attached a new version of SLRU patch. I've
>> removed add_postfix and fixed EXEC_BACKEND case.
>
> Thanks.
>
> Please do not use "committs" in commit_ts.c; people didn't like the
Ildus Kurbangaliev wrote:
> Thanks for the review. I've attached a new version of SLRU patch. I've
> removed add_postfix and fixed EXEC_BACKEND case.
Thanks.
Please do not use "committs" in commit_ts.c; people didn't like the
abbreviated name without the underscore. But then, why are we
abbrevi
On 11/06/2015 08:53 PM, Robert Haas wrote:
On Fri, Nov 6, 2015 at 6:27 AM, Ildus Kurbangaliev
wrote:
There is a patch that splits SLRU LWLocks to separate tranches and
moves them to SLRU Ctl. It does some work from the main patch from
this thread, but can be commited separately. It also simplif
On Fri, Nov 6, 2015 at 6:27 AM, Ildus Kurbangaliev
wrote:
> There is a patch that splits SLRU LWLocks to separate tranches and
> moves them to SLRU Ctl. It does some work from the main patch from
> this thread, but can be commited separately. It also simplifies
> lwlock.c.
Thanks. I like the dir
On Wed, 23 Sep 2015 11:46:00 -0400
Robert Haas wrote:
> On Wed, Sep 23, 2015 at 11:22 AM, Alvaro Herrera
> wrote:
> > Robert Haas wrote:
> >> On Tue, Sep 22, 2015 at 5:16 AM, Ildus Kurbangaliev
> >> wrote:
> >> > Yes, probably.
> >> > I'm going to change API calls as you suggested earlier.
On Wed, Sep 23, 2015 at 11:22 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Tue, Sep 22, 2015 at 5:16 AM, Ildus Kurbangaliev
>> wrote:
>> > Yes, probably.
>> > I'm going to change API calls as you suggested earlier.
>> > How you do think the tranches registration after initialization shoul
Robert Haas wrote:
> On Tue, Sep 22, 2015 at 5:16 AM, Ildus Kurbangaliev
> wrote:
> > Yes, probably.
> > I'm going to change API calls as you suggested earlier.
> > How you do think the tranches registration after initialization should
> > look like?
>
> I don't see any need to change anything th
On Tue, Sep 22, 2015 at 5:16 AM, Ildus Kurbangaliev
wrote:
> Yes, probably.
> I'm going to change API calls as you suggested earlier.
> How you do think the tranches registration after initialization should
> look like?
I don't see any need to change anything there. The idea there is that
an ext
On Tue, 15 Sep 2015 14:39:51 -0400
Robert Haas wrote:
> On Tue, Sep 15, 2015 at 12:44 PM, Ildus Kurbangaliev
> wrote:
> > On Mon, 14 Sep 2015 06:32:22 -0400
> > Robert Haas wrote:
> >
> >> On Sun, Sep 13, 2015 at 5:05 PM, Ildus Kurbangaliev
> >> wrote:
> >> > Yes, that is because I tried to go
On Tue, Sep 15, 2015 at 2:44 PM, and...@anarazel.de wrote:
> On 2015-09-15 14:39:51 -0400, Robert Haas wrote:
>> We could, but since that would be strictly more annoying and less
>> flexible than what we've already got, why would we?
>
> I don't find the current approach of having to define tranch
On 2015-09-15 14:39:51 -0400, Robert Haas wrote:
> We could, but since that would be strictly more annoying and less
> flexible than what we've already got, why would we?
I don't find the current approach of having to define tranches in every
backend all that convenient. It also completely breaks
On Tue, Sep 15, 2015 at 12:44 PM, Ildus Kurbangaliev
wrote:
> On Mon, 14 Sep 2015 06:32:22 -0400
> Robert Haas wrote:
>
>> On Sun, Sep 13, 2015 at 5:05 PM, Ildus Kurbangaliev
>> wrote:
>> > Yes, that is because I tried to go with current convention working
>> > with shmem in Postgres (there are
On Mon, 14 Sep 2015 06:32:22 -0400
Robert Haas wrote:
> On Sun, Sep 13, 2015 at 5:05 PM, Ildus Kurbangaliev
> wrote:
> > Yes, that is because I tried to go with current convention working
> > with shmem in Postgres (there are one function that returns the
> > size and others that initialize that
On Sun, Sep 13, 2015 at 5:05 PM, Ildus Kurbangaliev
wrote:
> Yes, that is because I tried to go with current convention working with
> shmem in Postgres (there are one function that returns the size and
> others that initialize that memory). But I like your suggestion about
> API functions, in tha
> On Sep 13, 2015, at 11:32 PM, Robert Haas wrote:
>
> On Sun, Sep 13, 2015 at 12:43 PM, Ildus Kurbangaliev
> wrote:
>> Added changes related to the latest master (for individual LWLocks
>> definitions)
>
> If I haven't said this clearly enough already, I'm not OK with
> changing the tranche n
On Sun, Sep 13, 2015 at 12:43 PM, Ildus Kurbangaliev
wrote:
> Added changes related to the latest master (for individual LWLocks
> definitions)
If I haven't said this clearly enough already, I'm not OK with
changing the tranche name from char * to a fixed-size character array.
Nor am I OK with li
Added changes related to the latest master (for individual LWLocks
definitions)
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
lwlocks_refactor_v3.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Sun, 6 Sep 2015 23:18:02 +0200
"and...@anarazel.de" wrote:
> On 2015-09-06 22:57:04 +0300, Ildus Kurbangaliev wrote:
> > Ok, I've kept only one tranche for individual LWLocks
>
> But you've added the lock names as a statically sized array to all
> tranches? Why not just a pointer to an array
On 2015-09-06 22:57:04 +0300, Ildus Kurbangaliev wrote:
> Ok, I've kept only one tranche for individual LWLocks
But you've added the lock names as a statically sized array to all
tranches? Why not just a pointer to an array that's either NULL ('not
individualy named locks') or appropriately sized?
On Sep 6, 2015, at 2:36 PM, and...@anarazel.de wrote:On 2015-09-05 12:48:12 +0300, Ildus Kurbangaliev wrote:Another parts require a some discussion so I didn't touch them yet.At this point I don't see any point in further review until these areaddressed.The idea to create an individual tranches for
1 - 100 of 102 matches
Mail list logo
