ect if JIT is supported is by trying to load
the configured JIT backend (jit_provider GUC).
Greetings,
Andres Freund
Hi,
On 2025-02-05 14:20:59 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2025-02-05 14:09:02 -0500, Tom Lane wrote:
> >> Hard to tell, considering the cfbot has been completely wedged
> >> since Sunday.
>
> > It passed on the postgres repo just befo
sed on the postgres repo just before this commit:
https://cirrus-ci.com/build/4733656549294080
and then failed with it:
https://cirrus-ci.com/build/5944955807465472
Greetings,
Andres Freund
Hi,
On 2025-02-05 19:42:05 +0100, Jelte Fennema-Nio wrote:
> On Wed, 5 Feb 2025 at 00:22, Andres Freund wrote:
> > Pushed like that.
> >
> > I'll watch CI and BF over the next hours.
>
> I guess you probably noticed, but in case you didn't: CI on windows is
a) doesn't have ordered access support, which causes a bunch of O(NBuffers)
operations and makes things like readahead etc way more expensive
b) doesn't benefit from spatial locality, even though buffer lookups have a
very high degree of spatial locality
Greetings,
Andres Freund
r, I'd expect it
to change noticeably. Might also be worth at looking at perf stat for cache
misses, hitm, etc.
Greetings,
Andres Freund
Hi,
I pushed these changes as part of
https://postgr.es/m/fucdlk6bgvrz6vb6ruscxa5xof5w2c3voxoqontl7oasf4idxl%40uyljndimefct
Greetings,
Andres Freund
Hi,
On 2025-02-04 12:46:42 -0500, Andres Freund wrote:
> On 2025-01-30 16:18:54 +0300, Nazir Bilal Yavuz wrote:
> > On Wed, 29 Jan 2025 at 19:50, Andres Freund wrote:
> > > I don't think that's the entirety of the issue.
> > >
> > > Our dep
Hi,
On 2025-01-30 16:18:54 +0300, Nazir Bilal Yavuz wrote:
> On Wed, 29 Jan 2025 at 19:50, Andres Freund wrote:
> > I don't think that's the entirety of the issue.
> >
> > Our dependencies aren't quite airtight enough. With a sufficiently modern
> &
gt; tab->at_params.toast_parent = InvalidOid;
> +
> + /*
> + * Later we check reloptions for
> vacuum_max_eager_freeze_failure_rate
> + * override
> + */
> + tab->at_params.max_eager_freeze_failure_rate =
> vacuum_max_eager_freeze_failure_rate;
> tab->at_storage_param_vac_cost_limit = avopts ?
> avopts->vacuum_cost_limit : 0;
> tab->at_storage_param_vac_cost_delay = avopts ?
I'd mention where that is, so that a reader of that comment doesn't have to
search around...
I think this is pretty close!
Greetings,
Andres Freund
Hi,
On 2025-02-01 15:43:41 +0100, Ants Aasma wrote:
> On Fri, Jan 31, 2025, 15:43 Andres Freund wrote:
>
> > > Maybe it's a red herring though, but it looks pretty suspicious.
> >
> > It's unfortunately not too surprising - our buffer mapping table is a
when it's off, the replica behaves
> worse, more replication lag).
Yea, I was hoping for a profile with recovery_prefetch=off, so we can see what
records are causing most of the "slow" lookups.
Greetings,
Andres Freund
Hi,
On January 31, 2025 5:22:43 PM EST, Robert Treat wrote:
>On Fri, Jan 31, 2025 at 10:25 AM Andres Freund wrote:
>>
>> Hi,
>>
>> On 2025-01-30 21:24:05 -0500, Andres Freund wrote:
>> > On January 30, 2025 8:55:36 PM EST, Tom Lane wrote:
>> > >
#include
>
> #ifdef ENABLE_GSS
> -#if defined(HAVE_GSSAPI_H)
> -#include
> -#else
> -#include
> -#endif /*
> HAVE_GSSAPI_H */
> +#include "libpq/pg-gssapi.h"
> #endif /* ENABLE_GSS */
This #ifdef ENABLE_GSS probably isn't necessary anymore.
Greetings,
Andres Freund
Hi,
On 2025-01-30 21:24:05 -0500, Andres Freund wrote:
> On January 30, 2025 8:55:36 PM EST, Tom Lane wrote:
> >Andres Freund writes:
> >> While working on polishing the AIO patchset, I was trying to figure out
> >> where
> >> to fit the new GUCs. So fa
ng table due to the lack of locality and because dynahash is
really poor hash table implementation.
Greetings,
Andres Freund
Hi
On January 30, 2025 8:55:36 PM EST, Tom Lane wrote:
>Andres Freund writes:
>> While working on polishing the AIO patchset, I was trying to figure out where
>> to fit the new GUCs. So far I had a new "top-level" #--- style section named
>> "WIP AIO GUC doc
3 # 1-32; relevant only if io_method =
worker
Greetings,
Andres Freund
Hi,
On 2025-01-29 18:24:45 +0300, Nazir Bilal Yavuz wrote:
> On Tue, 28 Jan 2025 at 17:02, Andres Freund wrote:
> >
> > Hi,
> >
> > On January 28, 2025 7:13:16 AM EST, Jelte Fennema-Nio
> > wrote:
> > >Since about ~11 hours ago the ecpg test is con
_startup_packet_die()
actually need to do _exit(), we should be able to do non-blocking network IO
around these parts - at least for SSL we largely do, we just don't check for
interupts in in the right places.
Other questions:
- Can ipc/interrupts.c style interrupts be sent by postmaster? I think they
ought to before long.
Greetings,
Andres Freund
y_barrier();
I don't think you need a memory barrier between signal handler and normal
code. A compiler barrier, sure, sometimes also something to protect against
partial writes. but memory barriers shouldn't be needed.
> +/*
> + * Set an interrupt flag in this backend.
> + */
> +void
> +RaiseInterrupt(InterruptType reason)
> +{
> + uint32 old_pending;
> +
> + old_pending = pg_atomic_fetch_or_u32(MyPendingInterrupts, 1 << reason);
> +
> + /*
> + * If the process is currently blocked waiting for an interrupt to
> arrive,
> + * and the interrupt wasn't already pending, wake it up.
> + */
> + if ((old_pending & (1 << reason | 1 << SLEEPING_ON_INTERRUPTS)) == 1 <<
> SLEEPING_ON_INTERRUPTS)
This is a somewhat hard to read line. Maybe it's worth breaking it out into
two conditions? Or use a local variable?
Greetings,
Andres Freund
Hi,
On January 28, 2025 7:13:16 AM EST, Jelte Fennema-Nio
wrote:
>Since about ~11 hours ago the ecpg test is consistently failing on
>Window with this error[1]:
>
>> Could not open file
>> C:/cirrus/build/src/interfaces/ecpg/test/compat_informix/dec_test.c for
>> reading
>
>I took a quick loo
Hi,
On 2025-01-26 13:10:35 -0500, Andres Freund wrote:
> On 2025-01-25 16:06:29 -0800, Jacob Brazeal wrote:
> > diff --git a/src/backend/storage/lmgr/lwlock.c
> > b/src/backend/storage/lmgr/lwlock.c index 2f558ffea1..d3a2619072 100644 ---
> > a/src/backend/storage/lmgr/lwloc
(which just guarantees that the compiler isn't eliding the read and that the
read isn't torn). Personally I don't think there's a need to rephrase the
comment, but I probably wrote it, so take that with a grain of salt.
Greetings,
Andres Freund
PS: FYI, this list values properly quoting messages instead of replying ontop
of the entire quoted messages.
kends (up to 2^18-1) here and not the
> size of the ProcNumber data type. So I do think the comment should read
> 2^18-1 and not 2^23-1. Here is a patch to that effect.
At the time that comment was written MAX_BACKENDS was 2^23-1. Alexander and I
lowered MAX_BACKENDS in 48354581a49c to 2^18-1 and
Hi,
On 2025-01-24 15:06:17 -0500, Andres Freund wrote:
> Unless somebody argues against, I'm planning to push all but the last later
> today, wait for the buildfarm to settle, and then push the last. This is a
> dependency of multiple other things, so it'd be good to get it i
se-local relation and once with
a shared rel.
"Scenario 4":
Doesn't expect to trigger a conflict, so the race doesn't matter.
"Scenario 5":
Theoretically racy, but the window seems much smaller, it looks like the
conflict has multiple chances to be triggered due to each of the updates
happening in a separate session (and thus transaction).
Greetings,
Andres Freund
push all but the last later
today, wait for the buildfarm to settle, and then push the last. This is a
dependency of multiple other things, so it'd be good to get it in soon.
On 2025-01-15 08:38:33 +, Bertrand Drouvot wrote:
> On Tue, Jan 14, 2025 at 06:55:03PM -0500, Andres Freund
iscussion of the failure there:
> https://www.postgresql.org/message-id/657815a2-5a89-fcc1-1c9d-d77a6986b...@gmail.com
> (In short, I observed that that test suffers from bgwriter's activity.)
I don't think it's quite right to blame this on bgwriter. E.g. a checkpoint
will also emit XLOG_RUNNING_XACTS. The problem is that the test just is racy
and that needs to be fixed.
Greetings,
Andres Freund
Hi,
On 2025-01-24 14:23:26 -0500, Andres Freund wrote:
> On 2025-01-24 11:42:15 -0500, Tom Lane wrote:
> There's a failure before this one:
> [05:23:54.643](0.013s) not ok 23 - activeslot slot invalidation is logged
> with vacuum on pg_class
>
>
> > This has been ha
og.pl?nm=drongo&dt=2024-10-14%2016%3A39%3A49
Which fail like this:
- 8< -
stderr:
# poll_query_until timed out executing this query:
#
# SELECT 'waiting' FROM pg_locks WHERE locktype = 'relation' AND NOT granted;
#
# expecting this output:
# waiting
# last actual query output:
#
# with stderr:
# Failed test 'startup deadlock: lock acquisition is waiting'
# at C:/prog/bf/root/HEAD/pgsql/src/test/recovery/t/031_recovery_conflict.pl
line 261.
Greetings,
Andres Freund
r3
That's not *really* comparable, because the role membership in question isn't
being dropped, but still.
> FWIW I'm assuming we're not looking for a "fix" for already released
> versions, right?
I suspect that changing it in a minor version would cause trouble for another
set of users...
Greetings,
Andres Freund
Hi,
On 2025-01-22 09:50:18 -0800, Paul Ramsey wrote:
> > On Jan 22, 2025, at 9:36 AM, Andres Freund wrote:
> > On 2025-01-22 10:22:45 -0600, Nathan Bossart wrote:
> >> On Wed, Jan 22, 2025 at 07:57:52AM -0800, Paul Ramsey wrote:
> >>> The problem we are having i
Hi,
On 2025-01-22 11:43:20 -0600, Nathan Bossart wrote:
> On Wed, Jan 22, 2025 at 11:21:03AM -0500, Andres Freund wrote:
> > fsync(open(oldname1));
> > fsync(open(oldname2));
> > ..
> > fsync(open(oldnameN));
> >
> > rename(oldname1, newname1);
> >
_queued_signals();
}
#endif
Which seems really rather undesirable.
But given how windows signals are currently delivered via the equivalent code
in CHECK_FOR_INTERRUPTS(), I don't really see an alternative at this point :(.
Greetings,
Andres Freund
Hi,
On 2025-01-22 11:50:30 -0500, Andres Freund wrote:
> On 2025-01-22 07:57:52 -0800, Paul Ramsey wrote:
> > It is possible we have been Doing It Wrong all this time, and would love
> > some pointers on the right way to do this.
>
> All your interrupt handler is doing
that variable? Seems you
could just check postgres' QueryCancelPending? And perhaps ProcDiePending, if
you want to handle termination too.
Greetings,
Andres Freund
Hi,
On 2025-01-22 01:14:22 +, Andy Fan wrote:
> Andres Freund writes:
> > FWIW, I've seen the fsyncs around recycling being a rather substantial
> > bottleneck. To the point of the main benefit of larger segments being the
> > reduction in number of fsyncs at t
7;s not quite trivial to emit a WAL record with
extra information for a transaction iff the transaction actually performed
DML.
Greetings,
Andres Freund
recycling being a rather substantial
bottleneck. To the point of the main benefit of larger segments being the
reduction in number of fsyncs at the end of a checkpoint. I think we should
be able to make the fsyncs a lot more efficient by batching them, first rename
a bunch of files, then fsync them a
ng that doesn't allow running pg_buffercache), using
DebugPrintBufferRefcount() is much more targeted.
Greetings,
Andres Freund
ut it really isn't a whole lot.
I've in the past tried to get the linux filesytem developers to add an
fallocate mode that doesn't utilize the "unwritten extents" "optimization",
but didn't have luck with that. The block layer in linux actually does have
support for zeroing out regions of blocks without having to do actually write
the data, but it's only used in some narrow cases (don't remember the
details).
Greetings,
Andres Freund
Hi,
On 2025-01-17 13:03:35 -0500, Andres Freund wrote:
> > Previously, all interrupts except process dying were ignored while a
> > process was blocked writing to a socket. If the connection to the client
> > was broken (no clean FIN nor RST), a process sending results to the
&
Hi,
On 2025-01-17 13:03:35 -0500, Andres Freund wrote:
> I don't see anything implementing the promotion of ERRORs to FATAL? You're
> preventing the error message being sent to the client, but I don't think that
> causes the connection to be terminated. The pre-existing
{
> + if (whereToSendOutput == DestRemote)
> + whereToSendOutput = DestNone;
> + ProcessRecoveryConflictInterrupts();
> + }
> + }
>
This largely duplicates the existing code in
ProcessClientWriteInterrupt(). Perhaps it's worth flipping the order of
branches so that we first check that we're neither blocked nor have
InterruptHoldoffCount == 0 && CritSectionCount == 0?
Greetings,
Andres Freund
Hi,
On 2025-01-17 14:00:49 +0900, Michael Paquier wrote:
> XLogRecGetFullXid() has been introduced in 67b9b3ca3283 back in 2019,
> but as far as I can see this has never been used in the code and this
> is used nowhere in the core code.
>
> I have looked at Debian's codesearch and also looked at t
Hi,
On 2025-01-16 17:11:09 +, Bertrand Drouvot wrote:
> On Thu, Jan 16, 2025 at 11:38:47AM -0500, Andres Freund wrote:
> > Hi,
> >
> > On 2025-01-16 15:59:31 +, Bertrand Drouvot wrote:
> > > On Wed, Jan 15, 2025 at 03:11:32PM +0900, Michael Paquier wrote:
&
allowed to just opt out of the restriction of not allowing memory allocations
in critical sections?
The only cases where we can somewhat safely allocate memory in critical
sections is when using memory contexts with pre-reserved memory, where there's
a pretty low bound on how much memory is going to be needed. E.g. logging a
message inside a critical section, where elog.c can reset ErrorContext
afterwards.
Greetings,
Andres Freund
case again. And for something like
injection points (not really convinced that it's a good thing to have stats
for, but ...), allocation the shared memory stats object outside of the
critical section and not having any pending stats seems to be the right
approach.
Greetings,
Andres Freund
gets considerably worse. IIRC I saw something
like an 8x regression on a large machine in the past, but I couldn't find the
actual numbers anymore, so I wouldn't want to bet on it.
Greetings,
Andres Freund
m metadata changes.
Note that not all filesystems can benefit from wal_init_zero=1, e.g. ZFS or
BTRFS won't benefit, because they always allocate new disk space for each
write. With the associated overheads.
Greetings,
Andres Freund
Hi,
On 2025-01-14 13:06:31 +, Bertrand Drouvot wrote:
> On Tue, Jan 14, 2025 at 12:58:44AM -0500, Andres Freund wrote:
> > The current code has the weird behaviour of going through PM_WAIT_BACKENDS.
> > I
> > left it like that for now. In fact more paths do so now, becau
irectly jump to PM_WAIT_DEAD_END in fatal situations:
Attached patch is implemented that way.
Greetings,
Andres Freund
>From 833ee00ea2a1341b2e20e88c96d8824c09189df2 Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Fri, 10 Jan 2025 11:11:40 -0500
Subject: [PATCH v4 1/7] checkpointer: Req
Hi,
On 2025-01-13 12:20:39 +, Bertrand Drouvot wrote:
> On Fri, Jan 10, 2025 at 02:07:25PM -0500, Andres Freund wrote:
> > There wasn't
> > any code to treat receiving PMSIGNAL_XLOG_IS_SHUTDOWN in the wrong state as
> > fatal. I think this needs to be treated the s
Hi,
On 2025-01-13 15:43:46 -0500, Robert Haas wrote:
> On Wed, Jan 8, 2025 at 7:26 PM Andres Freund wrote:
> > 1) Shared memory representation of an IO, for the AIO subsystem internally
> >
> >Currently: PgAioHandle
> >
> > 2) A way for the issuer of
Hi,
On 2025-01-11 13:22:39 -0800, Jeremy Schneider wrote:
> It's a cleaner solution if JIT works more like an extension, and we can
> run a single build and split JIT into a separate package.
It does work like that. Only llvmjit.so has the llvm dependency, the main
postgres binary doesn't link to
hat the first and crash recovery scenarios
are more similar. Thomas, what do you think?
Separately, is it a problem that somewhere in process_pm_* we did
ConfigurePostmasterWaitSet(false) but then the event loop in ServerLoop()
continues to process "old" WL_SOCKET_ACCEPT events?
Greetings,
An
Hi,
Thanks for the reviews!
On 2025-01-09 12:01:05 +, Bertrand Drouvot wrote:
> On Wed, Jan 08, 2025 at 02:26:15PM -0500, Andres Freund wrote:
> === 2
>
> + PM_WAIT_XLOG_ARCHIVAL, /* waiting for archiver and walsenders to
>
> > I don't love PM_WAIT_XLOG_A
Hi,
On 2025-01-09 16:50:45 +0300, Nazir Bilal Yavuz wrote:
> On Wed, 8 Jan 2025 at 22:26, Andres Freund wrote:
> === 0005
>
> > I think this is much better than before. I don't love PM_WAIT_XLOG_ARCHIVAL,
> > but I can't think of anything better.
>
> I
Hi,
On 2025-01-09 20:10:24 +0200, Ants Aasma wrote:
> On Thu, 9 Jan 2025 at 18:25, Andres Freund wrote:
> > > I'm curious about this because the checksum code should be fast enough
> > > to easily handle that throughput.
> >
> > It seems to top out at ab
n't think this makes it worse in any meaningful way. It's not really
different from having other heap-specific params like freeze_min_age in
VacuumParams.
Greetings,
Andres Freund
Hi,
On 2025-01-09 10:59:22 +0200, Ants Aasma wrote:
> On Wed, 8 Jan 2025 at 22:58, Andres Freund wrote:
> > master: ~18 GB/s
> > patch, buffered:~20 GB/s
> > patch, direct, worker: ~28 GB/s
> > patch, direct, uring: ~35 GB/s
> >
&g
Hi,
On 2025-01-07 14:59:58 -0500, Robert Haas wrote:
> On Tue, Jan 7, 2025 at 11:11 AM Andres Freund wrote:
> > The difference between a handle and a reference is useful right now, to have
> > some separation between the functions that can be called by anyone (taking a
> >
Hi,
On 2025-01-07 22:09:56 +0200, Heikki Linnakangas wrote:
> On 07/01/2025 18:11, Andres Freund wrote:
> > > I didn't quite understand the point of the prepare callbacks. For example,
> > > when AsyncReadBuffers() calls smgrstartreadv(), the
> > > shared_buff
Hi,
On 2025-01-08 16:01:19 -0600, Nathan Bossart wrote:
> On Wed, Jan 08, 2025 at 03:07:24PM -0500, Andres Freund wrote:
> > Out of curiosity, have you measured whether this has a positive effect
> > without
> > pg_stat_statements? I think it'll e.g. also affect
Hi,
On 2025-01-08 15:04:39 +0100, Jakub Wartak wrote:
> On Mon, Jan 6, 2025 at 5:28 PM Andres Freund wrote:
> > I didn't think that pg_stat_* was quite the right namespace, given that it
> > shows not stats, but the currently ongoing IOs. I am going with pg_aios for
Hi,
On 2025-01-08 12:12:19 -0600, Nathan Bossart wrote:
> On Tue, Oct 22, 2024 at 02:54:57PM -0500, Nathan Bossart wrote:
> > My colleague Salvatore Dipietro (CC'd) sent me a couple of profiles that
> > showed an enormous amount of s_lock() time going to the
> > __sync_lock_test_and_set() call in
ooks at environment variables. Which means you just need to set an
environment variable, which can be done without make:
PGOPTIONS="..." meson test ...
or export PGOPTIONS="..."; mesoin test ...
Greetings,
Andres Freund
Hi,
On 2025-01-08 14:48:21 +, Bertrand Drouvot wrote:
> On Wed, Jan 08, 2025 at 03:10:03PM +0200, Heikki Linnakangas wrote:
> > On 08/01/2025 04:10, Andres Freund wrote:
> > > 0002: Make logging of postmaster signalling child processes more
> > > consistent
&g
Hi,
On 2025-01-08 15:10:03 +0200, Heikki Linnakangas wrote:
> On 08/01/2025 04:10, Andres Freund wrote:
> > I instead opted to somewhat rearrange the shutdown sequence:
> > - I don't love the naming of the various PMState values (existing and new),
> >but a larger r
0004, the reason for this thread.
Comments? Better ideas?
Greetings,
Andres Freund
[1] A buffered write completes and RememberSyncRequest() fails, leading to the
IO workers performing the flush itself.
>From 5978a67e17b2750b766d959b4529c09a8d5b3023 Mon Sep 17 00:00:00 2001
From: And
{"io_method", PGC_POSTMASTER, RESOURCES_MEM,
> > + gettext_noop("Selects the method of asynchronous I/O to
> > use."),
> > + NULL
> > + },
> > + &io_method,
> > + DEFAULT_IO_METHOD, io_method_options,
> > + NULL, assign_io_method, NULL
> > + },
> > +
>
> The description is a bit funny because synchronous I/O is one of the
> possible methods.
Hah. How about:
"Selects the method of, potentially asynchronous, IO execution."?
Greetings,
Andres Freund
Hi,
On 2025-01-07 17:09:58 +0200, Heikki Linnakangas wrote:
> On 01/01/2025 06:03, Andres Freund wrote:
> > Hi,
> >
> > Attached is a new version of the AIO patchset.
>
> I haven't gone through it all yet, but some comments below.
Thanks!
> > The bigg
Hi,
On January 6, 2025 5:15:25 PM EST, Nathan Bossart
wrote:
>On Mon, Jan 06, 2025 at 03:50:24PM -0600, Nathan Bossart wrote:
>> I'm obviously biased, but I think it would be unfortunate to block features
>> like this one because of low settings that would otherwise be unsuitable
>> for any rea
mmand ids, but they're not suitable for general purpose queries. So I
> think we should turn that into an error, per attached patch.
Hm. I'm not sure it's a good idea to forbid this. Couldn't there be sane C
code in an output functions calling GetTransactionSnapshot() or such to do
some internal lookups?
Greetings,
Andres Freund
Hi,
On 2025-01-06 10:52:20 -0800, Noah Misch wrote:
> Patches 1 and 2 are still Ready for Committer.
I feel somewhat weird about pushing 0002 without a user, but I guess it's
still exercised, so it's probably fine...
> On Tue, Dec 31, 2024 at 11:03:33PM -0500, Andres Freund
Hi,
On 2024-12-19 17:29:12 -0500, Andres Freund wrote:
> > Not about patch itself, but questions about related stack functionality:
> >
> >
> >
> > 7. Is pg_stat_
ething here a few weeks ago, as well, and only flushing the stats
> at redo was not enough while being full of holes.
Good then that I was not at all proposing to only flush the stats at redo?
Greetings,
Andres Freund
data size), and insert records associated to
> their stats kind.
As mentioned in the other thread, I don't think we need this - nearly all the
information is already and in the WAL for the actual action that the stats
track. We should re-emit the stats changes during recovery.
Greetings,
Andres Freund
on the WAL
record of the "underlying object".
Do you have counter-examples?
Greetings,
Andres Freund
Hi,
On 2024-12-20 11:39:42 -0500, Andres Freund wrote:
> On 2024-12-19 17:47:13 +1100, Michael Harris wrote:
> > This is a different system to those I previously provided logs from.
> > It is also running RHEL8 with a similar configuration to the other
> > system.
>
&g
Hi,
On 2025-01-02 11:41:56 +0100, Andrea Gelmini wrote:
> Il giorno mar 31 dic 2024 alle ore 16:31 Andres Freund
> ha scritto:
>
> 2024-12-19 04:47:04 CET [2646363]: ERROR: could not extend file
> > "pg_tblspc/107724/PG_16_202307071/465960/3232056651.2" by 11 blo
On 2025-01-02 10:36:48 +0800, jian he wrote:
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F5318
> shows lots of failures, but it doesn't seem to tell you about doc build
> failure.
It does:
https://cirrus-ci.com/task/6472750665039872?logs=docs_build#L0
[15:26:26.443] time make -
en messages, whereas previous they were more frequent
b) f_bfree increased substantially.
I assume that somewhere around 2AM some script prunes old partitions?
Greetings,
Andres Freund
Hi,
On December 30, 2024 10:29:53 AM GMT+01:00, Peter Eisentraut
wrote:
>On 25.12.24 11:22, Heikki Linnakangas wrote:
>> Thanks for the links. It's disappointing there isn't a standard way to do
>> this. It's nice to see the comments in cpython's makeexp_aix script
>> explaining the "hidden tr
Hi,
On 2024-12-20 18:27:13 +0100, Jelte Fennema-Nio wrote:
> On Fri, 20 Dec 2024 at 01:54, Andres Freund wrote:
> > Arguably the configuration *did* tell us, by having a higher hard limit...
> >
> > But opting into a higher rlimit, while obviously adhering to the hard limit
ould probably reduce fragmentation, and the extra space would be
quickly used in workloads where we extend by a bunch of blocks at once,
anyway.
Greetings,
Andres Freund
Hi,
On 2024-12-19 17:34:29 -0500, Tom Lane wrote:
> Andres Freund writes:
> > My current thoughts around this are that we should generally, independent of
> > io_uring, increase the FD limit ourselves.
>
> I'm seriously down on that, because it amounts to an assumption
Hi,
Sorry for loosing track of your message for this long, I saw it just now
because I was working on posting a new version.
On 2024-11-18 13:19:58 +0100, Jakub Wartak wrote:
> On Fri, Sep 6, 2024 at 9:38 PM Andres Freund wrote:
> Thank You for worth admiring persistence on this. Ple
On 2024-12-19 09:31:14 -0600, Nathan Bossart wrote:
> On Thu, Dec 19, 2024 at 02:44:53PM +0900, Michael Paquier wrote:
> > I've been double-checking the code to refresh myself with the problem,
> > and I don't see a reason to not apply something like the attached set
> > down to v13 for all these r
ink() - but at the end of a checkpoint we do that operations hundreds of
times in a row on a busy server. And that's just after potentially doing lots
of write IO during a checkpoint, filling up drive write caches / eating up
IOPS/bandwidth disk quots.
Greetings,
Andres Freund
Hi,
On 2024-12-18 12:00:48 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Maybe we should consider switching those platforms to unnamed posix
> > semaphores?
>
> I already looked into that. OpenBSD still doesn't have cross-process
> posix semaphores, at le
Hi,
On 2024-12-18 15:53:39 +, Bertrand Drouvot wrote:
> On Wed, Dec 18, 2024 at 10:35:45AM -0500, Andres Freund wrote:
> > Hi,
> >
> > On 2024-12-18 15:14:07 +, Bertrand Drouvot wrote:
> > > While working on [1], it has been noticed that pgstat_flush_io()
id/3010886.1634950831%40sss.pgh.pa.us
* netbsd, 2022:
https://www.postgresql.org/message-id/20220828013914.5hzc7kvcpum5h2yn%40awork3.anarazel.de
But TBH, nobody uses openbsd and netbsd if performance matters even one
iota. And considering a bunch of postgres changes to deal with idiotic default
sysv limits doesn't feal like a sensible thing to do in 2024.
Greetings,
Andres Freund
$SUBJECT, until the
> walwriter is part of the I/O stats tracking system.
I don't really see the point of this change? What do we gain by moving stuff
around like you did?
Greetings,
Andres Freund
Hi,
On 2024-12-17 17:07:34 -0500, Peter Geoghegan wrote:
> On Tue, Dec 17, 2024 at 4:46 PM Andres Freund wrote:
> > ISTM that we could do better with some fairly simple cooperation between
> > index
> > and table AM. It should be rather rare to look up a TID that was remove
On 2024-12-17 15:32:06 -0600, Nathan Bossart wrote:
> Committed.
Thanks!
x27;ve seen enough bugs / corruption leading to indexes pointing to wrong and
nonexisting tuples to make me think it's worth being a bit more proactive
about raising errors for such cases. Of course what I described above can
only detect index entries pointing to non-existing tuples, but that's still
a good bit better than nothing.
Greetings,
Andres Freund
Hi,
On 2024-12-17 19:57:13 +0200, Heikki Linnakangas wrote:
> On 14/12/2024 01:44, Andres Freund wrote:
> > The zero_damaged_pages path in bufmgr.c makes sense to me, but this one
> > seems
> > less sane to me. If you want to recover from a data corruption event and
&g
Hi,
On 2024-12-17 14:25:01 -0500, Andres Freund wrote:
> On 2024-12-17 13:09:49 -0500, Tom Lane wrote:
> > I wrote:
> > > Andres Freund writes:
> > >> Was about to apply that, but then started to wonder if we don't need the
> > >> same
> >
1 - 100 of 1754 matches
Mail list logo
