On Fri, Apr 26, 2024 at 4:54 AM Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Melanie
> Plageman and Richard Guo, who have accepted invitations to become our
> newest PostgreSQL committers.
Congratulations!!
--Jacob
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` is security.
>
> Agreed, although the the
On Thu, Apr 25, 2024 at 10:35 AM Robert Haas wrote:
> Maybe I'm missing something here, but why doesn't sslnegotiation
> override sslmode completely? Or alternatively, why not remove
> sslnegotiation entirely and just have more sslmode values? I mean
> maybe this shouldn't happen categorically,
On Thu, Apr 25, 2024 at 9:17 AM Robert Haas wrote:
>
> It is difficult to imagine a world in which we have both requiredirect
> and forcedirect and people are not confused.
Yeah... Any thoughts on a better scheme? require_auth was meant to
lock down overly general authentication; maybe a
On Tue, Apr 23, 2024 at 2:20 PM Heikki Linnakangas wrote:
>
> Attached patch tries to fix and clarify those.
s/negotiatied/negotiated/ in the attached patch, but other than that
this seems like a definite improvement. Thanks!
> (Note that the client will only attempt GSSAPI encryption if it can
On Wed, Apr 24, 2024 at 1:57 PM Peter Eisentraut wrote:
> I'm concerned that there appears to be some confusion over whether ALPN
> is a performance feature or a security feature. RFC 7301 appears to be
> pretty clear that it's for performance, not for security.
It was also designed to give
On Tue, Apr 23, 2024 at 8:13 PM Tatsuo Ishii wrote:
> SELECT v.a, count(*) OVER w
> FROM (VALUES ('A'),('B'),('B'),('C')) AS v (a)
> WINDOW w AS (
> ORDER BY v.a
> ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
> PATTERN (B+)
> DEFINE B AS a = 'B'
> )
> a | count
> ---+---
> A |
On Tue, Apr 23, 2024 at 10:43 AM Robert Haas wrote:
> I've not followed this thread closely enough to understand the comment
> about requiredirect maybe not actually requiring direct, but if that
> were true it seems like it might be concerning.
It may be my misunderstanding. This seems to imply
On Mon, Apr 22, 2024 at 2:20 PM Jelte Fennema-Nio wrote:
> 1. I strongly believe minor protocol version bumps after the initial
> 3.1 one can be made painless for clients/poolers (so the ones to
> 3.2/3.3/etc). Similar to how TLS 1.3 can be safely introduced, and not
> having to worry about
On Mon, Apr 22, 2024 at 10:42 PM Michael Paquier wrote:
>
> On Mon, Apr 22, 2024 at 10:47:51AM +0300, Heikki Linnakangas wrote:
> > On 22/04/2024 10:19, Michael Paquier wrote:
> >> As a whole, I can get behind a unique GUC that forces the use of
> >> direct. Or, we could extend the existing
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 h
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
> On 19/04/2024 08:06, Michael Paquier wrote:
> > Since 91044ae4baea (require ALPN for direct SSL connections) and
> > d39a49c1e459 (direct hanshake), direct SSL connections are supported
> > (yeah!), still the thread where this has been
On Wed, Apr 10, 2024 at 12:31 AM Peter Eisentraut wrote:
> * src/backend/libpq/be-secure-openssl.c
>
> +#include
>
> This patch doesn't appear to add anything, so why does it need a new
> include?
This one was mine -- it was an indirect header dependency that was
effectively removed in 1.1.0
On Mon, Apr 8, 2024 at 10:24 PM Michael Paquier wrote:
> At the end, having a way to generate JSON blobs randomly to test this
> stuff would be more appealing
For the record, I'm working on an LLVM fuzzer target for the JSON
parser. I think that would be a lot more useful than anything we can
On Tue, Apr 9, 2024 at 7:30 AM Andrew Dunstan wrote:
> I think Michael's point was that if we carry the code we should test we
> can run it. The other possibility would be just to remove it. I can see
> arguments for both.
Hm. If it's not acceptable to carry this (as a worse-is-better smoke
On Tue, Apr 9, 2024 at 4:54 AM Andrew Dunstan wrote:
> On 2024-04-09 Tu 01:23, Michael Paquier wrote:
> There is no direct check on test_json_parser_perf.c, either, only a
> custom rule in the Makefile without specifying something for meson.
> So it looks like you could do short execution check
On Fri, Apr 5, 2024 at 5:14 PM Michael Paquier wrote:
> Saying that, my spidey sense tingles at the recent commit
> 3311ea86edc7, that had the idea to introduce a 20k line output file
> based on a 378 line input file full of random URLs. In my experience,
> tests don't require to be that large
On Fri, Apr 5, 2024 at 3:32 PM Daniel Gustafsson wrote:
> > An autoreconf run on my machine pulls in more changes (getting rid of
> > the symbols we no longer check for).
>
> Ah yes, missed updating before formatting the patch. Done in the attached.
The commit subject may still need to be
On Fri, Apr 5, 2024 at 2:48 PM Daniel Gustafsson wrote:
> But does that actually work? If I change the API_COMPAT to the 1.1.1 version
> number and run configure against 1.0.2 it passes just fine. Am I missing some
> clever trick here?
Similarly, I changed my API_COMPAT to a nonsense
On Fri, Apr 5, 2024 at 9:59 AM Daniel Gustafsson wrote:
> Attached is a WIP patch to get more eyes on it, the Meson test for 1.1.1 fails
> on Windows in CI which I will investigate next.
The changes for SSL_OP_NO_CLIENT_RENEGOTIATION and
SSL_R_VERSION_TOO_LOW look good to me.
> -Remove
On Fri, Apr 5, 2024 at 6:24 AM Robert Haas wrote:
> I wonder how hard it would be to just code up our own binary to do
> this. If it'd be a pain to do that, or to maintain it across SSL
> versions, then it's a bad plan and we shouldn't do it. But if it's not
> that much code, maybe it'd be worth
On Thu, Apr 4, 2024 at 6:37 PM Michael Paquier wrote:
> From where did you pull the LibreSSL sources? Directly from the
> OpenBSD tree?
I've been building LibreSSL Portable: https://github.com/libressl/portable
> Ah, right. OpenSSL_add_all_algorithms() is documented as having no
> effect in
On Thu, Apr 4, 2024 at 1:42 PM Jelte Fennema-Nio wrote:
> Maybe that's something worth addressing too. I expected that
> install/install-quiet was a strict superset of a plain ninja
> invocation.
Maybe that's the intent, but I hope not, because I don't see any
reason for `ninja install` to worry
On Thu, Apr 4, 2024 at 11:06 AM Nathan Bossart wrote:
> ../postgresql/src/common/jsonapi.c: In function ‘IsValidJsonNumber’:
> ../postgresql/src/common/jsonapi.c:2016:30: error: ‘dummy_lex.inc_state’ may
> be used uninitialized in this function [-Werror=maybe-uninitialized]
> 2016 | if
On Thu, Apr 4, 2024 at 11:12 AM Jacob Champion
wrote:
> What's in the `...`? I wouldn't expect to find the test binary in your
> tmp_install.
Oh, I wonder if this is just a build dependency thing? I typically run
a bare `ninja` right before testing, because I think most of those
depend
On Thu, Apr 4, 2024 at 10:17 AM Jelte Fennema-Nio wrote:
> Command 'test_json_parser_incremental' not found in
> /home/jelte/opensource/postgres/build/tmp_install//home/jelte/.pgenv/pgsql-17beta9/bin,
> ...
I can't reproduce this locally...
What's in the `...`? I wouldn't expect to find the
On Wed, Apr 3, 2024 at 3:27 PM Daniel Gustafsson wrote:
> The patch will also need to be adjusted to work with LibreSSL, but I know
> Jacob
> was looking into that so ideally we should have something to review before
> the weekend.
v3 does that by putting back checks for symbols that aren't
On Wed, Apr 3, 2024 at 11:13 AM Tom Lane wrote:
> wikipedia says that RHEL7 ends ELS as of June 2026 [1].
I may have misunderstood something in here then:
https://www.redhat.com/en/blog/announcing-4-years-extended-life-cycle-support-els-red-hat-enterprise-linux-7
> ELS for RHEL 7 is now
On Wed, Apr 3, 2024 at 10:38 AM Tom Lane wrote:
> Also, calling Photon 3
> dead because it went EOL three days ago seems over-hasty.
Well, March 1, but either way I thought "dead" for the purposes of
this thread meant "you can't build the very latest version of Postgres
on it", not "we've
On Wed, Apr 3, 2024 at 8:29 AM Tom Lane wrote:
> I count 3 machines running 1.0.1, 18 running some flavor
> of 1.0.2, and 7 running various LibreSSL versions.
I don't know all the tradeoffs with buildfarm wrangling, but IMO all
those 1.0.2 installations are the most problematic, so I dug in a
On Tue, Apr 2, 2024 at 11:55 AM Daniel Gustafsson wrote:
> The attached removes 1.0.2 support (meson build parts untested yet) with a few
> small touch ups of related documentation. I haven't yet done the research on
> where that leaves LibreSSL since we don't really define anywhere what we
>
On Mon, Apr 1, 2024 at 4:53 PM Andrew Dunstan wrote:
> Anyway, here are new patches. I've rolled the new semantic test into the
> first patch.
Looks good! I've marked RfC.
> json_lex() is not really a very hot piece of code.
Sure, but I figure if someone is trying to get the performance of the
On Thu, Mar 28, 2024 at 3:34 PM Daniel Gustafsson wrote:
> In jsonapi.c, makeJsonLexContextCstringLen initialize a JsonLexContext with
> palloc0 which would need to be ported over to use ALLOC for frontend code.
Seems reasonable (but see below, too).
> On
> that note, the errorhandling in
On Fri, Mar 29, 2024 at 9:42 AM Andrew Dunstan wrote:
> Here's a new set of patches, with I think everything except the error case
> Asserts attended to. There's a change to add semantic processing to the test
> suite in patch 4, but I'd fold that into patch 1 when committing.
Thanks! 0004 did
On Mon, Mar 25, 2024 at 3:14 PM Jacob Champion
wrote:
> - add Assert calls in impossible error cases [2]
To expand on this one, I think these parts of the code (marked with
`<- here`) are impossible to reach:
> switch (top)
> {
> case JSON_TOKEN_STRING:
> if (next
On Mon, Mar 25, 2024 at 4:24 PM Andrew Dunstan wrote:
> OK, so we invent a new error code and have the parser return that if the
> stack depth gets too big?
Yeah, that seems reasonable. I'd potentially be able to build on that
via OAuth for next cycle, too, since that client needs to limit its
On Mon, Mar 25, 2024 at 4:12 PM Jacob Champion
wrote:
> Stack size should be pretty limited, at least on the platforms I'm
> familiar with. So yeah, the recursive descent will segfault pretty
> quickly, but it won't repalloc() an unbounded amount of heap space.
> The alternativ
On Mon, Mar 25, 2024 at 4:02 PM Andrew Dunstan wrote:
> Well, what's the alternative? The current parser doesn't check stack depth in
> frontend code. Presumably it too will eventually just run out of memory,
> possibly rather sooner as the stack frames could be more expensive than the
>
On Wed, Mar 20, 2024 at 11:56 PM Andrew Dunstan wrote:
> Thanks, included that and attended to the other issues we discussed. I think
> this is pretty close now.
Okay, looking over the thread, there are the following open items:
- extend the incremental test in order to exercise the semantic
On Tue, Mar 5, 2024 at 4:12 PM David Zhang wrote:
> Any comments or feedback would be greatly appreciated!
Hi David -- I haven't had time to get to this for the 17 release
cycle, but I'm interested in this feature and I intend to review it at
some point for 18. I think OCSP will be especially
On Fri, Mar 22, 2024 at 6:15 AM Daniel Gustafsson wrote:
> While staging this to commit I realized one silly thing about it warranting
> another round here. The ASN.1 timediff code can diff against *any* timestamp,
> not just the UNIX epoch, so we could just pass in the postgres epoch and skip
>
On Wed, Mar 20, 2024 at 2:15 PM Jacob Champion
wrote:
> I think solutions for case 1 and case 2 are necessarily at odds under
> the current design, if auth_delay relies on slot exhaustion to do its
> work effectively. Weakening that on purpose doesn't make much sense to
>
This new return path...
> + if (!tok_done)
> + {
> + if (lex->inc_state->is_last_chunk)
> + return JSON_INVALID_TOKEN;
...also needs to set the token pointers. See one approach in the
attached diff, which additionally asserts that we've consumed the
entire
On Tue, Mar 19, 2024 at 3:07 PM Andrew Dunstan wrote:
> On Mon, Mar 18, 2024 at 3:35 PM Jacob Champion
> wrote:
>> With the incremental parser, I think prev_token_terminator is not
>> likely to be safe to use except in very specific circumstances, since
>> it could
On Wed, Mar 20, 2024 at 7:50 AM Daniel Gustafsson wrote:
> We are subtracting 30 years from a calculation that we know didnt overflow, so
> I guess if the certificate notBefore (the notAfter cannot be that early since
> we wouldn't be able to connect with it) was set to early enough? It didn't
>
On Wed, Mar 20, 2024 at 7:03 AM Daniel Gustafsson wrote:
> The issue here is that postgres use a different epoch from the unix epoch, so
> any dates calcuated based on the unix epoch need to be adjusted.
Ah, thank you! I had just reproduced Cary's problem and was really confused...
> I've
On Mon, Mar 18, 2024 at 1:48 PM Cary Huang wrote:
> Attached is the v10 patch with the above changes. Thanks again for the review.
Awesome, looks good.
On my final review pass I saw one last thing that bothered me (sorry
for not seeing it before). The backend version of
ASN1_TIME_to_timestamptz
ex->token_terminator = dummy_lex.token_terminator;
if (partial_result == JSON_SUCCESS)
lex->inc_state->partial_completed = true;
return partial_result;
commit 3d615593d6d79178a8b8a208172414806d40cc03
Author: Jacob Champion
Date: Mon Mar 11
On Fri, Mar 8, 2024 at 4:16 PM Cary Huang wrote:
> Yes, I noticed this in the SSL test too. I am also in GTM-8, so for me the
> tests would fail too due to the time zone differences from GMT. It shall be
> okay to specifically set the outputs of pg_stat_ssl,
> ssl_client_get_notbefore, and
On Sun, Mar 17, 2024 at 4:49 PM Daniel Gustafsson wrote:
> I took another look at this tonight and committed it with some mostly cosmetic
> changes.
Great! Thanks everyone.
--Jacob
I've been poking at the partial token logic. The json_errdetail() bug
mentioned upthread (e.g. for an invalid input `[12zz]` and small chunk
size) seems to be due to the disconnection between the "main" lex
instance and the dummy_lex that's created from it. The dummy_lex
contains all the
On Wed, Mar 13, 2024 at 12:01 PM Alvaro Herrera wrote:
> On 2024-Mar-13, Jelte Fennema-Nio wrote:
> > Sadly I'm having a hard time reliably reproducing this race condition
> > locally. So it's hard to be sure what is happening here. Attached is a
> > patch with a wild guess as to what the issue
On Tue, Mar 12, 2024 at 11:38 PM Michael Paquier wrote:
> On Tue, Mar 12, 2024 at 08:38:43PM -0400, Andrew Dunstan wrote:
> > yeah, although maybe worth a different patch.
>
> I've wanted that a few times, FWIW. I would do a split, mainly for
> clarity.
Sounds good, split into v2-0002. (That
Hello,
Both the incremental JSON [1] and OAuth [2] patchsets would be
improved by json_errdetail(), which was removed from FRONTEND builds
in b44669b2ca:
>The routine providing a detailed error message based on the error code
>is made backend-only, the existing code being unsafe to use
On Sun, Mar 10, 2024 at 11:43 PM Andrew Dunstan wrote:
> I haven't managed to reproduce this. But I'm including some tests for it.
If I remove the newline from the end of the new tests:
> @@ -25,7 +25,7 @@ for (my $size = 64; $size > 0; $size--)
> foreach my $test_string (@inlinetests)
> {
>
Some more observations as I make my way through the patch:
In src/common/jsonapi.c,
> +#define JSON_NUM_NONTERMINALS 6
Should this be 5 now?
> + res = pg_parse_json_incremental(&(incstate->lex), &(incstate->sem),
> +
On Wed, Mar 6, 2024 at 2:45 PM Michael Banck wrote:
> In order to at least make case 2 not worse for exponential backoff, we
> could maybe disable it (and just wait for auth_delay.milliseconds) once
> MAX_CONN_RECORDS is full. In addition, maybe MAX_CONN_RECORDS should be
> some fraction of
On Wed, Mar 6, 2024 at 12:34 PM Tomas Vondra
wrote:
> Doesn't this mean this approach (as implemented) doesn't actually work
> as a protection against this sort of DoS?
>
> If I'm an attacker, and I can just keep opening new connections for each
> auth request, am I even subject to any auth
On Wed, Mar 6, 2024 at 8:10 AM Nathan Bossart wrote:
> Assuming you are referring to the case where we run out of free slots in
> acr_array, I'm not sure I see that as desirable behavior. Once you run out
> of slots, all failed authentication attempts are now subject to the maximum
> delay,
On Tue, Mar 5, 2024 at 1:51 PM Nathan Bossart wrote:
> I don't have a strong opinion about making this configurable, but I do
> think we should consider making this a hash table so that we can set
> MAX_CONN_RECORDS much higher.
I'm curious why? It seems like the higher you make
I keep forgetting -- attached is the diff I'm carrying to plug
libpq_encryption into Meson. (The current patchset has a meson.build
for it, but it's not connected.)
--Jacob
commit 64215f1e6b68208378b34cc0736d2f0eb1d45919
Author: Jacob Champion
Date: Wed Feb 28 11:28:17 2024 -0800
WIP
On Mon, Mar 4, 2024 at 6:23 AM Daniel Gustafsson wrote:
> > On 12 Sep 2023, at 21:40, Jacob Champion wrote:
Sorry for the long delay!
> >> + ssl_client_get_notbefore() returns text
> >> ...> + ssl_client_get_notafter() returns text
> >
> > I t
ntally disabled direct SSL connection completely and always used
> negotiated mode, the tests would still pass. I'd like to see some tests
> that would catch that.
+1
On Mon, Mar 4, 2024 at 7:29 AM Heikki Linnakangas wrote:
> On 01/03/2024 23:49, Jacob Champion wrote:
> > I'll s
On Wed, Feb 28, 2024 at 4:10 AM Heikki Linnakangas wrote:
> I think we'd want to *avoid* changing the major protocol version in a
> way that would introduce a new roundtrip, though.
I'm starting to get up to speed with this patchset. So far I'm mostly
testing how it works; I have yet to take an
On Thu, Feb 29, 2024 at 1:08 PM Daniel Gustafsson wrote:
> + /* TODO */
> + CHECK_SETOPT(actx, CURLOPT_WRITEDATA, stderr);
> I might be missing something, but what this is intended for in
> setup_curl_handles()?
Ah, that's cruft left over from early debugging, just so that I could
see what
On Wed, Feb 28, 2024 at 9:40 AM Daniel Gustafsson wrote:
> +#define ALLOC(size) malloc(size)
> I wonder if we should use pg_malloc_extended(size, MCXT_ALLOC_NO_OOM) instead
> to self document the code. We clearly don't want feature-parity with server-
> side palloc here. I know we use malloc in
On Wed, Feb 28, 2024 at 2:54 PM Daniel Gustafsson wrote:
> I rank that as one of my better typos actually. Fixed though.
LGTM!
Thanks,
--Jacob
[re-adding the CC list I dropped earlier]
On Wed, Feb 28, 2024 at 1:52 PM Daniel Gustafsson wrote:
>
> > On 28 Feb 2024, at 22:50, Andrew Dunstan wrote:
> > Can you give some more details about what this python gadget would buy us?
> > I note that there are a couple of CPAN modules that
On Tue, Feb 27, 2024 at 11:20 AM Jacob Champion
wrote:
> This is done in v17, which is also now based on the two patches pulled
> out by Daniel in [1].
It looks like my patchset has been eaten by a malware scanner:
550 Message content failed content sc
On Mon, Feb 26, 2024 at 9:20 PM Andrew Dunstan wrote:
> The good news is that the parser is doing fine - this issue was due to a
> thinko on my part in the test program that got triggered by the input
> file size being an exact multiple of the chunk size. I'll have a new
> patch set later this
On Fri, Feb 23, 2024 at 2:30 AM Daniel Gustafsson wrote:
>
> The attached two patches are smaller refactorings to the SASL exchange and
> init
> codepaths which are required for the OAuthbearer work [0]. Regardless of the
> future of that patchset, these refactorings are nice cleanups and can
On Mon, Feb 26, 2024 at 7:08 AM Jacob Champion
wrote:
> As a brute force example of the latter, with the attached diff I get
> test failures at chunk sizes 1, 2, 3, 4, 6, and 12.
But this time with the diff.
--Jacob
diff --git
a/src/test/modules/test_json_pa
On Thu, Feb 22, 2024 at 3:43 PM Andrew Dunstan wrote:
> > Are there plans to fill out the test suite more? Since we should be
> > able to control all the initial conditions, it'd be good to get fairly
> > comprehensive coverage of the new code.
>
> Well, it's tested (as we know) by the backup
rings", not "all strings are now NULL".
--Jacob
commit 590ea7bec167058340624313d98c72976fa89d7a
Author: Jacob Champion
Date: Wed Feb 21 06:36:55 2024 -0800
WIP: mesonify
diff --git a/src/test/modules/meson.build b/src/test/modules/meson.build
index 8fbe742d38..e5c9bd10cf 10
On Wed, Feb 21, 2024 at 6:50 AM Jacob Champion
wrote:
> On Tue, Feb 20, 2024 at 9:32 PM Andrew Dunstan wrote:
> > *sigh* That's weird. I wonder why you can reproduce it and I can't. Can
> > you give me details of the build? OS, compiler, path to source, build
> > setup etc.
4
- build path is nested a bit (~/src/postgres/worktree-inc-json/build-dev)
--Jacob
commit 0075a88beec160cbb408d9a1e0a11d836fb55bdf
Author: Jacob Champion
Date: Wed Feb 21 06:36:55 2024 -0800
WIP: mesonify
diff --git a/src/test/modules/meson.build b/src/test/modules/meson.build
index 8
Hi all,
v14 rebases over latest and fixes a warning when assertions are
disabled. 0006 is temporary and hacks past a couple of issues I have
not yet root caused -- one of which makes me wonder if 0001 needs to
be considered alongside the recent pg_combinebackup and incremental
JSON work...?
On Tue, Feb 20, 2024 at 2:10 PM Andrew Dunstan wrote:
> Well, that didn't help a lot, but meanwhile the CFBot seems to have
> decided in the last few days that it's now happy, so full steam aead! ;-)
I haven't been able to track down the root cause yet, but I am able to
reproduce the failure
On Sun, Feb 4, 2024 at 6:51 AM vignesh C wrote:
> We should do something about these kinds of entries, there were few
> suggestions like tagging under a new category or so, can we add a new
> status to park these entries something like "Waiting for direction".
> The threads which have no
On Tue, Dec 5, 2023 at 1:44 AM Daniel Gustafsson wrote:
>
> > On 8 Nov 2023, at 20:00, Jacob Champion wrote:
>
> > Unfortunately the configure/Makefile build of libpq now seems to be
> > pulling in an `exit()` dependency in a way that Meson does not.
>
> I belie
lients have to
parse JSON as well. Those responses tend to be smaller, though, so
you'd have to really be hurting for resources to need this.
--Jacob
commit 79d0dc78b9f3b0bbc078876417b8f46970308e6e
Author: Jacob Champion
Date: Thu Jan 4 11:46:06 2024 -0800
WIP: try to speed up prediction
d
On Thu, Nov 9, 2023 at 5:43 PM Andrey Chudnovsky wrote:
> Do you plan to support adding an extension hook to validate the token?
>
> It would allow a more efficient integration, then spinning a separate process.
I think an API in the style of archive modules might probably be a
good way to go,
> commit a70f2a57f233244c0a780829baf48c624187d456
> Author: Tom Lane
> Date: Mon Nov 13 17:04:10 2023 -0500
>
>Don't try to dump RLS policies or security labels for extension objects.
(Thanks Tom!)
--Jacob
On Thu, Nov 9, 2023 at 11:02 AM Tom Lane wrote:
> I'm hearing nothing but crickets :-(
Yeah :/
Based on your arguments above, it sounds like your patch may improve
several other corner cases when backported, so that sounds good
overall to me. My best guess is that Timescale will be happy with
On Fri, Nov 3, 2023 at 5:28 AM Shlok Kyal wrote:
> Just want to make sure you are aware of these failures.
Thanks for the nudge! Looks like I need to reconcile with the changes
to JsonLexContext in 1c99cde2. I should be able to get to that next
week; in the meantime I'll mark it Waiting on
On Tue, Oct 24, 2023 at 7:49 PM Tatsuo Ishii wrote:
> I am impressed the simple NFA implementation.
Thanks!
> It would be nicer if it
> could be implemented without using recursion.
Yeah. If for some reason we end up going with a bespoke
implementation, I assume we'd just convert the algorithm
atchet up the complexity.
Thanks!
--Jacob
From fb3cbb6f99f0fe7b05027759454d7e0013225929 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Fri, 20 Oct 2023 16:11:14 -0700
Subject: [PATCH 2/2] squash! Row pattern recognition patch (executor).
- Extract pattern matching logic into match_p
On Wed, Oct 18, 2023 at 1:25 PM Tom Lane wrote:
> Stephen Frost writes:
> > This change would mean that policies added by a user after the extension
> > is created would just be lost by a pg_dump/reload, doesn't it?
>
> Yes. But I'd say that's unsupported, just like making other ad-hoc
>
On Fri, Sep 22, 2023, 3:13 AM Tatsuo Ishii wrote:
> > Op 9/22/23 om 07:16 schreef Tatsuo Ishii:
> >>> Attached is the fix against v6 patch. I will include this in upcoming
> >>> v7 patch.
> >> Attached is the v7 patch. It includes the fix mentioned above. Also
> > (Champion's address bounced;
On Mon, Sep 11, 2023 at 11:18 PM Tatsuo Ishii wrote:
> What I am not sure about is, you and Vik mentioned that the
> traditional NFA is superior that POSIX NFA in terms of performance.
> But how "lexicographic ordering" is related to performance?
I think they're only tangentially related. POSIX
Hello,
On 7/25/23 07:21, Daniel Gustafsson wrote:
> The attached version passes ssl tests for me on 1.0.2 through OpenSSL Git
> HEAD.
Tests pass for me too, including LibreSSL 3.8.
> + /* Calculate the diff from the epoch to the certificat timestamp */
"certificate"
> +
On Sat, Sep 9, 2023 at 4:21 AM Tatsuo Ishii wrote:
> Then we will get for str_set:
> r0: B
> r1: AB
>
> Because r0 only has classifier B, r1 can have A and B. Problem is,
> r2. If we choose A at r1, then r2 = B. But if we choose B at t1, then
> r2 = AB. I guess this is the issue you pointed out.
On 9/7/23 20:54, Tatsuo Ishii wrote:
>> DEFINE
>> A AS PREV(CLASSIFIER()) IS DISTINCT FROM 'A',
>> ...
>
> But:
>
> UP AS price > PREV(price)
>
> also depends on previous row, no?
PREV(CLASSIFIER()) depends not on the value of the previous row but the
state of the match so far.
Hello!
> (1) I completely changed the pattern matching engine so that it
> performs backtracking. Now the engine evaluates all pattern elements
> defined in PATTER against each row, saving matched pattern variables
> in a string per row. For example if the pattern element A and B
> evaluated to
v11 is a quick rebase over the recent Cirrus changes, and I've dropped
0006 now that psycopg2 can build against BSD/Meson setups (thanks Daniele!).
--Jacob1: 0278c7ba90 = 1: 36409a76ce common/jsonapi: support FRONTEND clients
2: bb3ce4b6a9 = 2: 1356b729db libpq: add OAUTHBEARER SASL mechanism
On 7/19/23 16:44, Jacob Champion wrote:
> This patch pushes down any
> forced-null and not-null Vars as ScanKeys. It doesn't remove the
> redundant quals after turning them into ScanKeys, so it's needlessly
> inefficient, but there's still a decent speedup for some of the basic
On Thu, Aug 24, 2023 at 6:25 PM Michael Paquier wrote:
> LD_PRELOAD is the only thing I can think about, but that's very fancy.
> Even with that, having a certificate with a NULL peer_cn could prove
> to be useful in the SSL suite to stress more patterns around it?
+1. Last we tried it, OpenSSL
On Wed, Aug 23, 2023 at 6:23 AM Daniel Gustafsson wrote:
> This has the smell of a theoretical problem, I can't really imagine a
> certificate where which would produce this. Have you been able to trigger it?
>
> Wouldn't a better fix be to error out on len == -1 as in the attached, maybe
> with
On Tue, Aug 22, 2023 at 1:07 AM Peter Eisentraut wrote:
> I have attached two patches, one to update the generation rules, and one
> where I have converted the existing test files. (I didn't generate them
> from scratch, so for example
> src/test/modules/ssl_passphrase_callback/server.crt that
On Mon, Aug 21, 2023 at 10:39 PM Michael Paquier wrote:
> 0002 and 0003 make this stuff fail, but isn't there a risk that this
> breaks applications that relied on these accidental behaviors?
> Assuming that this is OK makes me nervous.
I wouldn't argue for backpatching, for sure, but I guess I
1 - 100 of 797 matches
Mail list logo
