27;m inclined to leave that alone.
I pushed your patch after fooling with the comments a bit.
regards, tom lane
quired for correct usage. (The caller has
to produce an input that's of the base type, after all.) So it seems
like that's not a convenience so much as an encouragement to incorrect
coding. I propose, for HEAD only, 0002 which removes that misfeature
and requires callers to supply the i
don't like to break ABI in minor releases.
regards, tom lane
Bertrand Drouvot writes:
> On Fri, Jan 24, 2025 at 11:42:15AM -0500, Tom Lane wrote:
>> PS: FTR, the hits I got on this in the past 90 days were
>>
>> sysname |branch | snapshot | stage |
>>
Andrey Borodin writes:
> On 26 Jan 2025, at 20:37, Tom Lane wrote:
>> Maybe we should recast it as an action. What do you think of
>> "mark_expr_as_assignment_source"?
> Sounds better to me. I found no examples of similar functions nether in
> p
Srinath Reddy writes:
> as suggested did the changes and attached the patch for the same.
Uh ... what in the world is the point of changing
BufferIsExclusiveLocked's signature?
regards, tom lane
Andrey Borodin writes:
>> On 21 Jan 2025, at 23:12, Tom Lane wrote:
>> somebody will review this
> I'm trying to dig into the patch set. My knowledge of the module is shallow
> and I hope to improve it by reading more patches in this area.
Thanks for looking!
>
Peter Eisentraut writes:
> This has been committed. And I understand there is a buildfarm client
> update available for the affected buildfarm members.
BTW, shouldn't the CF entry for this get closed now?
regards, tom lane
on't initialize content locks for them.
We could either Assert that that's not applied to local buffers,
or act as though their lock is always held. Given Andres' argument
probably the latter is better.
regards, tom lane
Robert Treat writes:
> On Wed, Jan 22, 2025 at 8:02 AM Shinya Kato
> wrote:
>> I agree to it and fixed the patch.
> LGTM
LGTM too. Pushed with a couple of very minor tweaks.
regards, tom lane
a invalid format,as we are doing currently
> in pg.
Good idea. I pushed your patch with that addition.
regards, tom lane
ters
within LATIN-1 that have interesting case-folding behavior?
regards, tom lane
Robins Tharakan writes:
> On Sat, 25 Jan 2025 at 08:59, Tom Lane wrote:
>> alligator and lapwing are not reporting the
>> relevant log file, but what we do see is an install failure that
>> could well be down to a compile failure.
> You're probably right about that
t;postgres" appears earlier in the
path. So we're forcing a bunch of useless "make install"s,
but that was never mission-critical until today.
Unsurprisingly, lapwing is also running under /home/postgres/.
Apparently no other BF animals are.
regards, tom lane
t; on most animals, but not these two. How come?
regards, tom lane
Andrew Dunstan writes:
> On 2025-01-24 Fr 4:07 PM, Tom Lane wrote:
>> Looking at the buildfarm client script, it looks to me like it
>> will unconditionally try to run TAP tests in every contrib directory
>> that has a "t" subdirectory. Up to now, none of th
Andrew Dunstan writes:
> On 2025-01-24 Fr 10:57 AM, Tom Lane wrote:
>> Looks like alligator needs some help here too.
> That's an issue with the new TAP test - alligator isn't running the
> TestSepgsql module. lapwing has also had a TAP test failure.
Hmm. Neither o
scalar
input), but of course that only works when the value you want
to extract is in a JSON object field. I guess what would
be wanted is a new function f(jsonb) returns text, but I'm
unsure about a good name.
regards, tom lane
diff --git a/src/backend/utils/adt/json
tice that some of them
are 'with vacuum on pg_authid' but others are 'with vacuum on pg_class'.
So those are two different steps in the test script, and there are
other steps that are very similar but have not failed. Curiouser
and curiouser.
regards, tom lane
idea how to proceed on narrowing down the cause...
regards, tom lane
PS: FTR, the hits I got on this in the past 90 days were
sysname |branch | snapshot | stage |
107.
You might be able to work around this with auth_extra,
a la 1e3f461e8 and other past fixes.
regards, tom lane
uff, fine.
It's not like there's no other duplicativeness in their switch-parsing
logic.
regards, tom lane
ithub.com/PGBuildFarm/client-code/commit/60b72787036090c6bf829f5cef2b0b3e60f2a2db
>
> (or just copy the whole file from
> https://raw.githubusercontent.com/PGBuildFarm/client-code/refs/heads/main/PGBuild/Modules/TestSepgsql.pm)
Looks like alligator needs some help here too.
regards, tom lane
dy has spoken against the 0001 patch (replace errors with
return-a-null), so I think I'll go ahead and commit that one.
Then I'll return to this thread with a fleshed-out patch for 0002.
regards, tom lane
Amit Kapila writes:
> On Fri, Jan 24, 2025 at 8:39 AM Tom Lane wrote:
>> I think the problem is not so much the underscore as the
>> inconsistency. You've got "pub", "gen", and "cols" run together,
>> but then you feel a need to separa
g,
the more so because no other column in that catalog has an
underscore in its name.
I see that this was carried over from a related C typedef name,
but users aren't going to see that. They'll just see that
somebody couldn't be bothered to maintain a consistent style.
regards, tom lane
Paul Jungwirth writes:
> On 1/23/25 15:28, Tom Lane wrote:
>> I've only noticed the two, but I did not mount an aggressive search.
>> It's possible that there were failures before 1772d554b0, since I
>> now see that the diff is in a test case that is older than t
%3A35%3A57
regards, tom lane
ns.
Same error on two different machines makes it hard to credit hardware
glitches, if that's what you mean. I could believe a bad pointer
accessing unpredictable memory, but perhaps valgrind would catch that.
regards, tom lane
e to attack that:
https://commitfest.postgresql.org/51/4690/
That's been stalled for lack of review, so if you were interested
in helping out, that'd be great.
regards, tom lane
else
#define MAX_KILOBYTES (INT_MAX / 1024)
This is pretty much the crux of the whole thing, and you didn't
fix/remove the comment you falsified.
regards, tom lane
dback, because
I don't foresee anything very close to this getting committed.
But I'd encourage you to pursue the ideas in other forms as
suggested by this discussion.
regards, tom lane
eruser roles is
good enough for that, but I'm not quite sure.
regards, tom lane
Noah Misch writes:
> On Thu, Jan 23, 2025 at 01:22:13PM -0500, Tom Lane wrote:
>> An alternative idea (that maybe should also be done in PostmasterMain)
>> is to report the HINT only #ifdef __darwin__ and on other platforms
>> use the "Please report a bug" text.
&g
maybe should also be done in PostmasterMain)
is to report the HINT only #ifdef __darwin__ and on other platforms
use the "Please report a bug" text.
regards, tom lane
[1]
https://www.postgresql.org/message-id/18783-d1873b95a59b9103%40postgresql.org
ode that was trying to do
something special in that situation. (Perhaps there is an argument
for having some testing of the system's behavior when running as a
dropped role, but I doubt that this is the place to start on that.)
regards, tom lane
match after comparing 3 of 3 entries
1 match after comparing 3 of 4 entries
1 match after comparing 3 of 5 entries
which seems less inefficient. As said, you would never
notice this effect in short queries, but for queries that
queue a lot of events it could be important.
han it is for other format codes.
* I made some other cosmetic changes such as rearranging the
error checks into an order that made more sense to me.
Thanks for submitting this patch!
regards, tom lane
PUBLIC, and if it tries to inspect
current_user or related functions those will fail, but there's
no compromise to system integrity. So I'd just remove that test.
regards, tom lane
be fixing this is at a higher
level. Where are the repetitive find_ec_member_matching_expr calls
coming from?
regards, tom lane
need to change anything here. There
are many places in our docs where we flow into a or
similar block without punctuation, and most of them read just fine
to me.
regards, tom lane
d_at)=([6,7), [2018-01-01,2018-02-01)) is referenced
from table "temporal_fk_rng2rng".
-- a PK update that fails because both are referenced (even before commit):
BEGIN;
ALTER TABLE temporal_fk_rng2rng
ie, an expected error did not get thrown.
regards, tom lane
mory bloat, by not performing
afterTriggerCopyBitmap() unless we actually need a new
AfterTriggerSharedData entry. According to my measurements,
that thinko roughly tripled the space consumed per AFTER UPDATE
event :-(. I'm surprised nobody complained about that yet.
regards, tom lane
e else instead of bloating AfterTriggerSharedData.
The obvious fix would involve adding a bms_equal() call to the
comparison loop in afterTriggerAddEvent, which makes me quite
sad on performance grounds. Maybe it hardly matters in the
big scheme of things, though.
regards, tom lane
the index column's type. See v2
attached (now with a regression test).
regards, tom lane
diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c
index 7377912b41..c2efcb68d2 100644
--- a/src/backend/catalog/index.c
+++ b/src/backend/catalog/index.c
@
be in that mode if the OS is.
(If we end up inventing a FIPS-mode flag, I would fully expect
interested vendors to patch our code to force it on when the
OS-level flag is set, which is exactly what they will have done
to OpenSSL. We should design our behavior with that in mind.)
regards, tom lane
seems inconsistent that it sets up the index
column's attndims and atttypid this way.
regards, tom lane
likely costs more in space than
> extending the existing commit record with a session id, but seems like
> something an extension could do without changes in core.
I think this'd be an acceptable tradeoff if it only has to happen once
per commit. Not sure if that answers the request though.
regards, tom lane
ears. That's why, for example, we advance the end
date on every file every year, even if it receives no other changes
that year.
regards, tom lane
this, because I'd really like to
get it into v18, and feature freeze is getting closer.
regards, tom lane
to 100%.
regards, tom lane
s plenty more.
I'd suggest letting the worker process die and spawning a new one
if you need to redirect its efforts to a new database. If that
seems too expensive, rethink the design that requires you to do it.
regards, tom lane
as we add more input spaces:
regression=# select to_number('123', ' 999');
to_number
---
12
(1 row)
regression=# select to_number(' 123', ' 999');
to_number
---
1
(1 row)
This is bizarrely inconsistent, and I think what's causing it
is the extra space-consumption in NUM_numpart_from_char.
regards, tom lane
to older work, so we prefer
to use the same copyright dates as related older files even in less
clear-cut cases.
regards, tom lane
terms of developer overhead
versus likely formatting improvements.
(Of course, if a new version comes out that is way better than
what we're using, I could be persuaded that it's worth changing.
But from what you're showing here, that hasn't happened yet.)
regards, tom lane
NULLS option, throw
> an error.
Yeah, that would be my first thought too. The only question is
whether a function that fails to check that could crash. If it
merely gives surprising answers, I think this way is fine.
regards, tom lane
me dubiously-formatted
> values:
> postgres=# select to_number('mmmdcm', 'RN');
> to_number
> ---
> 4400
> (1 row)
Ugh. This makes more urgent my question about where roman_to_int's
algorithm came from, because there's evidently something not right
about it.
regards, tom lane
t we can, so that would be
counterproductive.
Do you have a strong argument for switching to some other specific
version of perltidy?
regards, tom lane
but it's at least
possible to see where it's coming from: it's eating the digits that
appear within a six-character window, and not any more.
Not sure if anyone would thank us for making this change though.
I can't avoid the suspicion that somebody somewhere is depending
on the current behavior.
Anyway, this is getting off-topic for the current thread.
regards, tom lane
Jacob Champion writes:
> On Mon, Jan 20, 2025 at 11:35 AM Tom Lane wrote:
>> Maybe we could add this to the existing src/test/ssl/ tests,
>> which already deal with that hazard?
> That seems okay in the short term. (But it certainly highlights our
> lack of a "PG_T
Asia/Singapore in this test case.
It has a roughly similar UTC offset, and that offset hasn't
changed in tzdb since 2003. (Gotta love "git blame".)
regards, tom lane
ot-run-by-default test case.
Maybe we could add this to the existing src/test/ssl/ tests,
which already deal with that hazard?
regards, tom lane
o your
question about whether we want to use some heuristics to limit
the planner's search space.
regards, tom lane
ne thing that is not well documented is that RESET ALL doesn't
touch either "session_authorization" or "role". I suppose the
reasoning is that those things are session properties specified
by the SQL standard. It's a little weird, but it's stood for
many years and I doubt we'd consider changing it now.
regards, tom lane
Hunaid Sohail writes:
> On Sat, Jan 18, 2025 at 5:27 AM Tom Lane wrote:
> Initially, when I looked at the test case:
> SELECT to_number('M CC', 'RN');
> I was confused about whether it should be 'MCC'. After further inspection,
> I realized that
ot more. The devil's in the details though.
regards, tom lane
-in window
> functions?
No, there needs to be a way for the individual window function to
throw error if that's specified for a function that can't handle it.
I'm just saying I don't want that to be hard-wired in some centralized
spot.
regards, tom lane
Michael Paquier writes:
> Small question on this one: would it be worth adding a check in
> sanity_check.sql for bumpy values?
Yeah, I didn't bother with a regression test in this draft, but
we should likely have one. Or was your point something different?
r
the feature to
specific functions.
regards, tom lane
>test3 |1
I looked at getting a better result here and decided that it didn't
look very promising. pg_dump uses format_type() to build the type
name to put in CREATE TABLE, and that doesn't have access to attndims.
regards, tom lane
diff --g
27;m afraid this ship sailed a long time ago. Perhaps it
was a poor decision but I think we're stuck with it.
regards, tom lane
ebugPrintBufferRefcount() is much more targeted.
Sounds like we're in agreement. I'll push Jacob's second patch.
regards, tom lane
ion-specific details about what is to be logged.
It would be impractical to satisfy all such cases in one implementation.
There would also be concerns about imposing overhead on users who
have no need for such a feature.
regards, tom lane
error from mx.zohocorp.com.
So I'm not going to hold my breath waiting for a reply.
regards, tom lane
mething we can do here, but the current patch feels
like a dead end.
regards, tom lane
+ OutputComment(&buf, _("Get information about each column\n"));
That leads to some oddly-formatted output.
Anyway, I encourage you to work on these issues and see if we
can get to a committable patch.
regards, tom lane
diff --git a/src/bin/psql/c
there more to do?
regards, tom lane
[1] https://commitfest.postgresql.org/51/5394/
(which might not be available, or our own process might
hold it already).
I'd vote for just removing them...
regards, tom lane
r leaving it alone.
regards, tom lane
t
patterns, and fixed it to not eat any more characters than it should.
This might allow putting back some format-combination capabilities,
but other than the whitespace angle I figure we can leave that for
people to request it.
regards, tom lane
diff --git a/doc/src/sgml/
-no-psqlrc) option when restoring a database ...
to provide clarity about what the switch does.
regards, tom lane
Pavel Stehule writes:
> pá 18. 10. 2024 v 22:23 odesílatel Tom Lane napsal:
>> The problem here is that we failed to pass through the result of
>> PG_GET_COLLATION() to text_starts_with. We could do that, certainly,
>> for a couple more lines of code. But it feels like th
worth splitting it into a series of two
patches: the first one just does code motion such as pushing existing
logic into a new subroutine, and then the second one has the logic
changes. Or maybe that wouldn't help much, but consider giving it a
try.
regards, tom lane
culation. Not sure why leafhopper and only
leafhopper would be showing that.
regards, tom lane
[1] https://www.postgresql.org/message-id/7270.1302902...@sss.pgh.pa.us
[2] https://www.postgresql.org/message-id/19320.1323039...@sss.pgh.pa.us
[3]
https://www.postgresql.org/message-id/e1kut0q-57...@gemulon.postgresql.org
this behavior. We have a
few such things already, such as suppress_redundant_updates_trigger()
and tsvector_update_trigger(). So I think a patch to make a
pre-written trigger for this purpose would be much less controversial.
regards, tom lane
apes
the optimization applies to and what's the rationale for the
transformation being correct. The commentary in pathnodes.h for the
new data structures is likewise so skimpy as to be near useless.
regards, tom lane
((unsigned int) (io_op)) >= IOOP_EXTEND)
Yeah, that's safe parenthesis-wise. Whether it'll silence
the warning from those old clangs remains to be seen.
(But if it doesn't, maybe it's not worth working harder,
given that they're old.)
regards, tom lane
enum.
Personally I'd keep the macro but move it to pgstat.h, close
to the enum declaration, so that there's more than epsilon
chance of someone who's changing the enum noticing they need
to update it.
regards, tom lane
quot;untoasted" because the latter feels like
it could also mean "detoasted". (And as I write this para, I'm
having a hard time wanting to upcase the words, which reinforces
my doubts about s/toast/TOAST/g.)
regards, tom lane
oblem, but a
static inline would remove the risk.)
regards, tom lane
ERE NOT (ur.rolname ~ '^pg_' AND um.rolname ~ '^pg_')"
> need a white space at the end?
The right paren is its own token in any case, so we don't need
a space for correctness. You could argue that it'd improve
readability, but who reads pg_dumpall's queries?
regards, tom lane
he other coding you suggest.
regards, tom lane
David Rowley writes:
> I agree that the evidence you (John) gathered is enough reason to use
> memcpy().
Okay ... doesn't quite match my intuition, but intuition is a poor
guide to such things.
regards, tom lane
pot checks looked sane).
I'm curious whether a similar workaround will help with the
Debian toolchain.
regards, tom lane
I noticed that v2 of this patch series failed to apply after
7b27f5fd3, so here's v3. No non-trivial changes.
regards, tom lane
From d82b50dc222fb8751f45875fb3627bf08ca2e0cf Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Wed, 15 Jan 2025 12:37:54 -0500
Subject: [PAT
EXTEND)
+ ((io_op) >= IOOP_EXTEND)
I suppose one alternative is to re-order the enum so that the
upper-limit check in this macro *isn't* tautological ... but
that seems a bit silly.
regards, tom lane
[1]
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=demoiselle&dt=2025-01-15%2005%3A20%3A59&stg=build
ulation, which I believe
most modern compilers will see.
regards, tom lane
7;t mean to minimize the question of whether we need better
documentation about this behavior.)
regards, tom lane
Nathan Bossart writes:
> On Tue, Jan 14, 2025 at 10:02:46PM -0500, Tom Lane wrote:
>> LGTM, although I don't know enough about Windows to know if the
>> "== SIG_ERR" test in that path is correct.
> It's apparently not [0]. :(
Bleah.
> My guess is that
nough about Windows to know if the
"== SIG_ERR" test in that path is correct.
regards, tom lane
1 - 100 of 2325 matches
Mail list logo
