On 09/04/2025 17:23, Tom Lane wrote:
Heikki Linnakangas writes:
Inconsistency is not good either though. I'm not sure it's worth the
churn, but I could get on board a patch to actually replace all
HeapTupleIsValid(tuple) calls with plain "tuple != NULL" checks. Keep
HeapTup
y. That'll probably be more hacky, but there's
little harm in doing it the the same hacky way for one more release.
(I have not looked at the patches, so don't know if there are other issues)
--
Heikki Linnakangas
Neon (https://neon.tech)
nd
we could wait for another year but merging it now doesn't seem to be
too much of a burden either.
[1]: https://commitfest.postgresql.org/patch/5250/
I would consider that a feature, too late for v18. There's not
particular benefit in getting it into v18 vs later.
--
Heikki Linnakan
t my method for
finding these, not for commit.
Clever!
0002 contains the fixes to commit.
Any objections to doing this soonish? Or in a few weeks?
Sure, let's do it. Why would we wait?
--
Heikki Linnakangas
Neon (https://neon.tech)
Hi,
We are pleased to announce the Release Management Team (RMT) (cc'd) for
the PostgreSQL 18 release:
- Tomas Vondra
- Nathan Bossart
- Heikki Linnakangas
You can find information about the responsibilities of the RMT here:
https://wiki.postgresql.org/wiki/Release_Management_Team
We
though. I'm not sure it's worth the
churn, but I could get on board a patch to actually replace all
HeapTupleIsValid(tuple) calls with plain "tuple != NULL" checks. Keep
HeapTupleIsValid() just for compatibility, with a comment to discourage
using it.
--
Heikki Linnakangas
Neon (https://neon.tech)
(moving to pgsql-hackers)
On 09/04/2025 12:39, Peter Eisentraut wrote:
On 09.04.25 10:53, Heikki Linnakangas wrote:
On 08/04/2025 22:41, Heikki Linnakangas wrote:
On 08/04/2025 20:06, Peter Eisentraut wrote:
While I was looking at this, I suggest to make the first argument
void *. This is
On 09/04/2025 13:28, Heikki Linnakangas wrote:
On 09/04/2025 12:39, Peter Eisentraut wrote:
On 09.04.25 10:53, Heikki Linnakangas wrote:
On 08/04/2025 22:41, Heikki Linnakangas wrote:
On 08/04/2025 20:06, Peter Eisentraut wrote:
While I was looking at this, I suggest to make the first
alue.
That's a much clearer explanation of the behavior, but now that I read
that paragraph, I wonder *why* it behaves like that. I'm sure it's just
historical reasons. But perhaps we should nuke autoinc altogether?
--
Heikki Linnakangas
Neon (https://neon.tech)
On 08/04/2025 19:11, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
On 08.04.25 16:59, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
Earth):
I'll park it in the next CF.
In my opinion this would still be totally OK for v18. It's just test
changes. I would rather commit cleanups like this sooner than later.
--
Heikki Linnakangas
Neon (https://neon.tech)
. The runtime
linker expects to tell it exactly where to look using -blibpath.
Ok, some comments would be in order to explain that, maybe with links to
the relevant AIX documentation.
--
Heikki Linnakangas
Neon (https://neon.tech)
the WAL before creating
the file? Or is there still a small window where it can leak, if the
file creation makes it to disk before crash but the undo log (or the WAL
record of the undo log entry) does not?
Have you done any performance testing of this? By "this" I mean the
overhead
On 01/04/2025 21:25, Heikki Linnakangas wrote:
On 07/03/2025 13:30, Maxim Orlov wrote:
Here is a rebase, v14.
Thanks! I did some manual testing of this. I created a little helper
function to consume multixids, to test the autovacuum behavior, and
found one issue:
Forgot to attach the test
On 01/04/2025 18:08, Andres Freund wrote:
Hi,
On 2025-04-01 13:34:53 +0300, Heikki Linnakangas wrote:
Here's a rebase of these patches.
Thanks!
Curious what made you do this? Do you need any parts of this soon?
No, I was just browsing through the commitfest.
I went ahead and comm
I added it for the btree opfamily too, and moved the function to
rangetypes.c since it's not just for gist anymore. I Ccmmitted that
part, and will start looking more closely at the remaining btree_gist
parts now.
--
Heikki Linnakangas
Neon (https://neon.tech)
ilds could grow quite large though.
--
Heikki Linnakangas
Neon (https://neon.tech)
ans that I need to be pretty confident that there are others
who are interested and invested in keeping working, take ownership, will
help to debug problems in a timely fashion, and can submit high-quality
fixes. I am not seeing that.
I also notice that all the AIX systems we have in the buildfarm are still:
- maintained by Noah, who - correct me if I'm wrong - is not
particularly interested in AIX or keen on maintaining them
- are on AIX 7.1.5, which I believe is already end-of-line
- running on power7 hardware which is 15 years old.
That's not very reassuring.
--
Heikki Linnakangas
Neon (https://neon.tech)
have a feeling it might be complicated to do correctly on
all platforms, but I don't know.
--
Heikki Linnakangas
Neon (https://neon.tech)
's not a bug fix. There was an
bug with the original commit 728f86fec6, which was resolved by reverting
it in v16 and v17. This commit brings it back in v17, hopefully bug-free
this time.
--
Heikki Linnakangas
Neon (https://neon.tech)
similar 1 GB limit in dsm_create(), but I think it's a bit
unfortunate that the array needs to be allocated upfront upon loading.
In short, ISTM the easy answer here is "use palloc_extended". But
there's a lot of room for further optimizations.
--
Heikki Linnakangas
Neon (https://neon.tech)
off
I was sold on this at first, but then I realized that the SET
documentation doesn't mention placeholder variables either. I think it
would be better to document them for SET, there's more room for
discussion there than in this table. The set_config() documentation
already
commit message!
--
Heikki Linnakangas
Neon (https://neon.tech)
e two different relations with
the same relnumber, in different tablespaces.
--
Heikki Linnakangas
Neon (https://neon.tech)
it's safe to say
that you missed it already.
--
Heikki Linnakangas
Neon (https://neon.tech)
n. In that case, the local
variable "num" is 0, the loop never executes, and the function returns 0.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 02/04/2025 22:41, Heikki Linnakangas wrote:
On 02/04/2025 20:18, Heikki Linnakangas wrote:
So I added it for the btree opfamily too, and moved the function to
rangetypes.c since it's not just for gist anymore. I Ccmmitted that
part, and will start looking more closely at the rema
On 03/04/2025 14:29, Daniel Gustafsson wrote:
On 2 Apr 2025, at 15:48, Heikki Linnakangas wrote:
And committed, with minor a bunch more little cleanups.
0001 in commit 09be39112654 seems to have missed (omitted?) adding the HAVE_
macros to pg_config.h.in, which doesn't matter as o
On 02/04/2025 20:18, Heikki Linnakangas wrote:
So I added it for the btree opfamily too, and moved the function to
rangetypes.c since it's not just for gist anymore. I Ccmmitted that
part, and will start looking more closely at the remaining btree_gist
parts now.
Here's an updated
On 01/04/2025 17:08, Heikki Linnakangas wrote:
I think this is pretty much ready for commit. I will go over it one more
time, and plan to push tomorrow.
And committed, with minor a bunch more little cleanups.
Thank you to everyone involved, in particular Jelte, Robert and Jacob! I
read
cutoff that autovacuum then uses, are not
in sync.
This patch removed MultiXactMemberFreezeThreshold(), per my suggestion,
but we threw this baby with the bathwater. We discussed that in this
thread, but didn't come up with any solution. But ISTM we still need
something like MultiXactMemberFreezeThreshold() to
o document that the server only uses up to 32 bytes, and
middleware should likewise try to "add" only 32 bytes or so to the key,
so that you can stack multiple such middleware without exceeding the
total length. And perhaps 256 bytes is still too small,
functions, if you search for "immediately acquired".
--
Heikki Linnakangas
Neon (https://neon.tech)
On 30/03/2025 14:32, Heikki Linnakangas wrote:
On 30/03/2025 13:28, Etsuro Fujita wrote:
Another thing I noticed is $SUBJECT: I think “if lock could not
immediately acquired” should be “if lock could not be immediately
acquired”. Attached is a patch for that.
Yep. And there are more
become
problematic if snapshotting a very large number of variables stats, so
I fixed it. Attached is a patch for that.
Good catch. Patch looks good to me at quick glance.
--
Heikki Linnakangas
Neon (https://neon.tech)
granted to us, and if LockErrorCleanup() was called twice,
the second call would call GrantAwaitedLock() even if the lock was
already released and cleaned up.
I've pushed a fix to put that back.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 21/03/2025 12:28, Tomas Vondra wrote:
But it seems it changed in 952365cded6, which is:
commit 952365cded635e54c4177399c0280cb7a5e34c11
Author: Heikki Linnakangas
Date: Mon Dec 23 12:42:39 2024 +0200
Remove unnecessary GetTransactionSnapshot() calls
In
zing
for aborts.
For the same reason, I believe the assertion failure we're discussing
here is also harmless. Even though the reused snapshot has a smaller
xmin than expected, all those transactions aborted and are thus not
visible anyway.
In any case, let's be tidy and fix both late
On 24/03/2025 16:56, Tomas Vondra wrote:
On 3/23/25 17:43, Heikki Linnakangas wrote:
On 21/03/2025 17:16, Andres Freund wrote:
Am I right in understanding that the only scenario (when in
STANDBY_SNAPSHOT_READY), where ExpireOldKnownAssignedTransactionIds()
would
"legally"
to invent something more here.
Hi Tomas,
Since you think patch v2 is already OK as-is, I have changed the
commitfest entry [1] for this to RfC.
Committed, thanks!
It's always a balancing act between test coverage and how long the tests
run. I agree this test is worth it, albeit w
e locking on it, but I've never had a problem with having
data from different connections mixed up. The lines are not that long,
it probably just relies on write(2) being atomic enough.
--
Heikki Linnakangas
Neon (https://neon.tech)
t snapshot A
has a lower xmin.
--
Heikki Linnakangas
Neon (https://neon.tech)
x00 implies an 24-bit integer, but these are uint8's. Let's use
plain base-10 decimals here rather than hex, like in 'case_map'.
Attached are fixes for those and some other minor things.
--
Heikki Linnakangas
Neon (https://neon.tech)
From 63213dce1ee4a5c410f6b473424bee2b
On 06/01/2025 23:30, Heikki Linnakangas wrote:
On 20/12/2024 19:31, Heikki Linnakangas wrote:
/*
* Struct representing all kind of possible snapshots.
*
* There are several different kinds of snapshots:
* * Normal MVCC snapshots
* * MVCC snapshots taken during recovery (in Hot-Standby mode
TableSpace() we do this:
WaitForProcSignalBarrier(EmitProcSignalBarrier(PROCSIGNAL_BARRIER_SMGRRELEASE));
Should we do the same here? Not sure where exactly to put that; perhaps
in mdcreate(), if the creation fails with STATUS_DELETE_PENDING.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 12/03/2025 21:31, Tom Lane wrote:
Heikki Linnakangas writes:
ReorderBufferGetRelids allocates an array with MemoryContextAlloc, and
ReorderBufferReturnRelids just calls pfree. The pools are long gone, and
now the naming looks weird.
Attached patch renames those functions and other such
On 03/03/2025 19:44, Heikki Linnakangas wrote:
In any case, the attached patch works and seems like an easy fix for
stable branches at least.
Committed that to master and all affected stable branches.
--
Heikki Linnakangas
Neon (https://neon.tech)
the terms Alloc/Free. I actually wonder if we should go further and
remove these functions altogether, and change the callers to call
MemoryContextAlloc directly. But I didn't do that yet.
Any objections?
--
Heikki Linnakangas
Neon (https://neon.tech)
es, and FindConflictTuple() too. Thanks, I'll
go fix those too.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 21/01/2025 12:05, Alexander Korotkov wrote:
On Tue, Jan 21, 2025 at 12:03 PM Alexander Korotkov
wrote:
On Sun, Dec 29, 2024 at 3:59 PM Heikki Linnakangas wrote:
However, I think GetLatestSnapshot() is wrong here anyway. None of this
matters for heapam which just ignores the 'sna
and forget to increase the array size.
--
Heikki Linnakangas
Neon (https://neon.tech)
parameter "authentication_timeout" (1 s .. 600 s)
I had to increase PG_TEST_TIMEOUT_DEFAULT due to some other test timing out
when run under valgrind (due to having to insert a lot of rows). But then this
test runs into the above issue.
The easiest way seems to be to just limit PG_TEST_TIMEOUT_D
On 05/03/2025 01:23, Michael Paquier wrote:
On Tue, Mar 04, 2025 at 05:58:42PM -0500, Andres Freund wrote:
On 2024-12-10 12:00:12 +0200, Heikki Linnakangas wrote:
2. Move the pgstat_bestart() call earlier in the startup sequence, so that a
backend shows up in pg_stat_activity before it
On 05/03/2025 21:25, Andres Freund wrote:
On 2025-02-28 22:24:56 +0200, Heikki Linnakangas wrote:
The second patch makes it possible to use ModifyWaitEvent() to switch
between WL_POSTMASTER_DEATH and WL_EXIT_ON_PM_DEATH. WaitLatch() used to
modify WaitEventSet->exit_on_postmaster_death direc
AM has checked the visibility map, and the VM bit was set.
IndexOnlyNext() can skip the VM check and use the tuple directly.
3. The index AM has checked the visibility map, and the VM bit was not
set. IndexOnlyNext() will fetch the tuple to check its visibility.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 04/03/2025 21:38, Nathan Bossart wrote:
On Tue, Mar 04, 2025 at 08:22:02PM +0200, Heikki Linnakangas wrote:
To make things less confusing, the attached patch renames all the functions
that are part of the overall signal/interrupt handling system but are *not*
executed in a signal handler to
ndle*() will go away, and the Process*()
functions will mostly stay. But IMHO this makes sense independently of
that work.
--
Heikki Linnakangas
Neon (https://neon.tech)From 0841756bc9b8108aeb5a0dc2b85fc9d0e7dbb11e Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Mon, 3 Mar 2025 10:50:4
lans are registered in the Append node? If it is legitimate for it
to care, we probably should've abstracted that somehow, rather than
expose that "GetNumRegisteredWaitEvents(set) == 1" means that there are
no other events registered yet.
In any case, the attached patch works and
was stamped already, but ...).
Looks good, thanks!
--
Heikki Linnakangas
Neon (https://neon.tech)
Lock and SInvalWriteLock.
I kind of wonder why we need that MSGNUMWRAPAROUND limit at all; can't
we just let the integer wrap around naturally? (after switching to
unsigned, that is). That doesn't need to be part of this patch though,
it can be done separately, if it's worthwhile..
.
--
Heikki Linnakangas
Neon (https://neon.tech)
special case
for some of the functions, not all. If you stored the special_case
separately for each function (as the high byte in the 'simplemap' field
perhaps, like I suggested on previous point), you could avoid having
those "dummy" special cases.
--
Heikki Linnakangas
Neon (https://neon.tech)
fillfactor.
--
Heikki Linnakangas
Neon (https://neon.tech)
not call the 3-way
ORDER proc in the first place? That would avoid the overhead of another
call here.
Aside from these micro-optimizations, I wonder about the "look-ahead"
logic in _bt_checkkeys_look_ahead. It feels pretty simplistic. Could you
use Exponential Search
(https:/
On 12/01/2025 03:26, Noah Misch wrote:
On Thu, Jan 09, 2025 at 11:39:53AM +0200, Heikki Linnakangas wrote:
On 07/01/2025 23:56, Noah Misch wrote:
@@ -697,9 +725,14 @@ CreateCacheMemoryContext(void)
*
* This is not very efficient if the target cache is nearly empty.
* However, it
On 07/01/2025 23:56, Noah Misch wrote:
On Tue, Dec 24, 2024 at 12:18:09AM +0200, Heikki Linnakangas wrote:
I'm thinking of the attached to fix this. It changes the strategy for
detecting concurrent cache invalidations. Instead of the "recheck" mechanism
that was introduced in co
thread, where I also needed
btmask_all_except3() but then removed the only call to
btmask_all_except2(). Instead of adding/removing code, it seems better
to just use a variadic function.
Nice. A variadic btmask_add() might be handy too.
And then 0004, the reason for this thread.
Overall, looks good to me.
--
Heikki Linnakangas
Neon (https://neon.tech)
needs to call the prepare functions explicitly, instead of having them
as callbacks. Nominally that's more steps, but IMHO it's better to be
explicit. The same actions were happening previously too, it was just
hidden in the callback. I updated the README to show that too.
I'm not wed
&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.
--
Heikki Linnakangas
Neon (https://neon.tech)
r, before the IO is submitted.
This would also make it easier to order functions more sensibly in aio.c, as
all the issuer functions would be together.
The functions on AIO handles that everyone can call already have a distinct
type (PgAioHandleRef vs PgAioHandle*).
Hmm, yeah I think you migh
On 07/01/2025 00:00, Andres Freund wrote:
On 2024-12-20 19:31:01 +0200, Heikki Linnakangas wrote:
While playing around some more with this, I noticed that this code in
GetTransactionSnapshot() is never reached, and AFAICS has always been dead
code:
Snapshot
GetTransactionSnapshot(void
On 27/12/2024 19:09, Maxim Orlov wrote:
On Wed, 18 Dec 2024 at 13:21, Heikki Linnakangas <mailto:hlinn...@iki.fi>> wrote:
Does the pg_upgrade code work though, if you have that buggy situation
where oldestOffsetKnown == false ?
...
>
>
pam, it could be the TID
like today, but a different AM could return some other token. Continue
to use SnapshotDirty in the index scan, but in the call to
table_tuple_lock(), instead of passing GetLatestSnapshot() and TID, pass
the token you got index_getnext_slot().
Thoughts?
--
Heikki Linnakangas
Neon (https://neon.tech)
flex NEWS file, this syntax was added in flex
2.5.34, and we already require 2.5.35.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 25/12/2024 18:34, Tom Lane wrote:
Heikki Linnakangas writes:
Ok, committed that, thanks1
The question this patch brings to my mind is whether libpgport
doesn't need the same treatment.
Good point. Yes it does.
I tested that by adding a dummy call to COMP_CRC32C() in a test module,
: cflag_libs,
c_pch: pch_c_h,
I also created entry in the commit fest with this patch
https://commitfest.postgresql.org/51/5457/
Ok, committed that, thanks1
--
Heikki Linnakangas
Neon (https://neon.tech)
worth considering.
Or maybe you could improve the selectivity estimator of the LIKE
operator to be more accurate to begin with.
--
Heikki Linnakangas
Neon (https://neon.tech)
good on
modern compilers and systems in general. Perhaps we should just always
use the system memset(). So for this patch, e key question is whether
there's something AIX specific here. I'd assume no. I'd assume it to
depend on the hardware rather than the OS.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 24/12/2024 09:38, Michael Paquier wrote:
On Tue, Dec 24, 2024 at 12:18:09AM +0200, Heikki Linnakangas wrote:
My first attempt was to insert the CatCTup or CatCList entry to the catcache
before starting to build it, marked with a flag to indicate that the entry
isn't fully built yet. But
On 14/12/2024 02:06, Heikki Linnakangas wrote:
Ok, I missed that. It does not handle the 2nd scenario though: If a new
catalog tuple is concurrently inserted that should be part of the list,
it is missed.
I was able to reproduce that, by pausing a process with gdb while it's
buildin
pgcommon@0@'.format(name),
link_with: cflag_libs,
+ link_whole: cflag_libs,
c_pch: pch_c_h,
kwargs: opts + {
'include_directories': [
--
Heikki Linnakangas
Neon (https://neon.tech)
CREATE TABLE test AS SELECT 2 as id;
session 2:
SELECT * FROM test;
id
(0 rows)
Session 2 sees the table that was created concurrently, but not its
contents.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 12/12/2024 22:26, Heikki Linnakangas wrote:
On 12/12/2024 21:57, Andres Freund wrote:
Perhaps we should have some assertions ensuring TransactionXmin has a
valid
value in some places?
+1, wouldn't hurt.
I didn't, after all, as I couldn't find a good place where to put th
On 16/12/2024 23:56, Nathan Bossart wrote:
On Mon, Dec 16, 2024 at 12:06:33PM +0200, Heikki Linnakangas wrote:
While working on the CSN snapshot patch, I got sidetracked looking closer
into the snapshot tracking in snapmgr.c. Attached are a few patches to
clarify some things.
I haven'
hat might be happening.
I don't know how that can happen, but I suspect commit 3c0fd64fec
because it changed things in that area. If you can find a way to
reproduce that even sporadically, that would be very helpful!
--
Heikki Linnakangas
Neon (https://neon.tech)
On 17/12/2024 23:28, Andres Freund wrote:
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
error into the relevant paths in HEAD
and see whether it triggers for anybody in the next months. Having all these
untested paths in md.c forever doesn't seem great.
+1
--
Heikki Linnakangas
Neon (https://neon.tech)
me with TEMP_CONFIG containing:
recovery_min_apply_delay = '500ms'
All the other tests (I ran check-world) pass with this setting. So maybe
this test lacks waiting for standby synchronization.
Fixed, thanks!
--
Heikki Linnakangas
Neon (https://neon.tech)
ept of a returned
statically-allocated snapshot, and the whole question of what does "used
very long" mean in GetTransactionSnapshot(). Thoughts on that?
--
Heikki Linnakangas
Neon (https://neon.tech)
From 7a32da753d05819c991d93cce3e3174f5a142238 Mon Sep 17 00:00:00 2001
From: Heikki Linn
nicer in
general, and it might also fix a few possible small memory leaks.
I did a bit more work on this, so here is an updated patch set.
Looks good to me. There's more work to be done, but this is all good
steps in the right direction.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 13/12/2024 17:30, Tom Lane wrote:
Heikki Linnakangas writes:
CatalogCacheCreateEntry() can accept catcache invalidations when it
opens the toast table, and it now has recheck logic to detect the case
that the tuple it's processing (ntp) is invalidated. However, isn't it
also pos
hat
we had processed in an earlier iteration of the loop? Or that a new
catalog tuple was inserted that should be part of the list we're building?
--
Heikki Linnakangas
Neon (https://neon.tech)
On 12/12/2024 21:57, Andres Freund wrote:
On 2024-12-12 20:16:39 +0200, Heikki Linnakangas wrote:
A straightforward fix is to ensure that TransactionXmin is updated whenever
MyProc->xmin is:
diff --git a/src/backend/utils/time/snapmgr.c
b/src/backend/utils/time/snapmgr.c
index a1a0c2ad
sactionXmin in all of those cases
as well, so that TransactionXmin is always the equal to MyProc->xmin.
Maybe even rename it to MyProcXmin to make that more clear.
--
Heikki Linnakangas
Neon (https://neon.tech)
#
# Session 3 starts with a cursor on table and fetches one row.
# Then it
On 09/12/2024 22:55, Heikki Linnakangas wrote:
Not sure how to fix this. A small sleep in the test would work, but in
principle there's no delay that's guaranteed to be enough. A more robust
solution would be to run a "select count(*) from pg_stat_activity" and
wait
On 09/12/2024 14:47, Tomas Vondra wrote:
On 12/9/24 13:30, Heikki Linnakangas wrote:
On 09/12/2024 01:12, Tomas Vondra wrote:
On 11/14/24 15:13, Heikki Linnakangas wrote:
On 09/10/2024 23:40, Heikki Linnakangas wrote:
I pushed the first three patches, with the new test and one of the
small
On 09/12/2024 01:12, Tomas Vondra wrote:
On 11/14/24 15:13, Heikki Linnakangas wrote:
On 09/10/2024 23:40, Heikki Linnakangas wrote:
I pushed the first three patches, with the new test and one of the small
refactoring patches. Thanks for all the comments so far! Here is a new
version of the
On 04/12/2024 03:24, Tom Lane wrote:
Andres Freund writes:
On 2024-12-03 22:06:59 +0200, Heikki Linnakangas wrote:
I spotted some more remnants of the "snapshot too old" feature that was
removed in v17. Barring objections, I will commit the attached patch to tidy
up.
Most of th
I spotted some more remnants of the "snapshot too old" feature that was
removed in v17. Barring objections, I will commit the attached patch to
tidy up.
--
Heikki Linnakangas
Neon (https://neon.tech)
From a24f69e0bcf38721e5ffe2c7b65f9901fa8b079d Mon Sep 17 00:00:00 2001
Fr
On 02/12/2024 09:32, Thomas Munro wrote:
On Sat, Nov 23, 2024 at 10:58 AM Heikki Linnakangas wrote:
Hmm, so this would replace the maybeSleepingOnInterrupts bitmask I
envisioned. Makes a lot of sense. If it's a single bit though, that
means that you'll still get woken up by inter
rg/wiki/If_and_only_if.
There was some previous discussion on pgsql-hackers on whether that
usage common enough, although I don't find the thread right now. You're
not the first one to think it's a typo :-).
--
Heikki Linnakangas
Neon (https://neon.tech)
1 - 100 of 1171 matches
Mail list logo
