On Tue, Oct 28, 2025 at 10:04:20PM +0900, Michael Paquier wrote:
> I'll clean up that tomorrow, which can be summarized as something like
> the attached (quick fix, need to double-check).
Done this cleanup as d3111cb753e8, and tweaked a bit the second patch
(order of the fields and docs) before ap
HI
I think there might be some misunderstanding — I’m only suggesting
changing
effective_xid_failsafe_age = Max(vacuum_failsafe_age,
autovacuum_freeze_max_age * 1.05);
to
effective_xid_failsafe_age = (vacuum_failsafe_age +
autovacuum_freeze_max_age) / 2.0;
In t
Unfortunately, I need to admit that I have messed a bit with v18.
I forgot to sync the pg_upgrade portion with the rest of the patch,
among other things. Here's a proper version with additional testing.
pg_upgrade/t/007_mxoff.pl is not meant to be committed, it's just
for test purposes. In order t
Hi Vignesh
Here are some review comments for the patch v24-0002.
These comments are just for the SGML docs. The patch needs a rebase so
I was unable to review the code.
==
Commit message
1.
A new column "prexcept" is added to table "pg_publication_rel", to maintain
the relations that the us
On Thu, Oct 30, 2025 at 04:18:26AM +, Bertrand Drouvot wrote:
> The tests are also stabilized on 17 thanks to 17a165d60f73 and on 16 thanks
> to 86392e8827d8, so I think that we should be fine on those branches too.
Applied down to v16, including the comment when the LWLock is
released for con
> On Oct 30, 2025, at 13:01, David Rowley wrote:
>
> On Thu, 30 Oct 2025 at 16:46, Chao Li wrote:
>>> On Oct 30, 2025, at 11:40, John Naylor wrote:
>>> Are you by chance running with asserts on? It's happened before, so I
>>> have to make sure. That makes a big difference here because I disa
On Thu, 30 Oct 2025 at 16:46, Chao Li wrote:
> > On Oct 30, 2025, at 11:40, John Naylor wrote:
> > Are you by chance running with asserts on? It's happened before, so I
> > have to make sure. That makes a big difference here because I disabled
> > diversion thresholds in assert builds so that reg
On Thu, 30 Oct 2025 at 16:40, Corey Huinker wrote:
> I'm in favor of the COUNT(NULL) optimization as well, as one of my favorite
> programming tropes is "There is nothing faster than nothing".
I think it would be much more interesting to do that if it could be
detected in cases like:
SELECT COU
Hi,
On Thu, Oct 30, 2025 at 11:25:18AM +0900, Michael Paquier wrote:
> On Wed, Oct 29, 2025 at 08:55:56AM +, Bertrand Drouvot wrote:
>
> > That's the test instability that triggered 818fefd8fd4 and not any report
> > from the field. I think that pre-818fefd8fd4 behavior has been there for a
>
On Wed, Oct 29, 2025 at 4:31 AM Dimitrios Apostolou wrote:
> Sorry to ping again, but was there a conclusion reached regarding adding the
> new file_extend_method setting?
No objections appeared, so the conclusion I am drawing is that we
should do this, and back-patch it into 17 for the upcoming
> On Oct 30, 2025, at 11:40, John Naylor wrote:
>
> On Thu, Oct 30, 2025 at 8:56 AM Chao Li wrote:
>
>> I changed work_men to 1GB and reran the test. As the high cardinality data
>> are still there, so I first reran with data:
>
>> With radix_sort on and off, execution time are almost the
On Tue, Oct 28, 2025 at 8:03 PM Jim Jones wrote:
>
>
>
> On 28/10/2025 00:55, Fujii Masao wrote:
> > If we mark transaction_read_only as GUC_REPORT, wouldn't the reset value
> > be sent automatically at the end of the transaction? It seems like we
> > wouldn't
> > need any new mechanism for that.
On Thu, 30 Oct 2025 at 15:58, wenhui qiu wrote:
> In fact, with the introduction of the vacuum_max_eager_freeze_failure_rate
> feature, if a table’s age still exceeds more than 1.x times the
> autovacuum_freeze_max_age, it suggests that the vacuum freeze process is not
> functioning properly. O
>
> It may be possible to apply transformations to other aggregate
> functions too, but I don't want to discuss that here. I mostly want to
> determine if the infrastructure is ok and do the count(*) one because
> it seems like the most likely one to be useful.
>
> One thing I wasn't too sure about
On Thu, Oct 30, 2025 at 8:56 AM Chao Li wrote:
> I changed work_men to 1GB and reran the test. As the high cardinality data
> are still there, so I first reran with data:
> With radix_sort on and off, execution time are almost the same.
Are you by chance running with asserts on? It's happened
On Wed, Oct 29, 2025 at 8:25 PM Ashutosh Bapat
wrote:
>
> On Wed, Oct 29, 2025 at 9:14 AM shveta malik wrote:
> >
> > On Tue, Oct 28, 2025 at 12:46 PM Ashutosh Bapat
> > wrote:
> > >
> > > On Mon, Oct 27, 2025 at 4:47 PM shveta malik
> > > wrote:
> > > >
> > > > Few comments:
> > > >
> > > > 1
> On Oct 29, 2025, at 18:33, Joel Jacobson wrote:
>
> On Wed, Oct 29, 2025, at 08:05, Chao Li wrote:
>>
>> I think the current implementation still has a race problem.
>>
>> Let’s say notifier N1 notifies listener’s L1 to read message.
>> L1 starts to read: it acquires the look, gets reading
On Thu, Oct 30, 2025 at 12:56 AM Masahiko Sawada wrote:
>
> On Wed, Oct 29, 2025 at 5:10 AM Amit Kapila wrote:
> >
> >
> > 8.
> > @@ -136,6 +137,12 @@ create_logical_replication_slot(char *name, char
> > *plugin,
> > temporary ? RS_TEMPORARY : RS_EPHEMERAL, two_phase,
> > failover, false
On 10/29/2025 6:53 AM, Euler Taveira wrote:
On Tue, Oct 28, 2025, at 1:51 PM, Álvaro Herrera wrote:
On 2025-Oct-27, Euler Taveira wrote:
On Mon, Oct 27, 2025, at 2:58 PM, Bryan Green wrote:
Thanks for even glancing at this. I did not add any regression
tests because the output goes to t
HI Nathan
> That approach would begin aggressively scaling the priority of tables
> sooner, but I don't know if that's strictly better. In any case, I'd like
> to avoid making the score calculation too magical.
In fact, with the introduction of the vacuum_max_eager_freeze_failure_rate
feature, if
"David E. Wheeler" writes:
> On Oct 29, 2025, at 19:52, Tom Lane wrote:
>> I'm asking to remove complexity, not add more. The buildfarm client
>> should not be checking either branch names or git tags to control
>> this, when we have a perfectly good convention about the existence
>> of .abi-com
Hi Vignesh,
Some review comments for v20251029_2-0001
==
General.
1.
I think it's more readable to consistently write the state name in
uppercase. There are a few affected comments:
e.g.
+ * we identify non-ready tables and non-ready sequences together to ensure
becomes
+ * we identify non-
On Wed, Oct 29, 2025 at 08:55:56AM +, Bertrand Drouvot wrote:
> Done that way in v3 attached. Please note that v3 does not take into account
> the XLogRecPtrIsInvalid() remark as this will be part of a global effort and
> it's not directly linked to what we want to achieve here.
This comment r
> On Oct 29, 2025, at 14:28, John Naylor wrote:
>
>
I just quick went through the code change. I guess I need more time to
understand the entire logic, but I find a typo that might effect the tests:
```
+ Assert(last = first);
```
“=“ should be “=="
Best regards,
--
Chao Li (Evan)
On Sat, Oct 25, 2025 at 1:48 AM Nathan Bossart wrote:
>
> On Sun, Sep 28, 2025 at 08:28:45PM -0500, David G. Johnston wrote:
> > On Sunday, September 28, 2025, jian he wrote:
> >> Since we already support INCLUDING STORAGE, I’m not sure that
> >> INCLUDING STORAGE PARAMETER is the right syntax to
> On Oct 29, 2025, at 19:29, John Naylor wrote:
>
> On Wed, Oct 29, 2025 at 3:25 PM Chao Li wrote:
>>> On Oct 29, 2025, at 14:28, John Naylor wrote:
>>>
>>> I suspect the challenge
>>> will be multikey sorts when the first key has low cardinality.
>>
>> As you predicted, when the first key
On Thu, 30 Oct 2025 at 13:24, Tom Lane wrote:
> > The reason I left it an unsigned type was that the check is doing: if
> > (chsize + ALLOC_CHUNKHDRSZ != blk_used), so we'd still catch this with
> > an unsigned type, even if it wrapped due to going negative due to a
> > bogus freeptr. Changing to
On 2025-10-29 19:55, Robert Haas wrote:
On Wed, Oct 29, 2025 at 2:06 PM Arne Roland wrote:
This virtually equivalent query issue occurs when the join condition is
(almost) unique. The different amount of tuples to process clearly
occurs when they are not.
I'm having trouble interpreting this.
On Oct 29, 2025, at 19:52, Tom Lane wrote:
> I'm asking to remove complexity, not add more. The buildfarm client
> should not be checking either branch names or git tags to control
> this, when we have a perfectly good convention about the existence
> of .abi-compliance-history to control it.
W
On Thu, 30 Oct 2025 at 13:22, Tom Lane wrote:
>
> David Rowley writes:
> > Is it worth mentioning there that we leave it up to the destruction of
> > the hash table itself to when the ExecutorState context is reset?
> > (Apparently execGrouping.c does not expose any way to do
> > tuplehash_destro
On Wed Oct 29, 2025 at 12:10 AM -03, jian he wrote:
> On Sat, Oct 25, 2025 at 2:27 AM Matheus Alcantara
> wrote:
>>
>> On this new version I also added some regress tests on postgres_fdw.sql
>>
>
> In the CopyFrom function, we have the CopyInsertMethod, CIM_SINGLE is slower
> than CIM_MULTI, I thi
On Wed, Oct 29, 2025 at 11:05:12AM -0700, Masahiko Sawada wrote:
> On Wed, Oct 29, 2025 at 12:02 AM Michael Paquier wrote:
>> Anyway, coming back to the patch, the argument of relying on the
>> slot's restart_lsn and the two xmins to restore the pre-818fefd8fd4
>> sounds good to me in light of 105
David Rowley writes:
> On Thu, 30 Oct 2025 at 12:55, Tom Lane wrote:
>> Seems like it's important that the value be signed, so maybe ssize_t?
>> Or ptrdiff_t?
> The reason I left it an unsigned type was that the check is doing: if
> (chsize + ALLOC_CHUNKHDRSZ != blk_used), so we'd still catch th
David Rowley writes:
> On Thu, 30 Oct 2025 at 08:51, Tom Lane wrote:
>> Here's a v2 that tries to clean up some of the mess.
> Thanks for doing that cleanup. A good improvement.
Thanks for reviewing!
> Just a couple of
> notes from the review for your consideration:
> 1) The comment in ExecEn
On Thu, 30 Oct 2025 at 12:55, Tom Lane wrote:
>
> David Rowley writes:
> > I did also consider [u]intptr_t, but thought Size was better as that's
> > what chsize is.
>
> Seems like it's important that the value be signed, so maybe ssize_t?
> Or ptrdiff_t?
I did think about this a bit. I did thin
On Sun, 2025-10-26 at 18:11 -0400, Tom Lane wrote:
> Related to this, while I was chasing Jeff's complaint I realized that
> the none-too-small simplehash table for this is getting made in the
> query's ExecutorState. That's pretty awful from the standpoint of
> being able to blame memory consumpt
David Rowley writes:
> It turns out that AllocSetCheck() thinks "long" is a good datatype to
> store the difference between 2 pointers. That's not going to work well
> on 64-bit Windows as long is 32-bit.
Ooops. Surprised we've not noticed this before.
> I did also consider [u]intptr_t, but tho
"David E. Wheeler" writes:
> On Oct 29, 2025, at 17:37, Tom Lane wrote:
>> ... I still do not like having any
>> policy decisions about which branches to check hard-wired into the
>> buildfarm client.
> Well that’s pretty easily addressed by adding a configuration for it. Maybe a
> regex to mat
On Thu, Oct 30, 2025 at 12:07:08PM +1300, David Rowley wrote:
> It turns out that AllocSetCheck() thinks "long" is a good datatype to
> store the difference between 2 pointers. That's not going to work well
> on 64-bit Windows as long is 32-bit.
Nice find. Your suggestion of using Size makes sens
On Fri, Oct 24, 2025 at 12:15 AM Shinya Kato wrote:
>
> Thank you all for the reviews!
>
> On Wed, Oct 8, 2025 at 4:34 AM Masahiko Sawada wrote:
> >
> > On Tue, Oct 7, 2025 at 12:01 PM Nathan Bossart
> > wrote:
> > >
> > > On Tue, Oct 07, 2025 at 10:17:38AM -0700, Masahiko Sawada wrote:
> > > >
I wrote:
> ... I think the expectation is that you turned on
> sepgsql_regression_test_mode manually before enabling this buildfarm
> test. I don't understand how < 18 would be passing if it weren't on,
> so the likely bet is that the test_sepgsql script is mistaken about
> how it's checking that.
On Oct 29, 2025, at 17:37, Tom Lane wrote:
> In the past we've never really thought that ABI was more than mildly
> solidified until around rc1. On the whole I'd rather wait until after
> the branch before starting to check ABI, simply because I don't care
> for the idea of adding .abi-complianc
Joe Conway writes:
> Everything < 18 passes.
Hmm ...
> 18 and HEAD get this failure:
> # The SELinux boolean 'sepgsql_regression_test_mode' must be
> # turned on in order to enable the rules necessary to run the
> # regression tests.
> I believe the boolean is flipped in the 17 and below tests
While reviewing another patch, I was playing around with a test case
to trigger a large memory allocation. I was doing this on Windows when
I got a nasty looking WARNING in a MEMORY_CONTEXT_CHECKING build:
create table t (a int);
insert into t values(1);
alter table t alter column a set (n_distinc
On Mon, Oct 27, 2025 at 5:22 AM Pradeep Kumar wrote:
>
> Hi All,
> In this thread they proposed fix_concurrent_slot_xmin_update.patch will solve
> this assert failure. After applying this patch I execute
> pg_sync_replication_slots() (which calls SyncReplicationSlots →
> synchronize_slots() → s
On Thu, 30 Oct 2025 at 08:51, Tom Lane wrote:
>
> I wrote:
> > David Rowley writes:
> >> I can't help wonder if we can improve the memory context parameter
> >> names in BuildTupleHashTable(). Every time I see "tablecxt" I have to
> >> remind myself that it's not for the bucket array, just the st
On 2025-10-22 We 3:24 PM, Nathan Bossart wrote:
On Wed, Oct 22, 2025 at 03:33:37PM +0300, Nazir Bilal Yavuz wrote:
On Tue, 21 Oct 2025 at 21:40, Nathan Bossart wrote:
I wonder if we could mitigate the regression further by spacing out the
checks a bit more. It could be worth comparing a var
On 10/28/25 18:49, Joe Conway wrote:
On 10/28/25 18:20, Jacob Champion wrote:
On Tue, Oct 28, 2025 at 2:47 PM Joe Conway wrote:
I am not understanding why ssl_passphrase_callbackCheck is being run at
all, but that is currently where I am stuck ¯\_(ツ)_/¯.
Old buildfarm client (REL_11). SSL te
> > One minor comment is to change is to remove the "let's save it" but
> > in the comments, as we are no longer saving a last_loc.
>
> Ah, yeah, that's a good change. I have pushed it now.
Thanks for pushing!
I will take 0002 on in a separate thread as there seems to
be agreement on doing somet
> > v16 is based on [0], with updates to the documentation and tests.
>
> Thanks for the updated patch!
>
> > +ok( $node->log_contains(qr/STATEMENT:\s+SELECT a FROM foo ORDER BY a
> > OFFSET \$1/s, $log_offset),
> > "bind and implicit transaction, no statement logged");
> Should it actually be
Bruce Momjian writes:
> On Fri, Oct 17, 2025 at 07:07:36PM -0400, Tom Lane wrote:
>> That seems overcomplicated: how does the buildfarm know
>> what's a maintenance branch? I think the rule should be
>> just "run ABI checks if the control file exists, else not".
> I assume we would want ABI brea
On Tue, 2025-10-21 at 11:28 -0700, Jeff Davis wrote:
> The attached patch refactors downcase_identifier() to use a method
> from
> the locale provider.
For now, I'm retracting this patch, instead opting for the narrower
change in the patch series here:
https://www.postgresql.org/message-id/d9657a
On Fri, Oct 17, 2025 at 07:07:36PM -0400, Tom Lane wrote:
> "David E. Wheeler" writes:
> > On Oct 17, 2025, at 17:51, Tom Lane wrote:
> >> NO. The rule is: if there's no such file, do not apply ABI checking.
> >> We are not interested in ABI complaints against master.
>
> > It only runs against
On Mon, Oct 13, 2025 at 7:15 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Mon, 13 Oct 2025 14:40:31 -0700,
> Masahiko Sawada wrote:
>
> > The patch refactors the CopyToStateData so that we can both hide
> > internal-u
On Wed, Oct 29, 2025 at 10:12:02PM +0200, Daniel Gustafsson wrote:
> > On 29 Oct 2025, at 20:47, Bruce Momjian wrote:
> >
> > On Tue, Oct 14, 2025 at 10:44:37AM +0200, Daniel Gustafsson wrote:
> >> Another inconsistency is that the documentation states this:
> >>
> >>"In this case the direc
On Thu, 2025-10-30 at 04:25 +1300, Thomas Munro wrote:
> Here are some sketch-quality patches to try out some of these ideas,
> for discussion. I gave them .txt endings so as not to hijack your
> thread's CI.
I like the direction this is going. I will commit the char32_t work
anyway, so afterward
> On 29 Oct 2025, at 20:47, Bruce Momjian wrote:
>
> On Tue, Oct 14, 2025 at 10:44:37AM +0200, Daniel Gustafsson wrote:
>> Another inconsistency is that the documentation states this:
>>
>>"In this case the directory is created by pg_dump and must not exist
>>before."
>>
>> ..which isn
I wrote:
> David Rowley writes:
>> I can't help wonder if we can improve the memory context parameter
>> names in BuildTupleHashTable(). Every time I see "tablecxt" I have to
>> remind myself that it's not for the bucket array, just the stuff we
>> have the buckets point to. Would "hashedtuplecxt"
On Mon, Oct 27, 2025 at 8:22 AM Alena Vinter wrote:
> Robert, this scenario actually occurred in production at one of our customer
> environments. Even though this workflow may be uncommon, PostgreSQL should
> still handle it gracefully. The fact that the server can end up in a state
> where it
On Wed, Oct 29, 2025 at 5:10 AM Amit Kapila wrote:
>
> On Tue, Oct 28, 2025 at 5:55 PM Amit Kapila wrote:
> >
> > I have noticed a few minor points:
> >
>
> Some more comments:
> 1.
> - if (RecoveryInProgress())
> - {
> -/*
> - * This check may have race conditions, but whenever
> -
Hi,
While working on a validator for keycloak[1] with libpq-oauth I find
out that to allow a self-signed certificated I had to set the CA on the
client but for this was required to also set the PGOAUTHDEBUG=UNSAFE
which generated a lot of information on the client side that I didn't
need for my te
On Wed, Oct 29, 2025 at 2:06 PM Arne Roland wrote:
> This virtually equivalent query issue occurs when the join condition is
> (almost) unique. The different amount of tuples to process clearly
> occurs when they are not.
I'm having trouble interpreting this. If it's important, please
clarify and
On Tue, 2025-10-28 at 14:54 -0700, Jeff Davis wrote:
> [21:48:21.794] ../../src/include/port/win32_port.h: At top level:
> [21:48:21.794] ../../src/include/port/win32_port.h:254:8: error:
> redefinition of ‘struct stat’
> [21:48:21.794] 254 | struct stat
> /* Th
On Tue, Oct 14, 2025 at 10:44:37AM +0200, Daniel Gustafsson wrote:
> Another inconsistency is that the documentation states this:
>
> "In this case the directory is created by pg_dump and must not exist
> before."
>
> ..which isn't true, since it will happily reuse an existing directo
On 10/29/25 01:05, Tomas Vondra wrote:
> ...
>> Yeah, I definitely want to protect against this. I believe similar
> failures can happen even with much lower m_w_m values (possibly ~2-3GB),
> although only with weird/skewed data sets. AFAICS a constant
> single-element array would trigger this, but
On Mon, Oct 13, 2025 at 10:22:53PM +0200, Christoph Berg wrote:
> Re: Robert Haas
> > My theory is that they'll be even less impressed if they try to use a
> > supposedly-compatible library and it breaks a bunch of stuff, but I
> > wonder what Christoph Berg (cc'd) thinks.
>
> It would also hinder
On Wed, Oct 29, 2025 at 8:36 AM Robert Haas wrote:
> On Wed, Oct 29, 2025 at 5:21 AM Richard Guo wrote:
> > I don't think the rewrite of unique-ification requires any adjustment
> > to this patch. I ran Q1 on v18, which does not include the
> > unique-ification changes, and here is what I observ
On Tue, Oct 28, 2025 at 1:55 AM Amit Kapila wrote:
>
> On Tue, Oct 28, 2025 at 8:59 AM shveta malik wrote:
> >
> > On Mon, Oct 27, 2025 at 11:56 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Oct 27, 2025 at 8:08 AM shveta malik
> > > wrote:
> > > >
> > > > On Mon, Oct 27, 2025 at 6:12 PM
On Tue, Oct 28, 2025 at 5:25 AM Amit Kapila wrote:
>
> On Tue, Oct 28, 2025 at 3:59 PM Amit Kapila wrote:
> >
> > On Mon, Oct 27, 2025 at 8:38 PM shveta malik wrote:
> > >
> > > On Mon, Oct 27, 2025 at 6:12 PM Amit Kapila
> > > wrote:
> > > >
> > >
> > > > Another related point is that, say we
On 2025-10-29 17:47, Robert Haas wrote:
On Wed, Oct 29, 2025 at 8:47 AM Robert Haas wrote:
I think the best shot at coming up with a
reproducer here is to study the cost differences in the queries where
the plan changes with the fix, particularly Q1 from my prior email.
So, the really intere
On Wed, Oct 29, 2025 at 12:02 AM Michael Paquier wrote:
>
> On Tue, Oct 28, 2025 at 11:53:26AM -0700, Masahiko Sawada wrote:
> > On Tue, Oct 28, 2025 at 1:58 AM Bertrand Drouvot
> > wrote:
>
> Apologies for not following closely what has been happening on this
> thread. I have just not been pay
Hi,
This patch series implements the TODO in predicate.c that suggests adding
ratio-based predicate lock limits.
(Resending with patch attachment, cause previous send was missing the
patch file)
The series is split into two logical commits:
1. Core implementation of the GUC variables and predica
On 22.10.25 10:04, Nazir Bilal Yavuz wrote:
diff --git a/.cirrus.tasks.yml b/.cirrus.tasks.yml
index eca9d62fc22..1c937247a9a 100644
--- a/.cirrus.tasks.yml
+++ b/.cirrus.tasks.yml
@@ -627,6 +627,8 @@ task:
TEST_JOBS: 8
IMAGE: ghcr.io/cirruslabs/macos-runner:sonoma
+XML_CATALOG
On Wed, Oct 29, 2025, at 17:48, Tom Lane wrote:
> However ... that won't actually work, the reason being that
> asyncQueueProcessPageEntries() doesn't work directly from an SLRU page
> but from a local copy. Even if it were to modify the state of that
> copy, no other backend would see the effects
On 28.10.25 13:33, Bertrand Drouvot wrote:
I do prefer to introduce XLogRecPtrIsValid(x) and switch to that. Then, do the
same kind of work on OidIsValid() and TransactionIdIsValid() and add an annual
check.
Idea is to get some code consistency while keeping macros which are valuable for
readabi
"Joel Jacobson" writes:
> On Wed, Oct 29, 2025, at 12:40, Heikki Linnakangas wrote:
>> That said, we could add COMMITTED/INVALID hint bits to AsyncQueueEntry,
>> similar to heap tuples, and set the hint bit instead of replacing the
>> original xid. That might be good for performance too: If the
On Wed, Oct 29, 2025 at 8:47 AM Robert Haas wrote:
> I think the best shot at coming up with a
> reproducer here is to study the cost differences in the queries where
> the plan changes with the fix, particularly Q1 from my prior email.
So, the really interesting thing about Q1 is that it contain
On Wed, 29 Oct 2025 at 09:19, Peter Smith wrote:
>
> Hi Vignesh,
>
> Some review comments patch V20251029-0001 (the test code only)
>
> ==
> src/test/subscription/t/036_sequences.pl
>
> 1.
> +##
> +## ALTER SUBSCRIPTION ... REFRESH PUBLICATION with (copy_data = off) should
> +# not upd
On Wed, Oct 29, 2025 at 10:24:17AM -0500, Sami Imseih wrote:
> I think we do need some documentation about this behavior, which v6 is
> still missing.
Would you be interested in giving that part a try?
> Another thing I have been contemplating about is the change in prioritization
> and the resul
On Wed, Oct 29, 2025 at 11:10:55AM +0800, wenhui qiu wrote:
> Typically, DBAs avoid setting autovacuum_freeze_max_age too close to
> vacuum_failsafe_age. Therefore, your logic most likely uses the
> vacuum_failsafe_age value.
> Would taking the average of the two be a better approach?
That approac
On Tue, Oct 28, 2025 at 05:44:37PM -0500, Sami Imseih wrote:
> My compiler is complaining about v6
>
> "../src/backend/postmaster/autovacuum.c:3293:32: warning: operation on
> ‘*score’ may be undefined [-Wsequence-point]
> 3293 | *score = *score = Max(*score, (double)
> in
On 28.10.25 22:54, Jeff Davis wrote:
I went back to using the check for __cplusplus, and added a comment
that hopefully clarifies things.
Yes, that looks more helpful now.
On Tue, Oct 28, 2025 at 6:08 PM Michael Paquier wrote:
> Three buildfarm members have reported after 8767b449a3a1: fairywren,
> drongo and hamerkop. All of them have reported green, so applied the
> equivalent cleanup on REL_18_STABLE with a92bbffbc3a7 for the service
> test.
Thank you!
--Jacob
On Wed, Oct 29, 2025 at 2:00 PM Thomas Munro wrote:
> I'm picturing something like PG_WCHAR_CHAR
> (direclty usable with ctype.h), PG_WCHAR_UTF32 (self-explanatory, also
> assumed be compatible with UTF-8 locales' wchar_t), PG_WCHAR_CUSTOM
> (we only know that ASCII range is sane as Ishii-san expl
> On Tue, Oct 28, 2025 at 12:16:28PM +1300, David Rowley wrote:
> > I think it's reasonable to want to document how autovacuum prioritises
> > tables, but maybe not in too much detail. Longer term, I think it
> > would be good to have a pg_catalog view for this which showed the
> > relid or schema/
On Wed, 2025-10-29 at 14:00 +1300, Thomas Munro wrote:
> I wonder if the logic to select the member/semantics could be turned
> into an enum in the encoding table, to make it even clearer, and then
> that could be used as an index into a table of ctype methods obejcts
> in _libc.c.
As long as we'r
On Wed, Oct 29, 2025 at 9:14 AM shveta malik wrote:
>
> On Tue, Oct 28, 2025 at 12:46 PM Ashutosh Bapat
> wrote:
> >
> > On Mon, Oct 27, 2025 at 4:47 PM shveta malik wrote:
> > >
> > > Few comments:
> > >
> > > 1)
> > > pgoutput_truncate:
> > >
> > > if (nrelids > 0)
> > > {
> > > OutputPluginPr
On Tue Oct 28, 2025 at 5:56 PM -03, Euler Taveira wrote:
> On Tue, Oct 28, 2025, at 9:29 AM, Matheus Alcantara wrote:
>> So here it is, see attached.
>>
>
> I took another look at this patch.
>
Thanks for reviewing!
> ! This adds a new "location" column on pg_available_extensions and
> ! pg_availa
On 16.10.25 01:19, Jacob Champion wrote:
I'm not sure if all this is better than an architecture where the
defaults and services are contained in different files. Since the
syntax and behavior of the two types of sections is explicitly
different, maybe combining them would be unnecessarily confus
Hi,
On 28/10/2025 17:37, Sami Imseih wrote:
v16 is based on [0], with updates to the documentation and tests.
Thanks for the updated patch!
+ok( $node->log_contains(qr/STATEMENT:\s+SELECT a FROM foo ORDER BY a
OFFSET \$1/s, $log_offset),
"bind and implicit transaction, no statement lo
On 29/10/2025 14:30, Joel Jacobson wrote:
On Wed, Oct 29, 2025, at 12:40, Heikki Linnakangas wrote:
On 25/10/2025 21:01, Joel Jacobson wrote:
I also want to share a new idea that Heikki Linnakangas came up with
during PgConf25 in Riga.
The idea is basically to scan the notification queue from
On Tue, Oct 28, 2025, at 1:51 PM, Álvaro Herrera wrote:
> On 2025-Oct-27, Euler Taveira wrote:
>
>> On Mon, Oct 27, 2025, at 2:58 PM, Bryan Green wrote:
>> > Thanks for even glancing at this. I did not add any regression
>> > tests because the output goes to the server log and not the client.
On Wed, Oct 29, 2025 at 6:43 AM Arne Roland wrote:
> Richard already covered a lot. I mainly want to reiterate, that a public test
> case would be immensely helpful.
I agree, and said the same.
> The Q1 you mentioned sadly isn't a real test case, where I can measure
> performance impact. More
On Wed, Oct 29, 2025 at 5:21 AM Richard Guo wrote:
> I don't think the rewrite of unique-ification requires any adjustment
> to this patch. I ran Q1 on v18, which does not include the
> unique-ification changes, and here is what I observed: without
> Ashutosh's patch, it performs a full partition
On Wed, Oct 29, 2025, at 12:40, Heikki Linnakangas wrote:
> On 25/10/2025 21:01, Joel Jacobson wrote:
>> I also want to share a new idea that Heikki Linnakangas came up with
>> during PgConf25 in Riga.
>>
>> The idea is basically to scan the notification queue from tail to head,
>> and update xids
> On 28 Oct 2025, at 22:44, Masahiko Sawada wrote:
>
> Andrey has shared his patch for base32hex support before[1]. While it
> needs to be updated, it seems to implement sufficient function.
I'd propose something like attached patch. It's on top of Ilmari's v2 patch
with small suggestions as
On Tue, Oct 28, 2025 at 5:55 PM Amit Kapila wrote:
>
> I have noticed a few minor points:
>
Some more comments:
1.
- if (RecoveryInProgress())
- {
-/*
- * This check may have race conditions, but whenever
- * XLOG_PARAMETER_CHANGE indicates that wal_level has changed, we
- * ver
Aleksander Alekseev writes:
> Hi,
>
> Thanks for the patch.
>
>> That does seem like a better fit. It's used mainly in recv functions,
>> which this basically is (but user-callable).
>>
>> Updated patch attaced.
>
> Perhaps bytea_uuid() should check the UUID format. Consider the
> following examp
Hi,
> > Updated patch attaced.
>
> Perhaps bytea_uuid() should check the UUID format. Consider the
> following example:
>
> SELECT
> uuid_extract_version('\x019a2f859cedb99d9c55044a2563'::bytea::uuid);
On the flip side we allow this:
=# select '019a2f85-9ced--b99d-9c55044a2563' :: uuid;
Thanks Álvaro, for the commit.
Closed the CF entry.
best regards,
Ranier Vilela
1 - 100 of 127 matches
Mail list logo
