【memory barrier】Should we update the README.barrier description.
Hi When I read the introduction of Weaknesses of Memory Barriers in README.barrier, the following maybe out-of-date now. Even very simple write operations often require additional synchronization. For example, it's not safe for multiple writers to simultaneously execute this code (supposing x is a pointer into shared memory): x->foo++; Although this may compile down to a single machine-language instruction, the CPU will execute that instruction by reading the current value of foo, adding one to it, and then storing the result back to the original address. If two CPUs try to do this simultaneously, both may do their reads before either one does their writes. *Eventually we might be able to use an atomic fetch-and-add instruction for this specific case on architectures that support it, but we can't rely on that being available everywhere, and we currently have no support for it at all. Use a lock.* Now, the postgres has support atomic operation and use it, in some cases we have not use the lock. -- Sent from: https://www.postgresql-archive.org/PostgreSQL-docs-f2165602.html
Re: Logical replication subscription owner
On Fri, 8 May 2020 at 03:03, Kyotaro Horiguchi wrote: > > A user can start physical replication without needing CONNECT on any > database if it has REPLICATION attribute. That means any user that > is allowed logical replication on a specific database (or even no > databases) can replicate the whole cluster using physical replication. > I don't think it is a proper behavior from the security perspective. > > Physical replication has a special entry in pg_hba.conf, hence, I don't think you need CONNECT on all databases. However, logical replication uses the same entry from a regular connection and I concur with Michael and Stephen that we should have LOGIN and REPLICATION privileges in those cases. If we drop the LOGIN requirement for logical replication, it means that a simple NOLOGIN won't be sufficient to block a certain role to execute queries because "replication=database" could be used to bypass it. Physical replication can't execute queries but logical replication can. IMO REPLICATION is an additional capability and it is not a superset that contains LOGIN. I prefer a fine-grained control. In sections 26.2.5.1 and 30.7, LOGIN are documented accordingly. I'm +0.5 to the idea of adding a WARNING when you create/alter a role that has REPLICATION but not LOGIN. -- Euler Taveira http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Logical replication subscription owner
Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> ISTM those statements are contradictory. The two privileges could >> only be called orthogonal if it's possible to make use of one without >> having the other. As things stand, REPLICATION without LOGIN is an >> entirely useless setting. > Allowing a login to the system by a role that doesn't have the LOGIN > privilege isn't sensible though. The fundamental issue here is whether a replication connection is a "login". I'd argue that it is not; "login" ought to mean a normal SQL connection. I realize that a replication connection can issue SQL commands (which, as I recall, Robert has blasted as a crappy design --- and I agree). But it's already the case that a replication connection has much greater privileges than plain SQL, so I don't think that that aspect ought to compel us to design the privilege bits as they are set up now. If you think that LOGIN should be required to issue SQL commands, then shouldn't doing SET ROLE to a non-LOGIN role disable your ability to issue SQL? > Perhaps a middle ground would be to set LOGIN on a role when REPLICATION > is set on it, if it's not already set (maybe with a NOTICE or WARNING or > such saying "also enabling LOGIN for role X", or maybe not if people > really think it should be obvious). It seems to me that there's value in having a role that can only connect for replication purposes and not as a regular SQL user. The existing definition doesn't support that, and the rather silly kluge you're proposing doesn't fix it. regards, tom lane
Re: Logical replication subscription owner
Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Michael Paquier writes: > > Not to make the life of everybody more complicated here, but I don't > > agree. LOGIN and REPLICATION are in my opinion completely orthogonal > > and it sounds more natural IMO that a REPLICATION user should be able > > to log into the server only if it has LOGIN defined. > > ISTM those statements are contradictory. The two privileges could > only be called orthogonal if it's possible to make use of one without > having the other. As things stand, REPLICATION without LOGIN is an > entirely useless setting. Allowing a login to the system by a role that doesn't have the LOGIN privilege isn't sensible though. Perhaps a middle ground would be to set LOGIN on a role when REPLICATION is set on it, if it's not already set (maybe with a NOTICE or WARNING or such saying "also enabling LOGIN for role X", or maybe not if people really think it should be obvious). I don't think taking away login should take away replication though as maybe there's some reason why someone would want that, nor should we take away login if replication is taken away, this would strictly just be a change for when REPLICATION is added to a role that doesn't have LOGIN already. Thanks, Stephen signature.asc Description: PGP signature
Re: Another modest proposal for docs formatting: catalog descriptions
Fabien COELHO writes: > Possibly. I'm a little at odds with Type not being above types, but far on > the left, so that you cannot really "see" that it is about the format, Yeah, agreed. We can adjust the space in the header independently of what's in the table entries, so it'd be possible to put more space between "Column" and "Type" ... but I'm not sure if that would fix it. > If I can suggest more adjustements, maybe the description margin is a too > much, I'd propose reduce it to about 3 chars wide. Obviously any aesthetic > opinion is by definition subjective and prone to differ from one person to > the next… This is more Jonathan's department than mine, but I personally prefer more indentation to less --- you want the column names to stick out so you can find them. Anyway, the present indentation is (it looks like) the same as we are using in s, which this layout is based on. regards, tom lane
Re: Another modest proposal for docs formatting: catalog descriptions
Hello Tom, Here's a more fully fleshed out draft for this, with stylesheet markup to get extra space around the column type names. I find this added spacing awkward, espacially as attribute names are always one word anyway. I prefer the non spaced approach. It's certainly arguable that that look is too heavy-handed. In the attached, I knocked down the extra space from 1em to 0.25em, which makes it quite a bit subtler --- are you any happier with this? Yes, definitely. BTW, I don't think it's very accurate that "attribute names are always one word" --- see the second attachment. Indeed. Here if anything I'm wanting a little more space. I'm fine with 0.25em which allows some breathing without looking awkward. Maybe a little more would still be okay, but not much more. If spacing is discussed, should the layout rather try to align type information, eg: I thought about that, but it seems extremely close to some of the earlier function-table layouts that were so widely panned. The SGML source would have to be a lot uglier too, probably with explicit use of spanspec's on every row. Hmmm, that's the kind of things I was afraid of. It could be done no doubt, but I think people would not see it as an improvement. Possibly. I'm a little at odds with Type not being above types, but far on the left, so that you cannot really "see" that it is about the format, especially with long attribute names: Column Type Description quite_a_long_attribute and_its_type ... The horizontal distance between "Type" and "and_its_type" is so wide as to hide the clue that the former is describing the later. But maybe aligning would be too ugly. If I can suggest more adjustements, maybe the description margin is a too much, I'd propose reduce it to about 3 chars wide. Obviously any aesthetic opinion is by definition subjective and prone to differ from one person to the next… -- Fabien.
Re: Logical replication subscription owner
Michael Paquier writes: > Not to make the life of everybody more complicated here, but I don't > agree. LOGIN and REPLICATION are in my opinion completely orthogonal > and it sounds more natural IMO that a REPLICATION user should be able > to log into the server only if it has LOGIN defined. ISTM those statements are contradictory. The two privileges could only be called orthogonal if it's possible to make use of one without having the other. As things stand, REPLICATION without LOGIN is an entirely useless setting. regards, tom lane
Re: Logical replication subscription owner
On Fri, May 08, 2020 at 03:03:26PM +0900, Kyotaro Horiguchi wrote: > At Fri, 8 May 2020 01:02:11 -0400, Alvaro Herrera > wrote in >> On 2020-May-07, Tom Lane wrote: >>> FWIW, I would argue that LOGIN permits logging in on a regular SQL >>> connection, while REPLICATION should permit logging in on a >>> replication connection, and there's no reason for either to depend on >>> or require the other. >> >> I agree with this. > > I agree, too. Anyway, it is unreasonable that a user is banned for > the lack of replication-attribute after a successful *replication* > login. Not to make the life of everybody more complicated here, but I don't agree. LOGIN and REPLICATION are in my opinion completely orthogonal and it sounds more natural IMO that a REPLICATION user should be able to log into the server only if it has LOGIN defined. -- Michael signature.asc Description: PGP signature
Re: Another modest proposal for docs formatting: catalog descriptions
Hello Tom, Here's a more fully fleshed out draft for this, with stylesheet markup to get extra space around the column type names. I find this added spacing awkward, espacially as attribute names are always one word anyway. I prefer the non spaced approach. If spacing is discussed, should the layout rather try to align type information, eg: attributetype description --- foo bla this does this and that ... and here is an example about it --- foo-foo-foo bla-bla whatever bla bla blah bla foo foo foo ... and stuff I'm not sure how achievable it is from a xml & processing point of view, and how desirable it is, I'm just throwing it for consideration. -- Fabien.
