On 06/06/2024 18:27, Robert Haas wrote:
On Thu, Jun 6, 2024 at 7:32 AM Heikki Linnakangas wrote:
Barring objections, I'll commit this later today or tomorrow. Thanks for
the report!
Committed.
I think you may have forgotten to push.
Huh, you're right. I could swear I did...
Pushed now
On 06/06/2024 17:23, Robert Haas wrote:
On Thu, Jun 6, 2024 at 5:00 AM Heikki Linnakangas wrote:
If there is some material harm from compiling with multithreading
support even if you're not using it, we should try to fix that. I'm not
dead set against having a compile-time option, but I don't
On 05/06/2024 16:58, Heikki Linnakangas wrote:
On 04/06/2024 01:49, Heikki Linnakangas wrote:
A straightforward fix is to modify RelationFlushRelation() so that if
!IsTransactionState(), it just marks the entry as invalid instead of
calling RelationClearRelation(). That's what
re is some material harm from compiling with multithreading
support even if you're not using it, we should try to fix that. I'm not
dead set against having a compile-time option, but I don't see the need
for it at the moment.
--
Heikki Linnakangas
Neon (https://neon.tech)
something with the PG_MODULE_MAGIC line, I think it should involve
options-passing of some form rather than just having an alternate
macro name.
+1, that would be nicer.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 04/06/2024 01:49, Heikki Linnakangas wrote:
A straightforward fix is to modify RelationFlushRelation() so that if
!IsTransactionState(), it just marks the entry as invalid instead of
calling RelationClearRelation(). That's what RelationClearRelation()
would do anyway, if it didn't hit
it to RelationInvalidateRelation.
--
Heikki Linnakangas
Neon (https://neon.tech)From 227f173d1066955a2ab6aba12c508aaa1f416c27 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Wed, 5 Jun 2024 13:29:51 +0300
Subject: [PATCH 1/3] Make RelationFlushRelation() work without ResourceOwner
during abort
made, and having to update
builds for pgAdmin and the Windows installers, I think it's clear it's
far more experimental on that platform than it is on Linux at least.
What kind of issues did you run into? Have they been fixed since?
--
Heikki Linnakangas
Neon (https://neon.tech)
d relation. So before going for the
straightforward fix, I'm going to see if I can refactor
RelationClearRelation() to be less complicated.
--
Heikki Linnakangas
Neon (https://neon.tech)
ction backend process. When
the connection is terminated, the backend process exits, cleaning up any
resources including the WaitEventSet.
--
Heikki Linnakangas
Neon (https://neon.tech)
you provide some more details on the expectations here?
Smallest possible patch that makes Postgres work on AIX again.
Perhaps start with the patch you posted yesterday, but remove hunks from
it one by one, to see which ones are still needed.
--
Heikki Linnakangas
Neon (https://neon.tech)
is enabled, but it's not effective
because all leading keys are different?
--
Heikki Linnakangas
Neon (https://neon.tech)
in section "Performance
Test")
Impressive. Did you test the performance of the cases where MK-sort
doesn't help, to check if there is a performance regression?
--
Heikki Linnakangas
Neon (https://neon.tech)
of these test cases are broken as such, you just don't get the
benefit of the optimization. I suspect they might all have the same root
cause, as they all involve constants in the target list. I think that's
a pretty common use case of UNION though.
--
Heikki Linnakangas
Neon (https://neon.tech)
t's also a fine use of the
commitfest app. The expected workflow is to get some review on the
patch, and then move it back to Waiting on Author.
--
Heikki Linnakangas
Neon (https://neon.tech)
and cirrus CI runs automatically.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 16/05/2024 17:08, Daniel Gustafsson wrote:
On 16 May 2024, at 15:54, Robert Haas wrote:
On Wed, May 15, 2024 at 9:33 AM Heikki Linnakangas wrote:
Ok, yeah, I can see that now. Here's a new version to address that. I
merged ENC_SSL_NEGOTIATED_SSL and ENC_SSL_DIRECT_SSL to a single method
now check
conn-sslnegotiation. That seems more clear now that there is no fallback.
--
Heikki Linnakangas
Neon (https://neon.tech)
From 7a2bc2ede5ba7bef147e509ce3c4d5472c8e0247 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Wed, 15 May 2024 16:27:51 +0300
Subject: [PATCH v2 1/1] Remov
order. I think you'd still need a "main" sql file that includes
all the other files in the right order. And using the table names as
filenames gets tricky if the table names contain any funny characters.
For manual operations, yeah, I can see it being useful nevertheless.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 13/05/2024 16:55, Jelte Fennema-Nio wrote:
On Mon, 13 May 2024 at 15:38, Heikki Linnakangas wrote:
Here's a patch to implement that.
+ if (conn->sslnegotiation[0] == 'd' &&
+ conn->sslmode[0] != 'r' && conn->sslmode[0] != 'v')
I think these
On 10/05/2024 16:50, Heikki Linnakangas wrote:
New proposal:
- Remove the "try both" mode completely, and rename "requiredirect" to
just "direct". So there would be just two modes: "postgres" and
"direct". On reflection, the automatic fallback
On 13/05/2024 12:50, Jelte Fennema-Nio wrote:
On Sun, 12 May 2024 at 23:39, Heikki Linnakangas wrote:
In v18, I'd like to make sslmode=require the default. Or maybe introduce
a new setting like "encryption=ssl|gss|none", defaulting to 'ssl'. If we
want to encourage encryption, that's
On 11/05/2024 23:45, Jelte Fennema-Nio wrote:
On Fri, 10 May 2024 at 15:50, Heikki Linnakangas wrote:
New proposal:
- Remove the "try both" mode completely, and rename "requiredirect" to
just "direct". So there would be just two modes: "postgres" an
xhtml#alpn-protocol-ids
Nice, thanks!
Committed the change from "TBD-pgsql" to "postgresql", thanks!
--
Heikki Linnakangas
Neon (https://neon.tech)
On 29/04/2024 22:32, Jacob Champion wrote:
On Mon, Apr 29, 2024 at 12:06 PM Heikki Linnakangas wrote:
There is a small benefit with sslmode=prefer if you connect to a server
that doesn't support SSL, though. With sslnegotiation=direct, if the
server rejects the direct SSL connection
an intentional scheme there, probably just done for
convenience or copied from previous practice. These should be organized
into appropriate header files.
+1 for moving all these to header files. Also all the "other stuff" in
patch 0007.
--
Heikki Linnakangas
Neon (https://neon.tech)
gMode(InitProcessing)" calls in other Main functions too
(AutoVacLauncherMain, BackgroundWorkerMain, etc.), and I think those can
also be removed.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 29/04/2024 21:43, Jacob Champion wrote:
On Mon, Apr 29, 2024 at 1:38 AM Heikki Linnakangas wrote:
If you only
have v17 servers in your environment, so you know all servers support
direct negotiation if they support SSL at all, but a mix of servers with
and without SSL, sslnegotiation
On 29/04/2024 21:04, Jacob Champion wrote:
On Fri, Apr 26, 2024 at 3:51 PM Heikki Linnakangas wrote:
I finally understood what you mean. So if the client supports ALPN, but
the list of protocols that it provides does not include 'postgresql',
the server should reject the connection
On 29/04/2024 21:06, Ranier Vilela wrote:
Em seg., 29 de abr. de 2024 às 14:56, Heikki Linnakangas
mailto:hlinn...@iki.fi>> escreveu:
On 29/04/2024 20:10, Ranier Vilela wrote:
> Hi,
>
> With TLS 1.3 and others there is possibly a security flaw us
he PostgreSQL server: the server disconnects without
reading the message. And I don't see any way for an ALPACA attack when
the server ignores the client's message. Nevertheless, from the point of
view of keeping the attack surface as small as possible, aborting
earlier seems better.
--
Heikki Lin
d/3a6f126c-e1aa-4dcc-9252-9868308f6cf0%40iki.fi
[5]
https://www.postgresql.org/message-id/CA%2BTgmoaNkRerEmB9JPgW0FhcJAe337AA%3D5kp6je9KekQhhRbmA%40mail.gmail.com
--
Heikki Linnakangas
Neon (https://neon.tech)
e returns NULL or an empty string. So
I think an empty string is better.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 26/04/2024 02:23, Jacob Champion wrote:
On Thu, Apr 25, 2024 at 2:50 PM Heikki Linnakangas wrote:
I think that comes down to the debate upthread, and whether you think
it's a performance tweak or a security feature. My take on it is,
`direct` mode is performance, and `requiredirect
On 27/04/2024 11:27, Anton A. Melnikov wrote:
Hello!
Maybe add PGDLLIMPORT to
extern bool LoadedSSL;
and
extern struct ClientSocket *MyClientSocket;
definitions in the src/include/postmaster/postmaster.h ?
Peter E noticed and Michael fixed them in commit 768ceeeaa1 already.
--
Heikki
On 23/04/2024 20:02, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 2:43 PM Heikki Linnakangas wrote:
On 19/04/2024 19:48, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
With direct SSL negotiation, we always require ALPN.
(As an aside: I haven't gotten
ncmode' option is already
quite weird in that it seems to override the "require"d priority of
"sslmode=require", which it IMO really shouldn't.
Yeah, that combination is weird. I think we should forbid it. But that's
separate from sslnegotiation.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 24/04/2024 23:51, Peter Eisentraut wrote:
On 08.04.24 10:38, Heikki Linnakangas wrote:
On 08/04/2024 04:25, Heikki Linnakangas wrote:
One important open item now is that we need to register a proper ALPN
protocol ID with IANA.
I sent a request for that:
https://mailarchive.ietf.org/arch
there. And you can get pretty far by just running
'pg_dump --schema-only' on both databases and comparing them with 'diff'.
--
Heikki Linnakangas
Neon (https://neon.tech)
GSSAPI request. So that comment applies
to sslnegotiation=direct, but not sslnegotiation=requiredirect.
Attached patch tries to fix and clarify those.
(Note that the client will only attempt GSSAPI encryption if it can find
kerberos credentials in the environment.)
--
Heikki Linnakangas
Neon
for example.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 22/04/2024 10:47, Heikki Linnakangas wrote:
On 22/04/2024 10:19, Michael Paquier wrote:
On Sat, Apr 20, 2024 at 12:43:24AM +0300, Heikki Linnakangas wrote:
On 19/04/2024 19:48, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
With direct SSL negotiation, we
On 22/04/2024 10:19, Michael Paquier wrote:
On Sat, Apr 20, 2024 at 12:43:24AM +0300, Heikki Linnakangas wrote:
On 19/04/2024 19:48, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
With direct SSL negotiation, we always require ALPN.
(As an aside: I
On 19/04/2024 19:48, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
With direct SSL negotiation, we always require ALPN.
(As an aside: I haven't gotten to test the version of the patch that
made it into 17 yet, but from a quick glance it looks like we're
TLS layer is established with direct
SSL, you never need to retry with traditional negotiation, or vice versa.
[1]
https://www.postgresql.org/message-id/CAAWbhmjetCVgu9pHJFkQ4ejuXuaz2mD1oniXokRHft0usCa7Yg%40mail.gmail.com
--
Heikki Linnakangas
Neon (https://neon.tech)
On 18 April 2024 14:15:43 GMT+03:00, Sriram RK wrote:
>Thanks Noah and Team,
>
>We (IBM-AIX team) looked into this issue
>
>https://www.postgresql.org/message-id/20240225194322...@rfd.leadboat.com
>
>This is related to the compiler issue. The compilers xlc(13.1) and gcc(8.0)
>have issues. But we
more occurrences I've found
with a bit of grepping.
+1
--
Heikki Linnakangas
Neon (https://neon.tech)
ould clear the HEAP_MOVED_IN flag instead.
[1]
https://www.postgresql.org/message-id/CAAKRu_azf-zH%3DDgVbquZ3tFWjMY1w5pO8m-TXJaMdri8z3933g%40mail.gmail.com
--
Heikki Linnakangas
Neon (https://neon.tech)From 9dcd528dd42f689e207d808bee388fb233b2e25e Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: S
ce(llvm_opt0_orc);
llvm_opt0_orc = NULL;
}
}
The autoconf test that set HAVE_DECL_LLVMORCREGISTERPERF was removed in
commit e9a9843e13. I believe that's a leftover that should also have
been removed.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 11/04/2024 16:37, Ranier Vilela wrote:
Em qui., 11 de abr. de 2024 às 09:54, Heikki Linnakangas
mailto:hlinn...@iki.fi>> escreveu:
On 11/04/2024 15:03, Ranier Vilela wrote:
> Em qua., 10 de abr. de 2024 às 18:28, Heikki Linnakangas
> mailto:hlinn...@iki.fi>
typo while reading the code.
--
Heikki Linnakangas
Neon (https://neon.tech)
From 5f531b719c176b2f316b6341fa062af508ed2e10 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Sun, 7 Apr 2024 22:34:23 +0300
Subject: [PATCH 1/2] fix typos
---
doc/src/sgml/maintenance.sgml
(moved to pgsql-hackers, change subject)
On 10/04/2024 18:54, Heikki Linnakangas wrote:
On 10/04/2024 17:48, Peter Eisentraut wrote:
On 08.04.24 01:50, Heikki Linnakangas wrote:
Add tests for libpq gssencmode and sslmode options
Why aren't these tests at
src/interfaces/libpq/t
On 11/04/2024 18:09, Alexander Korotkov wrote:
On Thu, Apr 11, 2024 at 1:46 AM Heikki Linnakangas wrote:
On 07/04/2024 00:52, Alexander Korotkov wrote:
* At first, we check that pg_wal_replay_wait() is called in a non-atomic
* context. That is, a procedure call isn't wrapped
.
Pushed the patch and reverted binaryheap changes.
Thank you!
--
Heikki Linnakangas
Neon (https://neon.tech)
On 11/04/2024 15:03, Ranier Vilela wrote:
Em qua., 10 de abr. de 2024 às 18:28, Heikki Linnakangas
mailto:hlinn...@iki.fi>> escreveu:
On 10/04/2024 21:07, Ranier Vilela wrote:
> Hi,
>
> Per Coverity.
>
> The function ReorderBufferTXNByXid,
On 11/04/2024 01:37, Michael Paquier wrote:
On Thu, Apr 11, 2024 at 12:20:55AM +0300, Heikki Linnakangas wrote:
To move this forward, here's a patch to switch to a pairing heap. In my very
quick testing, with the performance test cases posted earlier in this thread
[1] [2], I'm seeing
oesn't feel quite ready for v17, and IMHO should
be reverted. It's a nice feature, so I'd love to have it fixed and
reviewed early in the v18 cycle.
--
Heikki Linnakangas
Neon (https://neon.tech)
ld already have its
ReorderBufferTXN entry, so ReorderBufferTXN() should never return NULL.
It's not surprising if Coverity doesn't understand that, but setting the
'create' flag doesn't seem like the right fix. If we add "Assert(txn !=
NULL)", does that silence it?
--
Heikki Lin
On 10/04/2024 08:31, Amit Kapila wrote:
On Wed, Apr 10, 2024 at 11:00 AM Heikki Linnakangas wrote:
On 10/04/2024 07:45, Michael Paquier wrote:
On Tue, Apr 09, 2024 at 09:16:53PM -0700, Jeff Davis wrote:
On Wed, 2024-04-10 at 12:13 +0900, Michael Paquier wrote:
Wouldn't the best way forward
to switch the pairing heap,
performance test that, and revert the binary heap changes.
--
Heikki Linnakangas
Neon (https://neon.tech)
hash table. And it's cheap to to insert to (O(1)), so we could
probably remove the MAX_HEAP_TXN_COUNT_THRESHOLD, and always keep the
heap up-to-date.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 09/04/2024 07:40, Erik Rijkers wrote:
Typo. fix:
-attempted first. If the server ejectes GSS encryption, SSL is
+attempted first. If the server rejects GSS encryption, SSL is
Fixed, thanks!
--
Heikki Linnakangas
Neon (https://neon.tech)
: Hard feature freeze deadline
This would also give everyone more visibility, so that we're not all
surprised by the last minute flood of commits.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 08/04/2024 04:25, Heikki Linnakangas wrote:
One important open item now is that we need to register a proper ALPN
protocol ID with IANA.
I sent a request for that:
https://mailarchive.ietf.org/arch/msg/tls-reg-review/9LWPzQfOpbc8dTT7vc9ahNeNaiw/
--
Heikki Linnakangas
Neon (https
On 08/04/2024 04:28, Tom Lane wrote:
Heikki Linnakangas writes:
Committed this. Thank you to everyone involved!
Looks like perlcritic isn't too happy with the test code:
koel and crake say
./src/test/libpq_encryption/t/001_negotiate_encryption.pl: Return value of
flagged function ignored
ortant open item now is that we need to register a proper ALPN
protocol ID with IANA.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 07/04/2024 13:19, Heikki Linnakangas wrote:
1st patch fixes the LDAP setup tests, and 2nd patch fixes the error
handling in the END blocks.
Committed and backpatched these test fixes.
--
Heikki Linnakangas
Neon (https://neon.tech)
nd 2nd patch fixes the error
handling in the END blocks.
[1] https://commitfest.postgresql.org/47/4742/
--
Heikki Linnakangas
Neon (https://neon.tech)From 6f09361ac0dbac5c2aef59b6a24e92486097cb43 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Sun, 7 Apr 2024 13:06:39 +0300
Subject: [PATCH 1/2
stgres: heikki postgres [local] ANALYZE(_start+0x21)[0x564889971a61]
2024-04-03 20:15:49.157 EEST [262101] LOG: server process (PID 262232)
was terminated by signal 6: Aborted
--
Heikki Linnakangas
Neon (https://neon.tech)
and attached the diff.
Applied those changes, and committed. Thank you!
Off-list, Melanie reported that there is a small regression with the
benchmark script she posted yesterday, after all, but I'm not able to
reproduce that.
Actually, I think it was noise.
Ok, phew.
--
Heikki Linnakangas
Neon
On 02/04/2024 16:11, Heikki Linnakangas wrote:
On 01/04/2024 20:22, Melanie Plageman wrote:
Review for 0003-0006 (I didn't have any new thoughts on 0002). I know
you didn't modify them much/at all, but I noticed some things in my code
that could be better.
Ok, here's what I have now. I made
;
The SELECT takes about 390 ms on 'master', and 230 ms with the patch.
This is pretty much the best case for this patch, real world gains will
be much smaller. Nevertheless, nice speedup!
--
Heikki Linnakangas
Neon (https://neon.tech)
implementation to vacuumlazy.c as is. Would
be nice to have just one copy of this in some common place, but I also
wasn't sure where to put it.
--
Heikki Linnakangas
Neon (https://neon.tech)
From be8891155c93f3555c49371f9804bdf5ba578f6e Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Tue
han "(prstate.options &
HEAP_PRUNE_PAGE_MARK_UNUSED_NOW) != 0" anyway.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 01/04/2024 19:08, Melanie Plageman wrote:
On Mon, Apr 01, 2024 at 05:17:51PM +0300, Heikki Linnakangas wrote:
diff --git a/src/backend/access/heap/pruneheap.c
b/src/backend/access/heap/pruneheap.c
@@ -256,15 +270,16 @@ heap_page_prune(Relation relation, Buffer buffer,
tup.t_tableOid
On 01/04/2024 09:05, Andrey M. Borodin wrote:
I think it makes sense to close this commitfest only after Feature Freeze on
April 8, 2024 at 0:00 AoE.
What do you think?
+1. IIRC that's how it's been done in last commitfest in previous years too.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 29/03/2024 09:01, Thomas Munro wrote:
On Fri, Mar 29, 2024 at 9:45 AM Heikki Linnakangas wrote:
master (213c959a29):8.0 s
streaming-api v13: 9.5 s
Hmm, that's not great, and I think I know one factor that has
confounded my investigation and the conflicting reports
en marked yet.
I haven't finished updating all the comments, but I am really interested
to know what you think about heap_prune_chain() now.
Looks much better now, thanks!
--
Heikki Linnakangas
Neon (https://neon.tech)
On 28/03/2024 13:15, Matthias van de Meent wrote:
On Tue, 5 Mar 2024 at 15:08, Heikki Linnakangas wrote:
I hope I didn't joggle your elbow reviewing this, Jacob, but I spent
some time rebase and fix various little things:
With the recent changes to backend startup committed by you
On 28/03/2024 03:53, Melanie Plageman wrote:
On Thu, Mar 28, 2024 at 01:04:04AM +0200, Heikki Linnakangas wrote:
One change with this is that live_tuples and many of the other fields are
now again updated, even if the caller doesn't need them. It was hard to skip
them in a way that would save
() decides what to do with each tuple, and
ensures that each tuple is marked only once, and the subroutines update
all the variables, add the item to the correct arrays etc. depending on
what we're doing with it.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 24/03/2024 15:02, Thomas Munro wrote:
On Wed, Mar 20, 2024 at 4:04 AM Heikki Linnakangas wrote:
Maybe 'pg_streaming_read_next_buffer' or just 'pg_streaming_read_next',
for a shorter name.
Hmm. The idea of 'buffer' appearing in a couple of names is that
there are conceptually other kinds
On 24/03/2024 18:32, Melanie Plageman wrote:
On Thu, Mar 21, 2024 at 9:28 AM Heikki Linnakangas wrote:
In heap_page_prune_and_freeze(), we now do some extra work on each live
tuple, to set the all_visible_except_removable correctly. And also to
update live_tuples, recently_dead_tuples
and vacuum WAL record formats"). Marking this as Committed in the
commitfest.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 24/03/2024 21:55, Melanie Plageman wrote:
On Sat, Mar 23, 2024 at 01:09:30AM +0200, Heikki Linnakangas wrote:
On 20/03/2024 21:17, Melanie Plageman wrote:
There is another patch in the commitfest that touches this area: "Recording
whether Heap2/PRUNE records are from VACUUM or
/cmp/etc are lifted and
shifted from one file to another. When I am reviewing a big diff, it is
always helpful to know where I need to review line-by-line.
Done.
From 5d6fc2ffbdd839e0b69242af16446a46cf6a2dc7 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Wed, 20 Mar 2024 13:49:59 +0200
On 20/03/2024 23:03, Melanie Plageman wrote:
On Wed, Mar 20, 2024 at 03:15:49PM +0200, Heikki Linnakangas wrote:
diff --git a/src/include/access/heapam.h b/src/include/access/heapam.h
index ee0eca8ae02..b2015f5a1ac 100644
--- a/src/include/access/heapam.h
+++ b/src/include/access/heapam.h
how much value do these assertions carry?
If you're intent on keeping them, perhaps casting child_type to
int here would suppress the warnings. But personally I think
I'd lose the Asserts.
Yeah, it's not a very valuable assertion. Removed, thanks!
--
Heikki Linnakangas
Neon (https://neon.tech)
s just 'pgsr->distance = pgsr->max_pinned_buffers' ?
--
Heikki Linnakangas
Neon (https://neon.tech)
regular and shared iterators be merged, or wrapped under a
common interface?
--
Heikki Linnakangas
Neon (https://neon.tech)
postgres user,
and print a warning or refuse to start up if they are.
(Another way to read this proposal is to rename the GUC that's been
discussed in this thread to 'configuration_managed_externally'. That
makes it look less like a security feature, and describes the intended
use case.)
-
to me, albeit a very minor one. Certainly not an
optimization, it doesn't affect performance in any way, only what
EXPLAIN reports. So committed and backported that to all supported branches.
--
Heikki Linnakangas
Neon (https://neon.tech)
On 13/03/2024 09:30, Heikki Linnakangas wrote:
Attached is a new version of the remaining patches.
Committed, with some final cosmetic cleanups. Thanks everyone!
--
Heikki Linnakangas
Neon (https://neon.tech)
nd commit messages.
I'll wait for a new version from you before reviewing more.
--
Heikki Linnakangas
Neon (https://neon.tech)
From 622620a7875ae8c1626e9cd118156e0c734d44ed Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Sun, 17 Mar 2024 22:52:28 +0200
Subject: [PATCH v3heik
On 15/03/2024 16:00, Tom Lane wrote:
Heikki Linnakangas writes:
On 15/03/2024 13:09, Heikki Linnakangas wrote:
I committed a patch to do that, to put out the fire.
That's turning the buildfarm quite red. Many, but not all animals are
failing like this:
It may be even worse than
On 15/03/2024 14:10, Heikki Linnakangas wrote:
On 15/03/2024 13:09, Heikki Linnakangas wrote:
I committed a patch to do that, to put out the fire.
That's turning the buildfarm quite red. Many, but not all animals are
failing like this:
---
/home/buildfarm/hippopotamus/buildroot/HEAD
On 15/03/2024 13:09, Heikki Linnakangas wrote:
On 15/03/2024 01:13, Tom Lane wrote:
Michael Paquier writes:
Or we could just disable runningcheck because of the concurrency
requirement in this test. The test would still be able to run, just
less times.
No, actually we *must* mark all
with the current definition of injection points. The point
of installcheck mode is that the tests are supposed to be safe to
run in a live installation. Side-effects occurring in other
databases are completely not OK.
I committed a patch to do that, to put out the fire.
--
Heikki Linnakangas
Neon (https
e installchecks.
Oops.
It would be nice to automatically detach all the injection points on
process exit. You wouldn't always want that, but I think most tests hold
a session open throughout the test, and for those it would be handy.
--
Heikki Linnakangas
Neon (https://neon.tech)
hat makes no sense. That injection point is
only used by the test in src/test/modules/gin/. Perhaps that ran at the
same time as the intarray test? But they run in separate instances, with
different data directories. And the 'gin' test passed.
I'm completely stumped. Anyone have a theory?
--
Heikki Linna
1 - 100 of 1061 matches
Mail list logo