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
I had
seen "count" or "occurrence" I think I would have understood that
without further explanation, too.
So my point was: to me, N is more self-documenting than replace_at,
and less self-documenting than count or occurrence.
If your mileage varies on that point, so be it!
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, May 15, 2024 at 3:30 PM Nathan Bossart wrote:
> On Wed, May 15, 2024 at 12:06:03PM -0400, Robert Haas wrote:
> > What jumps out at me when I read this patch is that it says that an
> > incremental run should do steps 1-3 of a complete run, and then
> > immediatel
you think we should get into all that?
--
Robert Haas
EDB: http://www.enterprisedb.com
telling you what I think, and I'm pleased
that we think as similarly as we do, despite remaining differences.
--
Robert Haas
EDB: http://www.enterprisedb.com
uld still be able to guess
that too, because there's nothing other than a pattern that you'd
expect to pass to a regexp-replacement function that starts with p,
but it would still be worse than what we have now.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, May 15, 2024 at 3:23 PM Chapman Flack wrote:
> What would be wrong with that, for consistency's sake?
It was proposed and rejected upthread, but that's not to say that I
necessarily endorse the reasons given.
--
Robert Haas
EDB: http://www.enterprisedb.com
complaints. If you can describe *exactly*
how date_bin fails to meet your expectations, there is a much better
chance that something useful will happen here.
--
Robert Haas
EDB: http://www.enterprisedb.com
t to be a
character position or something, not an occurrence count.
--
Robert Haas
EDB: http://www.enterprisedb.com
ble"
> query.
I don't think it's at all obvious that this belongs on the server side
rather than the client side. I think it could be done in either place,
or both. I just think we don't have the infrastructure to do it
cleanly, at present.
--
Robert Haas
EDB: http://www.enterprisedb.com
y, the only
argument I see against it is that getting from where we are to there
would be a gigantic amount of work for the value we'd derive.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, May 15, 2024 at 2:46 PM Robert Haas wrote:
> Examples in the regression tests aren't meant as tests, not examples
> for users to copy. If we want examples, those belong in the
> documentation. However, I see that regexp_replace already has some
> examples at
> https://www
e regression tests aren't meant as tests, not examples
for users to copy. If we want examples, those belong in the
documentation. However, I see that regexp_replace already has some
examples at
https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-POSIX-REGEXP
so
Hi,
This patch is currently parked in the July CommitFest:
https://commitfest.postgresql.org/48/4735/
That's fine, except that I think that what the previous discussion
revealed is that we don't have consensus on how backtrace behavior
ought to be controlled: backtrace_on_internal_error was one
it gets too complicated that can itself become a
source of objections. But it's an idea.
--
Robert Haas
EDB: http://www.enterprisedb.com
t has been given so far is completely wrong, he can try to
demonstrate that the patch does all kinds of wonderful things with
very few disadvantages. But I think if he does that last, he's going
to find that it's not really possible, because I'm pretty sure that
Tom is right.
--
Robert Haas
EDB: http://www.enterprisedb.com
is nearly enough to justify such a strange
behavior.
--
Robert Haas
EDB: http://www.enterprisedb.com
ere is still interest in working on this topic rather
> than move it again.
Done.
--
Robert Haas
EDB: http://www.enterprisedb.com
ikely to make sense or not. It is entitled to
decide, as a matter of policy, that it's not willing to perform
compression, either because of CPU consumption or security concerns or
whatever, but it has no knowledge of what the purpose of this
particular connection is.
--
Robert Haas
EDB: http://www.enterprisedb.com
rent approach. Feel free to use, ignore, etc.
--
Robert Haas
EDB: http://www.enterprisedb.com
pgindent_readme_v2.patch
Description: Binary data
not a composite type",
+ errmsg("type %s is not a stand-alone composite type",
I agree with Peter's complaint that people aren't going to understand
what a stand-alone composite type means when they see the revised
error message; to really help people, we're going to need to do better
hould establish that
for certain and probably also establish what made it start working; if
it works provided you do X, Y, or Z, we should establish what those
things are.
I'm cool with adding diff to the list of dependencies.
I'd prefer to see us update the other links rather
On Fri, Mar 22, 2024 at 1:57 PM Robert Haas wrote:
> Rather, I think that it's entirely appropriate to do what Roberto
> suggested, which is to say, let users know that they're going to use
> some extra resources if they increase the setting, and then let them
> figure out what
Procedural comment:
It's better to get this patch committed with an imperfect test case
than to have it miss beta1.
...Robert
uld really be symmetric
on the client and server sides? Isn't it for the server just to
specify a list of acceptable algorithms, and the client to set the
compression options? If both sides are trying to set the compression
level, for example, who wins?
--
Robert Haas
EDB: http://www.enterprisedb.com
to_server=lzma
libpq_compression=server_to_client=gzip;client_to_server=lzma
libpq_compression=client_to_server=lzma;client_to_server=gzip
And if I wrote libpq_compression=server_to_client=gzip that would mean
send data to the client using gzip and in the other direction use
whatever the default is.
--
Robert Haas
EDB: http://www.enterprisedb.com
n our documentation that should be used
instead of "extension SQL script"; perhaps look for similar examples,
or the documentation of extensions themselves, and copy the wording.
Shouldn't "mem_tableam_handler" be "my_tableam_handler"?
--
Robert Haas
EDB: http://www.enterprisedb.com
1 - 100 of 6976 matches
Mail list logo
