Robert Haas writes:
> Never mind all this. I think what I have in mind requires doing what
> you did first. So if you're happy with what you've got, I'd go for it.
OK. HEAD-only sounds like a good compromise. Barring objections,
I'll do that later today.
Robert Haas writes:
> On Mon, May 6, 2024 at 7:31 PM Tom Lane wrote:
>> So maybe this is not really worth fixing. Thoughts?
> Hmm, I thought the RLS condition needed to accept the old and new
> TIDs, but not (InvalidBlockNumber,0). I might well have misunderstood,
> though.
g in -l mode: ProcessArchiveRestoreOptions
saves the result of _tocEntryRequired in te->reqs, but PrintTOCSummary
doesn't, and that will bollix its subsequent _tocEntryRequired checks
for "dependent" TOC entries.
regards, tom lane
whether we have a live bug
in this area in released branches; and if so, why we've not seen
reports of that.
regards, tom lane
le_to.
Hmm, the SJE code didn't really touch any of this logic, so why
didn't we see the failure before?
regards, tom lane
David Rowley writes:
> Why not "Fix INSERT with multi-row VALUES clauses ..."?
To my mind, the VALUES clause is the data source for INSERT,
so "from" seems appropriate. I'm not going to argue hard
about it.
regards, tom lane
. I'm pretty sure it means "Fix
> multiple-row VALUES clauses with INSERT statements when ...", but I'm
> not sure.
The problem happens in commands like
INSERT INTO tab VALUES (1,2), (3,4), ...
We treat this separately from the single-VALUES-row case for
efficiency reasons.
regards, tom lane
announcement.
+1. This is hardly a major bug fix --- it's just blocking off
something that people shouldn't be doing in the first place.
regards, tom lane
nduly in bed with undocumented implementation details, that I can't
imagine anyone is actually using such an RLS condition or ever will.
So maybe this is not really worth fixing. Thoughts?
regards, tom lane
[1]
https://www.postgresql.org/message-id/CA%2BTgmobwgL1XyV4uy
s which way variables get labeled in EXPLAIN,
I'd be kind of disinclined to spend extra cycles. But in any case,
I rather suspect you'll find that this actively breaks things.
Whether we change the varno on a Var isn't really optional, and there
are cross-checks in setrefs.c to make sure things match up.
regards, tom lane
omething.
I wouldn't remove it, but maybe an Assert is good enough. The tests
on Vars' varno should be equally pointless no?
regards, tom lane
the disable_cost hack would be a good idea to ensure the desired
> TidPath gets chosen, but this problem is not the fault of that.
> We're not making the TidPath with the correct contents in the first
> place.
Still true.
regards, tom lane
the desired
TidPath gets chosen, but this problem is not the fault of that.
We're not making the TidPath with the correct contents in the first
place.
regards, tom lane
quisite to moving
forward. Alternatively, perhaps it'd be good enough to forbid SJE
only when the non-target relation is actually mentioned in RETURNING.
regards, tom lane
[1]
https://www.postgresql.org/message-id/flat/CAEZATCWx0J0-v=Qjc6gXzR=KtsdvAE7Ow=D=mu50agoe+pv...@mail.gmail.com
amount of
WAL we generate isn't all that system-specific.
regards, tom lane
This fixes bug #18456 [1]. Since we're in back-branch release freeze,
I'll just park it for the moment. But I think we should shove it in
once the freeze lifts so it's in 17beta1.
regards, tom lane
[1]
https://www.postgresql.org/message-id/18456-8
-disabledness-count method, if we trim back
the number of places using disable_cost to the absolute minimum.
regards, tom lane
ntal tension about whether this is valid user namespace
or not, it just makes things less predictable.
regards, tom lane
lot of further hacking. Not sure we want to relocate
that filter responsibility in just one view.
regards, tom lane
ide applications and
libraries that want to work across different PG/OpenSSL versions?
regards, tom lane
See
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7155cc4a60e7bfc837233b2dea2563a2edc673fd
As usual, please send any corrections by Sunday.
regards, tom lane
cumentation in order.
Really, even the syntax chapter has some mentions of nulls.
If we did have a "Data" chapter there would be a case for
putting it as the *first* chapter of Part II.
I suppose we could address the nonlinearity gripe with a bunch
of cross-reference links, in which case maybe something under
Data Types is the least bad approach.
regards, tom lane
Peter Eisentraut writes:
> On 29.04.24 18:14, Tom Lane wrote:
>> OK. After poking at that for awhile, it seemed like "default to
>> HEAD" fits into meson a lot better than "throw an error if the
>> variable isn't set", so I switched to doing it like
Peter Eisentraut writes:
> On 30.04.24 19:29, Tom Lane wrote:
>> Also, the bigger picture here is the seeming assumption that "if
>> we change pg_trgm then it will be safe to replicate from x86 to
>> arm". I don't believe that that's a good idea and I&#x
hen sprintf decided to print "(null)" instead of dumping
core (cf 3779ac62d). This is more evidence in favor of catalog
corruption, but it doesn't tell us exactly what kind.
Maybe reindexing pg_type would improve matters?
regards, tom lane
h was far from commit-ready.
I think we should revert SJE for v17 and do a thorough design
review before trying again in v18.
regards, tom lane
won't need an explicit sort
later, since the query might need joins or aggregation on top of
the scan node. So it's far from trivial to decide that the scan
node doesn't need to emit the sort column.
In any case, I'm uninterested in making the world safe for a
design that's going to fail if the planner doesn't choose an
indexscan on a specific index. That's too fragile.
regards, tom lane
our commands consistent in the other
direction.
regards, tom lane
nk it could become section 5.2 in
ddl.sgml, between "Table Basics" and "Default Values". Another
angle could be to put it after "Default Values" --- except that
that section already assumes you know what a null is.
I've not read any of David's text in detail yet, but that's my
two cents on where to place it.
regards, tom lane
into the SQL of a system view is risky because it
is really, really painful to adjust the SQL in a released version.
You could back-patch a fix for this if done at the C level, but
I doubt we'd go to the trouble if it's done in the view.
regards, tom lane
arly
a small change with little if any risk of future breakage.
Option (2) ... not so much.
regards, tom lane
es.
Perhaps. pg_control already covers endianness, which I think
is the root of the hashing differences I showed. Adding a field
for char signedness feels a little weird, since it's not directly
a property of the bits-on-disk, but maybe we should.
regards, tom lane
Masahiko Sawada writes:
> On Tue, Apr 30, 2024 at 12:37 PM Tom Lane wrote:
>> I think this will break existing indexes that are working fine.
>> Yeah, it would have been better to avoid the difference, but
>> it's too late now.
> True. So it will be a PG18 item.
id that in C
code but it's harder to do in SQL.
(2) It's not clear to me that this test couldn't be run by a
non-bootstrap superuser. I think "current_user" is actually
the correct thing for the role executing the test.
regards, tom lane
Masahiko Sawada writes:
> On Tue, Apr 23, 2024 at 11:57 PM Tom Lane wrote:
>> Reject as not a bug. Discourage people from thinking that physical
>> replication will work across architectures.
> While cross-arch physical replication is not supported, I think having
> a
debug_discard_caches is on, it will succeed)
I wonder if we shouldn't just remove that test case as being
too unstable -- especially since it's not proving much anyway.
regards, tom lane
I wrote:
> Pushed, thanks for reviewing!
Argh, I forgot I'd meant to push b0c5b215d first not second.
Oh well, it was only neatnik-ism that made me want to see
those other animals fail --- and a lot of the buildfarm is
red right now for $other_reasons anyway.
rega
Daniel Gustafsson writes:
> On 29 Apr 2024, at 21:15, Tom Lane wrote:
>> v3 attached also has a bit more work on code comments.
> LGTM.
Pushed, thanks for reviewing!
regards, tom lane
Daniel Gustafsson writes:
>> On 28 Apr 2024, at 20:52, Tom Lane wrote:
>> ... It's a little bit
>> nasty to look at the ACL column of pg_init_privs, because that text
>> involves the bootstrap superuser's name which is site-dependent.
>> What I did to t
Mark Hill writes:
> Do we know, is it posted anywhere on the postgresql.org site what CVE's will
> be addressed in the next round up updates
> to Postgres which should come out next Thursday, May 9th, 2024?
We do not announce that sort of thing in advance.
Peter Eisentraut writes:
> On 26.04.24 21:24, Tom Lane wrote:
>> Concretely, I'm proposing the attached. Peter didn't like
>> PG_COMMIT_HASH, so I have PG_COMMIT_REFSPEC below, but I'm not
>> wedded to that if a better name is proposed.
> This seem
re is no "make
installcheck" equivalent for them. Each TAP test creates its own
database instance (or maybe several), so that instance won't have
anything else going on.
regards, tom lane
atabase can break it. So I'm fine
with tightening up prepared_xacts's query. I just wonder how far
we want to try to carry this.
(BTW, on the same logic, should ecpg's twophase.pgc be using a
prepared-transaction name that's less generic than "gxid"?)
regards, tom lane
it regularly by very-low-probability bugs of this kind.
regards, tom lane
x27;s especially unhappy about omitting .gitrevision, they'll
speak up.
regards, tom lane
ser, 'postgres') AS initprivs
This is of course not bulletproof: with a sufficiently weird
bootstrap superuser name, we could get false matches to parts
of "regress_dump_test_role" or to privilege strings. That
seems unlikely enough to live with, but I wonder if anybody has
a better
l tests so I stuck
>> a new tests in `timestamp.sql`. If there's a better place, then
>> please let me know.
They're in horology.sql, so I moved the tests there and pushed it.
Thanks for the report!
regards, tom lane
OID for a generic object-with-privileges using the
catcache and objectaddress.c's tables of object properties. That
assumption seems to exist already, eg ExecGrant_common also assumes
it, but it's not obvious that it must be so.
regards, tom lane
diff --git a/doc
though.
regards, tom lane
Daniel Gustafsson writes:
> On 21 Apr 2024, at 23:08, Tom Lane wrote:
>> So the meson animals are not running the test that sets up the
>> problematic data.
> I took a look at this, reading code and the linked thread. My gut feeling is
> that Stephen is right in that
be appropriate to revisit that decision,
but I sure don't want to do it piecemeal, one symbol at a time.
Also, if we did rename this one, the logical choice would be
WAL_CONTROL_FILE not PG_CONTROL_FILE.
regards, tom lane
Concretely, I'm proposing the attached. Peter didn't like
PG_COMMIT_HASH, so I have PG_COMMIT_REFSPEC below, but I'm not
wedded to that if a better name is proposed.
regards, tom lane
diff --git a/GNUmakefile.in b/GNUmakefile.in
index 30553b2a95..27357e5e
ntrol GUC, and
I think the consensus is that the one we have now is under-designed.
So I also vote for a full revert and try again in v18.
regards, tom lane
tantially saner.
> Yet that's essentially what we've done with period, and I don't think
> we can blame that on the SQL standard
Yes, we can. Please do not rant further about this until you've
read the section of a recent SQL spec.
regards, tom lane
5.38.0 and 5.38.2 are broken.
If the misbehavior is that new, I'm inclined to do nothing about it,
figuring that they'll fix it sooner not later. If we were seeing
failures in main-line check-world tests then maybe it'd be worth
band-aiding those, but AFAICS we're not.
regards, tom lane
Robert Haas writes:
> On Fri, Apr 26, 2024 at 12:15 PM Tom Lane wrote:
>> If I'm reading SQL99 correctly, they deny allowing the first
>> identifier to be a column name when there's more than one identifier,
>> so that you must table-qualify a composite column b
Robert Haas writes:
> On Fri, Apr 26, 2024 at 11:55 AM Tom Lane wrote:
>> Well, that would be one way of making the consistency problem be not
>> our problem, but it would be a sad restriction. It'd void a lot of
>> the arguable use-case for this feature, if you ask
Robert Haas writes:
> On Thu, Apr 25, 2024 at 5:51 PM Tom Lane wrote:
>> A different approach we could take is to implement the SQL99 rules
>> for , or at least move closer to that.
> I'm not familiar with these rules. Do they allow stuff like a.b.c.d.e,
> or bette
Robert Haas writes:
> On Thu, Apr 25, 2024 at 5:05 PM Tom Lane wrote:
>> What I'm trying to say is: given that the command "alter type T alter
>> attribute A type foo" exists, users would reasonably expect the system
>> to honor that on its own for any compo
Anton Voloshin writes:
> On 18/04/2023 20:34, Tom Lane wrote (on pgsql-committers):
>>> I shall now retire to a safe distance and watch the buildfarm.
> Unfortunately, on fresh perl (5.38.2 verified) and on ru_RU.UTF-8
> locale, it breaks basic float comparison: 0 <
uld
* create an ordering hazard during dump/reload: it's possible that
* the family has been created but not yet populated with the required
* operators.)
regards, tom lane
ACUUM will set all-visible bits
for temp tables even in the presence of concurrent transactions.
regards, tom lane
h
indeed I thought we had, but I can't find any evidence of that in
vacuumlazy.c, nor did a trawl of the commit log turn up anything
promising. Am I just looking in the wrong place?
regards, tom lane
e, not a schema or catalog name.
There's zero good reason for the latter two cases, other than
compatibility with thirty-year-old design mistakes. I kind of
doubt we could make that fly though.
regards, tom lane
Robert Haas writes:
> On Thu, Apr 25, 2024 at 12:34 PM Tom Lane wrote:
>> Uh, no. My point is that if you make a custom output function
>> for "type complex (real float8, imaginary float8)", that function
>> will probably crash pretty hard if what it's h
Robert Haas writes:
> This thread caught my eye this morning, and I'm confused.
> On Thu, Apr 25, 2024 at 12:44 AM Tom Lane wrote:
>> The primary outcome would be to require a huge amount of new work
>> to be done by a lot of software, much of it not under our control.
&
's formatted as %d not %u). See
https://www.postgresql.org/docs/devel/xindex.html#XINDEX-STRATEGIES
regards, tom lane
Peter Eisentraut writes:
> On 25.04.24 06:20, Tom Lane wrote:
>> Something I've been mulling over is whether to suggest that the
>> proposed "new port" should only target building with gcc.
> My understanding is that the old xlc is dead and has been replaced by
functions would cope
well with ALTER TABLE/ALTER TYPE commands that change those
rowtypes?
regards, tom lane
r versions. So back-
porting seems like an unlikely decision.
> Anyway, getting an access to such compilers to be able to debug issues
> on hosts that take less than 12h to just compile the code would
> certainly help its adoption.
+many
regards, tom lane
Greg Sabino Mullane writes:
> On Tue, Apr 23, 2024 at 6:06 PM Tom Lane wrote:
>> Now, if we just do it exactly like that
>> then trying to "make dist" without setting PG_COMMIT_HASH will
>> fail, since "git archive" has no default for its
>> a
Peter Eisentraut writes:
> On 24.04.24 00:05, Tom Lane wrote:
>> # Export the selected git ref
>> git archive ${gitref} | tar xf - -C pgsql
> Where does ${gitref} come from? Why doesn't this line use git archive
> HEAD | ... ?
${gitref} is an argument to the script
to
> be allowing only one,
> GRANT { USAGE | CREATE | ALL [ PRIVILEGES ] }
> ON SCHEMAS
> TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]
> while the syntaxes for tables and sequences are described correctly.
Yup, you're right. I'll push this shortly.
regards, tom lane
f codes. I attached a patch for this fix.
> Yes, I think you are right.
I agree. Do you want to do the honors?
regards, tom lane
Michael Paquier writes:
> On Tue, Apr 23, 2024 at 11:03:40PM -0400, Tom Lane wrote:
>> Hah. Seems like the comment for isall needs to explain that it
>> exists for this purpose, so we don't make this mistake again.
> How about something like the attached?
I was thin
/tools/pgindent/typedefs.list
but never remove any. But that hardly removes the need for
an occasional cleanup pass.
regards, tom lane
tation/maintenance effort.
regards, tom lane
Michael Paquier writes:
> On Tue, Apr 23, 2024 at 01:01:04PM -0400, Tom Lane wrote:
>> That is, query jumbling no longer distinguishes "DEALLOCATE x" from
>> "DEALLOCATE ALL", because the DeallocateStmt.name field is marked
>> query_jumble_ignore. Now ma
t's a good thing, or if we
should hack the makefile a little further to allow PG_COMMIT_HASH
to default to HEAD.
Thoughts, better ideas?
regards, tom lane
Michael Paquier writes:
> On Mon, Apr 22, 2024 at 06:46:27PM +0200, Matthias van de Meent wrote:
>> On Mon, 22 Apr 2024 at 17:41, Tom Lane wrote:
>>> I think it would be a good idea to push 0003 for v17, just so nobody
>>> grows an unnecessary dependency on that
ound worker processes (start with bgworker.h).
regards, tom lane
Daniel Gustafsson writes:
>> On 22 Apr 2024, at 18:04, Tom Lane wrote:
>> Seems like a useful change
> Agreed.
>> ... about like this?
> Patch LGTM.
Pushed.
regards, tom lane
gt; to resolve it?
Reject as not a bug. Discourage people from thinking that physical
replication will work across architectures.
regards, tom lane
Alvaro Herrera writes:
> On 2024-Apr-22, Tom Lane wrote:
>> The main reason there's a delta is that people don't manage to
>> maintain the in-tree copy perfectly (at least, they certainly
>> haven't done so for this past year). So we need to do that
>>
IEEE float arithmetic standard says that Inf is
greater than any finite value, and in particular it'd be
greater than MAXIMUM_ROWCOUNT.
regards, tom lane
Jeff Davis writes:
> On Mon, 2024-04-22 at 16:19 -0400, Tom Lane wrote:
>> Loading data without stats, and hoping
>> that auto-analyze will catch up sooner not later, is exactly the
>> current behavior that we're doing all this work to get out of.
> That's th
Nathan Bossart writes:
> On Mon, Apr 22, 2024 at 04:08:08PM -0400, Tom Lane wrote:
>> I think the actual plan now is that we'll sync the in-tree copy
>> with the buildfarm's results (and then do a tree-wide pgindent)
>> every so often, probably shortly before bet
nalyze will catch up sooner not later, is exactly the
current behavior that we're doing all this work to get out of.
I don't really think we want it to continue to be the default.
regards, tom lane
ty process, but you're right that
the README needs to explain the incremental method as being
the one most developers would usually use.
Want to write some text?
regards, tom lane
> since the units for work_mem are { "B", "kB", "MB", "GB", and "TB"}
Seems like a useful change ... about like this?
regards, tom lane
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index f51b3e0
trivial that it
could also be sensible to just push them to get them out of the way.
regards, tom lane
Daniel Gustafsson writes:
>> On 6 Apr 2024, at 01:10, Tom Lane wrote:
>> (So now I'm wondering why *only* copperhead has shown this so far.
>> Are our other cross-version-upgrade testing animals AWOL?)
> Clicking around searching for Xversion animals I didn't sp
Tomas Vondra writes:
> On 4/21/24 00:19, Tom Lane wrote:
>> I'm not suggesting that this is an interesting security vulnerability,
>> because if you can control the arguments to createdb it's probably
>> game over long since. But wrapping the arguments is good f
Tomas Vondra writes:
> On 4/20/24 22:40, Tom Lane wrote:
>> Seems reasonable. The alternative could be to remove createdb.c's use
>> of fmtId() here, but I don't think that's actually better.
> Why? It seems to me this is quite close to e.g. LOCALE_PROVIDER, a
ve createdb.c's use
of fmtId() here, but I don't think that's actually better.
regards, tom lane
oc0
- 0.74% int4in
0.69% pg_strtoint32_safe
Depressingly small amount of useful work being done there compared
to the management overhead. Seems like some micro-optimization
in this area could be a useful project for v18.
regards, tom lane
a "new port" mindset then it would be
totally reasonable to say that it only supports very recent AIX
releases, so I'd hope at least some of the cruft could be removed.
regards, tom lane
for that example. Do you have some really
> expensive debugging infrastructure enabled, perhaps?
Oh, never mind, now I see you are testing a version of the table
with no indexes, rather than the way it's set up in the regression
database. Apologies for the noise.
regards, tom lane
481 ms
Hm, I get about 13 ms for that example. Do you have some really
expensive debugging infrastructure enabled, perhaps?
regards, tom lane
Robert Haas writes:
> On Fri, Apr 19, 2024 at 3:31 PM Tom Lane wrote:
>> That would be a reasonable answer if we deem the problem to be
>> just "the buildfarm is unhappy". What I'm wondering about is
>> whether the feature will be useful to end users with
901 - 1000 of 8344 matches
Mail list logo
