Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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 --

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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:

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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 =

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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,

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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 >> >> +

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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,

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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,

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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 > > +

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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,

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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: +

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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:

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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? >

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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.

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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.

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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 >

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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 >

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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 > }

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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 >

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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 > >>

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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 >> >

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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: >> >>

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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,

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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)

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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. > > > >

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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.

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

> 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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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: > >>

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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 >

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

> 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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

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

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

Hi, 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 are addressed. > The idea to create an individual tranches for individual LWLocks have > come from