nd (2) we have some mechanism for limiting the
> number of extra pins that we're holding to a reasonable number given the
> size of shared_buffers.
FWIW, there's already some logic for (2) in LimitAdditionalPins(). Currently
used to limit how many buffers a backend may pin for bulk re
th partitioned queries it often
is. Depending on the form of "control" that's harder if IAMs are in control,
because control flow needs to return to the executor to be able to switch to a
different node, so we can't wait for IO inside the AM.
There probably are ways IAMs could be in "control" that would be compatible
with such constraints however.
Greetings,
Andres Freund
ery will be
executed. And in fact the same plan might be executed multiple ways, in
case of prepared statements.
The obvious advantage is of course that we can influence the choice of
paths.
I suspect we'd eventually want a mix of both. Plan time to be able to
influence plan shape, ExecInit* to deal with not knowing how the query will be
consumed at plan time. Which suggests that we could start with whichever is
easier and extend later.
Greetings,
Andres Freund
*proc;
> BackendId backendId = InvalidBackendId;
>
> - proc = BackendPidGetProc(pid);
> -
> /*
>* See if the process with given pid is a backend or an auxiliary
> process.
> - *
> - * If the given process is a backend, use its backend id in
> - * SendProcSignal() later to speed up the operation. Otherwise, don't do
> - * that because auxiliary processes (except the startup process) don't
> - * have a valid backend id.
>*/
> - if (proc != NULL)
> - backendId = proc->backendId;
> - else
> + proc = BackendPidGetProc(pid);
> + if (proc == NULL)
> proc = AuxiliaryPidGetProc(pid);
>
> /*
> @@ -183,6 +175,8 @@ pg_log_backend_memory_contexts(PG_FUNCTION_ARGS)
> PG_RETURN_BOOL(false);
> }
>
> + if (proc != NULL)
> + backendId = GetBackendIdFromPGProc(proc);
How can proc be NULL here?
Greetings,
Andres Freund
ate - scan through next page of a TIDBitmap
> *
> - * Returns a TBMIterateResult representing one page, or NULL if there are
> - * no more pages to scan. Pages are guaranteed to be delivered in numerical
> - * order. If result->ntuples < 0, then the bitmap is "lossy"
Hi,
On 2024-02-12 17:33:24 -0800, Jeff Davis wrote:
> On Mon, 2024-02-12 at 15:36 -0800, Andres Freund wrote:
> >
> > It doesn't really seem like a necessary, or even particularly useful,
> > part. You couldn't just call WALRead() for that, since the caller
> >
on't have on all compilers!). Trapping on such overflows
makes it far easier to find problems with tools like sqlsmith.
Greetings,
Andres Freund
ble to C++ than C.
> I did try using atomic_thread_fence as per atomic_thread_fence -
> cppreference.com
> <https://en.cppreference.com/w/c/atomic/atomic_thread_fence>
The semantics of atomic_thread_fence are, uh, very odd. I'd just use
MemoryBarrier().
Greetings,
Andres Freund
the latest return value of
> WaitXLogInsertionsToFinish()). That seems invasive, though.
FWIW, I think LogwrtResult is an anti-pattern, perhaps introduced due to
misunderstanding how cache coherency works. It's not fundamentally faster to
access non-shared memory. It'd make far more sense to allow lock-free access
to the shared LogwrtResult and
Greetings,
Andres Freund
Hi,
On 2024-02-12 17:04:23 -0600, Nathan Bossart wrote:
> On Mon, Feb 12, 2024 at 01:31:30PM -0800, Andres Freund wrote:
> > One thing that's worth checking is if this ends up with *worse* code when
> > the
> > comparators are inlined. I think none of the chang
Hi,
On 2024-02-12 12:46:00 -0800, Jeff Davis wrote:
> On Mon, 2024-02-12 at 12:18 -0800, Andres Freund wrote:
> > + upto = Min(startptr + count, LogwrtResult.Write);
> > + nbytes = upto - startptr;
> >
> > Shouldn't it pretty much be a bug to ever encount
lacing includes of heapam.h/heap.h with table.h etc where appropriate.
While I can see applying some targeted changes without more work, I don't
really see much point in applying a lot of the other removals without actually
committing to adding the necessary IWYU annotations to our code to make iwyu
actually usable.
Greetings,
Andres Freund
r will understand it only cares about
a < b, not about the other possibilities. I'm not sure that's still true with
the more complicated optimized version.
Greetings,
Andres Freund
Hi,
On 2024-02-12 12:50:12 -0800, Andres Freund wrote:
> On 2024-02-12 13:28:40 -0500, Andrew Dunstan wrote:
> I wonder if this indicates that we are either missing memory barriers
> somewhere or that the memory barriers we end up with on msvc + arm aren't
> correct? Either coul
Hi,
On 2024-02-09 15:32:10 -0500, Dave Cramer wrote:
> On Fri, 9 Feb 2024 at 14:36, Andres Freund wrote:
> > That's something like a segfault.
> >
> > One suspicion I have is that src/port/pg_crc32c_armv8_choose.c possibly
> > doesn't properly support msvc.
acktrace?
I wonder if this indicates that we are either missing memory barriers
somewhere or that the memory barriers we end up with on msvc + arm aren't
correct? Either could explain why the problem doesn't occur when building
with optimizations.
Greetings,
Andres Freund
ion), pg_popcnt_choose.c
> (CPUID and xgetbv check) and pg_popcnt_x86_64_accel.c (64/512bit x86
> implementations).
> I'm not an expert in meson, but splitting might add complexity to meson.build.
>
> Could you elaborate if there are other benefits to the split file approac
bug to ever encounter this? There aren't
equivalent checks in WALRead(), so any user of WALReadFromBuffers() that then
falls back to WALRead() is just going to send unwritten data.
ISTM that this should be an assertion or error.
Greetings,
Andres Freund
nd/commands/event_trigger.c:955:72:
note: each undeclared identifier is reported only once for each function it
appears in
Greetings,
Andres Freund
Hi,
On 2024-02-09 15:27:57 -0800, Noah Misch wrote:
> On Fri, Feb 09, 2024 at 10:24:32AM -0800, Andres Freund wrote:
> > On 2024-01-26 07:42:33 +0100, Alvaro Herrera wrote:
> > > This suggests that finding a way to make the ifunc stuff work (with good
> > > performanc
On 2024-02-09 14:04:29 -0600, Nathan Bossart wrote:
> On Fri, Feb 09, 2024 at 08:40:47PM +0100, Mats Kindahl wrote:
> > On Fri, Feb 9, 2024 at 5:27 PM Tom Lane wrote:
> >> We do pretty much assume that "int" is "int32". But I agree that
> >> assuming anything about the width of size_t is bad. I
uthentication support. MIT Kerberos can be
> -downloaded from
> -https://web.mit.edu/Kerberos/dist/index.html";>.
> -
> -
Btw, this is the only dependency that I hadn't been able to test on windows
when I was hacking on the CI stuff last. I'm not sure it relly still works.
Greetings,
Andres Freund
Hi,
On 2024-02-09 11:53:35 -0800, Andres Freund wrote:
> > Between MSYS2, mingw-w64 and Chocolatey, there are a lot of options
> > available to users. So shouldn't we try to recommend only of them,
> > then align the buildfarm and the CI to use one of them?
>
> I th
ools,
which makes it harder to test. I had started to work on adding an option for
the relevant vcpkg packages to install the binaries, but got stuck on some CLA
stuff (cleared up since), after finding that that required some bugfixes in
zstd.
Greetings,
Andres Freund
heck if the problem persists if you change
cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1)
to
cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 0)
Also, yikes, that's an ugly way of doing hardware detection. Jumping out of a
signal handler into normal code. Brrr.
Greetings,
Andres Freund
> + cstate->cur_attval = string;
> +
> + if (cstate->opts.csv_mode)
> + {
More unfortunate intermingling of multiple formats in a single routine.
> +
> + if (cstate->defaults[m])
> + {
> + /*
> + * The caller must supply econtext and have switched
> into the
> + * per-tuple memory context in it.
> + */
> + Assert(econtext != NULL);
> + Assert(CurrentMemoryContext ==
> econtext->ecxt_per_tuple_memory);
> +
> + values[m] = ExecEvalExpr(defexprs[m], econtext,
> &nulls[m]);
> + }
I don't think it's good that we end up with this code in different copy
implementations.
Greetings,
Andres Freund
ntly depending on the
input.
> These cpus are really neat things...
Indeed.
Greetings,
Andres Freund
see a
performance benefit by increasing MAX_SEND_SIZE?
I don't think we should add configuration parameters without at least some
demonstration of practical gains, otherwise we'll end up with hundreds of
never-useful config options.
Greetings,
Andres Freund
len=len@entry=1) at pqcomm.c:1302
So it's the issue that we wait effectively forever to to send a FATAL. I've
previously proposed that we should not block sending out fatal errors, given
that allows clients to do prevent graceful restarts and a lot of other things.
Greetings,
Andres Freund
ime now
- you acquire the spinlock for single increments of n_writers, perhaps that
could become an atomic, to reduce contention?
- I don't think it's a good idea to do memory allocations in the middle of a
PG_CATCH. If the error was due to out-of-memory, you'll throw another error.
Greetings,
Andres Freund
Hi,
On 2024-02-09 13:19:49 +0500, Andrey M. Borodin wrote:
> > On 8 Feb 2024, at 06:52, Nathan Bossart wrote:
> > For the same compASC() test, I see an ~8.4% improvement with your int64
> > code and a ~3.4% improvement with this:
>
> If we care about branch prediction in comparison function, mayb
opts : pgport_variants
>link_with: cflag_libs,
>c_pch: pch_c_h,
>kwargs: opts + {
> +'c_args': opts.get('c_args', []) + cflags_avx512_popcnt,
> 'dependencies': opts['dependencies'] + [ssl],
>}
> )
This will build all of pgport with the avx flags, which wouldn't be correct, I
think? The compiler might inject automatic uses of avx512 in places, which
would cause problems, no?
While you don't do the same for make, isn't even just using the avx512 for all
of pg_bitutils.c broken for exactly that reson? That's why the existing code
builds the files for various crc variants as their own file.
Greetings,
Andres Freund
Hi,
On 2024-01-26 07:42:33 +0100, Alvaro Herrera wrote:
> This suggests that finding a way to make the ifunc stuff work (with good
> performance) is critical to this work.
Ifuncs are effectively implemented as a function call via a pointer, they're
not magic, unfortunately. The sole trick they pr
iffer
> > (see also pg_server_to_any)."
> >
> > Other than that, +1
>
> Cool. I've used your wording and applied that on HEAD.
Thanks. LGTM.
Greetings,
Andres Freund
x27;t apply,
but it's pretty easy to introduce similar bugs in other places, so it seems
quite plausible that greenplum might have done so. We also did have more
proc_exit()s in signal handlers in older branches, so it might just be an
issue that also was present before.
Greetings,
Andres Freund
define the target.
> +doxygen_cmd = find_program('doxygen', required: false)
I'd add "native: true", it'd not work to find the program in the target
environment of a cross build.
> +
> +# Find the dot command. If not found, no graphs will be generated.
> +dot_cmd = find_program('dot', required: false)
Dito.
Greetings,
Andres Freund
Hi,
On 2024-02-08 13:44:02 -0500, Tom Lane wrote:
> Nathan Bossart writes:
> > On Thu, Feb 08, 2024 at 02:16:11PM +0100, Mats Kindahl wrote:
> >> +/*
> >> + * Compare two integers and return -1, 0, or 1 without risking overflow.
> >> + *
> >> + * This macro is used to avoid running into overflow
Hi,
On 2024-02-07 19:52:11 -0600, Nathan Bossart wrote:
> On Wed, Feb 07, 2024 at 04:42:07PM -0800, Andres Freund wrote:
> > On 2024-02-07 16:21:24 -0600, Nathan Bossart wrote:
> >> The assembly for that looks encouraging, but I still need to actually test
> >> it...
&
Hi,
On 2024-02-07 16:21:24 -0600, Nathan Bossart wrote:
> On Wed, Feb 07, 2024 at 01:48:57PM -0800, Andres Freund wrote:
> > Now, in most cases this won't matter, the sorting isn't performance
> > critical. But I don't think it's a good idea to standardiz
t64) *(const int32 *) b;
Perhaps we could have a central helper for this somewhere?
Greetings,
Andres Freund
[1]
-- prep
CREATE EXTENSION IF NOT EXISTS intarray;
DROP TABLE IF EXISTS arrays_to_sort;
CREATE TABLE arrays_to_sort AS SELECT array_shuffle(a) arr FROM (SELECT
ARRAY(SELECT generate_series(1, 100)) a), generate_series(1, 10);
-- bench
SELECT (sort(arr))[1] FROM arrays_to_sort;
x27;re
* either two heterogeneously-typed containers, or a
container and
* some scalar type.
*
* We don't have to consider the WJB_END_ARRAY and
WJB_END_OBJECT
* cases here, because we would have seen the
corresponding
* WJB_BEGIN_ARRAY and WJB_BEGIN_OBJECT tokens first,
and
* concluded that they don't match.
*/
It's not surprising that the compiler can't understand that you can't get
ra = WJB_DONE, rb = WJB_END_ARRAY or such.
Greetings,
Andres Freund
) etc.
- spinlock_finish_release() - not holding the lock anymore
This would get called by SpinLockRelease(), UnlockBufHdr()
- spinlock_prepare_spin() - about to spin waiting for a spinlock
like the current init_spin_delay()
This would get called in s_lock(), LockBufHdr() etc.
- spinlock_finish_spin() - completed waiting for a spinlock
like the current finish_spin_delay()
This would get called in s_lock(), LockBufHdr() etc.
I don't love the spinlock_ prefix, that could end up confusing people. I toyed
with "spinlike_" but am not in love either.
Greetings,
Andres Freund
thought I'd raise it.
Perhaps we should make the state a bitmap and have a single
AssertNotInState(HOLDING_SPINLOCK | IN_SIGNALHANDLER)
Greetings,
Andres Freund
m (vagueness alert). To reduce
contention we already have to hold both ProcArrayLock and XidGenLock when
changing membership, so that holding either of the locks prevents the set of
members to change. This, kinda and differently, adds yet another lock to that.
> It's not clear if we need that optimization at all. I was able to
> write a test case that become slower without this: set max_connections
> to a very high number (> 5000), and create+truncate a table in the
> same transaction thousands of times to send invalidation messages,
> with fsync=off. That became about 20% slower on my laptop. Arguably
> that's so unrealistic that it doesn't matter, but nevertheless, this
> commit restores the performance of that.
I think it's unfortunately not that uncommon to be bottlenecked by sinval
performance, so I think it's good that you're addressing it.
Greetings,
Andres Freund
27;d expect. Signal delivery is fairly heavyweight, getpid() is one
of the cheapest system calls (IIRC only beat by close() of an invalid FD on
recent-ish linux). If it were to become an issue, we'd much better spend our
time reducing the millions of signals/sec that'd have to involve.
Greetings,
Andres Freund
Hi,
On 2024-02-06 15:11:05 +0900, Michael Paquier wrote:
> On Mon, Feb 05, 2024 at 09:46:42PM -0800, Andres Freund wrote:
> > No - what I mean is that it doesn't make sense to have copy_attribute_out(),
> > as e.g. CopyToTextOneRow() already knows that it's dealing
Hi,
On 2024-02-06 12:51:48 -0500, Tom Lane wrote:
> Michael Paquier writes:
> > On Mon, Feb 05, 2024 at 06:05:04PM -0800, Andres Freund wrote:
> >> I haven't yet dug into the code history. One guess is that this should only
> >> have been set this way for COPY FRO
Hi,
On 2024-02-06 11:41:06 +0900, Michael Paquier wrote:
> On Mon, Feb 05, 2024 at 05:41:25PM -0800, Andres Freund wrote:
> > On 2024-02-06 10:01:36 +0900, Michael Paquier wrote:
> >> If you have concerns about that, I'm OK to revert, I'm not wedded to
> >> t
ing that will never be
used.
Unsurprisingly, only doing transcoding when encodings differ yields a sizable
improvement, about 18% for [2].
I haven't yet dug into the code history. One guess is that this should only
have been set this way for COPY FROM.
Greetings,
Andres Freund
[1] https:/
Hi,
On 2024-02-06 10:01:36 +0900, Michael Paquier wrote:
> On Mon, Feb 05, 2024 at 10:21:18AM -0800, Andres Freund wrote:
> > Have you benchmarked the performance effects of 2889fd23be5 ? I'd not at all
> > be surprised if it lead to a measurable performance regression.
>
many
indirect function calls.
Greetings,
Andres Freund
super-annoyed.
NP - I could have phrased mine better as well...
> > On Wed, Jan 31, 2024 at 10:24 PM Andres Freund wrote:
> > > While not perfect - e.g. because networks might use jumbo packets / large
> > > MTUs
> > > and we don't know how many outstandi
at once (something like ~1400 bytes), even if that requires copying some
of the input data. It might not be sent on its own, but it should make it
reasonably unlikely to end up with tiny tiny packets.
Greetings,
Andres Freund
leaks=0";
> +}
> +
> +#endif
Wonder if we should move this into some static library and link it into all
binaries that don't want leak detection? It doesn't seem great to have to
adjust this in a bunch of files if we want to adjust the options...
Greetings,
Andres Freund
, so making our stack depth check work
with asan would be worthwhile.
I discussed this in a bit more in
https://postgr.es/m/20231129193920.4vphw7dqxjzf5v5b%40awork3.anarazel.de
Greetings,
Andres Freund
Hi,
On January 29, 2024 2:09:23 PM PST, Tom Lane wrote:
>Andres Freund writes:
>> On 2024-01-29 15:01:06 -0500, Robert Haas wrote:
>>> And it still baffles me why we allow everyone to pick their own system for
>>> capitalizing identifiers out of a hat, without ev
hate some capitalization/underscore styles, but I hate spending
time feeling out which capitalization style I should use so much more. Let's
at least define some minimal naming guidelines for new code.
Personally I like under_score_style for functions and variables and CamelCase
for types.
Greetings,
Andres Freund
orth reconsidering if we want this warning to be enabled or not.
+1 for allowing declarations to be intermixed with code, -infinity for
changing existing code to do so.
Greetings,
Andres Freund
Hi,
On 2024-01-24 15:05:12 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-01-24 12:14:17 +0100, Alvaro Herrera wrote:
> >> I do wonder if we want to keep this around, given that it's been more
> >> than one year broken and nobody seems to have notice
built and run by default instead? OTOH,
regress.c:test_spinlock() actually covers about as much as the standalone
test...
Greetings,
Andres Freund
Hi,
On 2024-01-23 22:00:01 +0300, Alexander Lakhin wrote:
> 23.01.2024 20:30, Andres Freund wrote:
> > I don't think that's viable and would cause more problems than it solves,
> > it'd
> > make us think that we might have an old postgres process hanging a
Hi,
On 2024-01-23 17:26:19 -0600, Tristan Partin wrote:
> On Tue Jan 23, 2024 at 4:23 PM CST, Andres Freund wrote:
> > Hi,
> >
> > On 2024-01-23 15:50:11 -0600, Tristan Partin wrote:
> > > What is keeping us from using pthread_sigmask(3) instead of
> > >
sn't limited to a single thread. You'd definitely need to use
pthread_sigprocmask etc to address that aspect alone.
Greetings,
Andres Freund
esc *desc)
>
> init_local_spin_delay(&delayStatus);
>
> + START_SPIN_LOCK();
> while (true)
> {
> /* set BM_LOCKED flag */
Seems pretty odd that we now need init_local_spin_delay() and
START_SPIN_LOCK(). Note that init_local_spin_delay() also wraps handling of
__FILE__, __LINE__ etc, so it seems we're duplicating state here.
Greetings,
Andres Freund
ason this isn't using a plain spinlock is that this way we
can modify more state with a single atomic operation. But all the dangers of
using spinlocks apply just as well.
Greetings,
Andres Freund
Hi,
On 2024-01-23 21:07:08 +0200, Heikki Linnakangas wrote:
> On 22/01/2024 23:07, Andres Freund wrote:
> > > diff --git a/src/backend/utils/activity/backend_status.c
> > > b/src/backend/utils/activity/backend_status.c
> > > index 1a1050c8da1..92f24db4e18 100644
es which use libcurl (like Neon). Under the hood, libcurl calls
> SCDynamicStoreCopyProxies[1], which apparently causes the check to fail.
Maybe I'm missing something, but isn't that indicating the exact opposite,
namely that the check is precisely doing what it's intended?
Greetings,
Andres Freund
Hi,
On 2024-01-23 13:09:22 +0100, Thomas Kellerer wrote:
> Yoni Sade schrieb am 21.01.2024 um 19:07:
> > It would be useful to have the ability to define for a role default
> > vCPU affinity limits/thread priority settings so that more active
> > sessions could coexist similar to MySQL resource gr
Hi,
On 2024-01-23 08:00:00 +0300, Alexander Lakhin wrote:
> 22.01.2024 23:41, Andres Freund wrote:
> > ISTM that we shouldn't basically silently overlook shutdowns due to crashes
> > in
> > the tests. How to not do so is unfortunately not immediately obvious to
&
to the exception case where needed, than to add a new function doing checking
and converting most things to that.
Greetings,
Andres Freund
re a point in keeping 728f86fec6 as well on HEAD? That does not
> strike me as wise to keep that in the tree for now. If it needs to be
> reworked, looking at this problem from scratch would be a safer
> approach.
IDK, I think we'll introduce this type of bug over and over if we don
Hi,
On 2024-01-22 15:19:36 -0600, Nathan Bossart wrote:
> On Mon, Jan 22, 2024 at 02:44:57PM -0600, Nathan Bossart wrote:
> > On Mon, Jan 22, 2024 at 12:41:17PM -0800, Andres Freund wrote:
> >> I noticed that I was getting core dumps while executing the tests, without
> >
ve IsBackgroundWorker, IsAutoVacuumLauncherProcess() and
> IsAutoVacuumWorkerProcess() in favor of new Am*Process() macros that
> use MyBackendType. For consistency with the existing Am*Process()
> macros.
The Am*Process() macros aren't realy new, they are just implemented
differently, right? I guess there are a few more of them now.
Given that we are probably going to have more process types in the future, it
seems like a better direction would be a AmProcessType(proctype) style
macro/inline function. That we we don't have to mirror the list of process
types in the enum and a set of macros.
Greetings,
Andres Freund
endent of this patch - by coincidence I just
sent an email about the issue
https://www.postgresql.org/message-id/20240122204117.swton324xcoodnyi%40awork3.anarazel.de
a few minutes ago.
Greetings,
Andres Freund
tabase system is ready to accept
connections
ISTM that we shouldn't basically silently overlook shutdowns due to crashes in
the tests. How to not do so is unfortunately not immediately obvious to me...
Greetings,
Andres Freund
XLOG_BLCKSZ)) &&
> + phdr->xlp_tli == tli))
> + break;
I still think that anything that requires such checks shouldn't be
merged. It's completely bogus to check page contents for validity when we
should have metadata telling us which range of the buffers is valid and which
not.
Greetings,
Andres Freund
ock again if we couldn't immediately acquire it, search
the fsm, and retry if we couldn't find any free space, which would
substantially increase contention.
The FSM is the source of substantial contention, disabling it actually results
in substantial throughput increases. Vastly incre
Hi,
On January 9, 2024 11:33:29 AM PST, Robert Haas wrote:
>On Tue, Jan 9, 2024 at 2:23 PM Melanie Plageman
> wrote:
>> Yes, I agree. I thought about it more, and I prefer updating the FSM
>> and setting nonempty_pages into lazy_scan_[no]prune(). Originally, I
>> had ordered the patch set with t
or? Can you
> provide a minimal example? And so on.
I looked around for a bit, and couldn't really find good documentation around
this. The best I found is
https://developer.android.com/ndk/guides/abis#native-code-in-app-packages
which does strongly imply that the library names aren't versioned.
Greetings,
Andres Freund
Hi,
On 2024-01-05 15:23:12 -0500, Robert Haas wrote:
> On Fri, Jan 5, 2024 at 3:05 PM Andres Freund wrote:
> > An aside:
> >
> > As I think we chatted about before, I eventually would like the option to
> > remove index entries for a tuple during on-access pruning,
the simplest fix would be to just
map android to linux, similar to how dragonflybsd is mapped to netbsd. Blind
attempt attached.
It looks like that might be all that's required, as it looks like meson knows
that android doesn't properly deal with soversion.
Greetings,
Andres Freund
dif
urn in the
existing MemoryContextStatsInternal() when that's the case.
Greetings,
Andres Freund
be quite beneficial when you have huge indexes. The
reason I mention this is that then we'd have another source of marking items
unused during pruning.
Greetings,
Andres Freund
Hi,
On 2024-01-04 17:37:27 -0500, Melanie Plageman wrote:
> On Thu, Jan 4, 2024 at 3:03 PM Andres Freund wrote:
> >
> > On 2023-11-17 18:12:08 -0500, Melanie Plageman wrote:
> > > Assert(ItemIdIsNormal(lp));
> > > htup = (He
Hi,
On 2024-01-05 14:19:23 -0500, Robert Haas wrote:
> On Fri, Jan 5, 2024 at 2:11 PM Andres Freund wrote:
> > I see it fairly regularly. Including finding several related bugs that lead
> > to
> > stuck systems last year (signal handlers are a menace).
>
> In that
Hi,
On 2024-01-05 10:20:39 +0800, Andy Fan wrote:
> Andres Freund writes:
> > On 2024-01-04 14:59:06 +0800, Andy Fan wrote:
> >> My question is if someone doesn't obey the rule by mistake (everyone
> >> can make mistake), shall we PANIC on a production environme
Hi,
On 2024-01-05 08:51:53 -0500, Robert Haas wrote:
> On Thu, Jan 4, 2024 at 6:06 PM Andres Freund wrote:
> > I think we should add infrastructure to detect bugs like this during
> > development, but not PANICing when this happens in production seems
> > completely
> &
lding a spinlock. Might be easier than code analysis.
I don't think that's particularly promising. Lackey is *slow*. And it requires
actually reaching problematic states. Consider e.g. the case that was reported
upthread, an lwlock acquired within a spinlock protected section - most of the
time that's not going to result in a lot of cycles, because the lwlock is
free.
Greetings,
Andres Freund
nvestigating such issues very hard.
I think we should add infrastructure to detect bugs like this during
development, but not PANICing when this happens in production seems completely
non-viable.
Greetings,
Andres Freund
very handling, but it'd be "local" overhead, rather
than something affecting scalability.
FWIW, these days spinlocks do report a wait event when in perform_spin_delay()
- albeit without detail which lock is being held.
Greetings,
Andres Freund
kipState) because it is required for using the streaming
> read interface but not a natural change on its own. VacSkipState is per
> block and the LVRelState is referenced for the whole relation vacuum.
I'd do it the other way round, i.e. either embed VacSkipState ino LVRelState
or point to it from VacSkipState.
LVRelState is already tied to the iteration state, so I don't think there's a
reason not to do so.
Greetings,
Andres Freund
erything after ReadBufferExtended() and the end of the loop into its
own function
2) All the code in the loop body after the call to lazy_scan_prune() is
specific to the lazy_scan_prune() path, it doesn't make sense that it's at
the same level as the the calls to lazy_scan_noprune(),
lazy_scan_new_or_empty() or lazy_scan_prune(). Either it should be in
lazy_scan_prune() or a new wrapper function.
3) It's imo wrong that we have UnlockReleaseBuffer() (there are 6 different
places unlocking if I didn't miscount!) and RecordPageWithFreeSpace() calls
in this many places. I think this is largely a consequence of the previous
points. Once those are addressed, we can have one common place.
But I digress.
Greetings,
Andres Freund
now,"
I didn't like that either :)
> and I don't think "reap" has a precise, universally-understood meaning.
Less concerned about that.
> You could call this "mark_unused_now" or "immediately_mark_unused" or
> something and it would be far more self-documenting, IMHO.
How about 'no_indexes' or such?
Greetings,
Andres Freund
, Tom changed it.
>
> So don't blame me. :-)
But I'd like you to feel guilty (no, not really) and fix it (yes, really) :)
Greetings,
Andres Freund
Hi,
On 2023-12-21 10:46:02 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-12-21 10:22:49 -0500, Tom Lane wrote:
> >> We could make it version-specific,
> >> https://www.postgresql.org/docs/17/installation.html
> >> and task src/tools/version_st
Hi,
On 2023-12-21 16:20:45 +0100, Tomas Vondra wrote:
> On 12/21/23 14:43, Andres Freund wrote:
> >> AFAICS this seems similar to some of the AIO patch, I wonder what that
> >> plans to do. I need to check.
> >
> > Yes, most of this exists there. The diffe
ted as soon as the branch is made?
I think it runs a few times a day - breaking the link for a few hours wouldn't
be optimal, but also not the end of the world. But redirecting $vnext -> to
devel would probably be a more reliable approach.
Greetings,
Andres Freund
On 2023-12-21 19:55:51 +0530, Amit Kapila wrote:
> On Thu, Dec 21, 2023 at 5:05 PM Andres Freund wrote:
> > We clearly can't just expose the numerical value for a C enum. So it has to
> > be
> > converted to something SQL representable.
> >
>
> We c
seems similar to some of the AIO patch, I wonder what that
> plans to do. I need to check.
Yes, most of this exists there. The difference that with the AIO you don't
need to prefetch, as you can just initiate the IO for real, and wait for it to
complete.
Greetings,
Andres Freund
that are likely to be consumed. If an index scan is under a
LIMIT 1, we shoulnd't prefetch. Similar for sequential scan with the
infrastructure in
https://postgr.es/m/CA%2BhUKGJkOiOCa%2Bmag4BF%2BzHo7qo%3Do9CFheB8%3Dg6uT5TUm2gkvA%40mail.gmail.com
Greetings,
Andres Freund
401 - 500 of 4240 matches
Mail list logo
