ed 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
>
would cope
well with ALTER TABLE/ALTER TYPE commands that change those
rowtypes?
regards, tom lane
-
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 thinking
t/typedefs.list
but never remove any. But that hardly removes the need for
an occasional cleanup pass.
regards, tom lane
ntenance 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
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
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
o 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
>> to clean up
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 the dis
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
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
t
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
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 f51b3e0b50..3fb68
h 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 spot any,
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 for
>>
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, and w
of fmtId() here, but I don't think that's actually better.
regards, tom lane
- 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
t 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
769.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 this
Etsuro Fujita writes:
> On Thu, Apr 4, 2024 at 3:49 PM Laurenz Albe wrote:
>> On Thu, 2024-04-04 at 02:19 -0400, Tom Lane wrote:
>>> I am not quite clear on how broken an installation needs to be to
>>> reject "UTC" as a time zone setting, except that the br
Robert Haas writes:
> On Fri, Apr 19, 2024 at 2:44 PM Tom Lane wrote:
>> This patch failed to survive contact with the buildfarm. It looks
>> like the animals that are unhappy are choking like this:
>> pg_basebackup: error: backup failed: ERROR: symbolic link target too lo
Robert Haas writes:
> On Fri, Apr 19, 2024 at 2:08 PM Tom Lane wrote:
>> I've not been following this thread, so I don't have an opinion
>> about what the design ought to be. But if we still aren't settled
>> on it by now, I think the prudent thing is to revert the
e some way to get longer symlink paths into tar format?
(If not POSIX, I bet there's a widely-accepted GNU extension.)
regards, tom lane
r prime time.
regards, tom lane
use it might be running concurrently, which may lead to the
> checking being unstable.
> Any thoughts?
Let's not go there at all. I don't think there's enough field
demand to justify dealing with this concept.
regards, tom lane
d it still doesn't
change the results ... although looking at how CSTRING is used,
it looks safer to give it the same precedence as IDENT.
I think we should change parse.pl to give one or the other of these
results before something more serious breaks there.
regards, tom lane
dules' hooks/bgw from performing actions on my
> particular database?
That would be a feature for the individual module to implement.
regards, tom lane
h as TAP tests. So I'm not that concerned
about this, although if someone is feeling anal enough to rename
the test role I won't stand in the way.
regards, tom lane
Andres Freund writes:
> On 2024-04-18 23:11:52 -0400, Tom Lane wrote:
>> I was just looking locally at what I got by removing that, and sadly
>> I don't think I believe it: there are a lot of places where it claims
>> we hit lines we don't, and vice versa. That might be
Andres Freund writes:
> On 2024-04-18 22:18:34 -0400, Tom Lane wrote:
>> (If our code coverage tools worked on bison/flex stuff,
>> maybe this'd be less scary ... but they don't.)
> For bison coverage seems to work, see e.g.:
Yeah, I'd just noticed that --- I had it in my
Andres Freund writes:
> On 2024-04-17 23:10:53 -0400, Tom Lane wrote:
>> I think we should hold off on this. I found a simpler way to address
>> ecpg's problem than what I sketched upthread. I have a not-ready-to-
>> show-yet patch that allows the vast majority of ecpg's g
be fired for those changes. If such a trigger modifies or
blocks the effect of one of these commands, the end result could
be to break referential integrity. It is the trigger programmer's
responsibility to avoid that.
regards, tom lane
there's no tomorrow"), and
I want to fix that before presenting it. One could almost argue that
we don't care about memory consumption of the ecpg preprocessor;
but I think it's possible to do better.
regards, tom lane
y setting SKIP_READLINE_TESTS in the
animal's build_env options.
regards, tom lane
it different,
since there's not the C99-requires-the-feature angle.
regards, tom lane
though.
regards, tom lane
ike it would be a painful exercise with not a
lot of benefit in the end.
I do agree with Andrew that splitting func.sgml into multiple files
would be beneficial.
regards, tom lane
Michael Paquier writes:
> On Mon, Apr 15, 2024 at 07:42:38PM -0400, Tom Lane wrote:
>> Please, if you have the time.
> Okay, done that in the 12~16 range then, removing all traces of
> xmlParseMemory() including for xml_is_well_formed() in 12~14. That
> should calm d
or normalization. Should we
> change that, also?
It's definitely not OK for the standard test suite to include
internet access. Seems like we need to separate "download new
source files" from "generate the derived files".
regards, tom lane
Andres Freund writes:
> On 2024-04-15 20:47:16 -0400, Tom Lane wrote:
>> Ah, thanks. I guess this depends on getopt_long reordering arguments
>> (since the "-o outfile" bit will come later). That is safe enough
>> in HEAD since 411b72034, but it might fail on weir
Andres Freund writes:
> On 2024-04-15 17:48:32 -0400, Tom Lane wrote:
>> But I have no idea about making it work in meson. Any suggestions?
> So you just want to compile define.c twice? The below should suffice:
> - 'define': ['-DCMDLINESYM=123'],
> + 'define': ['-DCMDL
by
depslog; bring this up on the mailing list if it affects you
WARNING: Could not create compilation database.
That's not a huge problem in itself, but I think we should figure
out what's the minimum version that works, and document that.
regards, tom lane
Michael Paquier writes:
> On Mon, Apr 15, 2024 at 07:14:22PM -0400, Tom Lane wrote:
>> I could switch the animal to use -Wno-deprecated-declarations in the
>> back branches, but I'd rather not. I think the right answer is to
>> back-patch Michael's 65c5864d7 (xml2: Replac
-patch Michael's 65c5864d7 (xml2: Replace deprecated routines with
recommended ones). We speculated about that at the time (see e.g.,
400928b83) but didn't pull the trigger. I think 65c5864d7 has now
baked long enough that it'd be safe to back-patch.
regards, tom lane
-o $@ $< $<
But I have no idea about making it work in meson. Any suggestions?
regards, tom lane
[1] https://www.postgresql.org/message-id/3897526.1712710536%40sss.pgh.pa.us
From 9fa59a96edf28d0b5e7a483234b3ae70a95046d5 Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Mo
interesting to back the animal's CFLAGS down
to -O0 and see if things get more stable.
regards, tom lane
uncs/readfuncs, thereby breaking
stored views/rules if the Node is one that can appear in a parsetree.
So the bar to making such a change in a stable branch would be very
high.
regards, tom lane
David Rowley writes:
> On Mon, 15 Apr 2024 at 11:54, Tom Lane wrote:
>> would this also allow us to get rid of any default:
>> cases in switches on command tags?
> git grep "case CMDTAG_" does not yield any results.
OK. It was worth checking.
regards, tom lane
dTag* functions with COMMAND_TAG_NEXTTAG.
+1, but would this also allow us to get rid of any default:
cases in switches on command tags?
regards, tom lane
Thomas Munro writes:
> On Sun, Apr 14, 2024 at 11:49 AM Tom Lane wrote:
>> OK, I tried dtruss'ing psql on macOS. What I see is that with
>> Apple's libedit, the response to SIGINT includes this:
>> kill(0, 2) = 0 0
> https://gi
seems to be vastly exceeding its authority here. If
signaling the whole process group were wanted, it would have been
the responsibility of the original signaller to do that.
regards, tom lane
f the job or by one of
the following: ...
so I suspect zsh is treating that stack of processes as a "job" and
zapping all of it. There is certainly nothing in psql that would
attempt to signal its parent process (let alone grandparent).
regards, tom lane
seconds, how is it waiting
for 60 ms (and, presumably, repeating that)? The logic in
pg_sleep is pretty simple, and it's hard to think of anything except
the system clock jumping (far) backwards that would make this
happen. Any chance of extracting the local variables from the
pg_sleep stack frame?
regards, tom lane
Erik Wienhold writes:
> On 2024-04-13 00:20 +0200, Tom Lane wrote:
>> I'm not here to defend plpgsql's factorization ;-). However, it
>> doesn't really have a parser of its own, at least not for expressions,
>> so I'm not sure how your suggestion could be made to work.
>
orization ;-). However, it
doesn't really have a parser of its own, at least not for expressions,
so I'm not sure how your suggestion could be made to work.
regards, tom lane
issues.
regards, tom lane
Andres Freund writes:
> On 2024-04-11 23:15:38 -0400, Tom Lane wrote:
>> On the third hand, it's still true that we have no comparable
>> behavior for any other source of system lockups, and it's difficult
>> to make a case that stuck spinlocks really need more concern than
&
still miles ahead of the manual solution.
On the third hand, it's still true that we have no comparable
behavior for any other source of system lockups, and it's difficult
to make a case that stuck spinlocks really need more concern than
other kinds of bugs.
regards, tom lane
ter? I flat out don't
believe the idea that having a backend stuck on a spinlock
would otherwise go undetected.
regards, tom lane
Andres Freund writes:
> On 2024-04-11 16:35:58 -0400, Tom Lane wrote:
>> Indeed. I recall reading, not long ago, some Linux kernel docs to the
>> effect that automatic stack growth is triggered by a reference into
>> the page just below what is currently mapped as your st
rk into it. But on the basis of what I'm
seeing right now, I think maybe we ought to give up on it.
regards, tom lane
Andres Freund writes:
> On 2024-04-11 16:11:40 -0400, Tom Lane wrote:
>> We wouldn't need to fix it, if we simply removed the NUM_DELAYS
>> limit. Whatever kicked us off the sleep doesn't matter, we might
>> as well go check the spinlock.
> I suspect we should fix it
tion being large enough already.
> I don't really have an opinion about the concrete warning limit to use.
Given the above, I'm tempted to say we should make it 8K. But I know
we have a bunch of places that allocate page images as stack space,
so maybe that'd be too painful.
regards, tom lane
ice that we have
no timeout or "stuck lwlock" detection. So that would basically
remove the stuck-spinlock behavior in an indirect way, without
adding any safety measures that would justify thinking that it's
less likely we needed stuck-lock detection than before.
regards, tom lane
Robert Haas writes:
> On Wed, Apr 10, 2024 at 9:53 PM Tom Lane wrote:
>> Maybe we should rip out the whole mechanism and hard-wire
>> spins_per_delay at 1000 or so.
> Or, rip out the whole, whole mechanism and just don't PANIC.
By that you mean "remove the NUM_DELAYS l
in loops,
and I'm not sure that what LWLockWaitListLock and the bufmgr
callers are doing should be assumed to have timing behavior
identical to that.
regards, tom lane
failing.
(Keep in mind that the existing timeout of ~2 min is already several
geological epochs to a computer, so arguing that spinning another
couple minutes would have resulted in success seems more like wishful
thinking than reality.)
regards, tom lane
Jelte Fennema-Nio writes:
> On Wed, 10 Apr 2024 at 22:11, Tom Lane wrote:
>> If there's a case you can demonstrate where "\d foo" doesn't optimize
>> into an indexscan, we should look into exactly why that's happening,
>> because I think the cause must be more subt
Andres Freund writes:
> On 2024-04-10 16:05:21 -0400, Tom Lane wrote:
>> Yeah. So what's the conclusion? Leave it alone? Commit to
>> HEAD only?
> I think we should certainly fix it. I don't really have an opinion about
> backpatching, it's just on the line between
Jelte Fennema-Nio writes:
> On Wed, 10 Apr 2024 at 20:06, Tom Lane wrote:
>> Really? ISTM this argument is ignoring an optimization the backend
>> has understood for a long time.
> Interesting. I didn't know about that optimization. I can't check
> right now, but probab
f690, once the
> waitqueue is long, the spinlock will be held for an extended amount of time.
Yeah. So what's the conclusion? Leave it alone? Commit to
HEAD only?
regards, tom lane
idence
against it. Someone would have to do similar analysis on the
code we *actually* use to convince me that we need to worry.
regards, tom lane
Index Cond: (relname = 'foo'::text)
Filter: (relname ~ '^foo$'::text)
(3 rows)
regards, tom lane
Andres Freund writes:
> On 2024-04-10 13:03:05 -0400, Tom Lane wrote:
>> So I think we need something like the attached.
> LGTM.
On third thought ... while I still think this is a misuse of
perform_spin_delay and we should change it, I'm not sure it'll do
anything to address Par
Andres Freund writes:
> Hi,
> On 2024-04-10 12:28:10 -0400, Tom Lane wrote:
>> I don't think it's correct to re-initialize the SpinDelayStatus each
>> time around the outer loop. That state should persist through the
>> entire acquire operation, as it does in a
ld be chosen
by multiple backends.
regards, tom lane
use they all reset their SpinDelayStatus.
Lather, rinse, repeat. If the s_lock code were being used as
intended, they would soon acquire different cur_delay settings;
but that never happens. That is not the RNG's fault.
So I think we need something like the attached.
hat is
causing this spot to become so heavily contended.)
regards, tom lane
andomness in other ways.
regards, tom lane
roscopic, then we are going to have
nonrandomness problems in a lot of other places, so I'd lean
towards revising the RNG not band-aiding s_lock. We've seen
nothing to suggest such problems, though.)
regards, tom lane
Thomas Munro writes:
> On Wed, Apr 10, 2024 at 5:03 PM Tom Lane wrote:
>> I don't doubt that there are other clang versions where the problem
>> bites a lot harder. What result do you get from the test I tried
>> (turning mm_strdup into a no-op macro)?
> #defi
ot be using spinlocks.
regards, tom lane
e have a strong opinion for or against adding SERIALIZE
> to the default set of explain features enabled with ANALYZE?
I am 100% dead set against that, because it would silently render
EXPLAIN outputs from different versions quite non-comparable.
regards, tom lane
worth it; but if we can get that info for free
it seems worthwhile to not break this for inheritance cases.
regards, tom lane
Thomas Munro writes:
> On Wed, Apr 10, 2024 at 11:44 AM Tom Lane wrote:
>> ... On my Mac laptop
>> (Apple clang version 15.0.0), the compile time for preproc.o went from
>> 6.7sec to 5.5sec.
> Having seen multi-minute compile times on FreeBSD (where clang is the
>
401 - 500 of 15459 matches
Mail list logo
