Hi,
On 2024-06-05 21:59:42 -0400, Robert Haas wrote:
> On Wed, Jun 5, 2024 at 9:50 PM Andres Freund wrote:
> > Depending on the architecture / ABI / compiler options it's often not
> > meaningfully more expensive to access a thread local variable than a
> > "norma
.
I think we might be able to gain some small performance benefits via the
annotations, which actualy might make it viable to just apply the annotations
regardless of using threads or not.
Greetings,
Andres Freund
g-ci-windows-ci) needs to be used on both VS and
> MinGW tasks.
> I attached a patch for using pg-ci-windows-ci Windows image on VS and
> MinGW tasks.
Thanks! Pushed to 15, 16 and master.
Greetings,
Andres Freund
Hi,
On 2024-06-03 14:28:13 -0500, Nathan Bossart wrote:
> On Mon, Jun 03, 2024 at 12:08:52PM -0700, Andres Freund wrote:
> > Why do we think that increasing the number of PGPROC slots, heavyweight
> > locks
> > etc by 256 isn't going to cause issues? That's not an
need a native uint128 implementation to control the
> overflows with uint64.
I'm confused - isn't using common/int.h entirely sufficient for that? Nearly
all architectures have more efficient ways to check for 64bit overflows than
doing actual 128 bit math.
Greetings,
Andres Freund
this is really something that needs to be called out.
>
> Sure, probably not a problem, but if that’s the sole qualifier for making
> binary changes, I think it’s worth saying, as opposed to “we don’t make
> any”. Something like “Only changes to padding, which you never used anyway,
> right?” :-)
IDK, to me something like this seems to promise more than we actually can.
Greetings,
Andres Freund
ngs,
Andres Freund
ypically that'd not be
the case when we introduce a new field in a minor version.
> Unless, that is, we can provide a complete list of things not to do (like
> make use of padding) to avoid it. Is that feasible?
You can't really rely on the contents of padding, in general. So I don't think
this is really something that needs to be called out.
Greetings,
Andres Freund
hould just work on gcc, or at least has in the recent past.
ISTM if we want to test for -export_dynamic like what you proposed, we should
do so only if --export-dynamic wasn't found. No need to incur the overhead on
!macos.
Greetings,
Andres Freund
Hi,
At some point this patch switched from rdtsc to rdtscp, which imo largely
negates the point of it. What lead to that?
Greetings,
Andres Freund
Hi,
On May 30, 2024 8:03:33 AM PDT, Andrew Dunstan wrote:
>On Thu, May 30, 2024 at 6:32 AM Aleksander Alekseev <
>aleksan...@timescale.com> wrote:
>
>>
>>
>> By a quick look on the buildfarm we seem to use Ninja >= 1.11.1.
>> However since Meson can use both Ninja and VS as a backend I'm not
>>
t'd be even better if we could just get perl to print out the flags in an
easier to parse way, but I couldn't immediately see a way.
Greetings,
Andres Freund
diff --git i/meson.build w/meson.build
index d6401fb8e30..191a051defb 100644
--- i/meson.build
+++ w/meson.build
@@ -997,13 +997
Hi,
On 2024-05-22 18:33:03 -0400, Bruce Momjian wrote:
> On Tue, May 21, 2024 at 09:40:28AM -0700, Andres Freund wrote:
> > On 2024-05-18 11:13:54 -0400, Bruce Momjian wrote:
> > I agree keeping things reasonably short is important. But I don't think
> > you're
> > e
scussing criteria when it doesn't at
all feel like a conversation.
In the end, these are patches to the source code, I don't think you can just
wave away widespread disagreement with your changes. That's not how we do
postgres development.
Greetings,
Andres Freund
these patches, we could do either of the following:
> 5) We update master, PG16, and PG15, but we hold all of them until the
> warning in PG15 is fixed.
I think we should apply the fix in <= 15 - IMO it's a correct compiler
warning, what we do right now is wrong.
Greetings,
Andres Freund
I have these settings as PGC_USERSET for now. Maybe they
> should be PGC_SUSET?
That probably would be right.
> Another thought: Do we really need three separate settings?
Maybe not three settings, but a single setting, with multiple values, like
debug_io_direct?
Greetings,
Andres Freund
o-features=enabled/disabled and specifying
specifically which dependencies you want to be used.
Greetings,
Andres Freund
Hi,
On 2024-05-21 09:27:20 -0700, Andres Freund wrote:
> Also, the release notes are also not just important to users. I often go back
> and look in the release notes to see when some some important change was made,
> because sometimes it's harder to find it in the git log, due to sheer
I think it's a good thing for somebody other than the author to have a
hand in writing a release notes entry for a change. The primary author(s) are
often too deep into some issue to have a good view of the right level of
detail and understandability.
Greetings,
Andres Freund
Hi,
On 2024-05-18 10:59:47 -0400, Bruce Momjian wrote:
> On Wed, May 15, 2024 at 08:48:02PM -0700, Andres Freund wrote:
> > +many.
> >
> > We're having this debate every release. I think the ongoing reticence to
> > note
> > performance improvements in the
On 2024-05-17 16:03:09 -0400, Peter Geoghegan wrote:
> On Fri, May 17, 2024 at 3:50 PM Andres Freund wrote:
> > You're saying that the data is correctly accessible on primaries, but broken
> > on standbys? Is there any difference in how the page looks like on the
> > p
not provided via pkg-config or cmake. But it doesn't know about our
extra_include_dirs parameter. We should probably fix that...
Greetings,
Andres Freund
On 2024-05-20 09:37:46 -0400, Robert Haas wrote:
> On Sat, May 18, 2024 at 6:09 PM Andres Freund wrote:
> > A few tests with ccache disabled:
>
> These tests seem to show no difference between the two releases, so I
> wonder what you're intending to demonstrate here.
They
ata divergence between
primary and standby and to old tuples re-appearing on either.
Another question: Do you use pg_repack or such?
Greetings,
Andres Freund
number of huge
pages. I don't think a system view or such would not help here.
Greetings,
Andres Freund
24kB is going to already be quite bad, so we don't
protect users much by forbidding a setting lower than 1MB.
Just for comparison, with a limit of 1MB, < 17 needed to do the first cleanup
pass after 174472 dead tuples. That's a 20x improvement. Really nice.
Greetings,
Andres Freund
[1\ htt
doesn't exist, we'll reenter
during the next call, and then do the same thing again.
I don't think this is a huge performance issue or anything, but somehow it
seems indicative of something being "wrong".
It seems likely we encounter this issue not just with gist, but I haven't
checked yet.
Greetings,
Andres Freund
Hi,
On 2024-05-16 15:01:31 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-05-16 14:50:50 -0400, Tom Lane wrote:
> >> The intention was certainly always that it be atomic. If it isn't
> >> we have got *big* trouble.
>
> > We unfortunately d
. See
https://postgr.es/m/CA%2BhUKGLhLGCV67NuTiE%3Detdcw5ChMkYgpgFsa9PtrXm-984FYA%40mail.gmail.com
Greetings,
Andres Freund
work, while noting other, far
smaller, things in the release notes, pretty much tells us that our work isn't
valued.
Greetings,
Andres Freund
ot;TAM" comes from for "table access method"? I
> find it thoroughly horrible and wish we didn't use it. What's wrong
> with using "table AM"? It's not that much longer, much clearer and
> reuses our well-established acronym AM.
Strongly agreed. I don't know why I dislike TAM so much though.
Greetings,
Andres Freund
we can deal with
duplicate function names. Are you thinking that somehow we'd end up with
symbol interposition or something?
Greetings,
Andres Freund
fits together
that well. If we either had TEXTDOMAIN reliably set across extensions or it'd
architecturally be pretty, I'd go for it, but imo it's neither.
Greetings,
Andres Freund
provide "extension
scoped" information, FWIW. Even just providing the full path to the extension
library could be useful.
Greetings,
Andres Freund
Hi,
On 2024-05-13 19:25:11 -0300, Fabrízio de Royes Mello wrote:
> On Mon, May 13, 2024 at 5:51 PM Andres Freund wrote:
> > It's not entirely trivial to provide errfinish() with a parameter
> indicating
> > the extension, but it's doable:
> >
> > 1) Have PG_
hen errors out, it'll be seens
as being part of postgres.
But I think that's ok - they're going to be properly errcode-ified etc.
Thoughts?
Greetings,
Andres Freund
>From 1c59c465f2d359e8c47cf91d1ea458ea3b64ec84 Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Mon, 13 May 2024 13:47:41
ink so. The bug is that something is modifying the buffer
despite it being exclusively locked.
I.e. what we likely have here is a bug somewhere in the hash index code.
Greetings,
Andres Freund
Hi,
On 2024-05-09 20:53:27 +0100, Dagfinn Ilmari Mannsåker wrote:
> Andres Freund writes:
> > On 2024-05-09 20:12:38 +0100, Dagfinn Ilmari Mannsåker wrote:
> >> Attached is a patch which adds a check-docs target for meson, which
> >> takes 0.3s on my laptop.
>
a lot slower on windows, fwiw, due to the number of
files being opened/created. I guess that might also be the case on slow
storage, due to filesystem journaling.
Greetings,
Andres Freund
th postgres_full_xml? I.e. you could just
have the alias_target depend on postgres_full_xml?
Greetings,
Andres Freund
ore flexible than having to have
precisely the right information in the startup message, and most clients not
needing it.
Greetings,
Andres Freund
like pg_stat_statements having its own,
fairly ... mediocre, stats storage shouldn't be necessary.
Do we need to increase the stats version, I didn't check if the order we
currently store things in and the numerical order of the stats IDs are the
same.
Greetings,
Andres Freund
Hi,
On 2024-05-06 12:37:26 -0500, Justin Pryzby wrote:
> On Mon, May 06, 2024 at 10:04:13AM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2024-05-06 09:05:38 -0500, Justin Pryzby wrote:
> > > In March, I noticed that a backend got stuck overnight doing:
> > &
ust" waiting for very slow IO? Is there a lot of
dirty memory? Particularly on these old kernels that can lead to very extreme
delays.
grep -Ei 'dirty|writeback' /proc/meminfo
> [...]
> Full disclosure: the VM that hit this issue today has had storage-level
> errors (reported here at ZZqr_GTaHyuW7fLp@pryzbyj2023), as recently as 3
> days ago.
So indeed, my suspicion from above is confirmed.
Greetings,
Andres Freund
On 2024-04-26 14:39:16 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I don't think enabling backtraces without a way to disable them is a good
> > idea
> > - security vulnerablilities in backtrace generation code are far from
> > unheard
> > of and can
at a GUC of this exact shape
> is a design dead end --- and that's what we're seeing now.
I don't think enabling backtraces without a way to disable them is a good idea
- security vulnerablilities in backtrace generation code are far from unheard
of and can make error handling a lot slower...
Greetings,
Andres Freund
On 2024-04-26 06:54:26 -0500, Jonathan S. Katz wrote:
> The Core Team would like to extend our congratulations to Melanie Plageman
> and Richard Guo, who have accepted invitations to become our newest
> PostgreSQL committers.
>
> Please join us in wishing them much success and few reverts!
ort, rather than the AIX (and windows) style. That'd
make it considerably less impactful on the buildsystem level. I don't know
what the performance difference is these days.
Greetings,
Andres Freund
Hi,
On 2024-04-18 10:54:18 +0200, Christoph Berg wrote:
> Re: Andres Freund
> > > This commit broke VPATH builds when the original source directory
> > > contains symlinks.
> > Argh, this is missing spaces around the '=', leading to the branch always
> > being en
eadahead is disabled or just not aggressive enough
after crossing segment boundaries, larger reads reduce the number of times
you're likely to be blocked waiting for read IO.
Which is also why I think that making MAX_SEND_SIZE configurable is a really
poor proxy for improving the situation.
We're imo much better off working on read_stream.[ch] support for reading WAL.
Greetings,
Andres Freund
o only
cast the pointers to the key type, i.e. char *. And incidentally that does
prevent the warning.
The reason it doesn't happen in newer versions of postgres is that we aren't
using guc_var_compare() in the relevant places anymore...
Greetings,
Andres Freund
have, but I think it will be
> tricky to do better, and I don't think I want to spend time on it, at
> least not now.
Oh, yea, that's clearly a much bigger and separate project...
Greetings,
Andres Freund
Hi,
On 2024-04-23 09:15:27 +1200, Thomas Munro wrote:
> I find myself wondering if symlinks should go on the list of "things
> we pretended Windows had out of convenience, that turned out to be
> more inconvenient than we expected, and we'd do better to tackle
> head-on with a more portable
log the current state, so we can in retrospect analyze e.g. whether
there was continual, but slow, replay progress, or whether replay was entirely
stuck. wait_for_catchup() not being debuggable has been a problem in many
different tests, so I think it's high time to fix that.
Greetings,
Andres Freund
On 2024-04-18 23:11:52 -0400, Tom Lane wrote:
> 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 se
so preventing coverage
for the actual scanner definition.
Greetings,
Andres Freund
ostgres is used extensively in our IBM product
> and is being exploited by multiple customers.
To be blunt: Then it'd have been nice to see some investment in that before
now. Both on the code level and the infrastructure level (i.e. access to
machines etc).
Greetings,
Andres Freund
Hi,
On 2024-04-18 09:03:21 -0400, Robert Haas wrote:
> On Wed, Apr 17, 2024 at 5:50 PM Andres Freund wrote:
> > > +If there are tablespace present in the backup, include tablespace_map as
> > > +a keyword parameter whose values is a hash. When tar_program is used,
Hi,
On 2024-04-18 09:07:43 -0300, Ranier Vilela wrote:
> On 18/04/2024 00:39, Andres Freund wrote:
> >There are lots of places that could benefit from adding 'static
> >const'.
>
> I found a few more places.
Good catches.
> Patch 004
>
> The opposite
are also quite useful for exploitation,
as one doesn't need to figure out precise addresses.
Greetings,
Andres Freund
On 2024-04-17 23:10:53 -0400, Tom Lane wrote:
> Jelte Fennema-Nio writes:
> > As I expected this problem was indeed fairly easy to address by still
> > building "backend/parser" before "interfaces". See attached patch.
>
> I think we should hold off on this. I found a simpler way to address
>
Hi,
Uh, huh.
On 2024-04-17 15:42:28 +0200, Christoph Berg wrote:
> Re: Andres Freund
> > https://git.postgresql.org/pg/commitdiff/e6927270cd18d535b77cbe79c55c6584351524be
>
> This commit broke VPATH builds when the original source directory
> contains symlinks.
I.e. a sym
paces instead?
Looks like it'd simplify at least the extended test somewhat?
Greetings,
Andres Freund
that.
Greetings,
Andres Freund
>From d43a10b5ba46b010c8e075b1062f9f30eb013498 Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Wed, 17 Apr 2024 14:27:03 -0700
Subject: [PATCH v1 1/3] static const: Convert struct option arrays
---
src/bin/initdb/initdb.c | 2 +-
src/
On 2024-04-16 07:32:55 +0900, Michael Paquier wrote:
> On Mon, Apr 15, 2024 at 11:57:20AM -0700, Andres Freund wrote:
> > GlobalVisTestNonRemovableHorizon()/GlobalVisTestNonRemovableFullHorizon()
> > only
> > existed for snapshot_too_old - but that was removed in f691f5b80
within
the backend, according to -Wl,--gc-sections,--print-gc-sections. A lot of that
is entirely expected stuff, like RegisterXactCallback(). But there are also
long-unused things like TransactionIdIsActive().
Greetings,
Andres Freund
t; + * is done.
> + */
> + while (!CommitTransactionCommandInternal());
Personally I'd use
{
}
instead of just ; here. The above scans weirdly for me. But it's also not
important.
Greetings,
Andres Freund
Hi,
On 2024-04-17 12:07:24 +0100, Dagfinn Ilmari Mannsåker wrote:
> Andres Freund writes:
> > I think the manual work for writing signatures in sgml is not insignificant,
> > nor is the volume of sgml for them. Manually maintaining the signatures
> > makes
> > it i
functions.sql, 1016 occurrences of
func_table_entry in funcs.sgml and 3.3k functions in pg_proc. I'm not saying
that differences due to system_functions.sql wouldn't be annoying to deal
with, but it'd also be far from the end of the world.
Greetings,
Andres Freund
Hi,
On 2024-04-16 15:05:32 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I think we should work on generating a lot of func.sgml. Particularly the
> > signature etc should just come from pg_proc.dat, it's pointlessly painful to
> > generate that by hand. And for a lo
Hi,
On 2024-04-15 18:23:21 -0700, Jeff Davis wrote:
> On Mon, 2024-04-15 at 17:05 -0700, Andres Freund wrote:
> > Can't we test this as part of the normal testsuite?
>
> One thing that complicates things a bit is that the test compares the
> results against ICU, so a mismatch
m pg_proc,
because of xrefs etc. Although perhaps we could just strip those out for
pg_proc.
We'd need to add some more metadata to pg_proc, for grouping kinds of
functions together. But that seems doable.
Greetings,
Andres Freund
tially be addressed by having more "block oriented AM"
helpers in core, like we have for table_block_parallelscan*. Doesn't work for
everything, but should for something like analyze.
Greetings,
Andres Freund
On 2024-04-16 13:33:53 +0300, Alexander Korotkov wrote:
> Reverted.
Thanks!
Hi,
On 2024-04-15 10:54:16 -0400, Robert Haas wrote:
> On Fri, Apr 12, 2024 at 3:33 PM Andres Freund wrote:
> > Here's a patch implementing this approach. I confirmed that before we
> > trigger
> > the stuck spinlock logic very quickly and after we don't. Howeve
Hi,
On 2024-04-16 15:45:42 +0300, Alexander Korotkov wrote:
> On Tue, Apr 16, 2024 at 1:48 AM Andres Freund wrote:
> > On 2024-03-06 14:17:23 +0200, Alexander Korotkov wrote:
> > > 0001 Turn tail recursion into iteration in CommitTransactionCommand()
> > > I did
r as you have it.
> > Hm, independent of this, seems a bit odd that we don't include the memory
> > context type in pg_backend_memory_contexts?
>
> That seems like useful information to include. It sure would be
> useful to have in there to verify that I'm testing BumpStats(). I've
> written a patch [2].
Nice!
Greetings,
Andres Freund
Hi,
On 2024-04-15 20:47:16 -0400, Tom Lane wrote:
> 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
s 1.10, released 2020-01-27.
Greetings,
Andres Freund
Hi,
On 2024-04-15 16:53:48 -0700, Jeff Davis wrote:
> On Sun, 2024-04-14 at 15:33 -0700, Andres Freund wrote:
> > - Coverage for some of the new unicode code is pretty poor:
> >
> > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/common/unicode_category.c.gcov
64d7 has now
> baked long enough that it'd be safe to back-patch.
Looks like a reasonable plan to me.
Greetings,
Andres Freund
ck, because it leads to the build failing
because of main being duplicated. But it'd work the same with another, "non
overlapping", file.
Greetings,
Andres Freund
Hi,
On 2024-04-16 10:26:57 +1200, David Rowley wrote:
> On Mon, 15 Apr 2024 at 10:33, Andres Freund wrote:
> > - The new bump allocator has a fair amount of uncovered functionality:
> >
> > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/backend/utils/mmgr/
n() calls?
That's of course largely unrelated to the coverage aspects. I just got
curious.
Greetings,
Andres Freund
Hi,
On 2024-04-15 15:36:04 -0400, Robert Haas wrote:
> On Sun, Apr 14, 2024 at 6:33 PM Andres Freund wrote:
> > - Some of the new walsummary code could use more tests.
> >
> > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/backend/backup/walsummaryfuncs.c.
Hi,
On 2024-04-15 16:02:00 -0400, Robert Haas wrote:
> On Mon, Apr 15, 2024 at 3:47 PM Andres Freund wrote:
> > That said, I don't like the state after applying
> > https://postgr.es/m/CAPpHfdvuT6DnguzaV-M1UQ2whYGDojaNU%3D-%3DiHc0A7qo9HBEJw%40mail.gmail.com
> > because ther
ations before calling acquirefunc.
This is honestly leaving me somewhat speechless.
Greetings,
Andres Freund
nterface in some form, earlier in the thread.
What are you actually arguing for here?
Greetings,
Andres Freund
Hi,
GlobalVisTestNonRemovableHorizon()/GlobalVisTestNonRemovableFullHorizon() only
existed for snapshot_too_old - but that was removed in f691f5b80a8. I'm
inclined to think we should remove those functions for 17. No new code should
use them.
Greetings,
Andres Freund
age/buffer/bufmgr.c.gcov.html#L5978
...
Greetings,
Andres Freund
#2333
Greetings,
Andres Freund
nfortunately the logs aren't accessible anymore, so I can't check the precise
patch level of the compiler and/or the precise invocation used.
Greetings,
Andres Freund
Thoughts?
On the code level, I thought if it'd be good to have a common prefix for all
the automatically set variables. Right now that's CI_, but I'm not at all
wedded to that.
Greetings,
Andres Freund
>From 5d26ecfedbcbc83b4cb6e41a34c1af9a3ab24cdb Mon Sep 17 00:00:00 2001
From: Andres Freund
he automated image generation
for CI:
https://github.com/anarazel/pg-vm-images/blob/main/scripts/windows_install_mingw64.ps1#L21-L22
I wonder if we should maintain something like that list somewhere in the
postgres repo instead...
Greetings,
Andres Freund
Hi,
On 2024-04-12 11:33:17 -0700, Andres Freund wrote:
> I wonder if, for easy backpatching, the easiest solution is to just reset
> errno before calling pg_usleep(), and only increment status->delays if
> errno != EINTR. Given our pg_usleep() implementations, that'd preven the stuc
Hi,
Given that I found several ways to spuriously trigger the stuck spinlock
logic, I think we need to backpatch a fix.
On 2024-04-11 21:41:39 -0700, Andres Freund wrote:
> Tracking the total amount of time spent sleeping doesn't require any
> additional syscalls, due to the nanosleep()
lots of creaky old code
- libpam - undermaintained, lots of creaky old code
- the rest
Greetings,
Andres Freund
Hi,
On 2024-04-12 09:43:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Oh my. There's a workload that completely trivially hits this, without even
> > trying hard. LISTEN/NOTIFY.
>
> Hm. Bug in the NOTIFY logic perhaps?
I don't think it's a bug, async.c:SignalB
Hi,
On 2024-04-11 21:41:39 -0700, Andres Freund wrote:
> FWIW, I just reproduced the scenario with signals. I added tracking of the
> total time actually slept and lost to SpinDelayStatus, and added a function to
> trigger a wait on a spinlock.
>
> To wait less, I set max_standby_
Hi,
On 2024-04-11 20:47:37 -0700, Andres Freund wrote:
> > So there's that. But that's not an argument that we need to be in a
> > hurry to timeout; if the built-in reaction time is less than perhaps
> > 10 minutes you're still miles ahead of the manual solution.
>
1 - 100 of 8843 matches
Mail list logo
