Re: Code of Conduct plan
On Fri, Sep 14, 2018 at 11:10 AM, Dave Page wrote: > That wording has been in the published draft for 18 months, and noone > objected to it that I'm aware of. There will always be people who don't like > some of the wording, much as there are often people who disagree with the > way a patch to the code is written. Sooner or later though, the general > consensus prevails and we have to move on, otherwise nothing will ever get > completed. It's not clear to me that there IS a general consensus here. It looks to me like the unelected core team got together and decided to impose a vaguely-worded code of conduct on a vaguely-defined group of people covering not only their work on PostgreSQL but also their entire life. It is not difficult to imagine that someone's private life might include "behavior that may bring the PostgreSQL project into disrepute." However, I also don't think it matters very much. The Code of Conduct Committee is going to consist of small number of people -- at least four, perhaps a few more. But there are hundreds of people involved on the PostgreSQL mailing lists, maybe thousands. If the Code of Conduct Committee, or the core team, believes that it can impose on a very large group of people, all of whom are volunteers, some set of rules with which they don't agree, it's probably going to find out pretty quickly that it is mistaken. If people from that large group get banned for behavior which is perceived by other members of that large group to be legitimate, then there will be a ferocious backlash. Nobody wants to see people who are willing to contribute driven away from the project, and anyone we drive away without a really good reason will find some other project that welcomes their participation. So the only thing that the Code of Conduct Committee is likely to be able to do in practice is admonish people to be nicer (which is probably a good thing) and punish really egregious conduct, especially when committed by people who aren't involved enough that their absence will be keenly felt. In practice, therefore, democracy is going to win out. That's both good and bad. It's good because nobody wants a CoC witch-hunt, and it's bad because there's probably some behavior which legitimately deserves censure and will escape it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: Code of Conduct plan
On Fri, Sep 14, 2018 at 4:17 PM, Tom Lane wrote: > There's been quite a lot of input, from quite a lot of people, dating > back at least as far as a well-attended session at PGCon 2016. I find > it quite upsetting to hear accusations that core is imposing this out > of nowhere. From my perspective, we're responding to a real need > voiced by other people, not so much by us. Yeah, but there's a difference between input and agreement. I don't think there's been a mailing list thread anywhere at any time where a clear majority of the people on that thread supported the idea of a code of conduct. I don't think that question has even been put. I don't think there's ever been a developer meeting where by a show of hands the idea of a CoC, much less the specific text, got a clear majority. I don't think that any attempt has been made to do that, either. Core is (thankfully) not usually given to imposing new rules on the community; we normally operate by consensus. Why this specific instance is an exception, as it certainly seems to be, is unclear to me. To be clear, I'm not saying that no harassment occurs in our community. I suspect women get harassed at our conferences. I know of only one specific incident that made me uncomfortable, and that was quite a few years ago and the woman in question laughed it off when I asked her if there was a problem, but I have heard rumors of other things on occasion, and I just wouldn't be too surprised if we're not all as nice in private as we pretend to be in public. And on the other hand, I think that mailing list discussions step over the line to harassment from time to time even though that's in full public view. Regrettably, you and I have both been guilty of that from time to time, as have many others. I know that I, personally, have been trying to be a lot more careful about the way I phrase criticism in recent years; I hope that has been noticeable, but I only see it from my own perspective, so I don't know. Nonwithstanding, I would like to see us, as a group, do better. We should tolerate less bad behavior in ourselves and in others, and however good or bad we are today as people, we should try to be better people. Whether or not the code of conduct plan that the core committee has decided to implement is likely to move us in that direction remains unclear to me. I can't say I'm very impressed by the way the process has been carried out up to this point; hopefully it will work out for the best all the same. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE
On Mon, Jul 8, 2024 at 6:08 PM Tom Lane wrote: > >> Hmm, if that check doesn't require INHERIT TRUE I'd say it's > >> a bug. > > > The code doesn't support that claim. > > That doesn't make it not a bug. Robert, what do you think? If this > is correct behavior, why is it correct? Correct is debatable, but it's definitely intentional. I didn't think that referencing a group in pg_hba.conf constituted either (a) the group inheriting the privileges of the role -- which would make it governed by INHERIT -- or (b) the group being able to SET ROLE to the role -- which would make it controlled by SET. I guess you're arguing for INHERIT which is probably the more logical of the two, but I'm not really sold on it. I think the pg_hba.conf matching is just asking whether X is in set S, not whether S has the privileges of X. For contemporaneous evidence of my thinking on this subject see https://www.postgresql.org/message-id/ca+tgmobheyynw9vrhvolvd8odspbjuu9cbk6tms6owd70hf...@mail.gmail.com particularly the paragraph that starts with "That's it". -- Robert Haas EDB: http://www.enterprisedb.com
Re: Backward compat issue with v16 around ROLEs
n. Prior to v16, this principle applied to grants of everything except role; now, it also applies to role grants. Whether that's correct is an arguable point, but it seems very strange to me to argue that role grants should work differently from every other type of grant in the system, and it does have some nice properties. But that means that the anti-circularity provisions that we apply in other cases also need to be applied to roles. Otherwise, in your example, if the ddevienne role were removed, dd_admin and dd_owner would retain the ability to administer each other even though that grant would now have no source. That administrative authority would have come from ddevienne originally but, by making a set of circular grants, dd_admin and dd_owner could arrange to retain that privilege even after ddevienne was gone. We now forbid that just as we do for other object types. However, it seems like we might be able to fix this by just making the code smarter. Maybe there's a problem that I'm not seeing, but if the boss grants a privilege to alice and alice grants it to bob and bob grants it back to alice and then the boss revokes the privilege, why can't we figure out that alice no longer has a source for that privilege *aside from the one involved in the cycle* and undo the reciprocal grants that bob and alice made to each other? Right now I believe we just ask "is the number of sources that alices has for this privilege still greater than zero" which only works if there are no cycles but maybe we can do better. We'd probably need to think carefully about concurrency issues, though, and whether pg_dump is smart enough to handle this case. Also, there are separate code paths for role grants and non-role grants, and since I went to a lot of trouble to make them work the same way, I'd really prefer it if we didn't go back to having them work differently... -- Robert Haas EDB: http://www.enterprisedb.com
Re: ERROR: too many dynamic shared memory segments
On Tue, Nov 28, 2017 at 2:32 AM, Dilip Kumar wrote: > I think BitmapHeapScan check whether dsa is valid or not if DSA is not > valid then it should assume it's non-parallel plan. > > Attached patch should fix the issue. So, create the pstate and then pretend we didn't? Why not just avoid creating it in the first place, like this? I haven't checked whether this fixes the bug, but if it does, we can avoid introducing an extra branch in BitmapHeapNext. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company no-pstate.patch Description: Binary data
Re: ERROR: too many dynamic shared memory segments
On Tue, Nov 28, 2017 at 9:45 AM, Dilip Kumar wrote:
>> I haven't checked whether this fixes the bug, but if it does, we can
>> avoid introducing an extra branch in BitmapHeapNext.
>
> With my test it's fixing the problem.
I tested it some more and found that, for me, it PARTIALLY fixes the
problem. I tested like this:
--- a/src/backend/access/transam/parallel.c
+++ b/src/backend/access/transam/parallel.c
@@ -279,7 +279,7 @@ InitializeParallelDSM(ParallelContext *pcxt)
* parallelism than to fail outright.
*/
segsize = shm_toc_estimate(&pcxt->estimator);
-if (pcxt->nworkers > 0)
+if (pcxt->nworkers > 0 && false)
pcxt->seg = dsm_create(segsize, DSM_CREATE_NULL_IF_MAXSEGMENTS);
if (pcxt->seg != NULL)
pcxt->toc = shm_toc_create(PARALLEL_MAGIC,
That turned out to produce more than one problem. I find that the
select_parallel test then fails like this:
ERROR: could not find key 18446744073709486082 in shm TOC at 0x10be98040
The fix for that problem seems to be:
--- a/src/backend/access/transam/parallel.c
+++ b/src/backend/access/transam/parallel.c
@@ -430,7 +430,8 @@ ReinitializeParallelDSM(ParallelContext *pcxt)
/* Recreate error queues. */
error_queue_space =
-shm_toc_lookup(pcxt->toc, PARALLEL_KEY_ERROR_QUEUE, false);
+shm_toc_lookup(pcxt->toc, PARALLEL_KEY_ERROR_QUEUE, true);
+Assert(pcxt->nworkers == 0 || error_queue_space != NULL);
for (i = 0; i < pcxt->nworkers; ++i)
{
char *start;
With that fix in place, I then hit a crash in parallel bitmap heap
scan. After applying no-pstate.patch, which I just committed and
back-patched to v10, then things look OK. I'm going to apply the fix
for the error_queue_space problem also.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Re: Why no pg_has_role(..., 'ADMIN')?
On Fri, Sep 20, 2024 at 12:37 PM Laurenz Albe wrote:
> > But knowing whether DROP ROLE will work,
> > w/o invalidating the current transaction,
> > seems like something quite useful to know now, no?
> >
> > I can query pg_auth_members for admin_option,
> > but only easily for direct membership. Taking into
> > account indirect membership, which I assume applies,
> > is exactly why pg_has_role() exists, no?
>
> That would be a useful addition, yes.
I think this already exists. The full list of modes supported by
pg_has_role() is listed in convert_role_priv_string(). You can do
something like pg_has_role('alice', 'USAGE WITH ADMIN OPTION'). This
is not new: it worked in older releases too, but AFAIK it's never been
mentioned in the documentation.
However, the precise rule for DROP ROLE in v16+ is not just that you
need to have ADMIN OPTION on the role. The rule is:
1. You must have ADMIN OPTION on the target role.
2. You must also have CREATEROLE.
3. If the target role is SUPERUSER, you must be SUPERUSER.
If I'm not wrong, pg_has_role(..., 'USAGE WITH ADMIN OPTION') will
test #1 for you, but not #2 or #3.
--
Robert Haas
EDB: http://www.enterprisedb.com
Re: Why no pg_has_role(..., 'ADMIN')?
On Fri, Sep 20, 2024 at 2:34 PM Tom Lane wrote: > I'm now inclined to add wording within the pg_has_role entry, along > the lines of > > WITH ADMIN OPTION or WITH GRANT OPTION can be added to any of > these privilege types to test whether ADMIN privilege is held > (all six spellings test the same thing). I don't have an opinion about the details, but +1 for documenting it somehow. I also think it's weird that we have six spellings that test the same thing, none of which are $SUBJECT. pg_has_role seems a little half-baked to me... -- Robert Haas EDB: http://www.enterprisedb.com
Re: Yet more ROLE changes in v18 beta1???
Hi Dominique, Thanks for testing. This time, whatever is going wrong here is probably not my fault, because I don't think I changed anything in this area for v18. Actually, I'm unaware of anyone else having made significant changes either, but that could very easily be a case of me not paying enough attention. I think we might need to know more about what exactly happened in order to track it down. -- Robert Haas EDB: http://www.enterprisedb.com
