On Wed, Apr 16, 2025 at 11:57 AM Andrey Borodin wrote:
>
>
>
> > On 16 Apr 2025, at 11:18, Ashutosh Bapat
> > wrote:
> >
> > Having only some of the nodes act as DCS
> > and others purely PostgreSQL nodes will reduce waste of resources.
>
> But typically you need more DCS nodes than PostgreSQL n
Alvaro Herrera 于2025年4月16日周三 03:12写道：
> On 2025-Apr-15, Tender Wang wrote:
>
> > I thought further about the lockmode calling find_inheritance_children
> > in ATPrepAddPrimaryKey.
> > What we do here? We first get oids of children, then check the if the
> > column of children has marked not-null,
> On 16 Apr 2025, at 11:18, Ashutosh Bapat wrote:
>
> Having only some of the nodes act as DCS
> and others purely PostgreSQL nodes will reduce waste of resources.
But typically you need more DCS nodes than PostgreSQL nodes. Did you mean
“Having only some of nodes act as PostgreSQL and others
On Wed, Apr 16, 2025 at 10:29 AM Andrey Borodin wrote:
>
> > We may build an extension which
> > has a similar role in PostgreSQL world as zookeeper in Hadoop.
>
> Patroni, pg_consul and others already use zookeeper, etcd and similar systems
> for consensus.
> Is it any better as extension than a
On Wed, 16 Apr 2025 at 02:03, Jacob Champion
wrote:
> Thank you for saying something; I'd hallucinated that srvoptions was
> limited to the server owner, and that's not true. It's pg_user_mapping
> that has the protection.
FWIW, I have some ideas on being able to store secrets in a server in
a sa
> On 16 Apr 2025, at 10:39, Kirill Reshke wrote:
>
> You can run bash from extension, what's the point?
You cannot run bash that will stop backend running bash.
Best regards, Andrey Borodin.
On Wed, 16 Apr 2025 at 10:25, Andrey Borodin wrote:
>
> I think I can provide some reasons why it cannot be neither extension, nor
> any part running within postmaster reign.
>
> 1. When joining cluster, there’s not PGDATA to run postmaster on top of it.
You can join the cluster on pg_basebackup
> On 16 Apr 2025, at 09:26, Tom Lane wrote:
>
> Andrey Borodin writes:
>> I think it's what Konstantin is proposing. To have our own Raft
>> implementation, without dependencies.
>
> Hmm, OK. I thought that the proposal involved relying on some existing
> code, but re-reading the thread th
On Wed, Mar 26, 2025 at 4:17 PM Zhijie Hou (Fujitsu)
wrote:
>
> Here's a rebased version of the patch series.
>
Thanks Hou-San for the patches. I am going through this long thread
and patches. One doubt I have is whenever there is a chance of
conflict-slot update (either xmin or possibility of it
> On 16 Apr 2025, at 09:33, Ashutosh Bapat wrote:
>
> In my experience, the load of managing hundreds of replicas which all
> participate in RAFT protocol becomes more than regular transaction
> load. So making every replica a RAFT participant will affect the
> ability to deploy hundreds of re
On Wed, Apr 16, 2025 at 9:37 AM Andrey Borodin wrote:
>
> My view is what Konstantin wants is automatic replication topology
> management. For some reason this technology is called HA, DCS, Raft, Paxos
> and many other scary words. But basically it manages primary_conn_info of
> some nodes to p
On Tue, Apr 15, 2025 at 5:44 AM Robert Haas wrote:
> On Thu, Apr 10, 2025 at 11:15 PM Thomas Munro wrote:
> > The new streaming BHS isn't just issuing probabilistic hints about
> > future access obtained from a second iterator. It has just one shared
> > iterator connected up to the workers' Rea
On 2025/04/15 23:37, Tom Lane wrote:
Fujii Masao writes:
Thanks for the report and patch! It looks good to me.
Agreed.
Since this issue exists in the back branches,
the patch needs be back-patched to all supported versions.
I doubt it's worth the trouble and buildfarm cycles to
back-pa
Andrey Borodin writes:
> I think it's what Konstantin is proposing. To have our own Raft
> implementation, without dependencies.
Hmm, OK. I thought that the proposal involved relying on some existing
code, but re-reading the thread that was said nowhere. Still, that
moves it from a large proje
> On 16 Apr 2025, at 04:19, Tom Lane wrote:
>
> feebly, and seems to have a bus factor of 1. Another example is the
> Spencer regex engine; we thought we could depend on Tcl to be the
> upstream for that, but for a decade or more they've acted as though
> *we* are the upstream.
I think it's
Hello Richard,
16.04.2025 06:05, Richard Guo wrote:
On Wed, Apr 16, 2025 at 11:54 AM Richard Guo wrote:
I noticed this recoveryCheck test failure on flaviventris after
pushing commit 3b35f9a4c (Fix an incorrect check in get_memoize_path).
...
I'm not convinced this failure is related to 3b35f9a
Chapman Flack writes:
> On 04/15/25 10:52, Tom Lane wrote:
>> The problem from a PL's standpoint is "given this input or output
>> of type FOO, should I transform it, and if so using what?". So
>> the starting point has to be a type not a transform.
> Perhaps the efficiency argument is really "s
On Wed, Apr 16, 2025 at 6:51 AM Tom Lane wrote:
>
> Or we could do what Jian suggested and just not emit any dropStmt
> for child indexes. I continue to fear that that will have
> undesirable side-effects, but I have to admit that I'm not sure
> what. The fact that the backend will automatically
On Wed, Apr 16, 2025 at 11:54 AM Richard Guo wrote:
> I noticed this recoveryCheck test failure on flaviventris after
> pushing commit 3b35f9a4c (Fix an incorrect check in get_memoize_path).
>
> ### Reloading node "standby"
> # Running: pg_ctl --pgdata xxx/pgdata reload
> server signaled
> ### Res
I noticed this recoveryCheck test failure on flaviventris after
pushing commit 3b35f9a4c (Fix an incorrect check in get_memoize_path).
### Reloading node "standby"
# Running: pg_ctl --pgdata xxx/pgdata reload
server signaled
### Restarting node "standby"
# Running: pg_ctl --wait --pgdata xxx/pgdat
On Wed, 16 Apr 2025 at 01:52, Álvaro Herrera wrote:
>
> On 2025-Apr-15, Mahendra Singh Thalor wrote:
>
> > I took this patch and did some testing. Patch looks good to me.
>
> Hello, thank you very much for looking.
>
> > I was not able to use "git am" in my setup due to CR's in patch but no
> > wa
On Thu, Apr 10, 2025 at 7:25 PM Amit Kapila wrote:
>
> On Tue, Jan 9, 2024 at 12:02 PM vignesh C wrote:
> >
> > As I did not see much interest from others, I'm withdrawing this patch
> > for now. But if there is any interest others in future, I would be
> > more than happy to work on this feature
On Mon, Apr 14, 2025 at 8:08 PM wenhui qiu wrote:
> No objections.It's a pity that the postgresql18 version has been code-frozen
v18 is now in feature freeze, but not code freeze, so bug fixes are
still allowed. I've pushed this patch after adding the "Reviewed-by"
tags.
Thanks
Richard
On 04/15/25 10:52, Tom Lane wrote:
> The problem from a PL's standpoint is "given this input or output
> of type FOO, should I transform it, and if so using what?". So
> the starting point has to be a type not a transform. ... protrftypes data
> is used as a filter before attempting a pg_transform
Hi Vignesh,
Some review comments for patch v20250325-0005 (docs).
==
doc/src/sgml/catalogs.sgml
(52.55. pg_subscription_rel)
1.
State code: i = initialize, d = data is being copied, f = finished
table copy, s = synchronized, r = ready (normal replication)
~
This is not part of the patch,
On Tue, Apr 15, 2025 at 04:08:55PM -0700, Jeff Davis wrote:
> On Mon, 2025-04-14 at 13:44 -0700, Noah Misch wrote:
> > However, I think v17's
> > concept of separate PG_REGEX_ symbols for the default-locale case is
> > still the
> > right thing for v18. In other words, this code should change to l
On Sat, Apr 5, 2025 at 7:31 PM Andres Freund wrote:
> Hi,
>
> On 2025-04-05 12:46:37 -0400, Tom Lane wrote:
> > 1. Invent a way to make a particular memory context read-only
> > after putting some data into it.
> >
> > 2. In debug builds, after we've built a tree that should be considered
> > rea
On Tue, Apr 15, 2025 at 3:25 PM Jelte Fennema-Nio wrote:
> I don't understand why it should be a server option instead of a user
> mapping option. Having it be a server option means that *any* Postgres
> user can read its contents.
Thank you for saying something; I'd hallucinated that srvoptions
Nikolay Samokhvalov writes:
> This is exactly what I wanted to write as well. The idea is great. At the
> same time, I think, consensus on many decisions will be extremely hard to
> reach, so this project has a high risk of being very long. Unless it's an
> extension, at least in the beginning.
Y
On Mon, 2025-04-14 at 13:44 -0700, Noah Misch wrote:
> v18 regc_pg_locale.c uses only the locale_t-extended forms, and it
> aims not to
> depend on LC_CTYPE. v17 used both tolower() and tolower_l(), but v18
> uses the
> latter only.
Fixed in v2-0001 by rewording the comment slightly.
>
> Howeve
After thinking about this a bit more: the problem is basically one
of things being done in the wrong order. And the way to ensure
that things get done in the right order is to set up the object
dependencies correctly. So what we need to do is to switch the
dependency direction between the child a
On Tue, Apr 15, 2025 at 8:08 AM Greg Sabino Mullane
wrote:
> On Mon, Apr 14, 2025 at 1:15 PM Konstantin Osipov
> wrote:
>
>> If anyone is working on Raft already I'd be happy to discuss
>> the details. I am fairly new to the PostgreSQL hackers ecosystem
>> so cautious of starting work in isolati
On Tue, 15 Apr 2025 at 22:48, Noah Misch wrote:
> yet be a
> postgres_fdw server option, postgres_fdw code can make it so. postgres_fdw
> already has explicit code to reclassify the "user" option.
I don't understand why it should be a server option instead of a user
mapping option. Having it be
I've prepared the updated patches as discussed, including the addition
of estimated lookups in the EXPLAIN output for Memoize. Please let me
know if you have any feedback or further suggestions.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 021cc6f5629a607cab3a0ec1021fc5f102dc0439 Mon
On Tue, 15 Apr 2025 at 23:34, Noah Misch wrote:
> That said, maybe having
> PQpipelineSync() was a mistake, since I think it's just PQsendPipelineSync() +
> PQflush().
Yes, IMO that's pretty much the case. But we cannot remove that
function because of backwards compatibility.
Note that for all t
On Tue, 15 Apr 2025 at 19:53, Jacob Champion
wrote:
> But let me turn this around, because we currently have the opposite
> problem: if someone comes in and adds a completely new feature
> depending on libcurl, and you want OAuth but you do not want that new
> feature -- or vice-versa -- what do y
On Fri, Feb 21, 2025 at 11:33:41AM +0900, Michael Paquier wrote:
> So let's take one step here, I have applied the main patch.
commit 41625ab wrote:
> * \syncpipeline queues a synchronisation request, without flushing the
> commands to the server, equivalent of PQsendPipelineSync().
libpq
On Tue, Apr 15, 2025 at 1:48 PM Noah Misch wrote:
> If we think oauth_client_secret should get dispchar="*" UI treatment yet be a
> postgres_fdw server option, postgres_fdw code can make it so. postgres_fdw
> already has explicit code to reclassify the "user" option.
Agreed, I will add an open i
> On 15 Apr 2025, at 23:03, David Rowley wrote:
> My vote is to make the levels 1-based in all locations where we output
> the context information.
I agree with this, pg_get_process_memory_contexts() also use 1-based levels
fwiw.
--
Daniel Gustafsson
Alvaro Herrera writes:
> On 2025-Apr-15, Tom Lane wrote:
>> Looking at the patch itself, it doesn't seem like the got_children
>> flag is accomplishing anything;
> Ah yes, I forgot to set got_children when reading the children list.
> This happens within the loop for columns, so the idea is to ob
On 2025-Apr-15, Tom Lane wrote:
> +1. Fundamentally the problem here is that pg_restore needs
>
> ALTER TABLE ONLY foo ADD PRIMARY KEY
>
> to not recurse to child tables at all. It is expecting this command
> to acquire a lock on foo and nothing else; and it has already taken
> care of making
On Wed, 16 Apr 2025 at 01:23, torikoshia wrote:
>=# select name, level from pg_backend_memory_contexts;
> name | level
>+---
> TopMemoryContext | 1
>=# select pg_log_backend_memory_contexts(pg_backend_pid());
On Wed, 16 Apr 2025 at 04:25, Robert Haas wrote:
>
> On Mon, Apr 14, 2025 at 8:23 PM David Rowley wrote:
> > "Estimates: capacity=N distinct keys=N lookups=N hit ratio=N.N%"
>
> Is lookups=N here the estimated number of lookups i.e. what we think
> nloops will end up being?
Yes. The estimate is
On Tue, Apr 15, 2025 at 01:16:12PM -0700, Jacob Champion wrote:
> On Tue, Apr 15, 2025 at 12:14 PM Noah Misch wrote:
> > I suspect this should use .dispchar="*" to encourage UIs to display
> > oauth_client_secret like a password field. Thoughts?
>
> Hmm, from a UI perspective I agree. (The built
On 2025-Apr-15, Mahendra Singh Thalor wrote:
> I took this patch and did some testing. Patch looks good to me.
Hello, thank you very much for looking.
> I was not able to use "git am" in my setup due to CR's in patch but no
> warning in the patch when I used "patch -p".
Hmm, don't blame me; rat
On Tue, 15 Apr 2025 at 21:44, Ilia Evdokimov
wrote:
> Wrapping the line in costs or verbose would help with test stability, but
> doing that only to simplify test output doesn't look like the right reason.
> Maybe it makes more sense to mask these values in other tests that use
> Memoize too. W
On Tue, Apr 15, 2025 at 12:14 PM Noah Misch wrote:
> I suspect this should use .dispchar="*" to encourage UIs to display
> oauth_client_secret like a password field. Thoughts?
Hmm, from a UI perspective I agree. (The builtin flow targets "public
clients", where secrets are discouraged and/or und
Alvaro Herrera writes:
> However, I've also been looking at this and realized that this code can
> have different structure which may allows us to skip the
> find_inheritance_children() altogether. The reason is that we already
> scan the parent's list of columns searching for not-null constraint
On Tue, Apr 15, 2025 at 12:21 PM Robert Haas wrote:
> I also don't mind being wrong, of course. But I think it's better to
> bet on making this like other things and then change strategy if that
> doesn't work out, rather than starting out by making this different
> from other things.
Works for m
On Tue, Apr 15, 2025 at 11:57 AM Christoph Berg wrote:
> What made me reconsider was Peter saying that what defines the blast
> radius of some feature is usually the extra dependency pulled in. If
> you don't like tracking OpenSSL problems, build without it. If you
> don't like libcurl, build with
On Tue, Apr 15, 2025 at 8:32 AM Peter Eisentraut wrote:
> On 10.04.25 01:08, Jacob Champion wrote:
> > Christoph noted that this was also confusing from the packaging side,
> > earlier, and Daniel proposed -Doauth-client/--with-oauth-client as the
> > feature switch name instead. Any objections? U
commit b3f0be7 wrote:
+ {"oauth_scope", NULL, NULL, NULL,
+ "OAuth-Scope", "", 15,
+ offsetof(struct pg_conn, oauth_scope)},
The field containing "" is documented as follows:
char *dispchar; /* Indicates how to display this field
in a
On 2025-Apr-15, Tender Wang wrote:
> I thought further about the lockmode calling find_inheritance_children
> in ATPrepAddPrimaryKey.
> What we do here? We first get oids of children, then check the if the
> column of children has marked not-null, if not, report an error.
> No operation here on c
Re: Jacob Champion
> But there's no connection between "libcurl" and "OAuth Device
> Authorization flow" in anyone's mind except the people who have worked
> on that feature.
Fwiw that was exactly the reason I originally voiced the idea to
rename.
> But let me turn this around, because we current
On 2025-04-15 Tu 2:30 PM, Mahendra Singh Thalor wrote:
Hi Andrew,
I did some refactoring to find out dump file extensions(.dmp/.tar etc)
in pg_restore. With the attached patch, we will not try to find out
file extension with each database, rather we will find out before the
loop.
Here, I am at
Ashutosh Bapat writes:
> On Mon, Apr 14, 2025 at 11:14 PM Tom Lane wrote:
>> This is disastrous for assorted reasons. The ALTER ADD CONSTRAINT
>> command might fail outright if we've loaded data for the referencing
>> table but not the referenced table.
> There's a comment in getConstraints()
>
On Sat, 5 Apr 2025 at 01:41, Andrew Dunstan wrote:
>
>
> On 2025-04-04 Fr 5:12 AM, Mahendra Singh Thalor wrote:
>
> On Fri, 4 Apr 2025 at 13:52, Mahendra Singh Thalor wrote:
>
> On Fri, 4 Apr 2025 at 01:17, Andrew Dunstan wrote:
>
> On 2025-04-01 Tu 1:59 AM, Mahendra Singh Thalor wrote:
>
> On M
On Tue, Apr 15, 2025 at 8:34 AM Christoph Berg wrote:
> I agree with this reasoning and retract my suggestion to rename the option.
(Thank you for chiming in; having the packager feedback has been
extremely helpful.)
While I have you, may I ask whether you're okay (from the packager
perspective)
Hello Andres,
14.04.2025 19:06, Andres Freund wrote:
Unfortunately I'm several hundred iterations in, without reproducing the
issue. I'm bad at statistics, but I think that makes it rather unlikely that I
will, without changing some aspect.
Was this an assert enabled build? What compiler and wh
Thanks for the comments!
On Tue, Apr 15, 2025 at 3:11 AM Andres Freund wrote:
>
> Hi,
>
> On 2025-04-14 09:58:19 -0700, James Hunter wrote:
> > I see two orthogonal problems, in processing Bitmap Heap pages in
> > parallel: (1) we need to prefetch enough pages, far enough in advance,
> > to hide
On Tue, Apr 15, 2025 at 5:31 AM Peter Eisentraut wrote:
> On 10.04.25 01:08, Jacob Champion wrote:
> > Christoph noted that this was also confusing from the packaging side,
> > earlier,
Since Christoph has withdrawn the request, I will drop -0002.
However, I'll go ahead and put some of my opinio
Chapman Flack writes:
> On 04/06/25 22:37, Tom Lane wrote:
>> BTW, I feel a little uncomfortable with the idea that we're adding
>> dependencies on objects that are explicitly mentioned nowhere in the
>> pg_proc entry.
> Pursuing that idea a bit further, was there a compelling original reason
> t
On Mon, Apr 14, 2025 at 11:14 PM Tom Lane wrote:
>
> I wrote:
> > Here's a draft patch for this. It seems to fix the problem in
> > light testing.
>
> I realized that the "repro" I had for this isn't testing the same
> thing that Dimitrios is seeing; what it is exposing looks more like
> a bug or
Em seg., 14 de abr. de 2025 às 18:11, Tom Lane escreveu:
> Robert Haas writes:
> > On Sun, Apr 13, 2025 at 7:34 PM Ranier Vilela
> wrote:
> >> The function *record_in* has a new report about resource leak.
> >> I think Coverity is right.
>
> > I agree, for small values of "right". The memory is
On Thu, Apr 10, 2025 at 4:05 PM Andres Freund wrote:
> I don't know of existing discussion, but it seems rather fundamental to me -
> if either DSA or memory contexts could be inconsistent at a CFI(), how could
> it possibly be safe to interrupt at that point? After all, after an error you
> need
Andrei Lepikhov writes:
> But what is the way you are proposing here? Do you mean that one more
> entity will be explicitly introduced: a transformed parse tree?
No, I wasn't thinking of adding new concepts, just saying that the
inputs to certain operations need to be treated as read-only.
What
Richard Guo writes:
> On Sun, Apr 6, 2025 at 1:46 AM Tom Lane wrote:
>> Years ago we fixed the executor to treat its input Plan trees as
>> read-only. It seems like we really ought to do the same for these
>> upstream subsystems. Surely, whatever benefit we get from changing
>> Node contents in
* Greg Sabino Mullane [25/04/15 18:08]:
> > If anyone is working on Raft already I'd be happy to discuss
> > the details. I am fairly new to the PostgreSQL hackers ecosystem
> > so cautious of starting work in isolation/knowing there is no
> > interest in accepting the feature into the trunk.
> >
On 3/16/25 2:19 PM, vignesh C wrote:
I noticed that Alvaro's comment from [1] is not yet addressed, I have
changed the status of commitfest entry to Waiting on Author, please
address them and change the status back to Needs review.
[1] -
https://www.postgresql.org/message-id/202502101154.bmb536n
Greg Sabino Mullane writes:
> On Tue, Apr 15, 2025 at 4:57 AM Srinath Reddy wrote:
>> - There's currently no native `\d`-style way to explore which tables are
>> using a given TAM.
> Perhaps there could be a more generic table-filtering mechanism for \d, but
> carving something out for such a ni
On 15 April 2025 18:18:41 CEST, Tom Lane wrote:
>Dimitrios Apostolou writes:
>> I only got the "ERROR: deadlock detected" message once, with pg_restore
>> compiled from master branch.
>
>Oh, hmm ... do you recall just when on the master branch? I'm
>wondering if it was before or after 14e87ffa5
On Mon, Apr 14, 2025 at 12:59:50PM -0700, Jeff Davis wrote:
> On Sat, 2025-04-12 at 05:34 -0700, Noah Misch wrote:
> > I think the code for (2) and for "I/i in Turkish" haven't returned.
> > Given
> > commit e3fa2b0 restored the v17 "I/i in Turkish" treatment for plain
> > lower(),
> > the regex c
Hi, Christoph!
You wrote a very interesting answer.
> First question would be "which round rule?"
I mean rounding up “as at school”, but there are nuances in programming.
> https://www.postgresql.org/docs/current/functions-math.html
Thanks a lot for the link to the doc!
> you set it to with
Hi, Tom!
> Round-to-nearest-even is a well-respected rule
Yes, you're convinced me! I can’t argue with IEEE 754 =) And, of course,
can’t break compatibility.
Best regards,
Daria Shanina
пн, 14 апр. 2025 г. в 17:26, Tom Lane :
> Christoph Moench-Tegeder writes:
> > ## Daria Shanina (vilensip
Hi Vignesh,
Some review comments for v20250525-0004.
==
Commit message
1.
A new sequencesync worker is launched as needed to synchronize sequences.
It does the following:
a) Retrieves remote values of sequences with pg_sequence_state() INIT.
b) Log a warning if the sequence parameter
On Mon, Apr 14, 2025 at 8:23 PM David Rowley wrote:
> Maybe we could compress the text output a bit with:
>
> "Estimates: capacity=N distinct keys=N hit ratio=N.N%"
Sure, that works for me.
> If we get it that compact, maybe lookups could fit in there too, i.e.:
>
> "Estimates: capacity=N distin
On Tue, Apr 15, 2025 at 1:45 PM Pavel Stehule wrote:
>>
>> seems pretty easy to fix.
>> we only need dropStmt when IndxInfo->parentidx oid is invalid.
>>
>> +if (!OidIsValid(indxinfo->parentidx))
>> +appendPQExpBuffer(delq, "DROP INDEX %s;\n", qqindxname);
>
>
> I don't think i
Hi Team, Please find the attached diff with the latest changes.
The diff file changes that were done for memset and spinlock, are modified
on top of the previous patch.
New changes for review: 0001-AIX-support.tas.memset.diffs
Previous patch: 0001-AIX-support.v8.patch
>> diff --git a/src/includ
Dimitrios Apostolou writes:
> I only got the "ERROR: deadlock detected" message once, with pg_restore
> compiled from master branch.
Oh, hmm ... do you recall just when on the master branch? I'm
wondering if it was before or after 14e87ffa5 (2024-11-08).
If it was after, then it might have been
On Mon, Nov 06, 2023 at 02:23:04PM +0100, Laurenz Albe wrote:
> SET CONSTRAINTS ALL DEFERRED;
Some years ago I wrote and submitted a patch to allow one to create
constraints that are ALWAYS DEFERRED so that they cannot be made
IMMEDIATE with SET CONSTRAINTS ALL IMMEDIATE. I do think that one cou
jian he writes:
> Thanks for simplifying the tests, overall all looks good.
OK, pushed and back-patched, but only to v14. I tried to make
a variant that'd work in v13, but it caused ExecCheckPlanOutput
to throw "Query provides a value for a generated column" errors
for UPDATEs. That's surely re
Re: Peter Eisentraut
> But worse, what you are hiding is the information what dependencies
> you are pulling in, which is the actual reason for the options. (If there
> was no external dependency, there would be no option at all.)
>
> This seems unnecessarily complicated and inconsistent. Once y
> On 15 Apr 2025, at 14:41, Robert Haas wrote:
>
> On Tue, Apr 15, 2025 at 3:46 AM Daniel Gustafsson wrote:
>>> On 15 Apr 2025, at 06:22, Amul Sul wrote:
>>> Attached is a patch that corrects the code comment for
>>> process_directory_recursively() in pg_combinebackup, where the comment
>>> inc
Hi,
On 2025-04-14 16:46:22 +0900, Michael Paquier wrote:
> While reading the AIO code I have noticed that the way it uses
> injection points is limited by the fact that we don't have support for
> runtime parameters in the existing injection point facility.
Yep.
> The code is shaped with two se
Hi,
>> The whole thing might take about 20 to 30 hours wall-clock time.
>
> After this dev cycle, things with a defined end to them hold a greater
> attraction than they did previously.
>
>>
>> So, there is some time to think about this. Please discuss here if
>> you're interested or have questi
> On 12 Apr 2025, at 01:26, Jonathan S. Katz wrote:
>
> Please join us in wishing Jacob much success and few reverts!
Congratulations, Jacob!
Best regards, Andrey Borodin.
On Mon, Apr 14, 2025 at 1:17 PM Jacob Champion
wrote:
> I believe so. I'm in the middle of the .pc stuff right now; v6 should
> have the fixes as long as I don't get stuck.
Done in v6-0001. I think this is now architecturally complete, so if
reviewers are happy I can work on docs and the commit m
On Sun, Apr 13, 2025 at 7:34 PM Ranier Vilela wrote:
> CID 1608916: (#1 of 1): Resource leak (RESOURCE_LEAK)
> 52. leaked_storage: Variable buf going out of scope leaks the storage
> buf.data points to.
>
> The function *record_in* has a new report about resource leak.
> I think Coverity is right
On Mon, 14 Apr 2025, Tom Lane wrote:
I wrote:
Here's a draft patch for this. It seems to fix the problem in
light testing.
I realized that the "repro" I had for this isn't testing the same
thing that Dimitrios is seeing; what it is exposing looks more like
a bug or at least a behavioral chan
Dear Hou,
Thanks for updating the patch! I can finally come back to the thread.
Regarding the max_retain_conflict_duration, I prefer GUC approach because it has
already had a mechanism for converting unit: subscription option does not have
it.
Below part contains my comments:
01. check_new_clu
On Mon, Apr 14, 2025 at 1:15 PM Konstantin Osipov
wrote:
> If anyone is working on Raft already I'd be happy to discuss
> the details. I am fairly new to the PostgreSQL hackers ecosystem
> so cautious of starting work in isolation/knowing there is no
> interest in accepting the feature into the t
Fujii Masao writes:
> Thanks for the report and patch! It looks good to me.
Agreed.
> Since this issue exists in the back branches,
> the patch needs be back-patched to all supported versions.
I doubt it's worth the trouble and buildfarm cycles to
back-patch, since this should be a can't-happen
On Thu, Jan 23, 2025 at 07:28:19PM +0100, Laurenz Albe wrote:
> On Thu, 2025-01-23 at 12:30 -0500, Tom Lane wrote:
> > Pushed with some cosmetic adjustments
>
> Thank you!
commit 01463e1 wrote:
> +NOTICE: I am regress_groot
Let's not incur trivially-avoidable trademark risks
(https://google.com
>
> I am writing to inquire about the use cases for the SAVEPOINT feature.
>
Savepoints are used to implement ON_ERROR_ROLLBACK in psql. See:
https://www.endpointdev.com/blog/2015/02/postgres-onerrorrollback-explained/
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgre
On Tue, Apr 15, 2025 at 4:57 AM Srinath Reddy wrote:
> - Table Access Methods are increasingly used.
>
Citation needed.
> - There's currently no native `\d`-style way to explore which tables are
> using a given TAM.
>
There's also no way to list which tables are unlogged. Or which have
autova
Pavel Stehule writes:
> I have not knowledge, why pg_dump exports DROP INDEX explicitly, although
> it is redundant.
I concur that the proposed patch is probably not the right fix.
It just looks wrong and arbitrary.
My first thought about the right way to fix it was that the
INDEX ATTACH TOC ent
On Thu, 10 Apr 2025 at 17:37, jian he wrote:
>
>
> I think the current test example is fine.
Ok, let it be so. I changed status to RFQ as I have no more input
here, and other reviewers in thread remain silent (so I assume they
are fine with v10)
--
Best regards,
Kirill Reshke
Hi,
With commit 32d3ed81, pg_backend_memory_contexts view will start
numbering memory context levels from 1 instead of 0 in PostgreSQL 18.
For example:
=# select name, level from pg_backend_memory_contexts;
name | level
+---
TopM
Hi,
On 2025-04-11 18:21:14 +0200, Wolfgang Walther wrote:
> Jacob Champion:
> > On Wed, Apr 9, 2025 at 4:42 PM Jelte Fennema-Nio wrote:
> > > I think your suggestion of not using any .so files would best there (from
> > > w user perspective). I'd be quite surprised if a static build still
> > >
* Yura Sokolov [25/04/15 14:02]:
> I've been working in a company which uses MongoDB (3.6 and up) as their
> primary storage. And it seemed to me as "God Send". Everything just worked.
> Replication was as reliable as one could imagine. It outlives several
> hardware incidents without manual inter
1 - 100 of 137 matches
Mail list logo
