_Notify() if we already have the
LockSharedObject(DatabaseRelationId, InvalidOid, 0, AccessExclusiveLock);
See the attached patch that is based on your the previous comment of
resetting the QUEUE_HEAD at AtAbort_Notify()
--
Matheus Alcantara
From f31e096ed8eef6b6988d145ecaa0f513ec9f1042 Mon Sep 17 00:00:00 20
attached patch with the example tap test. Not
> sure if using injections points is more preferable?
>
Great, I think that if we can have a way to reproduce this without an
injection point would be better. I dind't look the test yet but I'll try
to incorporate this on the next patch version. Thanks!
--
Matheus Alcantara
432
15 postgres0x0001052c5a38 PostmasterMain + 7096
16 postgres0x000105166488 main + 952
17 dyld0x00019145ab98 start + 6076
There is also some other tests failing, like isolation, regress and
others.
[1] https://www.postgresql.org/message-id/DCLSWKOKDAX4.3HS2NBE53P0M2%40gmail.com
--
Matheus Alcantara
tener backends.
[1]
https://www.postgresql.org/message-id/CAE7r3M%2BXwf0A_aNhu7pYQd7nDQaqaEnyCjtvqg8XsgManmPOUA%40mail.gmail.com
--
Matheus Alcantara
v1-0001-Make-AsyncQueueEntry-s-self-contained.patch
Description: Binary data
On Mon, Sep 8, 2025 at 12:23 PM David G. Johnston
wrote:
> Also seems like the extension location should be part of the output too.
>
I've posted a patch for this at [1]
[1] https://www.postgresql.org/message-id/DCTSKQAVOXIG.3A05JM1YORARK%40gmail.com
--
Matheus Alcantara
Any opinions on this?
[1]
https://www.postgresql.org/message-id/CAKFQuwbR1Fzr8yRuMW%3DN1UMA1cTpFcqZe9bW_-ZF8%3DBa2Ud2%3Dw%40mail.gmail.com
--
Matheus Alcantara
From 7a1c93f344c61c21f56692fe8eff77e5092929c0 Mon Sep 17 00:00:00 2001
From: Matheus Alcantara
Date: Mon, 15 Sep 2025 15:46:24 -0300
Su
On Tue Sep 9, 2025 at 7:49 PM -03, Rishu Bagga wrote:
> On Tue, Sep 9, 2025 at 3:34 PM Matheus Alcantara
> wrote:
>>
>> On Mon Sep 8, 2025 at 9:08 PM -03, Rishu Bagga wrote:
>> > Hi Joel, Arseniy, Matheus, thanks for taking a look. I’ve attached an
>> > upd
'm
getting a compile error:
src/backend/access/rmgrdesc/meson.build:4:20: ERROR: File asyncdesc.c does not
exist.
--
Matheus Alcantara
On Tue Sep 9, 2025 at 4:53 AM -03, Pierrick wrote:
>
> On 08/09/2025 17:35, Tom Lane wrote:
>> "David G. Johnston" writes:
>>> On Monday, September 8, 2025, Matheus Alcantara
>>> wrote:
>>>> On this step it will search the .control
>>
is that at the first
step of CREATE EXTENSION command it will try to find the primary
.control file of the extension. On this step it will search the .control
file on paths at extension_control_path in order and it will use the
first one that it finds and based on the .control file found it will
install the extension using the version specified on the command.
--
Matheus Alcantara
think?
[1]
https://www.postgresql.org/message-id/CAK98qZ3wZLE-RZJN_Y%2BTFjiTRPPFPBwNBpBi5K5CU8hUHkzDpw%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAFY6G8cJm73_MM9SuynZUqtqcaTuepUDgDuvS661oLW7U0dgsg%40mail.gmail.com
--
Matheus Alcantara
From c93fb480c7676b02bac5813a69d7df3d717fd9a
MVCCSnapshot() call, sorry about that
and thanks very much for all the explanation!
I'll keep on hold the development of new patch versions for this thread
and focus on review and test the patch from Rishu at [1] to see if we
can make progress using the WAL approach.
[1]
https://www.postgresql.org/message-id/CAK80%3DjipUfGC%2BUQSzeA4oCP9daRtHZGm2SQZWLxC9NWmVTDtRQ%40mail.gmail.com
--
Matheus Alcantara
ks for sharing the patch! I'll reserve some time to test and review.
--
Matheus Alcantara
On Wed Sep 3, 2025 at 8:51 PM -03, Rishu Bagga wrote:
> On Wed, Sep 3, 2025 at 2:14 PM Matheus Alcantara
>
> wrote:
>
>
>> IIUC we don't store notifications of aborted transactions on the
>
>> queue. On PreCommit_Notify we add the notifications on the queue
&g
Thanks for the comments!
On Tue Sep 2, 2025 at 4:37 AM -03, Yura Sokolov wrote:
> 29.08.2025 01:31, Matheus Alcantara пишет:
>> On Thu Aug 21, 2025 at 8:14 PM -03, Matheus Alcantara wrote:
>>> I'll work on this considering the initial Daniil comments at [1]
Vacuum don't need to be listen/notify aware.
> 4) We don't need to do an extra scan of the whole queue.
>
> What do you think?
>
IIUC we don't store notifications of aborted transactions on the queue.
On PreCommit_Notify we add the notifications on the queue and on
Commit_Notify() we signal the backends.
Or I'm missing something here?
--
Matheus Alcantara
roblem.
[1]
https://www.postgresql.org/message-id/CAK98qZ3wZLE-RZJN_Y%2BTFjiTRPPFPBwNBpBi5K5CU8hUHkzDpw%40mail.gmail.com
[2] https://www.postgresql.org/message-id
CAFY6G8cJm73_MM9SuynZUqtqcaTuepUDgDuvS661oLW7U0dgsg%40mail.gmail.com
--
Matheus Alcantara
From 839b2934fe3d73b78965198d86dba3b97e3696e2 Mon Sep
On Thu Aug 21, 2025 at 8:14 PM -03, Matheus Alcantara wrote:
> I'll work on this considering the initial Daniil comments at [1]
>
> [1]
> https://www.postgresql.org/message-id/CAJDiXgg1ArRB1-6wLtXfVVnQ38P9Y%2BCDfEc9M2TXiOf_4kfBMg%40mail.gmail.com
>
I've been working on
>> we have already stripped the $libdir so this will not behave
>> correctly, so if we have any extra slash in path we need to retain the
>> $libdir
>
> Please find the revised patch with improved comments and commit messages.
>
Thanks for the improvements! LGTM.
--
Matheus Alcantara
sue? I
still need to perform some other tests to validate that this fix is
fully correct but the check-world is passing.
Thoughts?
--
Matheus Alcantara
From c635b700b229a94101461e034bf739451c9f3b67 Mon Sep 17 00:00:00 2001
From: Matheus Alcantara
Date: Fri, 22 Aug 2025 10:23:31 -0300
Subject: [PAT
[1]
https://www.postgresql.org/message-id/CAJDiXgg1ArRB1-6wLtXfVVnQ38P9Y%2BCDfEc9M2TXiOf_4kfBMg%40mail.gmail.com
--
Matheus Alcantara
On Tue Aug 19, 2025 at 2:37 PM -03, Daniil Davydov wrote:
> Hi,
>
> On Tue, Aug 19, 2025 at 6:31 PM Matheus Alcantara
> wrote:
>>
>> On Tue Aug 19, 2025 at 12:57 AM -03, Daniil Davydov wrote:
>> > You have started a very long transaction, which holds its xid and p
e XIDs of the notification entries.
>
Thanks for the comments! Please see my reply at [1] that I mention that
I don't think that is too easy to have this specific scenario of a busy
backend loose dropped notifications.
[1] https://www.postgresql.org/message-id/DC7KGTXW3QSG.OZA24HONT78J%40gmail.com
--
Matheus Alcantara
ou have started a very long transaction, which holds its xid and prevents
> vacuum from freezing it. But what if the backend is stuck not inside a
> transaction? Maybe we can just hardcode a huge delay (not inside the
> transaction) or stop process execution via breakpoint in gdb. If we will use
> it
> instead of a long query, I think that this error may be reproducible.
>
But how could this happen in real scenarios? I mean, how the backend
could be stuck outside a transaction?
--
Matheus Alcantara
On Wed Aug 13, 2025 at 4:29 PM -03, Daniil Davydov wrote:
> Hi,
>
> On Mon, Aug 11, 2025 at 8:41 PM Matheus Alcantara
> wrote:
>>
>> On Wed Aug 6, 2025 at 7:44 AM -03, Álvaro Herrera wrote:
>> >> My questions:
>> >>
>> >> 1. Is
Group Key: t2.b
-> Seq Scan on public.eager_agg_t2 t2
Output: t2.a, t2.b, t2.c
Filter: (t2.c > '5'::double precision)
(19 rows)
Is this behavior correct? If it's correct, would be possible to check
this limitation on setup_eager_aggregation() and maybe skip all the
other work?
--
Matheus Alcantara
think about the following?
+
+ If the incoming connection to the FDW instance does not use SCRAM,
+ use_scram_passthrough is ignored and authentication
+ will instead use the password from the user mapping, if one is provided.
+
--
Matheus Alcantara
From d466c99bbe9bd
could have two GUC's; One
to enable and disable the oldest xmin check on async queue and the
second to control how far we want to prevent the vacuum from freezing
the oldest async queue xid, and if the min xid raises this limit we
ignore and truncate the xid.
I've write a draft patch that p
t; Execution Time: 20888.076 ms
> -- with eager aggregation
> Planning Time: 3.747 ms
> Execution Time: 7449.522 ms
>
> Any comments on these two changes?
>
It sounds like a good way to go for me, looking forward to the next
patch version to perform some other tests.
Thanks
--
Matheus Alcantara
y. I've
checked this on set_rel_size() -> set_subquery_pathlist() ->
check_and_push_window_quals().
> Also, this seems busted:
>
> # select row_number() over (order by oid) rn from pg_class qualify rn=1;
> server closed the connection unexpectedly
>
Thanks for testing! I'm working on this and some other issues.
--
Matheus Alcantara
tgres project's
> position on doing things like this are.
>
With this transformation users will see a Subquery plan node even if
it's not present on the original query, is that expected or it can be
confusing to users?
--
Matheus Alcantara
d like some
> sort of consensus before any work gets done.
>
What about SHOW CREATE TABLE? Some other databases support this syntax.
--
Matheus Alcantara
On Tue Jul 22, 2025 at 3:11 PM -03, Marcos Pegoraro wrote:
> Em ter., 22 de jul. de 2025 às 08:56, Matheus Alcantara <
> matheusssil...@gmail.com> escreveu:
>
>> The current patch supports the following syntaxes:
>> SELECT a, b, c
>> wf() OVER () as d
>
k it.
This transformation that you've suggested seems a better approach to
handle the QUALIFY clause to me as well. Unless anyone objects, I'll
prepare the next patch version based on that strategy.
Thanks very much for the comments!
--
Matheus Alcantara
On Mon Jul 21, 2025 at 5:23 PM -03, Vik Fearing wrote:
>
> On 21/07/2025 14:47, Matheus Alcantara wrote:
>> Hi all,
>>
>> I'm sending a proof-of-concept patch to add support for the QUALIFY
>> clause in Postgres. This feature allows filtering rows after window
cing another keyword
that effectively acts like WHERE at a different stage, I believe QUALIFY
improves clarity in many use cases, by avoiding the boilerplate and
visual noise of nested subqueries making it easier to write and reason
about.
--
Matheus Alcantara
nk = 1 AND rnk2 = 2).
Thoughts?
[1] https://docs.snowflake.com/en/sql-reference/constructs/qualify
[2]
https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax#qualify_clause
[3] https://duckdb.org/docs/stable/sql/query_syntax/qualify.html
--
Matheus Alcantara
v0-00
documentation.
>>
>> I've made some tests and I can confirm that is working correctly for
>> what I can see. I think that would be to start include the documentation
>> changes, what do you think?
>>
>
> It sounds tempting :)
> But perhaps first we should agree on the limitation of the
> 'autovacuum_max_parallel_workers' parameter.
>
Agree
> Please, see v6 patches :
> 1) Fixed typos in autovacuum.c and postgresql.conf.sample
> 2) Removed unused macro 'RelationGetParallelAutovacuumWorkers'
>
Thanks!
--
Matheus Alcantara
ptions *)
(relation)->rd_options)->autovacuum.parallel_autovacuum_workers : \
+(defaultpw))
+
---
Also pgindent is needed on some files.
---
I've made some tests and I can confirm that is working correctly for
what I can see. I think that would be to start include the
On Wed Jun 25, 2025 at 3:07 PM -03, Alexander Pyhalov wrote:
> Matheus Alcantara писал(а) 2025-06-25 14:36:
>> Hi, thanks for testing and reporting the issue!
>>
>> On 25/06/25 11:37, Alexander Pyhalov wrote:
>>> Hi.
>>> I've started to look at this fea
don't have the MyProcPort and the
scram keys, will it use the user and password configured on user mapping
properties? If that's also the case I think that we may have a problem
because the goal of this feature is to avoid storing the password on
user mapping.
Do you have steps to reproduce the issue?
--
Matheus Alcantara
hat I've mentioned on v1.
Thanks!
[1]
https://www.postgresql.org/message-id/CAD21AoAcfp5kdcsT5727Vw4JF-Rw7b73zXh_GwXqNHg3P7-UoA%40mail.gmail.com
--
Matheus Alcantara
. This will of course not fix any other PGresult-leakage
> cases that may exist, but I'm content to fix the known problem
> in back branches.
>
> (Patch is labeled .txt so that cfbot doesn't think it's the
> patch-of-record.)
>
Sounds reasonable to me. +1 for going forward with these patches.
--
Matheus Alcantara
of
the previous v4-000X patches and is raising an error:
❯❯❯ git am v5-0001-Avoid-resource-leaks-when-a-dblink-connection-fai.patch
Applying: Avoid resource leaks when a dblink connection fails.
error: patch failed: contrib/dblink/dblink.c:105
error: contrib/dblink/dblink.c: patch does not apply
Patc
I think that we can remove this parameter and move the rconn
allocation to the next if (connname) block. See attached as an example.
--
Matheus Alcantara
delay-rconn-allocation.diff
Description: Binary data
ettext_noop() call?
One other point is that as you've added TAP tests for the autovacuum I
think you also need to create a meson.build file as you already create
the Makefile.
You also need to update the src/test/modules/meson.build and
src/test/modules/Makefile to include the new test/modules/autovacuum
path.
--
Matheus Alcantara
5f966fe --rw--- matheusstaff
m 24248325 0x05f9677e --rw--- matheusstaff
Note that the the 0003 patch don't have this issue so at the end we will
not have problem with this I think, but it maybe be good to mention that
although the patches are separate, there is a dependency between them,
which may cause issues on buildfarm?
--
Matheus Alcantara
n_control_path past beta1.
>
Thanks Peter!
--
Matheus Alcantara
bstitute_path_macro() already handles the if/else on "piece" but I
think that this if/else version looks nicer. Fixed.
I've also included some documentation changes for this v5 version to
remove the "extension" from the examples and also mention the scenario
when using the
minor point:
+Then the postgresql directory will be appended io the
Typo on "io"? Maybe "into" or "in"?
--
Matheus Alcantara
tgresql" and "$system". We split these
paths based on the system path separator and get the next "piece" here:
char *piece = first_path_var_separator(ecp);
The first_path_var_separator() changes the "ecp" parameter on every call,
it returns the next path on "ecp" and changes it to have the remaining
paths to iterate over it.
> Other than that, I think this patch is good to go. Thanks!
>
Thanks for reviewing!
--
Matheus Alcantara
On Fri, Apr 25, 2025 at 4:13 PM David E. Wheeler wrote:
>
> On Apr 25, 2025, at 09:25, Matheus Alcantara wrote:
>
> > Yes, you are right. The problem was where I was asserting
> > control->control_dir != NULL. I've moved the assert after the "if
> > (!f
On Thu, Apr 24, 2025 at 7:27 PM David E. Wheeler wrote:
>
> On Apr 24, 2025, at 11:18, Matheus Alcantara wrote:
>
> > In v2 I've moved the logic to remove the /extension to
> > parse_extension_control_file(), do you think that this Assert on this
> > function woul
On Thu, Apr 24, 2025 at 7:21 AM Christoph Berg wrote:
>
> Re: Matheus Alcantara
> > I've tested with the semver extension and it seems to work fine with
> > this patch. Can you please check on your side to see if it's also
> > working?
>
> Hi Matheus,
>
with the semver extension and it seems to work fine with
this patch. Can you please check on your side to see if it's also
working?
I still want to make some polish on this patch and also include some
more test cases using the "directory" on the .control file but I think
that is stabl
privately IIUC we concluded that we may document
this limitation that using extension control path with an extension that
uses a custom "directory" field on .control file will not work. I think
that we may add a note section on "extension_control_path" doc on [2],
what do you think?
[1]
https://www.postgresql.org/message-id/0F50D989-B82D-4F59-9F13-C08A4673322C%40justatheory.com
[2]
https://www.postgresql.org/docs/devel/runtime-config-client.html#GUC-EXTENSION-CONTROL-PATH
--
Matheus Alcantara
.
--
Matheus Alcantara
hat guarantees
> that that's so, though. It'd fail if contrib hasn't been
> installed. Is there a reason to use "amcheck" rather than
> something more certainly available, like "plpgsql"?
There is no specific reason to use "amcheck" instea
_security_check(conn, rconn, connstr);
>
> - These comment additions probably belong in 0001 rather than 0002.
Fixed
> - As discussed offlist, 0002 needs pgperltidy'd rather than perltidy'd.
Fixed
> - I have attached some additional nitpicky comment edits and
> whitespace
that it would be good to move this part of the documentation to
0004 instead of 0007, what do you think?
--
Matheus Alcantara
On Fri, Mar 21, 2025 at 1:28 PM Jacob Champion
wrote:
>
> Great, thank you! Looking over v10, I think I've run out of feedback
> at this point. Marked Ready for Committer.
Thanks for all the effort reviewing this patch!
--
Matheus Alcantara
On Thu, Mar 27, 2025 at 4:42 PM Melanie Plageman
wrote:
>
> On Thu, Mar 27, 2025 at 2:46 PM Matheus Alcantara
> wrote:
> >
> > Just my 0.2 cents. I also like the first approach even though I prefer
> > the v4 version, but anyway, thanks very much for reviewing and
>
c and I marked the commitfest entry as such.
Just my 0.2 cents. I also like the first approach even though I prefer
the v4 version, but anyway, thanks very much for reviewing and
committing!
(I was sending my anwer just when I received your reply)
--
Matheus Alcantara
On Wed, Mar 26, 2025 at 7:41 AM Peter Eisentraut wrote:
>
> On 24.03.25 21:33, Matheus Alcantara wrote:
> >> I'm a bit confused about the refactoring patch 0001. There are some
> >> details there that don't seem right. For example, you write that the
>
On Mon, Mar 24, 2025 at 1:16 PM Peter Eisentraut wrote:
>
> On 21.03.25 19:24, Matheus Alcantara wrote:
> > On Fri, Mar 21, 2025 at 1:28 PM Jacob Champion
> > wrote:
> >>
> >> Great, thank you! Looking over v10, I think I've run out of feedback
>
hing bites us, and we're looking in the wrong place)
>
> Nope, testing shows it's not that, so I am rather confused about what was
> going on.
>
I'm not sure if I'm checking on the right place [1] but it seems that the
Contrib and ContribInstall is executed after Check step which causes this test
failure?
'steps_completed' => [
'SCM-checkout',
'Configure',
'Build',
'Check',
'Contrib',
'TestModules',
'Install',
'ContribInstall',
'TestModulesInstall',
'MiscCheck',
...
]
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snakefly&dt=2025-03-20%2009%3A46%3A05
--
Matheus Alcantara
d on get_extension_script_directory.
> 2. If the directory is not a full path, check for it under each
> directory in `extension_control_path`? But no, that points to
> `share/extension`, not `share`, so it can’t really searched unless it
> also lops off `extension` from the end of each path.
Maybe we could make the "extension" part of the extension control path
explicitly, like Peter has mentioned in his first patch version [1]?.
If "directory" is not set we could use "extension" otherwise use the
"directory" as a path suffix when searching on extension_control_path?
[1]
https://www.postgresql.org/message-id/0d384836-7e6e-4932-af3b-8dad1f6fee43%40eisentraut.org
--
Matheus Alcantara
On Thu, Mar 20, 2025 at 9:02 PM Jacob Champion
wrote:
>
> On Thu, Mar 20, 2025 at 12:54 PM Matheus Alcantara
> wrote:
> > Since the security checks are defined I'm attaching 0003 which include
> > the fix of security checks for postgres_fdw. It implements the
> >
[11:29:42.995](0.000s) # got: '1'
> > # expected: '0'
> > [11:29:42.995](0.000s) ok 2 - no parameters missing from guc_tables.c
> > [11:29:42.995](0.000s) ok 3 - no parameters marked as NOT_IN_SAMPLE in
> > postgresql.conf.sample
> > found GUC jit_cached in guc_tables.c, missing from
> > postgresql.conf.sample
>
> I tested in with make check and make installcheck . In v8 I found bugs,
> but not published fix yet.
>
Do you have any intent to work on a new version for this?
--
Matheus Alcantara
e more recent test changes.
> But I'm rapidly running out of feedback, so I think this is very
> close.
>
Fixed
Thanks very much for all the reviews on this patch!
--
Matheus Alcantara
v8-0001-dblink-refactor-get-connection-routines.patch
Description: Binary data
v8-0002-dblink-Add-SCRAM-pass-through-authentication.patch
Description: Binary data
On Mon, Mar 17, 2025 at 1:49 PM Jacob Champion
wrote:
>
> On Thu, Mar 13, 2025 at 2:38 PM Matheus Alcantara
> wrote:
> > I thought about this; The problem is that at this point, the scram keys
> > on connection options are base64 encoded (see appendSCRAMKeysInfo), so
>
Hi,
On Sun, Mar 16, 2025 at 10:30 AM vignesh C wrote:
>
> On Wed, 12 Feb 2025 at 00:11, Matheus Alcantara
> wrote:
> >
> > Hi,
> >
> > Em ter., 11 de fev. de 2025 às 03:39, jian he
> > escreveu:
> > > hi. some minor issue i found.
> > &g
On Thu, Mar 13, 2025 at 4:54 PM Jacob Champion
wrote:
>
> On Thu, Mar 13, 2025 at 6:59 AM Matheus Alcantara
> wrote:
> > Fixed by wrapping on PG_CATCH/pfree/PG_RE_THROW. I didn't managed to
> > create a test that use this code path, so let me know if I'm still
&g
also changed the "connstr check" and
"security check" to have a validation very similar to what Peter
implemented on 0001-WIP-postgres_fdw-Fix-SCRAM-pass-through-security
patch. I also reproduced this test case that you've created on this new
dblink patch version and we actually
ot call
find_extension_control_filename instead of putting this logic there
since we already set the control_dir when we find the control file, and
having the logic to set the control_dir or skip the find_in_path seems
more confusing on this function instead of on
parse_extension_control_file. Please let me know what you think.
--
Matheus Alcantara
v7-0001-extension_control_path.patch
Description: Binary data
to export too many things from there.)
>
I've exported substitute_path_macro because adding a new function on
dfmgr would require #include nodes/pg_list.h and I'm not sure what
approach would be better, please let me know what you think.
--
Matheus Alcantara
v6-0001-extension_control_path.patch
Description: Binary data
3_check_guc.pl line 85.
[11:29:42.995](0.000s) # got: '1'
# expected: '0'
[11:29:42.995](0.000s) ok 2 - no parameters missing from guc_tables.c
[11:29:42.995](0.000s) ok 3 - no parameters marked as NOT_IN_SAMPLE in
postgresql.conf.sample
found GUC jit_cached in guc_tables.c, missing from postgresql.conf.sample
--
Matheus Alcantara
> Just bikeshedding a bit ...
>
> I'm not mad keen on this design. I think the value should be either a
> single setting like "WARNING" or a set of type:setting pairs. I agree
> that "all" is a bad name, but I think "default" would make sense.
>
> I can live with it but I think this just looks a bit odd.
>
Just bringing some thoughts about it...
How about using something like *:WARNING? I'm not sure if it could also be
confusing as the "all" keyword, but I think it could also be interpreted as
"anything else use WARNING".
--
Matheus Alcantara
On Mon, Mar 3, 2025 at 4:16 PM Matheus Alcantara
wrote:
>
> Hi Alex,
>
> The code comments and the commit messages help a lot when reviewing! Thanks
> for
> the new version.
>
> The code LGTM and check-world is happy. I've also performed some tests and
> ever
th "The make_jsonpath_item_* functions" since we can have more
functions in the future that are not fully related with these. Does that make
sense?
--
Matheus Alcantara
--
Matheus Alcantara
v5-0001-extension_control_path.patch
Description: Binary data
cify the extension name.
This is a similar behaviour when, e.g we have a where clause that is
referencing a column that is present in multiple tables used in the query:
ERROR: 42702: column reference "b" is ambiguous LINE 1: select * from t inner
join t2 on t.a = t2.a where b = 10;
--
Matheus Alcantara
Hi
On Tue, Feb 25, 2025 at 5:29 PM Matheus Alcantara
wrote:
> Fixed on the attached v3.
>
After I've sent the v3 patch I noticed that the tests were failing on windows.
The problem was on TAP test that was using ":" as a separator on
extension_control_path and also the path
trlen(Extension_control_path) == 0)
> +{
> +paths = lappend(paths, ecp);
> + }
>
Fixed on the attached v3.
--
Matheus Alcantara
v3-0001-extension_control_path.patch
Description: Binary data
Thanks for all the comments on this folks! I probably underestimated
this change.
Thanks all.
--
Matheus Alcantara
lp with this patch I'm attaching a new version with the remaining TODOs
fixed and also with a new TAP test.
Thoughts?
--
Matheus Alcantara
v2-0001-extension_control_path.patch
Description: Binary data
tring type only
on these specific commands.
Thoughts?
--
Matheus Alcantara
v1-0001-Redact-user-password-on-pg_stat_statements.patch
Description: Binary data
ON_OK)
>
> I don't think this should be changed in a refactoring patch.
> PQstatus() can handle a NULL conn pointer.
>
Fixed
> > - if (rconn)
> > - pfree(rconn);
>
> Looks like this code in dblink_connect() was dropped.
>
Oops, fixed on connect_pg_server since this logic was moved to this function.
## Some other changes
I also added a new TAP test case to ensure that we return an error if
require_auth is overwritten with another value.
## Questions:
- The new dblink_connstr_has_scam_require_auth function is very similar with
dblink_connstr_has_pw, we may create a common function for these or let it
duplicated?
--
Matheus Alcantara
v3-0001-dblink-refactor-get-connection-routines.patch
Description: Binary data
v3-0002-dblink-Add-SCRAM-pass-through-authentication.patch
Description: Binary data
id I think that we could prohibit the
usage of other auth types when use_scram_passthrough is set, what do you think?
--
Matheus Alcantara
Hi, thanks for reviewing this patch!
Em seg., 10 de fev. de 2025 às 20:19, Jacob Champion
escreveu:
>
> On Wed, Jan 22, 2025 at 6:10 AM Matheus Alcantara
> wrote:
> > The attached patch enables SCRAM authentication for dblink connections when
> > using dblink_fdw without r
it looks good to me.
Thanks for the review! v3 with the fixes attached.
--
Matheus Alcantara
v3-0001-Use-read-stream-on-amcheck.patch
Description: Binary data
l.
>
>
> As for 'small values', it means that the average rows is between zero and
> one, to avoid rounding errors and misunderstanding. I think this would be
> ideal.
>
Get it, sounds reasonable to me.
--
Matheus Alcantara
ned but sometimes it can return 1 or more.
> >
> > * There are more spaces than necessary before "If a subplan node ..."
> >
> > * Maybe wrap 'rows' with ?
> >
>
> I agree with the last two points. As for the first one—maybe we could
> simply state that the average rows value can be decimal, especially for
> very small values?
>
I'm just not sure about the "small values"; the 'rows' in decimal will only
happen with small values? What would be a "small value" in this context? My main
point here is more that I think that it would be good to mention *why* the
'rows' can be decimal, not just describe that it could be decimal.
--
Matheus Alcantara
ws
will be returned but sometimes it can return 1 or more.
* There are more spaces than necessary before "If a subplan node ..."
* Maybe wrap 'rows' with ?
--
Matheus Alcantara
-of-rows-and-loops-as-decimal-fraction.patch
> postgres$
Just for reference I'm trying to apply based on commit fb056564ec5.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=fb056564ec5bc1c18dd670c963c893cdb6de927e
--
Matheus Alcantara
d-loops-as-decimal-fraction.patch
error: patch failed: src/test/regress/expected/partition_prune.out:3041
error: src/test/regress/expected/partition_prune.out: patch does not apply
--
Matheus Alcantara
://www.postgresql.org/message-id/27b29a35-9b96-46a9-bc1a-914140869...@gmail.com
--
Matheus Alcantara
v1-0002-dblink-Add-SCRAM-pass-through-authentication.patch
Description: Binary data
v1-0001-dblink-refactor-get-connection-routines.patch
Description: Binary data
Em qua., 15 de jan. de 2025 às 14:03, Peter Eisentraut
escreveu:
>
> On 14.01.25 15:14, Matheus Alcantara wrote:
> >> Attached is a fixup patch where I have tried to expand the documentation
> >> a bit in an attempt to clarify how to use this. Maybe check that what
Em ter., 14 de jan. de 2025 às 06:21, Peter Eisentraut
escreveu:
>
> On 09.01.25 16:22, Matheus Alcantara wrote:
> > Yeah, I also think that makes sense.
> >
> > I've made all changes on the attached v2.
>
> (This should probably have been v3, since you had a
uot;)));
>
> Maybe the option of having SCRAM pass-through should be mentioned here?
> It seems sort of analogous to the delegate GSSAPI credentials case.
>
Yeah, I also think that makes sense.
I've made all changes on the attached v2.
--
Matheus Alcantara
v2-0001-postgres_fdw-SCRAM-authentication-pass-through.patch
Description: Binary data
1 - 100 of 126 matches
Mail list logo
