#x27;d argue we don't want to enforce. This
is analogous to the way we let an object owner revoke her own ordinary
permissions, which the SQL model doesn't allow since those permissions
were granted to her by _SYSTEM.
regards, tom lane
quot; as an end in itself; it's part of re-examining
how all of this ought to work. I don't say that we have to have a
complete patch right away, only that we need a coherent end goal.
regards, tom lane
OLE | CURRENT_USER |
> SESSION_USER }
Agreed.
regards, tom lane
GLEN, and no LTREE_GET_SIGLEN.
regards, tom lane
s this detect the problem at hand?
regards, tom lane
rayExprs containing different
numbers of Consts as equivalent, maybe that'd be something we could
adopt without fixing point 1. I don't think anything that fuzzes the
treatment of Params can get away with that, though.
regards, tom lane
urbed that parts of this discussion seem to be getting
conducted with little understanding of the system's existing behaviors.
We should not be reinventing things we already have perfectly good
solutions for in the object-privileges domain.
regards, tom lane
indexes on ltree? If so, please
make that clear in the commit message, so I don't forget it
come May ;-)
Also, it looks like reindex is *not* required for indexes on
ltree[] ? That is, gist_ltree_ops indexes are affected but
not gist__ltree_ops?
regards, tom lane
target relation, ie do it back
in RemoveRelations. I've not thought hard about that, but it's
attractive if only because it'd mean you don't have to fix point 1.
regards, tom lane
tionships.
> I agree.
The bootstrap superuser clearly must be a special case in some way.
I'm not convinced that that means there should be other special
cases. Maybe there is a use-case for other "unowned" roles, but in
exactly what way would that be different from deeming such roles
to be owned by the bootstrap superuser?
regards, tom lane
d also involve making entries in pg_shdepend;
although for the case of roles owned by/granted to the bootstrap
superuser, we could omit those on the usual grounds that we don't need
to record dependencies on pinned objects.
regards, tom lane
e lack of similar APIs for the other direction seems odd.
It also feels to me that numeric_pg_lsn(), per se, doesn't belong in
numeric.c. A pretty direct comparison is numeric_cash(), which is
not in numeric.c but cash.c.
regards, tom lane
vignesh C writes:
> Here "pg_%" should be "pg_%%".
Right you are. Patch pushed, thanks!
regards, tom lane
y? Inserting such a setting in postgresql.conf and restarting
would be the first thing I'd think of if I needed to get out
of a problem. The only other way is to set it on the postmaster
command line, which is going to be awkward-to-impossible with
most system-provided start scripts.
a lot of
the use-cases for the feature. I supposed we'd want this to be a
PGC_POSTMASTER setting for security reasons.
regards, tom lane
roposed patch doesn't cause the *entire*
list to be skipped over. That seems like extra complexity and confusion
to no benefit.
regards, tom lane
Dmitry Dolgov <9erthali...@gmail.com> writes:
> On Mon, Mar 14, 2022 at 11:23:17AM -0400, Tom Lane wrote:
>> I do find it odd that the proposed patch doesn't cause the *entire*
>> list to be skipped over. That seems like extra complexity and confusion
>> to no ben
scuss better wordings ... but I doubt that
nothing-at-all is better.
regards, tom lane
a lot of the
new names are unintelligible. In particular, I suspect that the
patch is significantly redesigning when/where run-time pruning
happens (unless it's just letting that be run twice); but I don't
see any documentation or name changes suggesting where that
responsibility is now.
regards, tom lane
adequate for such a purpose.
What would you do with multiple-author patches, for a start?
regards, tom lane
g. I think you might need pushups comparable to
COMPLETE_WITH_ENUM_VALUE.
Also, personally, I'd rather not smash the names to lower case.
I think that's a significant decrement of readability.
regards, tom lane
ries,
not the underlying GUCs, and thus that the hooks need be invoked only
when creating, destroying or altering those entries. If we do have
a need for a hook editorializing on GUC value settings, that would
have to be an independent API --- but I have heard no calls for
the ability to have such a hook, and I don't think that this patch
is the place to introduce one.
regards, tom lane
Mark Dilger writes:
> On Mar 16, 2022, at 11:47 AM, Tom Lane wrote:
>> ... I therefore judge the
>> hook calls added to ExecSetVariableStmt and AlterSystemSetConfigFile
>> to be 100% useless, in fact probably counterproductive because they
>> introduce a boatload o
Joshua Brindle writes:
> On Wed, Mar 16, 2022 at 3:06 PM Tom Lane wrote:
>> It's going to be hard to do anything useful in a hook that (a) does
>> not know which GUC is being assigned to and (b) cannot do catalog
>> accesses for fear that we're not inside a tran
Andrew Dunstan writes:
> On 3/16/22 14:47, Tom Lane wrote:
>> I'm also fairly allergic to the way that this patch has decided to assign
>> multi-word names to privilege types (ie SET VALUE, ALTER SYSTEM). There
>> is no existing precedent for that, and I think it'
uot;%lld" with an
explicit cast to long long will work, so that's the preferred method
for printing 64-bit values in localizable strings. Not all of the old
code has been updated, though.
regards, tom lane
Peter Eisentraut writes:
> On 16.03.22 19:47, Tom Lane wrote:
>> ... Perhaps we could just use "SET" and
>> "ALTER", or "SET" and "SYSTEM"?
> I think Oracle and MS SQL Server have many multi-word privilege names.
> So user
't 618c16707 what you need here?
regards, tom lane
Greg Stark writes:
> On Fri, 11 Mar 2022 at 15:17, Tom Lane wrote:
>> The patch as-presented isn't very compelling for
>> lack of callers of the new function
> Tom, are you saying you think we're not interested in just adding this
> function unless it's pa
alternative.
> So unless anyone has strong objections against the proposed fix or can
> propose a better patch, I would suggest merging it.
Done now.
regards, tom lane
y "workers
can access fields A,B,C of MyPort but not fields X,Y,Z". I do not have
a concrete proposal for fixing it though.
regards, tom lane
y (or bare) (long long) and the maybe-all precedents does
> that.
Yes. Please do NOT do it like that. Write (long long), not something
else, to cast a value to match an "ll" format specifier. Otherwise
you're just making readers wonder whether your code is correct.
regards, tom lane
makes little sense to do it both ways in the
same patch.
> However, I am not sure how to update the *.po files under the pg_dump/po
> directory. Any suggestions?
The translation team manages those files. We don't normally touch them
during code development.
regards, tom lane
re more as a finger
exercise than because people use it regularly.
I added a regression test case too.
regards, tom lane
diff --git a/src/bin/psql/t/010_tab_completion.pl b/src/bin/psql/t/010_tab_completion.pl
index a54910680e..c6db1b1591 100644
--- a/src/bin/psql/t/010_tab_completion.pl
+++ b/s
tes. Now, if you're silly and do
set timezone to 'd
then readline gives you "efault' " and libedit gives you nothing.
But I think that's your own, um, fault. We don't have any other
places where tab completion is so aggressive as to remove quotes
from a keyword.
regards, tom lane
pe is
> defined here [1].
LGTM too. Pushed after rethinking the test case a bit.
regards, tom lane
copies of the code.
regards, tom lane
Jimmy Yih writes:
> Tom Lane wrote:
>> Actually though, maybe you *don't* want to do this in
>> RangeVarCallbackForDropRelation. Because of point 2, it might be
>> better to run find_all_inheritors after we've successfully
>> identified and locked the direct
, an
application wishing to check for error situations should set errno to
0, then call strtol() or strtoll(), then check errno.
Checking *endptr != '\0' is for detecting whether there is trailing
garbage after the number; which may be an error case or not as you
choose, but it&#x
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>> I think the reason the COMPLETE_WITH_ENUM_VALUE macro doesn't look
>> similar is that it hasn't made an attempt to work with input that
>> the user didn't quote --- that is, if you type
&
iple toast indexes then the counts for the table
indexes will be scaled up. We need to sum separately over the
table indexes and toast indexes, and I don't immediately see how
to do that without creating an optimization fence.
regards, tom lane
diff --git a/
as a different
problem, which is that if you do want most or all of the output,
computing each sub-aggregation separately is probably less
efficient than it could be. But this is probably the better way
to go unless someone has an even better idea.
regards, tom lane
di
ote, I believe I made it clear that I only need
> to detect garbage, not out-of-range values. And I think *endptr !=
> '\0' will do that.
Hmm ... do you consider an empty string to be valid input?
regards, tom lane
s for them at all, just mess it up.
The master copies of the .po files are kept in a different repo.
Also, I believe that extraction of new message strings is automated
already.
https://www.postgresql.org/docs/devel/nls.html
https://wiki.postgresql.org/wiki/NLS
regards, tom lane
spaces after the casts, as is project style).
regards, tom lane
umns in inconsistent orders. I'm not dead set
against this, but -0.5 or so.
regards, tom lane
o me like it's worth worrying about though -- it doesn't seem
like it could be hit more than once per query in normal cases.
regards, tom lane
t's
got whitespace issues. Please try to avoid unnecessary whitespace
changes ... pgindent will clean those up, but it makes reviewing
harder.
regards, tom lane
diff --git a/src/backend/utils/adt/datetime.c b/src/backend/utils/adt/datetime.c
index ba0ec35ac5..014e
long the lines of "I set foo to disabled, why is it showing
as zero?".
If we'd done it like this from the beginning, it'd have been
great, but retrofitting it now is a lot less appealing.
regards, tom lane
Andres Freund writes:
> On 2022-02-25 12:15:25 -0500, Tom Lane wrote:
>> The attached revision does that, standardizes on pg_fatal() as the
>> abbreviation for pg_log_error() + exit(1), and invents detail/hint
>> features as per previous discussion.
> This unfortuna
next cycle. I've bounced
> https://commitfest.postgresql.org/37/3523/ into the next CF. We'll
> need to do something like 75674c7e for master.
OK. You want me to push 75674c7e to HEAD?
regards, tom lane
the
mechanical change of the representation and then a second patch that
converts the shared variable to atomics. Since you've moved around
the places that read the shared variable, that part is subtler than
one could wish and really needs to be studied on its own.
regards, tom lane
Thomas Munro writes:
> On Tue, Mar 22, 2022 at 4:13 PM Tom Lane wrote:
>> OK. You want me to push 75674c7e to HEAD?
> Thanks, yes, please do.
Done.
regards, tom lane
ute
+NOTICE: in executor check perms: superuser finished execute
t
---
(0 rows)
I can duplicate that by adding "force_parallel_mode = regress"
to test_oat_hooks.conf, so a fair bet is that the duplication
comes from executing the same hook in both leader and worker.
me a couple minutes
Maybe better to suppress the audit messages if in a parallel worker?
regards, tom lane
via shared_preload_libraries or not.
(Note that the failures appear to be coming out of auxiliary
processes such as the checkpointer.)
As a quick-n-dirty fix to avoid reverting the entire test module,
perhaps just delete this error check for now.
regards, tom lane
Mark Dilger writes:
> On Mar 22, 2022, at 9:33 AM, Tom Lane wrote:
>> As a quick-n-dirty fix to avoid reverting the entire test module,
>> perhaps just delete this error check for now.
> Ok, done as you suggest:
I only suggested removing the error check in _PG_init, not
ch
Andrew Dunstan writes:
> On 3/22/22 12:58, Tom Lane wrote:
>> I only suggested removing the error check in _PG_init, not
>> changing the way the test works.
> Mark and I discussed this offline, and decided there was no requirement
> for the module to be preloaded. Do you hav
e a comment
* I notice a typo "permisisons" in test_oat_hooks.sql
regards, tom lane
ork becomes significantly more complicated/expensive,
which these ideas might cause. But it's a refinement that could be
left for later --- and in any case, the responsibility would still
fundamentally be nbtree's. I don't think the planner would do more
than call some AM routine that could add decoration to an IndexScan
plan node.
Now ... where did I put my flameproof vest?
regards, tom lane
he results of the
CLOBBER_CACHE_ALWAYS animals with trepidation.)
Now, if our attitude to the OAT hooks is that we are going to
sprinkle some at random and whether they are useful is someone
else's problem, then maybe these are not interesting concerns.
regards, tom lane
Andrew Dunstan writes:
> I have committed the first of these. That will break the cfbot for this
> and the json_table patches. The remainder should be committed in the
> following days.
That patch is 0-for-three on my buildfarm animals.
regards, tom lane
ert.
regards, tom lane
1", else you are going to have issues
with notices from different workers being interleaved differently
from run to run. You might have that anyway, due to interleaving
of leader and worker messages.
regards, tom lane
Andres Freund writes:
> On 2022-03-22 16:55:49 -0400, Tom Lane wrote:
>> BTW, I've had a bee in my bonnet for a long time about whether some of
>> nbtree's scan setup work could be done once during planning, rather than
>> over again during each indexscan start.
&g
Justin Pryzby writes:
> If I'm not wrong, this is still causing issues at least on cfbot/windows, even
> since f0206d99.
That's probably a variant of the encoding dependency I described
upthread.
regards, tom lane
at or near "int"
> with this commit.
Yeah, I was just scratching my head about that. It's not clear how
that could be related; but jabiru doesn't seem to have a history of
random failures, so maybe it's real.
regards, tom lane
Andrew Dunstan writes:
> On 3/22/22 18:18, Tom Lane wrote:
>> Now, if our attitude to the OAT hooks is that we are going to
>> sprinkle some at random and whether they are useful is someone
>> else's problem, then maybe these are not interesting concerns.
> So th
f the JSON patch.
Let's merge in the next step, get to a state that does not
generate build warnings, and see what happens then.
regards, tom lane
some time ago.
regards, tom lane
"&" operators in many places.
regards, tom lane
s.
For my taste, names like "join_N" would be better.
On the whole, I'd recommend putting this idea on the back burner
for three or four years more.
regards, tom lane
is patch has been basically ignored for a full two years now.
(Remarkably, it's still passing in the cfbot.)
I have to think that that means there's just not enough interest
to justify committing it. Should we mark it rejected and move on?
If not, what needs to happen to get it unstuck?
miss anything; and that would also
allow us to not bother taking such a lock on pinned objects, which'd
greatly cut the cost (though not to zero).
regards, tom lane
ant text more along the
lines of "This may help the planner choose the most appropriate
method for joining the work table to the query's other tables".
regards, tom lane
han zero comment. Also, it's not "our" getenv is it?
0003: OK. Interesting though that we haven't seen these before.
0004: no opinion
regards, tom lane
t of this regex is meant to
accomplish, but it seems to be assuming more than it should
about the output format of TAP messages.
regards, tom lane
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2022-03-23%2013%3A21%3A44
adjusted the wording a bit too --- YMMV, but I think my text is clearer.
regards, tom lane
Simon Riggs writes:
> I've tried to sum up the various points from everybody into this doc
> patch. Thanks all for replies.
This seemed rather badly in need of copy-editing. How do you
like the attached text?
regards, tom lane
diff --git a/doc/src/sgml/mvcc
ut it seems advisable to keep that separate from
-fsanitize=undefined.)
regards, tom lane
Simon Riggs writes:
>> [New patch version pending]
Do you have any objection if I rename the GUC to
recursive_worktable_factor? That seems a bit clearer as to what
it does, and it leaves more room for other knobs in the same area
if we decide we need any.
regard
Dmitry Dolgov <9erthali...@gmail.com> writes:
> On Tue, Mar 22, 2022 at 04:55:49PM -0400, Tom Lane wrote:
>> In short: I would throw out just about all the planner infrastructure
>> that's been proposed so far. It looks bulky, expensive, and
>> drastically underc
Jacob Champion writes:
> On Thu, 2022-03-17 at 18:33 -0400, Tom Lane wrote:
>> I think what we ought to do here is separate out the data that we think
>> parallel workers need access to. It does not seem wise to say "workers
>> can access fields A,B,C of MyPort but no
Andres Freund writes:
> Running with asan found an existing use-after-free bug in pg_waldump (*), a
> bug in
> dshash_seq_next() next that probably can't be hit in HEAD and a bug in my
> shared memory stats patch. I count that as a success.
Nice!
regards, tom lane
around, making the patch
harder to review. So maybe the best bet is to leave well enough
alone and expect the committer to re-pgindent before pushing it.
However, if you spot any diff hunks where there's just a whitespace
change, getting rid of those would be appreciated.
"Hou, Zhijie" writes:
> I found IncrementalSortPath type is not analyzed in outNode.
Indeed, that's supposed to be supported. Pushed, thanks for the patch!
regards, tom lane
way. Likely
what this patch should do is refactor that function so that its guts
can be used for other object-creation scenarios. (The fact that
this is so far from trivial is one reason I'm not in a hurry to
extend this sort of protection to other dependencies.)
regards, tom lane
cess
extract another's stack trace. I think that just adds more points
of failure, which is a bad thing in a feature that you're only going
to care about when things are a bit pear-shaped already.
regards, tom lane
ing around the SPI/parser/planner layer, to not a lot of gain.
However, it's not clear to me that that line of thought will work well
for the statement-level-trigger approach. In that case you might be
dealing with enough tuples to make a different plan advisable.
regards, tom lane
it's quite likely that the backtrace would
appear before stderr output that had actually been emitted earlier,
which'd be tremendously confusing.
(3) This isn't going to do anything good for my concerns about interleaved
output from different processes, either.
regards, tom lane
s
and one 220K-ish result, while the other curves had the reverse, so
the medians are different but there's probably not any non-chance
effect there.
Bottom line is that these patches don't appear to do much of
anything on M1, as you surmised.
regards, tom lane
be "needs review" now.
regards, tom lane
d.
Yeah. I'm not here to say "do nothing". But I think we need results
from more machines and more test cases to convince ourselves whether
there's a consistent, worthwhile win from any specific patch.
regards, tom lane
though
> whether just the Assert is wrong, or there's more fundamental
> issues here.
After looking into the git history I realized that this assertion is
quite new, stemming from David's a929e17e5a8 of 2020-11-02. So there's
something not right about that.
regards, tom lane
that it would've started to fail just now, because I don't really
see any changes in those branches that would explain a week-old change
in the test runtime.
Any thoughts?
regards, tom lane
hand, no?
regards, tom lane
ot because we made the test shorter ...
regards, tom lane
what lookup
mechanism would replace them? We can't exactly drop the encoding
conversion functionality.
regards, tom lane
cerned, so
storing something there only at execution time won't work either.
regards, tom lane
like it'd account
for that.
I don't think this can be considered RFC until the performance
issue is addressed.
regards, tom lane
101 - 200 of 17505 matches
Mail list logo
