hat we should just let objects be created
freely in the owned schema. Document the consequences of this and
blame any problems on user error.
(6) Your superior idea goes here!
--
Robert Haas
EDB: http://www.enterprisedb.com
doesn't for me. I understand it probably requires an injection
point to be certain of hitting the race condition, but I think that
would be worth doing. Otherwise, if something gets broken here by
accident, it might be a long time before anyone notices.
--
Robert Haas
EDB: http://www.enterprisedb.com
d do: ACCESS SHARE, SHARE, SHARE UPDATE EXCLUSIVE, EXCLUSIVE,
ACCESS EXCLUSIVE.
I've always thought that a pin was a lot like an access share lock and
a cleanup lock was a lot like an access exclusive lock.
But then again, using the same terminology for two different things
might be
ly argue that the nearest parallel to this level is
ShareUpdateExclusive: a self-exclusive lock level that permits
ordinary table access to continue while blocking exclusive locks, used
for an in-flight maintenance operation. But that's arguable, of
course.
--
Robert Haas
EDB: http://www.enterprisedb.com
f this than I do.
> DOES ANYBODY HAVE A BETTER NAME THAN SHARE-EXCLUSIVE???!?
AFAIK "share exclusive" or "SX" is standard terminology. While I'm not
wholly hostile to the idea of coming up with something else, I don't
think our tendency to invent our own way to d
dditional impulse.
See
http://postgr.es/m/CA+TgmoY=53ywd4dk4bpzco6h3dc0e8pdedtz_p2anm77ql0...@mail.gmail.com
for my proposal to address this issue.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Aug 20, 2025 at 3:13 PM Robert Haas wrote:
> Here's v2. 0001 is what you saw before with an attempt to fix the
> memory context handling. 0002 removes join_search_private. All I've
> tested is that the tests pass.
Here's v3 with a few more patches. I'm no
m. We don't have read support for these structs, so maybe it's fine.
> It looks weird though.
Left this one as-is for now.
Here's v2. 0001 is what you saw before with an attempt to fix the
memory context handling. 0002 removes join_search_private. All I've
tested is th
if extension_state etc is read_write_ignore, then
> extension_state_allocated etc had better be as well? I don't
> understand the rationale for preserving one without the other.
I figured we can't print a void** but we can print an integer and the
user might want to see it. Wrong idea?
--
Robert Haas
EDB: http://www.enterprisedb.com
le testing and
polishing. If people do not like this design, then I would like to
know what alternative they would prefer.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
v1-0001-Allow-private-state-in-certain-planner-data-struc.patch
Description: Binary data
cannot work, for the same reason. But manual slot operations can work,
so I do not think it is good to arbitrarily prohibit them. We do not
need a reason to specifically allow them; it is enough that there is
no good reason for them to be blocked.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Aug 11, 2025 at 1:55 PM Robert Haas wrote:
> [ some review ]
Another thing that's occurring to me here is that nothing prevents
other objects from making their way into the owned schema. Sure, if we
create a new schema with nobody having any permissions, then only the
creating
ionality because of an assertion failure that might just be
slightly sloppy coding.
--
Robert Haas
EDB: http://www.enterprisedb.com
s in AlterExtensionNamespace. In
the context of the patch, it's possible to puzzle out what is
happening, but I think the picture is not going to be clear to later
readers. It seems to me that this either needs some restructuring to
make the logical flow clearer, or a few well-written comments.
--
Robert Haas
EDB: http://www.enterprisedb.com
e exception for a couple valid changes under REPEATABLE
> READ and SERIALIZE, but I think they are expected and not a bug. (I
> think you would see the same thing outside of FKs.)
0001 and 0003 look OK to me on a quick read-through. 0002 seems to do
something horrible to isolation_schedul
t; 3. Change nothing. (This would be the choice if one is maximally concerned
>about deviating from the freeze and unconcerned about --enable-cassert
>builds of releases.)
>
> I am inclined to make today's change be (1).
Sounds right to me.
--
Robert Haas
EDB: http://www.enterprisedb.com
7;re doing
some kind of index scan and the contention is probably focused on the
upper-level index pages rather than the heap pages. You could maybe
imagine some crazy corner case where there's heap contention created
by TID scans, but that's too obscure a situation to justify adding
machinery of this kind.
--
Robert Haas
EDB: http://www.enterprisedb.com
bert didn't like 2a.
I think I like this a little better than your 2a. It's not a big deal, anyway.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Jul 28, 2025 at 2:42 PM Nathan Bossart wrote:
> On Mon, Jul 28, 2025 at 11:22:49AM -0400, Robert Haas wrote:
> > Committed. I removed the changes from the .po files since we don't
> > routinely update those, and I rewrote your proposal commit message.
>
> nitpick
mild preference so I am more than fine if
you want to just go ahead and do #2a as you proposed.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, May 26, 2025 at 7:40 AM Jakub Wartak
wrote:
> v2 attached, rebased and tested.
Committed. I removed the changes from the .po files since we don't
routinely update those, and I rewrote your proposal commit message.
--
Robert Haas
EDB: http://www.enterprisedb.com
raightforward enough that a
separate review was not required.
--
Robert Haas
EDB: http://www.enterprisedb.com
the size of "whatever" ranges from quite small to moderately
large. I imagine that such efforts end up duplicating a lot of heapam
code and probably always will; but if we can avoid increasing that
amount, I think it's a good idea.
--
Robert Haas
EDB: http://www.enterprisedb.com
within the PostgreSQL executor. The latter might
merit different infrastructure, although I cringe a little bit at the
idea of having two ways of implementing custom joins when the total
number of projects using this infrastructure is probably less than
five.
--
Robert Haas
EDB: http://www.enterprisedb.com
ly. In that case,
it's not restoring the databases, so dropping them seems
catastrophically bad.
--
Robert Haas
EDB: http://www.enterprisedb.com
er. I don't want to spend the time to upgrade
our testing infrastructure to catch future instances of this problem
right now, and therefore propose to just commit this fix and move on.
Thanks to my colleague Jacob Champion for helping track this down.
--
Robert Haas
EDB: http://www.enterprisedb.com
v1-0001-Avoid-throwing-away-the-error-message-in-syncrep_.patch
Description: Binary data
y be very afraid
of staying on OLD releases, where the behavior is extremely insecure
and such users can just go take over the superuser account whenever
they like.
Of course, you or others might see it differently.
--
Robert Haas
EDB: http://www.enterprisedb.com
op right up to the top of the list. You won't
necessarily be able to see buffers that are just a tiny bit hot, but
with a decent number of samples you should be able to clearly see the
stuff that's really hot. People often say things to me like "well what
if I just get really unlucky and always miss what is truly the hottest
buffer," but the law of large numbers says you don't really need to
worry about that as long as you collect a sufficiently large number of
samples, and that's not really difficult to do.
--
Robert Haas
EDB: http://www.enterprisedb.com
tered here. So maybe we can study how that works
and figure out how to apply it to this case.
--
Robert Haas
EDB: http://www.enterprisedb.com
ment that just
sticking a bunch of counters or timers in the same places where we put
the wait event calls would be the right thing in general.
Introspection is an important topic and, IMHO, deserves much more
specific and nuanced thought about what we're trying to accomplish and
how we're going about it.
--
Robert Haas
EDB: http://www.enterprisedb.com
l
> + * key like we do for other object types.
This is also good. I suggest s/Wherever/Technically, this is not
necessary, because wherever/ and s/There's/However, there's/.
--
Robert Haas
EDB: http://www.enterprisedb.com
+restore fails after a
+ * pg_import_system_collations('my_schema') that creates collations
+ * for a blend of encodings.
This comment is also useful, but if I were to be critical again, it
does a better job saying why we shouldn't do what the code then does
than why we should.
Neither of those issues seem like must-fix problems to me.
--
Robert Haas
EDB: http://www.enterprisedb.com
int, since it's only conditionally OK to lose it. So the rule
above doesn't necessarily fully apply to this situation.
> Anyway, I'm now convinced that the way forward for this particular
> issue is to represent the VM changes in the same WAL record that has
> the heap page changes, so I won't further belabor the issue.
Makes sense.
--
Robert Haas
EDB: http://www.enterprisedb.com
insert record.
Without looking at the code, if you're saying we could go from 2 WAL
records down to 1, that would improve performance, which would be
worthwhile, but not a bug fix.
> So, in summary, do you think we should do something about the
> lazy_scan_prune() -> visibilitymap_set() case where we advance the LSN
> of a clean buffer and don't mark it dirty?
Yes, I think that would be worth trying to fix.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Jun 30, 2025 at 5:34 PM Nathan Bossart wrote:
> These functions have been around for a while, but commits 48b5aa3 and
> 15afb7d were only back-patched to v16. Any objections if I apply them down
> to v13 now?
Seems fine to me.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Jun 30, 2025 at 8:14 PM Michael Paquier wrote:
> In short, thanks all for the work done here!
I'm glad to hear that you found it helpful!
--
Robert Haas
EDB: http://www.enterprisedb.com
nt page
+ * modification would fail to clear the VM bit. Though it is possible for
+ * the page-level bit to be set and the VM bit to be clear if checksums
+ * and wal_log_hints are not enabled.
+ */
The last sentence is not great English and maybe not that relevant,
either. I woul
On Tue, Jun 24, 2025 at 12:48 PM Nathan Bossart
wrote:
> On Mon, Jun 23, 2025 at 01:38:10PM -0400, Robert Haas wrote:
> > I had thought we had a consensus that pg_upgrade should preserve stats
> > but regularly pg_dump shouldn't include them; perhaps I misunderstood
> &
are) various --no-whatever switches to skip unwanted items. But
pg_dump should have dump a reasonable set of things by default, and
the user should be able to add to that or subtract from it.
--
Robert Haas
EDB: http://www.enterprisedb.com
everyone with half a brain should upgrade within a week or two when a
new version comes out, while others of us think that there might be
someone out there who still has a working PDP-11. Since any policy
that anyone is likely to actually propose falls somewhere between
those two extremes, half of us
le the second group thinks exactly the same about
the first group. There's hardly a topic to be found that produces more
apparent acrimony around here than what releases of things we ought to
still be supporting.
--
Robert Haas
EDB: http://www.enterprisedb.com
s a lot of options, and
it doesn't seem like a good bet to me to have options that are
equivalent to various combinations of other options. I don't see any
particular reason to believe that --statistics-only is even a
particularly likely combination of options for someone to want. I'd
rather keep it simple.
--
Robert Haas
EDB: http://www.enterprisedb.com
7;s a lot more confusing. Maybe there's
some issue of cross-version compatibility here that justifies this
complexity, but I don't see what it would be. I would think
--with-data has always been the default and always will be, so we just
don't need --with-data for anything. But maybe I'm confused.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Jun 10, 2025 at 4:52 PM Mark Dake wrote:
> Happy to clarify further or contribute a patch.
On Thu, Jun 12, 2025 at 9:23 AM Mark Drake wrote:
> Sorry, not a 'C' coder. A man must know his limits. ☹
Uh ... what?
--
Robert Haas
EDB: http://www.enterprisedb.com
y? How is the error code currently used and is this consistent?
People want to be able to filter logs by error code to find the events
that they care about, and if you just lump a bunch of quasi-related
things under one error code because technically the wording of the
error code would fit the situation, then they can't do that.
--
Robert Haas
EDB: http://www.enterprisedb.com
doesn't, either.
Now, none of that means that we couldn't define -(jsonb,jsonb) in the
manner you propose. But that's just a feature idea, not an
inconsistency.
--
Robert Haas
EDB: http://www.enterprisedb.com
es, then people could test for those and know
that they would get exactly these conditions and nothing else.
--
Robert Haas
EDB: http://www.enterprisedb.com
> appropriate to introduce a new, more specific error code for this
> purpose?
Makes sense to me. I'm not sure if we should use a new error code or
some other existing one, but conflating other things with serializable
failures seems like a bad plan.
--
Robert Haas
EDB: http://www.enterprisedb.com
at pretty obviously should be fixed.
Done.
*quakes in fear of incoming buildfarm results*
--
Robert Haas
EDB: http://www.enterprisedb.com
ise, it might get broken by some future patch without anybody
noticing.
(For clarity, I'm not attempting to insist on anything here, just
sharing a few thoughts that come to mind.)
--
Robert Haas
EDB: http://www.enterprisedb.com
table
functions that would cause a problem here. I still think it's a bad
direction to go.
--
Robert Haas
EDB: http://www.enterprisedb.com
;s built-in and what's provided by a
user or an extension. But I also don't think it works.
--
Robert Haas
EDB: http://www.enterprisedb.com
s agreement that this
change is an improvement, and it appears to me that we don't have
that. I read Fujii Masao's comments to indicate that he doesn't
necessarily agree with the change and wants it reverted, and I read
Michael Paquier's comments the same way. Unless I'm m
On Tue, Jun 3, 2025 at 1:24 PM Tom Lane wrote:
> Robert Haas writes:
> > I think the proposed patch should be committed and back-patched, after
> > fixing it so that it's pgindent-clean and adding a comment. Does
> > anyone have strong objection to that?
>
> No
mental
> exercises.
I think the proposed patch should be committed and back-patched, after
fixing it so that it's pgindent-clean and adding a comment. Does
anyone have strong objection to that?
--
Robert Haas
EDB: http://www.enterprisedb.com
wledge,
we've never formally classified the former type of problem as a
security vulnerability, although maybe there's an argument that it is
one. We've filed CVEs for problems of the latter sort.
--
Robert Haas
EDB: http://www.enterprisedb.com
of the primary vs. the state of the standby, a
call to pg_sync_replication_slots() may either create a slot or fail
to do so. A call at a slightly earlier or later time might have had a
different result. IIUC, this proposal would make different results due
to minor timing variations less probable.
-
t solution, of course, say if we think
it's sufficiently easier to implement. But considering that Tom and
Noah have both prototyped function trust systems, it seems highly
premature to conclude that there's no way forward along those lines.
--
Robert Haas
EDB: http://www.enterprisedb.com
(in one of several proposed
variations) that can close all of those holes.
--
Robert Haas
EDB: http://www.enterprisedb.com
rs>409GB. While I'm not opposed to a more efficient
solution, it seems reasonable to me to suppose that if you've got
shared_buffers>409GB, you're able to afford having this function use
>1GB.
--
Robert Haas
EDB: http://www.enterprisedb.com
ewriter to the planner to fix various problems discussed on
the thread. But we should decide whether the resulting situation is
acceptable to ship.
To be clear, I like this feature in concept and I don't want it to
crash and burn. But I even more don't want to ship something and then
ha
dby's
> nextXid, causing sync failure.
I still don't understand how this problem arises in the first place.
It seems like you're describing a situation where we need to prevent
the standby from getting ahead of the primary, but that should be
impossible by definition.
--
Robert Haas
EDB: http://www.enterprisedb.com
7;t be interpreted as anything sensible, we should reject
it rather than making up a fake value. However, I agree that it's best
not to do such tightening in the back-branches.
--
Robert Haas
EDB: http://www.enterprisedb.com
rmation on the Internet to explain why this sometimes happens and
sometimes doesn't, and various things I attempted as fixes didn't work
out. There could be something wrong specifically with this machine,
but I also wouldn't be too shocked if this is just randomly broken on
macO
But I also can't shake the feeling that I shouldn't *need* to
understand that stuff to use the feature. Isn't that the whole point?
--
Robert Haas
EDB: http://www.enterprisedb.com
that was what Tom said last September and I just assumed he
was right about the policy. If not, well then that's different.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, May 22, 2025 at 3:36 PM Nathan Bossart wrote:
> +1, I think defaulting to restoring everything in the dump file is much
> less surprising than the alternative.
+1.
--
Robert Haas
EDB: http://www.enterprisedb.com
we would have likely done that a
long time ago.
--
Robert Haas
EDB: http://www.enterprisedb.com
ug" parameter
> and another one - "debuG".
I guess my point is that this works just like other cases where SQL
identifiers are accessible in C code: they're normally lower-case but
they don't have to be if the user quoted them. I don't think it's
w
uery plan after the
check_stack_depth() call and before the rest of the logic in the
function. I've attached a sample patch to show what I have in mind.
--
Robert Haas
EDB: http://www.enterprisedb.com
example-execprocnodefirst-patch.diff
Description: Binary data
select 1;
ERROR: unrecognized EXPLAIN option "VERBOSE"
LINE 1: explain ("VERBOSE") select 1;
^
--
Robert Haas
EDB: http://www.enterprisedb.com
default" item in the open items list under
"Decisions to Recheck Mid-Beta", but that's arguably now. It also sort
of looks like we might have a consensus anyway: Jeff said "I lean
towards making it opt-in for pg_dump and opt-out for pg_upgrade" and I
agree with tha
xpand_virtual_generated_columns.
If Tom doesn't respond right away, I suggest that we need to add an
open item for http://postgr.es/m/602561.1744314...@sss.pgh.pa.us
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, May 21, 2025 at 2:31 PM Tom Lane wrote:
> Having said that, what's wrong with inventing some improved function
> names and never removing the old ones?
I don't particularly like the clutter, but if the consensus is that
the clutter doesn't matter, fair enough.
--
ge you to
look through the patch for other, similar places that could benefit
from a fuller explanation. And I hope somebody else shows up to
express interest in this so that your work is not wasted...
--
Robert Haas
EDB: http://www.enterprisedb.com
aged to overlook for all this time.
--
Robert Haas
EDB: http://www.enterprisedb.com
pen before and after the things that we
want the locking to happen after. And maybe that's true. Or maybe it's
close enough to true that it's still better than the status quo where
we're not taking locks at all. But on the other hand, since I can't
think of any compelling reason why it HAS to be true, maybe it isn't.
--
Robert Haas
EDB: http://www.enterprisedb.com
anks for the report.
Since this was Andres's commit, I think it would have been a good idea
to give at least 24 hours, or better yet a couple of days, for him to
comment before committing something.
--
Robert Haas
EDB: http://www.enterprisedb.com
nvent a GUC jsonb_tz_warning = { on | off } that advises you to
use the new functions instead, whenever you use the old ones.
3. After N years, flip the default value from off to on.
4. After M additional years, remove the old functions and the GUC.
5. Still get complaints.
--
Robert Haas
EDB: http://www.enterprisedb.com
check with this design when NoLock is
> > passed, so I think this is a reasonable alternative to that design.
>
> I'd have to see the patch to see whether I liked the end result. But
> I'm guessing that involves a lot of non-mechanical changes in the call
> sites, and
t;
> Given that XMLCast converts values between SQL and XML and vice versa,
> my rationale was that if the target type is not a text type (such as
> TEXTOID, VARCHAROID, or NAMEOID), then the cast operand must be of type
> xml, which makes this default: safe.
> [...]
> But I can see it looks unsafe. Do you have something like this in mind?
> [...]
> default:
> elog(ERROR, "unsupported target data type for XMLCast");
> }
Yes, exactly.
--
Robert Haas
EDB: http://www.enterprisedb.com
in recordDependencyOn()
but assert that the caller has previously acquired one. However, we
could still do the Assert() check with this design when NoLock is
passed, so I think this is a reasonable alternative to that design.
--
Robert Haas
EDB: http://www.enterprisedb.com
The legwork of sorting some of
that kind of stuff out should really happen before making a feature
proposal.
> I'm intrigued, and happy to stand by with an extinguisher. The road to
> great ideas is paved with bad ideas.
Thanks. That proposal is a task for another day, but I appreciate the sentiment.
--
Robert Haas
EDB: http://www.enterprisedb.com
ould make it much less wide in normal cases without making it much
longer. This has been percolating in my brain for a few years now and
I have the vague intention of proposing it at some point, but not
until I'm good and ready to be flamed to a well-done crisp, because
I'm quite sure there will be more than one opinion on the merits.)
--
Robert Haas
EDB: http://www.enterprisedb.com
don't have a better idea right
now, though.
If there are any notes that were taken during that unconference
session, please point me in the right direction; I was in another
session at that time but would read any available notes with interest.
--
Robert Haas
EDB: http://www.enterprisedb.com
in places
like pg_dumpall output, and maybe we should do that here ... kinda
just in case? But I'm not altogether sure that's a sufficient
justification, and at any rate I think we need to be clear on whether
that *is* the justification or whether there's something more concrete
that we'r
ong time (leading to race
conditions) or acquiring two locks on the same object with different
lock modes where we should really only acquire one. I'm all in favor
of solving this problem using heavyweight locks, but I think that
implicitly acquiring them as a side effect of recording de
omplex. Why not start simple and if someone
wants to do the work to add something more complicated, that is fine?
--
Robert Haas
EDB: http://www.enterprisedb.com
. I
don't know if that idea will work out but it certainly seems like a
good thing to try.
--
Robert Haas
EDB: http://www.enterprisedb.com
x27;s a data type for which DatumGetTextP will
produce a non-garbage return value? Maybe there's an answer to that
question, but there's no comment spelling it out; or maybe it's
actually just broken.
--
Robert Haas
EDB: http://www.enterprisedb.com
very
place that uses incremental sort decide whether to use an incremental
sort or a regular sort -- we should try to get to a place where it's
safe to use an incremental sort when it's possible without worrying
that it might actually be slower.
Or maybe that's not possible for some re
y that we can detect violations of this rule
automatically? I recall that we were recently discussing with Richard
Guo a proposed patch that would have had a similar problem, so it's
evidently not that hard for a committer to either fail to understand
what the rule is or fail to realize that they are violating it.
--
Robert Haas
EDB: http://www.enterprisedb.com
rations, but that way doesn't seem like
# it's going to scale well to multiple sources of mutability.
But I'm not sure I understand why it matters that there are multiple
sources of mutability here. Maybe I'm missing a piece of the puzzle
here.
--
Robert Haas
EDB: http://www.enterprisedb.com
dard? And, assuming yes, does the
SQL standard specify that permission checks should work as you
describe here, or is that something we decided?
--
Robert Haas
EDB: http://www.enterprisedb.com
oin removal code, and I'm not
sure about that either.
I'm just studying this for the first time so apologies if this review
is not quite up to standard.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, May 5, 2025 at 8:35 AM Robert Haas wrote:
> So it seems like the only real fix is to do as Tom proposes:
>
> # But don't we need to add
> # createrole_self_grant to the set of GUCs that pg_dump[all]
> # resets in the emitted SQL?
Tom, are you hoping that I'm goi
et it do that.
But we don't need to brand that as metadata; and we don't need a
method for other parts of the system to ask how much metadata exists.
At least, I don't think we do.
--
Robert Haas
EDB: http://www.enterprisedb.com
lobal and giving it a less generic name (e.g.
LogMemoryContextInProgress). However, perhaps others will disagree.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, May 1, 2025 at 2:22 PM Robert Haas wrote:
> > The other approach would be to do what we do for the role options and just
> > specify everything explicitly in the dump. The GUC is only a default
> > specifier so let's not leave room for defaults in the dump file.
ould, if it results in GRANTs that
> weren't there before).
Hmm. That might have been a better design. :-(
--
Robert Haas
EDB: http://www.enterprisedb.com
1 - 100 of 2085 matches
Mail list logo
