Hi to all note-takers
(I added two who I *think* I remember took notes)
Please upload the notes to the Unconference section in
https://wiki.postgresql.org/wiki/PGConf.dev_2025
I have also some random notes on scraps of paper from the two sessions
I attended and did not present and would like to
On Mon, May 5, 2025 at 11:19 AM DIPESH DHAMELIYA
wrote:
>
> Hello everyone,
>
> With the commit 556f7b7bc18d34ddec45392965c3b3038206bb62, Any plpgsql
> function that returns scalar value would not be able to use parallelism to
> evaluate a return statement. It will not be considered for parallel
On Tue, May 20, 2025 at 11:59 AM Michael Paquier wrote:
>
> On Tue, May 20, 2025 at 08:38:47AM +0900, Michael Paquier wrote:
> > With the semicolon in place, stmt_len gets set for the last query of
> > the string. Still digging more..
>
> And got it. The problem is that we are failing to update
On Tue, May 20, 2025 at 05:51:51PM +1200, David Rowley wrote:
> Given the planId stuff is new and has the same issue, I think that
> pushes me towards thinking now is better than later for fixing both.
>
> I'm happy to adjust my patch unless you've started working on it already.
Here you go with
> I too made this realization while reviewing the application. I concur it
> is something that we should try and mitigate. Sending a canary patch
> through once-a-day, or on any fixed time period, doesn’t quite seem
> sufficient. We have many commits per day and immediately switch to them as
> t
On Tue, May 20, 2025 at 02:09:13PM +0900, Michael Paquier wrote:
> On Mon, May 19, 2025 at 08:43:25PM -0700, Lukas Fittl wrote:
> > Yeah, +1 to making this consistent across both query ID and the new plan
> > ID, and changing both to int64 internally seems best.
>
> Any thoughts from others? I'm O
On Tue, 20 May 2025 at 16:07, Tom Lane wrote:
> Failures like this one [1]:
>
> @@ -340,9 +340,13 @@
> create function myinthash(myint) returns integer strict immutable language
>internal as 'hashint4';
> NOTICE: argument type myint is only a shell
> +ERROR: ROWS is not applicable when fun
On Tue, 20 May 2025 at 17:09, Michael Paquier wrote:
>
> On Mon, May 19, 2025 at 08:43:25PM -0700, Lukas Fittl wrote:
> > Yeah, +1 to making this consistent across both query ID and the new plan
> > ID, and changing both to int64 internally seems best.
>
> Any thoughts from others? I'm OK to take
> Test-scenario:
> --Created 250 sequences on both pub and sub.
> --There were 10 sequences mismatched.
> --Sequence replication worked as expected. Logs look better now:
>
> LOG: Logical replication sequence synchronization for subscription
> "sub1" - total unsynchronized: 250; batch #1 = 100 att
>> I too made this realization while reviewing the application. I concur it
>> is something that we should try and mitigate. Sending a canary patch
>> through once-a-day, or on any fixed time period, doesn’t quite seem
>> sufficient.
>
> Yeah, I'm afraid that won't do much except eat valuable cy
On Tue, May 20, 2025 at 8:38 AM shveta malik wrote:
>
> Please find few more comments:
>
> 1)
> ProcessStandbyPSRequestMessage:
> + /*
> + * This shouldn't happen because we don't support getting primary status
> + * message from standby.
> + */
> + if (RecoveryInProgress())
> + elog(ERROR, "the p
On Mon, May 19, 2025 at 08:43:25PM -0700, Lukas Fittl wrote:
> Yeah, +1 to making this consistent across both query ID and the new plan
> ID, and changing both to int64 internally seems best.
Any thoughts from others? I'm OK to take the extra step of switching
both fields on HEAD and write a patc
On Tue, May 20, 2025 at 8:35 AM Nisha Moond wrote:
>
> >
> > Thanks for the comments, these are handled in the attached v20250516
> > version patch.
> >
>
> Thanks for the patches. Here are my review comments -
>
> Patch-0004: src/backend/replication/logical/sequencesync.c
>
> The sequence count l
On Tue, May 20, 2025 at 8:11 AM Euler Taveira wrote:
>
> On Fri, May 16, 2025, at 12:06 PM, Fujii Masao wrote:
>
> The pgoutput plugin options are documented in the logical streaming
> replication protocol, but their default values are not mentioned.
> This can be inconvenient for users - for exam
David Rowley writes:
> Note that the actual row count is 1000 still, so that pretty much
> discounts corruption with the stored unique1 values. Unfortunately,
> that doesn't reduce the number of possible other reasons by very much.
Failures like this one [1]:
@@ -340,9 +340,13 @@
create functio
On Tue, May 20, 2025 at 08:38:47AM +0900, Michael Paquier wrote:
> With the semicolon in place, stmt_len gets set for the last query of
> the string. Still digging more..
And got it. The problem is that we are failing to update the
statement location in a couple of cases with subqueries, and tha
On Sat, 17 May 2025 at 01:19, Andres Freund wrote:
> @@ -42,7 +42,7 @@
> -> Nested Loop (actual rows=1000.00 loops=N)
> -> Seq Scan on tenk1 t2 (actual rows=1000.00 loops=N)
> Filter: (unique1 < 1000)
> - Rows Removed by Filter: 9000
> +
On Mon, May 19, 2025 at 8:12 PM Michael Paquier wrote:
> On Tue, May 20, 2025 at 02:03:37PM +1200, David Rowley wrote:
> > Aside from the struct field types changing for Query.queryId,
> > PlannedStmt.queryId and PgBackendStatus.st_query_id, the
> > external-facing changes are limited to:
> >
> >
On Tue, May 20, 2025 at 02:03:37PM +1200, David Rowley wrote:
> Aside from the struct field types changing for Query.queryId,
> PlannedStmt.queryId and PgBackendStatus.st_query_id, the
> external-facing changes are limited to:
>
> 1. pgstat_report_query_id() now returns int64 instead of uint64
> 2
"David G. Johnston" writes:
> On Monday, May 19, 2025, Tatsuo Ishii wrote:
>> I have observed cases where a cfbot entry fails without clear reason
>> [1]. Even if the patch just modifies comments, it has failed in some
>> cfbot test. In this case we could easily guess that master branch
>> might
Please find few more comments:
1)
ProcessStandbyPSRequestMessage:
+ /*
+ * This shouldn't happen because we don't support getting primary status
+ * message from standby.
+ */
+ if (RecoveryInProgress())
+ elog(ERROR, "the primary status is unavailable during recovery");
a) This error is not cle
Amit Langote writes:
> Pushed after some tweaks to comments and the test case.
My attention was drawn to commit 525392d57 after observing that
Valgrind complained about a memory leak in some code that commit added
to BuildCachedPlan(). I tried to make sense of said code so I could
remove the lea
>
> Thanks for the comments, these are handled in the attached v20250516
> version patch.
>
Thanks for the patches. Here are my review comments -
Patch-0004: src/backend/replication/logical/sequencesync.c
The sequence count logic using curr_seq in copy_sequences() seems buggy.
Currently, curr_se
On Monday, May 19, 2025, Tatsuo Ishii wrote:
> I have observed cases where a cfbot entry fails without clear reason
> [1]. Even if the patch just modifies comments, it has failed in some
> cfbot test. In this case we could easily guess that master branch
> might have problems at the time when the
On Fri, May 16, 2025, at 12:06 PM, Fujii Masao wrote:
> The pgoutput plugin options are documented in the logical streaming
> replication protocol, but their default values are not mentioned.
> This can be inconvenient for users - for example, when using pg_recvlogical
> with pgoutput plugin and ne
Robert Haas writes:
> What I'm concerned about is that I think that (as I said on the other
> thread) is that ProcessGetMemoryContextInterrupt is not really at all
> safe to execute at an arbitrary CHECK_FOR_INTERRUPTS().
I agree.
> In my mind, the possible fixes here are (1) revert that patch,
On Tue, 20 May 2025 at 03:05, Peter Eisentraut wrote:
> Or why not store query IDs as int64_t
> internally, too?
I had the same thought. Changing to int64 seems like a good and less
bug-prone tidy-up. I expected we ended up with uint64 as the previous
type was uint32, and uint64 is the natural se
I have observed cases where a cfbot entry fails without clear reason
[1]. Even if the patch just modifies comments, it has failed in some
cfbot test. In this case we could easily guess that master branch
might have problems at the time when the tests performed. But if a
patch modifies some codes, i
Hi,
On 2025-05-08 19:22:27 -0700, Noah Misch wrote:
> On Thu, May 08, 2025 at 09:06:18PM -0400, Andres Freund wrote:
> > On 2025-05-02 20:05:11 -0700, Noah Misch wrote:
> > > On Wed, Apr 30, 2025 at 04:00:35PM -0400, Andres Freund wrote:
>
> > We do need to hold interrupts in a few other places,
On 5/19/25 22:29, Peter Geoghegan wrote:
> On Mon, May 19, 2025 at 4:17 PM Tomas Vondra wrote:
>> Same effect as v1 for IOS, with regular index scans I see this:
>>
>> 64 clients: 0.7M tps
>> 96 clients: 1.5M tps
>>
>> So very similar improvement as for IOS.
>
> Just to be clear, you're saying my
Hello! Thanks for helping me with this.
I'm still trying to figure out what is going on with the Bookworm test
failures. I'm pretty sure this patchset should resolve all the issues
with the macOS build, but I don't think it will help the linux
failures unfortunately.
On Sat, May 10, 2025 at 4:02 A
On Mon, May 19, 2025 at 05:10:14PM -0500, Sami Imseih wrote:
> I am still not sure why this is the case, but wanted to share this
> for now.
Hmm. Something seems to not be compiling well for the final query of
a stmtmulti in gram.y with updateRawStmtEnd(), as we rely on the
position of the semico
> It is also possible that the regression is not coming from
> 499edb0 but I do not see another obvious candidate.
I used pg_stat_statements to repro the issue, and a bisect
resulted in 499edb0 being the source of the regression.
```
select pg_stat_statements_reset();
set pg_stat_statements.trac
On Mon, May 19, 2025 at 11:38:39AM -0500, Nathan Bossart wrote:
> On Tue, May 13, 2025 at 11:37:45AM -0700, Salvatore Dipietro wrote:
>> Based on your findings Nathan, what is the best way to proceed for this
>> change?
>> Do we need more validation for it? If yes, which kind?
>
> Well, I am conf
> On 1 May 2025, at 14:40, Robert Haas wrote:
> ..in general I'm
> skeptical that we can really set up something that is OK to do in an
> aborted transaction, because our ability to handle any further errors
> at that point is extremely limited, and this code is definitely
> complex enough that i
On Mon, May 19, 2025 at 11:19:48AM -0400, Robert Haas wrote:
> The advantage of Fujii-san's proposal is that it is very simple to
> implement. A subscription option would indeed be better, but it would
> also be considerably more complex. Why not start simple and if someone
> wants to do the work t
On Mon, May 19, 2025 at 02:13:45PM -0700, Hari Krishna Sunder wrote:
> I think it would be better to revert 9879105 since there can be a
> considerable number of true empty tables that we don´t need to process.
I'm not sure that's a use-case we really need to optimize. Even with
100,000 empty tab
On Mon, May 12, 2025 at 06:40:43PM -0400, Sami Imseih wrote:
> Also, LocationExpr is not really an expression node, but a wrapper to
> an expression node, so I think it's wrong to define it as a Node and be
> required to add the necessary handling for it in nodeFuncs.c. I think we
> can just define
On Mon, May 19, 2025 at 02:31:24PM +, David Steele wrote:
> But in PG18 we now get:
>
> NOTICE: AUDIT: SESSION,35,2,DDL,CREATE TABLE,TABLE,public.do_table,"CREATE
> TABLE do_table (""weird name"" INT)",
> NOTICE: AUDIT: SESSION,35,3,DDL,DROP TABLE,TABLE,public.do_table,"CREATE
> TABLE do_tab
On Mon, May 19, 2025 at 10:37:29AM +0800, jian he wrote:
> I saw REGROLEOID in foreign_expr_walker,
> I'm wondering whether REGDATABASEOID is reachable within foreign_expr_walker.
>
> not familiar with this area, also there are no coverage tests for
> other reg*Const,
> per
> https://coverage.pos
Sorry didn't know about the conference.
I think it would be better to revert 9879105 since there can be a
considerable number of true empty tables that we don’t need to process.
---
Hari Krishna Sunder
On Mon, May 19, 2025 at 9:51 AM Nathan Bossart
wrote:
> On Wed, May 14, 2025 at 01:30:48PM
On Mon, May 19, 2025 at 10:38:19AM -0500, Nico Williams wrote:
> On Mon, May 19, 2025 at 01:25:00PM +0300, Aleksander Alekseev wrote:
> > I agree this would be most convenient for the user. Unfortunately this
> > will require us to check every SELECT query: "oh, isn't it by any
> > chance ORDER BY
On Mon, May 19, 2025 at 4:17 PM Tomas Vondra wrote:
> Same effect as v1 for IOS, with regular index scans I see this:
>
> 64 clients: 0.7M tps
> 96 clients: 1.5M tps
>
> So very similar improvement as for IOS.
Just to be clear, you're saying my v2 appears to fix the problem
fully, for both plain
On 5/19/25 20:44, Peter Geoghegan wrote:
> On Mon, May 19, 2025 at 2:19 PM Peter Geoghegan wrote:
>> On Mon, May 19, 2025 at 2:01 PM Tomas Vondra wrote:
>>> The regular index scan however still have this issue, although it's not
>>> as visible as for IOS.
>>
>> We can do somewhat better with plai
On 06/06/2024 17:34, Peter Eisentraut wrote:
Additionally, there are non-standard functions that are not
thread-safe, such as getopt_long().
getopt_long() is not used in the server, only in client programs. The
server binary does actually accept a few "long" arguments, like --single
and --des
On Mon, May 19, 2025 at 3:37 PM Andres Freund wrote:
> I think we can do better - something like
>
> #ifdef PG_HAVE_8BYTE_SINGLE_COPY_ATOMICITY
> lsn = PageGetLSN(page);
> #else
> buf_state = LockBufHdr(bufHdr);
> lsn = PageGetLSN(page);
> UnlockBufHdr(bufHdr, buf_state);
> #endif
Hi,
On 2025-05-19 18:13:02 +0200, Tomas Vondra wrote:
> I believe enabling data checksums simply makes it more severe, because
> the BufferGetLSNAtomic() has to obtain header lock, which uses the same
> "state" field, with exactly the same retry logic. It can probably happen
> even without it, but
On 19/05/2025 12:25, Aleksander Alekseev wrote:
Tom, Nico, Vik,
TABLESAMPLE is hitched to a which can be basically
anything resembling a relation. So it appears the standard already
allows this and we just need to implement it.
Vik, many thanks for sharing this. I don't have a strong opini
On Mon, May 19, 2025 at 2:19 PM Peter Geoghegan wrote:
> On Mon, May 19, 2025 at 2:01 PM Tomas Vondra wrote:
> > The regular index scan however still have this issue, although it's not
> > as visible as for IOS.
>
> We can do somewhat better with plain index scans than my initial v1
> prototype,
On Mon, May 19, 2025 at 2:01 PM Tomas Vondra wrote:
> For index-only scans, yes.
Great.
> The regular index scan however still have this issue, although it's not
> as visible as for IOS.
We can do somewhat better with plain index scans than my initial v1
prototype, without any major difficultie
On Mon, May 19, 2025 at 1:02 PM Jeff Davis wrote:
> I'm not sure if you intended it this way, but using "clever" here
> suggests that it's an unusual trick. But isn't that the kind of thing
> heavyweight locks are for?
>
> FWIW, a lock while recording a dependency would not be surprising to
> me.
On 5/19/25 12:25, Aleksander Alekseev wrote:
```
-- imagine replacing inefficient array_sample(array_agg(t), 10)
-- with more efficient array_sample_reservoir(t, 10)
SELECT (unnest(agg)).* AS k FROM
( SELECT array_sample(array_agg(t), 10) AS agg FROM (
... here goes the subquery ...
) AS
On 5/19/25 19:20, Peter Geoghegan wrote:
> On Mon, May 19, 2025 at 12:42 PM Peter Geoghegan wrote:
>> We don't actually need to call BufferGetLSNAtomic() from _bt_readpage
>> during index-only scans (nor during bitmap index scans). We can just
>> not call BufferGetLSNAtomic() at all (except dur
On Mon, May 19, 2025 at 12:42 PM Peter Geoghegan wrote:
> We don't actually need to call BufferGetLSNAtomic() from _bt_readpage
> during index-only scans (nor during bitmap index scans). We can just
> not call BufferGetLSNAtomic() at all (except during plain index
> scans), with no possible downsi
On Wed, 2024-05-22 at 10:48 -0400, Robert Haas wrote:
> > Then, Tom proposed another approach in [2] which is that "creation
> > DDL will have
> > to take a lock on each referenced object that'd conflict with a
> > lock taken by DROP".
> > This is the one the current patch is trying to implement.
>
On Wed, May 14, 2025 at 01:30:48PM -0700, Hari Krishna Sunder wrote:
> Here is the patch with a comment.
Thanks.
> On Wed, May 14, 2025 at 8:53 AM Nathan Bossart
> wrote:
>> There was a similar report for vacuumdb's new --missing-stats-only option.
>> We fixed that in commit 9879105 by removing
On Fri, May 9, 2025 at 9:06 AM Tomas Vondra wrote:
> Good question. I haven't checked that explicitly, but it's a tiny data
> set (15MB) and I observed this even on long benchmarks with tens of
> millions of queries. So the hint bits should have been set.
>
> Also, I should have mentioned the quer
On Tue, May 13, 2025 at 11:37:45AM -0700, Salvatore Dipietro wrote:
> On Thu, 1 May 2025 at 14:50, Nathan Bossart wrote:
>> So...
>>
>> * The ISB does seem to have a positive effect without commit 3d0b4b1
>> applied.
>>
>> * With commit 3d0b4b1 applied, removing the ISB seems to have a positive
On Thu, 15 May 2025 at 18:19, Amit Kapila wrote:
>
> On Sun, May 11, 2025 at 6:53 AM Álvaro Herrera
> wrote:
> >
> > But the non-idiomatic locking of pg_partitioned_table appears to
> > continue to be the pain point of this patch. My impression is that
> > using a lock is the wrong approach to
Hi,
I looked at this again, and I think the reason is mostly obvious. Both
why it's trashing, and why it happens with checksums=on ...
The reason why it happens is that PinBuffer does this:
old_buf_state = pg_atomic_read_u32(&buf->state);
for (;;)
{
if (old_buf_state & BM_LOC
FWIW, all the hash function SQL interfaces, \df hash*,
have this behavior in which the result is a signed (int/bigint),
but the internal representation of the hash is an unsigned (int/bigint).
I am not sure why a comment is needed specifically for pg_stat_statements
--
Sami Imseih
Amazon Web Ser
> On 19 May 2025, at 6:10 PM, Jacob Champion
> wrote:
>
> On Mon, May 19, 2025 at 6:23 AM Aleksander Alekseev
> wrote:
>> In my experience people who have been contributing for some time use
>> format-patch and provide at least a draft of the commit message,
>> because they know it's more co
On 19/5/25 16:45, Tom Lane wrote:
[snip]
For one thing, I'm not sure how to teach the compiler that casting
"Query *" to "ConstQuery *" is okay but vice versa isn't.
Does C++ have a better story in this area?
Hi,
A C++ compiler *does* enforce "const correctness" (for examples
see, for ex
On Mon, May 19, 2025 at 01:25:00PM +0300, Aleksander Alekseev wrote:
> I agree this would be most convenient for the user. Unfortunately this
> will require us to check every SELECT query: "oh, isn't it by any
> chance ORDER BY random() LIMIT x?". I don't think we can't afford such
> a performance
On Mon, May 19, 2025 at 2:48 AM Amit Kapila wrote:
> The GUC wal_receiver_interval is also used for physical replication
> and logical launcher, so won't making it userset can impact those
> cases as well, but maybe that is okay. However, for the specific case
> you are worried about, isn't it bet
On Mon, May 19, 2025 at 6:23 AM Aleksander Alekseev
wrote:
> In my experience people who have been contributing for some time use
> format-patch and provide at least a draft of the commit message,
> because they know it's more convenient both for the reviewers (the
> patch has better chances to be
On 17.05.25 14:49, Michael Paquier wrote:
On Fri, May 16, 2025 at 04:05:01PM +0530, Shaik Mohammad Mujeeb wrote:
This conversion is intentional - most likely to match the bigint
type of the queryid column in pg_stat_statements. However, without
an explicit comment, this can be misleading. A begi
Hi,
On 2025-05-19 12:49:26 +0930, Robins Tharakan wrote:
> Hi Andres,
>
> On Fri, 16 May 2025 at 22:49, Andres Freund wrote:
> >
> > There have been other odd things on leafhopper, see e.g.:
> >
> https://www.postgresql.org/message-id/35d87371-f3ab-42c8-9aac-bb39ab5bd987%40gmail.com
> > https://
Isaac Morland writes:
> I assume this question has an obvious negative answer, but why can't we
> attach const declarations to the various structures that make up the plan
> tree (at all levels, all the way down)? I know const doesn't actually
> prevent a value from changing, but at least the comp
On Mon, May 19, 2025 at 10:35 AM Tom Lane wrote:
> I proposed a possible way to test for this at [1]. I was intending to
> get around to that sooner or later, but the urgency of the matter just
> went up in my eyes...
Ah, right, I actually read that thread but had forgotten about it. I
don't kno
Robert Haas writes:
> On Sun, May 18, 2025 at 7:31 PM Tom Lane wrote:
>> While chasing down Valgrind leakage reports, I was disturbed
>> to realize that some of them arise from a case where the
>> executor scribbles on the plan tree it's given, which it is
>> absolutely not supposed to do:
> Is
Hackers,
499edb0 introduced more precise locations for nested statements. In
general it works quite well and has made the pgAudit output much more
readable -- so kudos for that.
However, I have noticed one regression in the pgAudit tests. We have
this somewhat odd statement intentionally cra
On Mon, May 19, 2025 at 9:23 AM Jim Jones wrote:
> rebase
Hi,
Well, this patch is now more than 10 months old, and it's still the
case that nobody other than the author has said that they want this.
Is it time to give up?
I still don't think it's very clear either from the patch or from the
thr
On Sun, May 18, 2025 at 1:09 AM Masahiko Sawada wrote:
>
> On Sat, May 10, 2025 at 7:08 AM Amit Kapila wrote:
> >
> >
> > Can we have a parameter like immediately_reserve in
> > create_logical_slot API, similar to what we have for physical slots?
> > We need to work out the details, but that shou
Hi,
> > Is this really lowering the bar for new contributors? I've always held "be
> > liberal in what you accept" as a gold standard for projects I'm involved
> > in, to
> > remove barriers to entry. Good commit messages are obviously very
> > important,
> > but having your patch rejected (ye
On Thu, May 15, 2025 at 9:03 AM Andrei Lepikhov wrote:
> 2. IncrementalSort is not always more effective - it depends on the
> column's number of groups. In my experience, a non-cost-based decision
> one day meets the problematic case, and the people who stick with it are
> much more confused than
On Mon, 19 May 2025 at 08:35, Robert Haas wrote:
> On Sun, May 18, 2025 at 7:31 PM Tom Lane wrote:
> > While chasing down Valgrind leakage reports, I was disturbed
> > to realize that some of them arise from a case where the
> > executor scribbles on the plan tree it's given, which it is
> > abs
On Sun, May 18, 2025 at 7:31 PM Tom Lane wrote:
> While chasing down Valgrind leakage reports, I was disturbed
> to realize that some of them arise from a case where the
> executor scribbles on the plan tree it's given, which it is
> absolutely not supposed to do:
>
> /*
> * Initi
Tom, Nico, Vik,
> Seems to me the obvious answer is to extend TABLESAMPLE (or at least, some
> of the tablesample methods) to allow it to work on a subquery.
Currently our BERNOULLI and SYSTEM sampling methods don't allow
specifying the maximum number of rows that should be returned, only
the per
On Fri, May 16, 2025 at 5:39 PM Nisha Moond wrote:
>
> Hi,
>
> On Tue, May 13, 2025 at 3:48 PM shveta malik wrote:
> >
> >
> > With the given script, the problem reproduces on Head and PG17. We are
> > trying to reproduce the issue on PG16 and below where injection points
> > are not there.
> >
>
On Sun, May 18, 2025 at 4:06 PM Dilip Kumar wrote:
>
> Thanks for proposing the idea of making wal_level configurable at
> runtime. But why isn't making the relevant GUCs SIGHUP-reloadable
> sufficient?
>
> For enabling logical replication, users are already familiar with the
> wal_level and max_w
Thanks for your work and feedback!
I've updated the patches and added regular regression tests for
both pg_prewarm and amcheck.
On 2025-05-16 21:01, Fujii Masao wrote:
Also, since the issue was introduced in v17, this patch should be
back-patched to v17, right?
I agree with back-patching v3-
On Fri, May 16, 2025 at 9:11 PM Fujii Masao wrote:
>
> When multiple subscribers connect to different publisher servers,
> it can be useful to set different wal_receiver_timeout values for
> each connection to better detect failures. However, this isn't
> currently possible, which limits flexibili
On Mon, Mar 24, 2025 at 7:14 PM jian he wrote:
>
> v4-0003 table with empty rows aligned with master behavior.
> also will do table rewrite if the new column is domain with volatile
> check constraints,
> so less surprising behavior.
I found out that my v4-0003 is wrong.
For example, the followi
84 matches
Mail list logo
