Hi,
On July 3, 2024 3:17:29 PM GMT+02:00, Joe Conway wrote:
>On 7/2/24 17:39, Thomas Munro wrote:
>> One difference that jumps out is that the successful v3 run has label
>> worker:jc-m2-1 (Mac hosted by Joe), and the failure has
>> worker:pgx-m2-1 (Mac hosted by Christophe P). Is this a
Hi,
On 2024-07-01 21:12:25 +0200, Alvaro Herrera wrote:
> On 2024-Jul-01, Andres Freund wrote:
>
> > On 2024-07-01 11:10:24 +0200, Alvaro Herrera wrote:
> > > In the meantime I noticed that pg_attribute_aligned() is not supported
> > > in every platform/compiler, s
_atomic_compare_exchange_u64_impl(ptr, , target_))
> + if (pg_atomic_compare_exchange_u64_impl(ptr, ,
> target_))
> break;
> }
>
> - return Max(target_, currval);
> + return Max(target_, currval.u64);
What does the Max() actually achieve here? Shouldn't it be impossible to reach
this with currval < target_?
And why does target_ end in an underscore?
Greetings,
Andres Freund
On 2024-06-25 14:35:00 -0400, Robert Haas wrote:
> Is there any way that we could instead tweak things so that we adjust
> the visibility test object itself? Like can have a GlobalVisTest API
> where we can supply the OldestXmin from the VacuumCutoffs and have it
> ... do something useful with
Hi,
On 2024-06-25 12:31:11 -0400, Robert Haas wrote:
> On Tue, Jun 25, 2024 at 11:39 AM Melanie Plageman
> wrote:
> > On Tue, Jun 25, 2024 at 10:31 AM Robert Haas wrote:
> > > On Tue, Jun 25, 2024 at 9:07 AM Andres Freund wrote:
> > > > It's not hard -
whether we should fix this while the SDK is in
> beta or only after it is released.
Yea.
Greetings,
Andres Freund
On 2024-06-25 08:42:02 -0400, Robert Haas wrote:
> On Tue, Jun 25, 2024 at 8:03 AM Andres Freund wrote:
> > I think that's going in the wrong direction. We *want* to prune more
> > aggressively if we can (*), the necessary state is represented by the
> > vistest. That's a
vacuum. At some point in the middle
> of the vacuum, A ends the transaction. Are you saying that B's
> GlobalVisTest never really notices that this has happened?
Not at the moment, but we should add heuristics like that.
Greetings,
Andres Freund
ld be reasonable.
I think 1) often just leads to either tests not being written or being
fragile...
Greetings,
Andres Freund
ed binaries so there was a
> heavy focus on making sure everything was designed around the MSVC++ builds
> wherever they existed.
Agreed, this luckily got easier. But it also increased the variety of expected
library names / flags. It's entirely reasonable to build postgres with msvc
against an gcc built ICU or whatnot.
Greetings,
Andres Freund
cases are a bit less trivial
to search for.
Greetings,
Andres Freund
[1]
https://postgr.es/m/CAGPVpCSKS9E0An4%3De7ZDnme%2By%3DWOcQFJYJegKO8kE9%3Dgh8NJKQ%40mail.gmail.com
, xslt and uuid work without
patching the sources.
Greetings,
Andres Freund
40
If you want to run just the main regression tests with meson, you can:
meson test --suite setup --suite regress
To see the list of all tests
meson test --list
Greetings,
Andres Freund
Hi,
On June 22, 2024 7:32:01 PM GMT+02:00, walt...@technowledgy.de wrote:
>Andres Freund:
>> FWIW, dynamic linking has a noticeable overhead on other platforms too. A
>> non-dependencies-enabled postgres can do about 2x the connections-per-second
>> than a fully ki
d on whether the header and library can be found. I
> had to pass extra lib and include dirs:
Yea, right now libintl isn't using dependency detection because I didn't see
any platform where it's distributed with a .pc for or such. It'd be just a
line or two to make it use one...
Greetings,
Andres Freund
Hi,
On 2024-06-21 12:20:49 +0100, Dave Page wrote:
> On Thu, 20 Jun 2024 at 21:58, Andres Freund wrote:
> That is precisely what https://github.com/dpage/winpgbuild/ was intended
> for - and it works well for PG <= 16.
If we develop it into that - I'd be happy. I mostly want to b
or example:
-
https://github.com/microsoft/vcpkg/blob/master/ports/libpq/windows/msbuild.patch
-
https://github.com/conan-io/conan-center-index/blob/1b24f7c74994ec6573e322b7ae4111c10f620ffa/recipes/libpq/all/conanfile.py#L116-L160
- https://github.com/conda-forge/postgresql-feedstock/tree/main/recipe/patches
Greetings,
Andres Freund
Hi,
On 2024-06-18 12:00:13 -0700, Andres Freund wrote:
> On 2024-06-18 10:10:17 -0700, Noah Misch wrote:
> > > 1) Sometimes hangs hard on windows if started processes have not been shut
> > >down before script exits. I've mostly encountered this via the
> > >
Hi,
On 2024-06-18 16:09:09 -0500, Nathan Bossart wrote:
> On Tue, Jun 18, 2024 at 01:43:34PM -0700, Andres Freund wrote:
> > I just don't see much point in reserving 256 worker "possibilities", tbh. I
> > can't think of any practical system where it makes sense to use thi
Hi,
On 2024-06-18 08:36:57 -0500, Justin Pryzby wrote:
> On Fri, Jun 14, 2024 at 08:34:37AM -0700, Andres Freund wrote:
> > Hm. There actually already is the mingw ccache installed. The images for
> > mingw and msvc used to be separate (for startup performance when using
> >
Hi,
On 2024-06-18 14:00:00 -0500, Nathan Bossart wrote:
> On Mon, Jun 03, 2024 at 04:24:27PM -0700, Andres Freund wrote:
> > 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 th
ers) and/or barely gives time to switch to other tasks.
So we'd have to increase the cost limit.
Greetings,
Andres Freund
nch to be made,
> and then apply 0001 in HEAD/v18 only and 0002 in v17 and before.
> While 0001 seems fairly straightforward, it's still a nontrivial
> change and I'm hesitant to shove it in at this late stage of the
> v17 cycle.
Seems reasonable.
Greetings,
Andres Freund
Hi,
On 2024-06-18 10:10:17 -0700, Noah Misch wrote:
> On Mon, Jun 17, 2024 at 11:11:17AM -0700, Andres Freund wrote:
> > On 2024-06-15 16:48:24 -0700, Noah Misch wrote:
> > > On Sat, Jun 15, 2024 at 01:26:57PM -0400, Robert Haas wrote:
> > > > The one
> > &
Hi,
On 2024-06-18 15:54:27 +0100, Dave Page wrote:
> On Tue, 18 Jun 2024 at 15:38, Andres Freund wrote:
> > Do you have logs for those failures?
> >
>
> Sure - https://developer.pgadmin.org/~dpage/build-logs.zip. Those are all
> without any modifications to %LIB% or %IN
ee_c_sixty = 60.0;
Yikes, this is bad code. Relying on extern to have effects like this will just
break with lto. But not the responsibility of this patch.
> From 649e8086df1f175e843b26cad41a698c8c074c09 Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut
> Date: Wed, 8 May 2024 13:49:37 +0200
> Subject: [PATCH v2 10/10] Fix -Wmissing-variable-declarations warnings in
> bison code
>
> Add extern declarations for global variables produced by bison.
:(
Greetings,
Andres Freund
typically rely on finding things in either known installation directories
> or through lib/include vars.
I am not really following what you mean with the cmake bit here?
You can configure additional places to search for cmake files with
meson setup --cmake-prefix-path=...
> There really aren't standard directories like
> /usr/lib or /usr/include as we find on unixes, or pkgconfig files for
> everything.
Yes, and?
Greetings,
Andres Freund
doing something dangerous
is useful, for debugging or corruption recovery. If we flat out prohibit this
we'll just need a allow_system_table_mods_but_for_real option.
Greetings,
Andres Freund
OPT to CXXFLAGS as well. I think passing
> -Werror is just about the only reasonable use of COPT nowadays, so making
> that more robust seems useful. I don't think there is a need for a separate
> make variable for C++ here.
+1
Greetings,
Andres Freund
Hi,
On 2024-06-17 22:42:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-06-17 23:52:54 +0200, Daniel Gustafsson wrote:
> >> Since sqlca is, according to our docs, present in other database systems we
> >> should probably keep it a 5-char array for p
"X" and thatshortstr is printed:
printf("\"%s\": \"%s\" %d\n", bigstr, shortstr, shstr_ind);
Greetings,
Andres Freund
populates a relcache entry, then does DDL on the rel
> > after recovery ends.
Hm. The problematic cases presumably involves an access exclusive lock? If so,
could we do LogStandbyInvalidations() *before* logging the WAL record for the
inplace update? The invalidations can't be processed by other backends until
the exclusive lock has been released, which should avoid the race?
Greetings,
Andres Freund
an just
defaulting such code into changed semantics.
Greetings,
Andres Freund
n-access pruning.
- Larger tables with occasional lock conflicts cause autovacuum to be
cancelled and restarting from scratch over and over. If that happens before
the second table scan, this can easily eat up the whole cost budget without
making forward progress.
Greetings,
Andres Freund
in the way postgres is generating LLVM IR: please file a bug against
> > Postgres. (Feel free to reopen if you have some reason to believe the issue
> > is on the LLVM side.)
I suspect the issue might be that the version of clang and LLVM are diverging
too far. Does it work if you pass
e GUC here?
This also needs to change the documentation for the GUC.
Once we have this parameter we probably should add at least x25519 to the
allowed list, as that's the client side default these days.
But that can be done in a separate patch.
Greetings,
Andres Freund
ive side, due to a) increased number of syscalls b) too many
small packets being sent, as we use TCP_NODELAY c) kernel memory copies being
slower due to the small increments.
Greetings,
Andres Freund
y. It seems to be timing
dependent, I've encountered it after seemingly irrelevant ordering changes.
I suspect I could create a reproducer with a bit of time.
3) It's very slow on windows (in addition to the windows process
slowness). That got to be fixable to some degree.
Greetings,
Andres Freund
Hi,
On 2024-06-17 19:51:45 +0200, Daniel Gustafsson wrote:
> > On 17 Jun 2024, at 19:44, Andres Freund wrote:
>
> >> Let's bring that to Erica's patch for allowing a list of curves.
> >
> > I'm kinda wondering if we ought to do something about this in the
> &g
o do something about this in the
backbranches. Forcing unnecessary roundtrips onto everyone for the next five
years due to an oversight on our part isn't great. Once you're not local, the
roundtrip does measurably increase the "time to first query".
Greetings,
Andres Freund
separately), but I don't really understand most of this stuff.
Greetings,
Andres Freund
Hi,
On 2024-06-17 12:00:30 +0200, Daniel Gustafsson wrote:
> > On 17 Jun 2024, at 01:46, Andres Freund wrote:
>
> > When connecting with a libpq based client, the TLS establishment ends up
> > like
> > this in many configurations;
> >
> > C->S: TLSv1 39
ipt, they then should get automatically
cached.
Greetings,
Andres Freund
d almost be considered a small bug...
Greetings,
Andres Freund
Hi,
On 2024-06-16 19:07:49 -0400, Tom Lane wrote:
> Thomas Munro writes:
> > On Mon, Jun 17, 2024 at 10:38 AM Andres Freund wrote:
> >> I'm somewhat doubtful we'll just agree on making FFI::Platypus a hard
> >> dependency, but if we agree to do so...
>
> >
Hi,
On 2024-06-16 17:43:05 -0400, Andrew Dunstan wrote:
> On Fri, Jun 14, 2024 at 12:25 PM Andres Freund wrote:
> I guess it's a question of how widely available FFI::Platypus is. I know
> it's available pretty much out of the box on Strawberry Perl and Msys2'
> ucrt perl.
FWIW I
unning them via
"top-level" tools for different test types just won't work well. That's not
true for many projects where tests have vastly lower resource usage.
Greetings,
Andres Freund
Hi,
On 2024-06-14 12:27:12 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Initializing the gss cache at all isn't so much the problem. It's that we do
> > it for every connection. And that doing so requires locking inside gss. So
> > maybe we could just globally
endency, a small XS
wrapper could be an alternative.
Greetings,
Andres Freund
On 2024-06-14 09:11:11 -0700, Andres Freund wrote:
> On 2024-06-14 11:49:29 -0400, Tom Lane wrote:
> > Am I right in guessing that pytest will have nothing to do with that?
>
> Looks like there's a plugin for pytest to support tap as output:
> https://pypi.org/project/pytest
feature that cannot
> integrate with what we have because it demands its own control and
> result-collection infrastructure.
Dito.
Greetings,
Andres Freund
ver and over for every new connection.
Greetings,
Andres Freund
Hi,
On June 14, 2024 8:09:43 AM PDT, Andrew Dunstan wrote:
>Over at [1] Andres expressed enthusiasm for enabling TAP tests to call LibPQ
>directly via FFI, and there was some support from others as well. Attached is
>a very rough POC for just that.There are two perl modules, one which wraps
Hi,
On June 14, 2024 8:22:01 AM PDT, Justin Pryzby wrote:
>On Fri, Jun 14, 2024 at 05:36:54PM +0300, Nazir Bilal Yavuz wrote:
>> Hi,
>>
>> On Thu, 13 Jun 2024 at 14:56, Justin Pryzby wrote:
>> >
>> > ccache should be installed in the image rather than re-installed on each
>> > invocation.
>>
Hi,
On 2024-06-13 17:33:57 +0200, Dmitry Dolgov wrote:
> > On Mon, Jun 10, 2024 at 11:12:12AM GMT, Andres Freund wrote:
> > Hi,
> >
> > To investigate a report of both postgres and pgbouncer having issues when a
> > lot of new connections aree establis
"AVX-512 popcount without -mavx512vpopcntdq -mavx512bw" : links: NO
(cached)
Checking if "AVX-512 popcount with -mavx512vpopcntdq -mavx512bw" : links: YES
(cached)
Checking if "_mm512_clmulepi64_epi128 ... with -msse4.2 -mavx512vl
-mvpclmulqdq" : links: YES
Checking if "x86_64: popcntq instruction" compiles: YES (cached)
Greetings,
Andres Freund
small
amounts of data.
Greetings,
Andres Freund
Hi,
On 2024-06-12 14:33:31 -0400, Robert Haas wrote:
> On Wed, Jun 12, 2024 at 2:11 PM Andres Freund wrote:
> >
> >
> > In an extreme case i can see a tiny bit of overhead, but not enough to be
> > worth worrying about. Mostly because we're so profligate in doing
rgejoin_enabled for right joins inside select_mergejoin_clauses(),
but we don't call select_mergejoin_clauses() if !enable_mergejoin and jointype
!= FULL. I, what?
Greetings,
Andres Freund
Hi,
On 2024-06-11 07:28:23 -0700, Jacob Champion wrote:
> On Mon, Jun 10, 2024 at 1:04 PM Andres Freund wrote:
> > Just for context for the rest the email: I think we desperately need to move
> > off perl for tests. The infrastructure around our testing is basically
> >
new framework might have value, I don't
> think we need to run out and immediately rewrite several hundred TAP tests.
Oh, yea. That's not at all feasible to just do in one go.
Greetings,
Andres Freund
something we (PG devs) really can do
anything about. It's also
a) fairly easy thing to fix
b) fails during compilation
c) doesn't break ABI afaict
Greetings,
Andres Freund
se `sizeof(the struct)` or create their
> own instances of such structs --- patterns best avoided.
The padding case doesn't affect sizeof() fwiw.
I think there's too often not an alternative to using sizeof(), potentially
indirectly (via makeNode() or such. So this sounds a bit too general.
Greetings,
Andres Freund
Hi,
On 2024-06-07 21:42:58 +0300, Radu Radutiu wrote:
> On Fri, Jun 7, 2024 at 7:59 PM Andres Freund wrote:
> > On 2024-06-06 15:25:25 +0300, Radu Radutiu wrote:
> > > I have a query that forces an out of memory error, where the OS will kill
> > > the postgresql pr
Hi,
On 2024-06-10 16:46:56 -0400, Andrew Dunstan wrote:
>
> On 2024-06-10 Mo 16:04, Andres Freund wrote:
> > Hi,
> >
> >
> > Just for context for the rest the email: I think we desperately need to move
> > off perl for tests. The infrastructure around our t
I think somewhere between 1 and 4 a *substantial* amount of work would be
required to provide a bunch of the infrastructure that Cluster.pm etc
provide. Otherwise we'll end up with a lot of copy pasted code between tests.
Greetings,
Andres Freund
ere doesn't seem to indicate that
this is an area where we need to invest additional resources. We are already
severely constrained as a project by committer bandwidth, there are plenty
other things that seem more important to focus on.
Greetings,
Andres Freund
enerate a bunch of noise, but I think it's almost exclusively due to our
MemSet() macro.
Greetings,
Andres Freund
ned)
PQconnectStartParams
PQconnectdbParams
doConnect
Clearly the contention originates outside of our code, but is triggered by
doing pg_GSS_have_cred_cache() every time a connection is established.
Greetings,
Andres Freund
quence = r.input_sequence
rpl_snd_tro.reply_input_sequence = r.input_sequence
snd_tro.reply_input_sequence = t.input_sequence
First two are r.input_sequence to different columns, the third one also uses
reply_input_sequence but joins to t, not r.
Greetings,
Andres Freund
rs of tuples etc.
Greetings,
Andres Freund
reason we don't callback for 2pc commit/rollback prepared is
simpl: The code for doing a 2pc commit prepared lives in twophase.c, not
xact.c...
Greetings,
Andres Freund
help? And i don't see a
reason to strictly keep the structure size the same.
Greetings,
Andres Freund
portant when we crash: We've been talking about storing a
snapshot of the stats alongside each REDO pointer. Combined with updating
stats during crash recovery, we'll have accurate dead-tuple stats once recovey
has finished.
Greetings,
Andres Freund
lenodes" and "current relfilenode" - except that stats get reset manually
and upon crash anyway, making this less useful than if it were really
"lifetime" stats.
Greetings,
Andres Freund
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
1 - 100 of 8918 matches
Mail list logo
