that they've never been there and somehow nobody has
noticed.
Then again, maybe we have; see Noah's thread about in-place updates
breaking stuff and some of the surprising discoveries there. But it
seems worth investigating.
--
Robert Haas
EDB: http://www.enterprisedb.com
why should it go up for odd numbers of joinrels
and down for even numbers of joinrels? I wonder if these results are
really correct, and if they are, I wonder what could account for such
odd behavior
--
Robert Haas
EDB: http://www.enterprisedb.com
ten in a per-relation counter
and others in a per-relfilenode counter.
--
Robert Haas
EDB: http://www.enterprisedb.com
don't think you've done much to
help me get my patches committed, and while you have done some review
of other people's patches, it doesn't seem to often be the kind of
detailed, line-by-line review that is needed to get most patches
committed. So I'm curious how you expect this system to scale.
--
Robert Haas
EDB: http://www.enterprisedb.com
e else, but the real issue for me is that policies
have to be discoverable by the people who need to adhere to them, and
old mailing list discussions aren't.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, Jun 6, 2024 at 7:32 AM Heikki Linnakangas wrote:
> > Barring objections, I'll commit this later today or tomorrow. Thanks for
> > the report!
>
> Committed.
I think you may have forgotten to push.
--
Robert Haas
EDB: http://www.enterprisedb.com
first of these special interpretations is unnecessary and
should be removed. It seems pretty clear what 0 means.
--
Robert Haas
EDB: http://www.enterprisedb.com
t the moment.
Well, OK, so it sounds like I'm outvoted, at least at the moment.
Maybe that will change as more people vote, but for now, that's where
we are. Given that, I suppose we want something more like Tristan's
patch, but with a more extensible syntax. Does that sound right?
--
Robert Ha
h set does as anything better than grotty
hacks to work around serious design deficiencies. That is not a vote
against these patches: I see no better way forward. Nonetheless, I
dislike the lack of better options.
I have done only cursory review of the last two patches and don't feel
I'm in a place to certify them, at least not now.
--
Robert Haas
EDB: http://www.enterprisedb.com
think distros see the value in compiling with as many things turned on
as possible; when they ship with something turned off, it's because
it's unstable or introduces weird dependencies or has some other
disadvantage.
--
Robert Haas
EDB: http://www.enterprisedb.com
pensive on x86-64 windows, but not
> linux. On arm the overhead of TLS is more noticeable, across platforms,
> afaict.
I mean, to me, this still sounds like we want multithreading to be a
build-time option.
--
Robert Haas
EDB: http://www.enterprisedb.com
n the server is in threading mode.
--
Robert Haas
EDB: http://www.enterprisedb.com
It's a funny use of "max" and "min", because
the max is really what we're trying to do and the min is what we end
up with, and those terms don't necessarily bring those ideas to mind.
I don't have a better idea off-hand, though.
--
Robert Haas
EDB: http://www.enterprisedb.com
thing more than two bits is insane. If we want to
do something with the PG_MODULE_MAGIC line, I think it should involve
options-passing of some form rather than just having an alternate
macro name.
--
Robert Haas
EDB: http://www.enterprisedb.com
ple write protocolversion=3.1 to
opt in and then they could just keep that in the connection string
without harm, or at least without harm until 3.2 comes out? I don't
really like any of these options that well.
--
Robert Haas
EDB: http://www.enterprisedb.com
need more thought if
we decide that the *same* build of PostgreSQL can either launch
processes or threads per session, because then we'd to know which
extensions were available in whichever mode applied to the current
session.
That's all I've got for today.
--
Robert Haas
EDB: http://www.enterp
also want to do protocol-related things.
--
Robert Haas
EDB: http://www.enterprisedb.com
y break.
I'm not deathly opposed to it, but I think it's debatable and I'm sure
some people are going to be unhappy.
--
Robert Haas
EDB: http://www.enterprisedb.com
ne a comprehensive check of
> how popular extensions build against pgxs-from-meson. Packagers that
> make their production builds using meson now might be signing up for a
> long tail of the unknown.
That's a fair point, and I don't know what to do about it, but it
seems like something that n
? I feel like we're beyond the experimental stage now.
--
Robert Haas
EDB: http://www.enterprisedb.com
; might be a good enough reason
for people to calm down and stop yelling at me, but "it's no use
having a protocol version if we never bump it" definitely won't be.
--
Robert Haas
EDB: http://www.enterprisedb.com
ed or want either of those
characteristics here, so a lot of that complexity just isn't needed.
--
Robert Haas
EDB: http://www.enterprisedb.com
that seems to require
filling in at least one major hole the original design, which is a lot
to ask for (1) a back-patched fix or (2) a patch that someone who is
not the original author has to try to write and be responsible for
despite not being the one who created the problem.
--
Robert Haas
EDB: http://www.enterprisedb.com
ach. I agree with Tom that fixing this in REVOKE is a
bad plan; REVOKE is used by way too many things other than pg_dump,
and the behavior change is not in general desirable.
--
Robert Haas
EDB: http://www.enterprisedb.com
lem: dropping the
relation should forcibly remove the old stats, so there won't be any
conflict in this case.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi Bertrand,
It would be helpful to me if the reasons why we're splitting out
relfilenodestats could be more clearly spelled out. I see Andres's
comment in the thread to which you linked, but it's pretty vague about
why we should do this ("it's not nice") and whether we should do this
("I wonder
ating to the owned object(s). At least, I can't
currently see what else makes any sense.
--
Robert Haas
EDB: http://www.enterprisedb.com
armful stuff with them. Only due to a minor
> version upgrade. I think that's a bad idea to backpatch something with
> complex performance implications. Especially since they might even be
> based on potentially inaccurate data...
+1.
--
Robert Haas
EDB: http://www.enterprisedb.com
and that only because there's no choice -- if the role is
> about to go away, we can't hang on to a reference to its OID.
But I would have thought that the right thing to do to pg_init_privs
here would be essentially s/$OLDOWNER/$NEWOWNER/g.
I know I'm late to the party here, but why is t
));
I understand why these messages have the word "currently" in them, but
I bet the user won't. I'm not sure exactly what to recommend at the
moment (and I'm quite busy today due to the conference upcoming) but I
think we should try to find some way to rephrase these.
--
Robert Haas
EDB: http://www.enterprisedb.com
in general, what people do is
look for something that's slow (for them) and try to make it faster.
So the presumption should be that a performance feature has a
meaningful impact on users, and then in rare cases we may decide
otherwise.
--
Robert Haas
EDB: http://www.enterprisedb.com
t a lot.
OK. That seems fine to me, but I bet Jelte is going to disagree.
--
Robert Haas
EDB: http://www.enterprisedb.com
ly
get blocked, I think that's a bad plan and we shouldn't do it. But
it's quite possible I'm not fully understanding the situation.
--
Robert Haas
EDB: http://www.enterprisedb.com
efined it, or whether we
misinterpreted your earlier remarks.
--
Robert Haas
EDB: http://www.enterprisedb.com
ng the problem in the first place. Or maybe this
is another sign that we're doing the work at the wrong level.
--
Robert Haas
EDB: http://www.enterprisedb.com
ould definitely be fixed. Seems simple enough.
--
Robert Haas
EDB: http://www.enterprisedb.com
ell.
This might be a way of addressing some of the issues with this idea,
but I doubt it will be acceptable. I don't think we want to complicate
the slot API for this feature. There's too much downside to doing
that, in terms of performance and understandability.
--
Robert Haas
EDB: http://www.enterprisedb.com
which means we'd have to be able to predict fairly
accurately whether it was going to work out. But I do agree with you
that *if* we could make it work, it would probably be better than a
longer-lived cache.
--
Robert Haas
EDB: http://www.enterprisedb.com
in the
dependency code. That shouldn't break anything; it's just a bit
inefficient. My concern was really more about the maintainability of
the code. I fear that if we add code that takes heavyweight locks in
surprising places, we might later find the behavior difficult to
reason about.
Tom, what is your thought about that concern?
--
Robert Haas
EDB: http://www.enterprisedb.com
open item broken up into multiple open items,
one per issue.
Link [4] goes to a message that doesn't seem to relate to --dry-run.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, May 22, 2024 at 9:52 AM Robert Haas wrote:
> Another option that we should at least consider is "do nothing". In a
> case like the one Shlok describes, how are we supposed to know what
> the right thing to do is? Is it unreasonable to say that if the user
> doesn't w
e publications or subscriptions to exist, the user
should drop them?
Maybe it is unreasonable to say that, but it seems to me we should at
least talk about that.
--
Robert Haas
EDB: http://www.enterprisedb.com
log may not be as easy as we'd hope.
--
Robert Haas
EDB: http://www.enterprisedb.com
her case, a temporal
primary key is at least as unique as a regular primary key, but in
this case, it isn't. And someone might reasonably think that a
temporal primary key should exclude empty ranges just as all primary
keys exclude nulls. Or they might think the opposite.
At least, s
s this just preparatory to some other
work? These kinds of ambiguities can exist for any commit, not just
performance commits, but I bet that on average the problem is worse
for performance-related commits.
--
Robert Haas
EDB: http://www.enterprisedb.com
so to push the un-revert as a separate commit from the
bug fix, rather than together as suggested by Álvaro. Since time is
short due to the impending release and it's very late where you are,
I've taken care of this. Hope that's OK.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
tion oid that is constant,
> and wants to acquire NoLock?, need some clarification on this.
You need to acquire a lock. Otherwise, the relcache entry could change
underneath you while you're accessing it, which would result in
PostgreSQL crashing.
--
Robert Haas
EDB: http://www.enterprisedb.com
here's
already been some discussion of this, but I'm just telling you how it
strikes me on first look.
--
Robert Haas
EDB: http://www.enterprisedb.com
ections has as much to gain by compressing
> "header style" fields as http, so we are probably better off just not
> compressing > Work: https://www.redpill-linpro.com/
What do you think constitutes a header in the context of the
PostgreSQL wire protocol?
--
Robert Haas
EDB: http://www.enterprisedb.com
ed inputs. In that case, these kinds of attacks aren't
possible, or at least I don't see how, but you might want both
compression and encryption. I guess I don't understand why TLS removed
support for encryption entirely instead of disclaiming its use in some
appropriate way.
--
Robert Haas
On Mon, May 20, 2024 at 1:23 PM Jacob Champion
wrote:
> On Mon, May 20, 2024 at 10:01 AM Robert Haas wrote:
> > I really hope that you can't poke big enough holes to kill the feature
> > entirely, though. Because that sounds sad.
>
> Even if there are holes, I don't think
On Tue, Apr 23, 2024 at 1:27 PM Robert Haas wrote:
> Just a quick update. We have so far had 8 suggested patches from 6
> people, if I haven't missed anything. I'm fairly certain that not all
> of those patches are going to be good candidates for this session, so
> it would be great i
On Fri, May 17, 2024 at 10:11 PM Michael Paquier wrote:
> On Fri, May 17, 2024 at 03:53:58PM -0400, Robert Haas wrote:
> > The usual pattern for using hooks like this is to call the next
> > implementation, or the standard implementation, and pass down the
> > arguments tha
rhaps there's something here that is worth doing; I haven't thought
about this deeply and can't really do so at present. I do believe in
reasonable error detection, which I hope goes without saying, but I
also believe strongly in orthogonality: a tool should do one job and
do it as well as possible.
--
Robert Haas
EDB: http://www.enterprisedb.com
ll wait
> until after authentication, then I can poke holes in that too. My
> request is just that we choose one.
...we can fall back to this and you can try to poke holes here.
I really hope that you can't poke big enough holes to kill the feature
entirely, though. Because that sounds sad.
On Mon, May 20, 2024 at 11:37 AM Andres Freund wrote:
> On 2024-05-20 09:37:46 -0400, Robert Haas wrote:
> > On Sat, May 18, 2024 at 6:09 PM Andres Freund wrote:
> > > A few tests with ccache disabled:
> >
> > These tests seem to show no difference between the two
esulting CVE, because now you have to be able
to authenticate to make an exploit work. Perhaps that's an argument
for imposing a restriction here, but it doesn't seem to be the
argument that you're making.
--
Robert Haas
EDB: http://www.enterprisedb.com
nections, so refactoring the protocol layer shouldn't be too
> hard now.)
Sounds good!
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi,
Andy Fan asked me off-list for some feedback about this proposal. I
have hesitated to comment on it for lack of having studied the matter
in any detail, but since I've been asked for my input, here goes:
I agree that there's a problem here, but I suspect this is not the
right way to solve
t the buildfarm tests more different
configurations than we can reasonably afford to do in CI, but there is
no sense in pretending that having two different systems doing similar
jobs has no cost.
--
Robert Haas
EDB: http://www.enterprisedb.com
robably
> not practical with the current patch volume. What I'm thinking
> for the moment is to try to make that happen once a year or so.
I like this idea.
> Yeah, all this stuff ultimately gets done "for the good of the
> project", which isn't the most reliable motivation perhaps.
> I don't see a better one...
This is the really hard part.
--
Robert Haas
EDB: http://www.enterprisedb.com
don't know how we
do better: I just want to highlight the problem.
--
Robert Haas
EDB: http://www.enterprisedb.com
usion and that allowing
> configuration on *both* sides doesn't seem sufficiently useful to be
> worth adding that complexity.
I agree.
--
Robert Haas
EDB: http://www.enterprisedb.com
build rules for a temporary problem.
Arguably by doing this, but I don't think it's enough of a contortion
to get excited about.
Anyone else want to vote?
--
Robert Haas
EDB: http://www.enterprisedb.com
d, they
need to explain clearly why it's the first and not the second.
--
Robert Haas
EDB: http://www.enterprisedb.com
d slightly quicker
results for anyone using CI on back-branches and for other hackers who
are looking to back-patch bug fixes. I don't quite understand why we
want to throw those potential benefits out the window just because we
have a better fix for the future.
--
Robert Haas
EDB: http://www.enterprisedb.com
eview done by the patch author, we'd
first need to have a list of patches needing review.
And right now we don't, or at least not in any usable way.
commitfest.postgresql.org is supposed to give us that, but it doesn't.
--
Robert Haas
EDB: http://www.enterprisedb.com
de tree before passing it down, the chances of your
mistakes getting caught by these assertions are pretty darn low, since
they're very superficial checks.
--
Robert Haas
EDB: http://www.enterprisedb.com
ic and (3) I'm still not particularly happy about
the idea of making protocol parameters into GUCs in the first place.
Perhaps these are all minority positions, but I can't tell you what
everyone thinks, only what I think.
--
Robert Haas
EDB: http://www.enterprisedb.com
ents or documentation or the commit message or at
least a mailing list post.
My basic position is not that this patch is a bad idea, but that it
isn't really finished. The idea is probably a pretty good one, but
whether this is a reasonable implementation of the idea doesn't seem
clear, at
in
the direction of listing every alternative, which will become
unpalatable as soon as somebody adds one more way to do it, or maybe
it's unpalatable already.
Even if we don't do that, I don't see that there's a huge problem here.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Apr 23, 2024 at 12:55 AM Michael Paquier wrote:
> Thoughts?
The patch as proposed seems fine. Marking RfC.
--
Robert Haas
EDB: http://www.enterprisedb.com
n
the PostgreSQL 17 release.
Note that the Todo list is not a very good Todo list and most people
don't use it to find projects (and haven't for a long time). So it may
not get updated, or consulted, very often.
--
Robert Haas
EDB: http://www.enterprisedb.com
hings that are
thought to be important but we haven't gotten around to doing anything
about yet, but I think that's different from the parking lot CF.
--
Robert Haas
EDB: http://www.enterprisedb.com
hor is sad
because they have to click a link every 2 months to say "yeah, I'm
still here, please review my patch," we've already lost the game. That
person isn't sad because we asked them to click a link. They're sad
it's already been N * 2 months and nothing has happened.
--
Robert Haas
EDB: http://www.enterprisedb.com
to be out of support. If you feel otherwise, let's have
that argument, but I have a feeling that it may be more that you're
hoping I have some kind of oracular powers which, in reality, I lack.
--
Robert Haas
EDB: http://www.enterprisedb.com
itFest application down to a more reasonable
size and level of complexity. There's just no way everyone's up for
that level of pain. I'm not sure not up for that level of pain.
--
Robert Haas
EDB: http://www.enterprisedb.com
l
work that this would avoid. But it wouldn't solve any other problems,
so it's not really worth much consideration.
--
Robert Haas
EDB: http://www.enterprisedb.com
e, I'd at least consider making (4)
configurable.
It's tempting to just have one option, like \pset jsonformat
nullcolumns=omit;inlinevalues=json,array;rowformat=object;resultcontainer=array
simply because adding a ton of new options just for this isn't very
appealing. But looking at how long that is, it's probably not a great
idea. So I guess separate options is probably better?
--
Robert Haas
EDB: http://www.enterprisedb.com
his might be a case of -- convenient, reliable,
works with arbitrary queries -- pick two. I don't know. I wouldn't be
all that surprised if there's something clever and useful we could do
in this area, but I sure don't know what it is.
--
Robert Haas
EDB: http://www.enterprisedb.com
s. So, cool.
But, in your system, how does the client ask the server to switch to a
different compression algorithm, or to restart the compression stream?
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, May 17, 2024 at 9:02 AM Peter Eisentraut wrote:
> We already have the annotations feature, which is kind of this.
I didn't realize we had that feature. When was it added, and how is it
supposed to be used?
--
Robert Haas
EDB: http://www.enterprisedb.com
as the solution. We need to
find some way to create a system that does the right thing more often
by default.
--
Robert Haas
EDB: http://www.enterprisedb.com
re it's like "hmm, in this situation, either something
bad happened or it's just the somewhat unusual case where this happens
in the normal course of events, and we have no way to tell which it
is."
--
Robert Haas
EDB: http://www.enterprisedb.com
kicking them out of our CI system, so if he does
commit them, they'll be more likely to break the buildfarm. And in the
case of this specific patch, what we've done is punish Thomas for
trying to help out somebody who submitted a bug report, and at the
same time, made the patch he submitted less visible to anyone who
might want to help with it.
Wahoo!
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, May 17, 2024 at 1:05 AM Peter Eisentraut wrote:
> On 17.05.24 04:26, Robert Haas wrote:
> > I do*emphatically* think we need a parking lot.
>
> People seem to like this idea; I'm not quite sure I follow it. If you
> just want the automated patch testing, you can d
ernation," "Under Discussion," and
"Unclear" - but I think that's missing the point. What we really want
is to not see that stuff in the first place. It's a CommitFest, not
once-upon-a-time-I-wrote-a-patch-Fest.
--
Robert Haas
EDB: http://www.enterprisedb.com
the problem go away --
keeping large groups of people organized is a tremendously difficult
task under pretty much all circumstances, and the fact that, in this
context, nobody's really the boss, makes it a whole lot harder. But I
also feel like what we're doing right now can't possibly be the best
th
don't know if we want to support changing compression algorithms in
mid-stream. I don't think there's any reason we can't, but it might be
a bunch of work for something that nobody really cares about. Not
sure.
--
Robert Haas
EDB: http://www.enterprisedb.com
e concerns I
raised earlier about leaving room for more extension in the future.
Once we get past the startup message negotiation, the sky's the limit!
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, May 16, 2024 at 10:23 AM Heikki Linnakangas wrote:
> Yep, committed. Thanks everyone!
Thanks!
--
Robert Haas
EDB: http://www.enterprisedb.com
ist that GUC controls in its documentation.'. v7 is
> attached.
I think the comments need some wordsmithing.
I don't see why this parameter should be PGC_POSTMASTER.
--
Robert Haas
EDB: http://www.enterprisedb.com
lnegotiation. That seems more clear now that there is no fallback.
Unless there is a compelling reason to do otherwise, we should
expedite getting this committed so that it is included in beta1.
Release freeze begins Saturday.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
n't, because gzip is crazy slow. Use lz4 or zstd! But
it makes the point.)
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, May 15, 2024 at 4:22 PM Robert Treat wrote:
> Nope. Let's do the best bang for the buck improvement and we can see
> if we get any feedback that indicates more needs to be done.
Done.
--
Robert Haas
EDB: http://www.enterprisedb.com
better if you do this before we branch.
--
Robert Haas
EDB: http://www.enterprisedb.com
py_method was
going to list the things that it controlled, and that the comment was
going to say that you should update that list specifically. Just
saying that you may need to update some part of the documentation in
some way is fairly useless, IMHO.
--
Robert Haas
EDB: http://www.enterprisedb.com
s reasonable at all. We can't log the XID before it's
assigned, and we can't log the statement after the XID is assigned
without completely changing how the parameter works.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, May 15, 2024 at 4:50 PM Tom Lane wrote:
> At this point my OCD got the better of me and I did a little
> additional wordsmithing. How about the attached?
No objections here.
--
Robert Haas
EDB: http://www.enterprisedb.com
gets more than one vote is not really helping
anything.
--
Robert Haas
EDB: http://www.enterprisedb.com
1 - 100 of 7002 matches
Mail list logo
