On Mon, Jul 7, 2025 at 11:22 PM Tom Lane wrote:
>
> Dilip Kumar writes:
> >> IMHO we can just query the 'max_slot_wal_keep_size' after
> >> start_postmaster() and check what is the final resultant value. So now
> >> we will only throw an error if the final value is not -1. And we can
> >> remov
On Tue, Apr 15, 2025 at 4:36 PM jian he wrote:
>
> comment out tests are for to be implemented feature.
> There are some test changes that are indeed not necessary, I restored it back,
> please check attached.
hi.
refactor and rebase.
From d61f21e6fc410827d152a633e5699197c802870a Mon Sep 17 00:00
On 08/07/2025 02:37, Tom Lane wrote:
Vik Fearing writes:
Having read through this thread, is there any chance at all that we
might be able to implement feature F555, “Enhanced seconds precision”?
Don't see how we could do that without an on-disk compatibility break
for timestamps.
Yeah, I
Hi Andres,
Hi,
On 2025-07-05 07:09:00 +, Cédric Villemain wrote:
In my work on more careful PostgreSQL resource management, I've come to the
conclusion that we should avoid pushing policy too deeply into the
PostgreSQL core itself. Therefore, I'm quite skeptical about integrating
NUMA-spec
On 7/7/25 16:51, Cédric Villemain wrote:
* Others might use it to integrate PostgreSQL's own resources (e.g.,
"areas" of shared buffers) into policies.
Hope this perspective is helpful.
Can you explain how you want to manage this by an extension defined at
the SQL level, when most of t
On Thu, May 22, 2025 at 6:07 PM Richard Guo wrote:
> So, I think it's generally safe to use incremental sort whenever
> possible. There might be some corner cases where incremental sort is
> slower than full sort, and I think it would be best to address those
> in nodeIncrementalSort.c, as Robert
Dear Antonin,
> Having the extension in contrib would be useful in cases a 3rd party extension
> uses injection points in its regression tests. In particular, it's more
> practical for CI to install the "injection_points" extension by installing the
> "contrib" binary package than by building the
On Mon, Jul 07, 2025 at 01:58:18PM +0700, John Naylor wrote:
> With that, can this CF entry be closed?
I've missed that there was a CF entry. Closed now.
--
Michael
signature.asc
Description: PGP signature
Are there any objections against $SUBJECT?
Having the extension in contrib would be useful in cases a 3rd party extension
uses injection points in its regression tests. In particular, it's more
practical for CI to install the "injection_points" extension by installing the
"contrib" binary package
07.07.2025 11:17, Evgeny Voropaev wrote:
> Hello, hackers!
>
> Unfortunately, the problem of inconsistency while using prune_frezze
> with repairFragmentation=false does not only pertain to the content of
> dead and unused tuples, but it also can bring about inconsistency of
> locations of aliv
On Wed, 14 May 2025 at 08:35, Amit Kapila wrote:
>
> On Thu, Oct 17, 2024 at 5:03 AM Matthias van de Meent
> wrote:
> >
> > On Thu, 17 Oct 2024 at 00:33, Peter Geoghegan wrote:
> > >
> > > On Wed, Oct 16, 2024 at 5:48 PM Matthias van de Meent
> > > wrote:
> > > > In v17 and the master branch yo
On Sun, Jul 6, 2025 at 2:00 AM Alexander Lakhin wrote:
>
> --- a/src/backend/replication/logical/origin.c
> +++ b/src/backend/replication/logical/origin.c
> @@ -428,6 +428,7 @@ replorigin_drop_by_name(const char *name, bool
> missing_ok, bool nowait)
> * the specific origin and then re-
On Mon, Jul 7, 2025 at 11:03 AM Zhijie Hou (Fujitsu) wrote:
>
> On Sun, Jul 6, 2025 at 10:51 PM Masahiko Sawada wrote:
>
> > ==
> > > ==
> > > The workload is mostly same as [4].
> > >
> > > Workload:
> > > - Initially ran pgbenc
Hi,
On Tue, 29 Apr 2025 at 11:23, Nazir Bilal Yavuz wrote:
>
> Hi,
>
> On Thu, 13 Mar 2025 at 13:11, Nazir Bilal Yavuz wrote:
> > One thing I noticed is that gen_srcfiles['srcfiles'] seems wrong.
> > gen_sources is a better name compared to gen_srcfiles. So, I changed
> > it to gen_sources in v4
Hi,
I think there is a race scenario where a backend holding a conflicting
buffer pin isn't promptly canceled even when the standby limit has expired:
1. suppose there is a buffer pin conflict and standby limit has already
expired
2. startup process enters ResolveRecoveryConflictWithBufferPin and
Hi, hackers
If I understand correctly, we only need to check the specific bit
to determine whether a hash element needs relocation:
diff --git a/src/backend/utils/hash/dynahash.c
b/src/backend/utils/hash/dynahash.c
index 1ad155d446e..32fbae71995 100644
--- a/src/backend/utils/hash/dynahash.c
Hi Dean
On 30.06.25 19:18, Dean Rasheed wrote:
> v2 attached, now with docs and more test cases.
I'm wondering if the current behaviour with DEFAULT columns should be
mentioned in the docs.
CREATE TABLE t2 (a int PRIMARY KEY, b text DEFAULT 'default value');
INSERT INTO t2 VALUES (1, 'old value'
On 7/7/25 13:06, Arseniy Mukhin wrote:
> On Sun, Jul 6, 2025 at 10:49 PM Álvaro Herrera wrote:
>>
>> On 2025-Jul-06, Arseniy Mukhin wrote:
>>
>>> Sorry, forget to run a full test run with the new patch version. Some
>>> tests were unhappy with the new unknown support function. Here the new
>>>
On 2025-Jul-07, Tomas Vondra wrote:
> Alvaro, what's your opinion on the introduction of the new WITHIN_RANGE?
> I'd probably try to do this using the regular consistent function:
>
> (a) we don't need to add stuff to all BRIN opclasses to support this
>
> (b) it gives us additional testing of t
Hi,
On Wed, 25 Jun 2025 at 13:45, Nazir Bilal Yavuz wrote:
>
> Hi,
>
> On Tue, 24 Jun 2025 at 23:46, Jacob Champion
> wrote:
> >
> > On Tue, Jun 24, 2025 at 1:27 AM Nazir Bilal Yavuz
> > wrote:
> > > I think this is a good idea. Another point is that CI images and their
> > > packages are upda
Hi Tomas, some more thoughts after the weekend:
On Fri, Jul 4, 2025 at 8:12 PM Tomas Vondra wrote:
>
> On 7/4/25 13:05, Jakub Wartak wrote:
> > On Tue, Jul 1, 2025 at 9:07 PM Tomas Vondra wrote:
> >
> > Hi!
> >
> >> 1) v1-0001-NUMA-interleaving-buffers.patch
> > [..]
> >> It's a bit more complic
On 2025-Jul-05, Masahiko Sawada wrote:
> On Fri, Jul 4, 2025 at 8:01 PM Álvaro Herrera wrote:
> >
> > On 2025-Jul-04, Japin Li wrote:
> >
> > > I've opted to directly use %X/%08X for LSN formatting in this patch, with
> > > an
> > > accompanying comment near LSN_FORMAT_ARGS.
> >
> > Thank you!
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi Laurenz,
Nice focused patch.
Applied successfully on co
On Mon, 07 Jul 2025 at 19:34, Ashutosh Bapat
wrote:
> On Fri, Jul 4, 2025 at 5:18 PM Álvaro Herrera wrote:
>>
>> On 2025-Jul-04, Japin Li wrote:
>>
>> > I've opted to directly use %X/%08X for LSN formatting in this patch, with
>> > an
>> > accompanying comment near LSN_FORMAT_ARGS.
>>
>> Thank
Hi Andres, hi all,
Thanks a lot for the advice.
> My position is basically:
>
> 1) We should *never* add new long-duration polling loops to postgres. We've
>regretted it every time. It just ends up masking bugs and biting us in
>scenarios we didn't predict (increased wakeups increasing po
On 2025-07-07 Mo 10:13 AM, Tom Lane wrote:
Nazir Bilal Yavuz writes:
On Mon, 7 Jul 2025 at 13:51, Peter Eisentraut wrote:
Hmm. We have the (allegedly) same VS version in Cirrus CI, and it's
never shown a problem like this.
CI uses the latest VS 2019 (v16.11.48), it looks like buildfarm membe
* Others might use it to integrate PostgreSQL's own resources (e.g.,
"areas" of shared buffers) into policies.
Hope this perspective is helpful.
Can you explain how you want to manage this by an extension defined at
the SQL level, when most of this stuff has to be done when setting up
shared me
On Mon, Jul 7, 2025 at 9:53 AM shveta malik wrote:
>
> Thanks for the patch.
>
> > I couldn't figure out whether the query on primary to fetch all the
> > slots to be synchronized should filter based on invalidation_reason
> > and conflicting or not. According to synchronize_slots(), it seems
> >
> On Mon, Jul 07, 2025 at 01:57:42PM +0200, Tomas Vondra wrote:
> > It could be potentialy useful for any GUC that controls a resource
> > shared between backend, and requires restart. To make this GUC
> > changeable online, every backend has to perform some action, and they
> > have to coordinate
Hi,
On Mon, 7 Jul 2025 at 13:51, Peter Eisentraut wrote:
>
> On 06.07.25 00:27, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> On 04.06.25 08:15, Peter Eisentraut wrote:
> >>> For an explanation, the background is that MSVC has a "traditional"
> >>> preprocessor and a new "conforming" one. T
On 19/5/2025 15:21, Robert Haas wrote:
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 w
On Mon, Jul 7, 2025 at 6:36 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Mon, Jul 07, 2025 at 01:57:42PM +0200, Tomas Vondra wrote:
> > > It could be potentialy useful for any GUC that controls a resource
> > > shared between backend, and requires restart. To make this GUC
> > > changea
On 4/7/2025 10:30, Ilia Evdokimov wrote:
On 01.05.2025 15:22, Ilia Evdokimov wrote:
I attached updated v9 patch with the suggested changes. The updated
line in the EXPLAIN looks like this:
Text format:
Estimates: capacity=1 distinct keys=1 lookups=2 hit percent=50.00%
Non-text format:
> Did you add the patch to the CommitFest App?
Yes, I had attempted to register the patch earlier but had to wait for the
cool-off period to pass for my newly created account.
I’ve now successfully registered the patch on the CommitFest app
https://commitfest.postgresql.org/patch/5901
Thanks and
On Fri, 4 Jul 2025 at 13:07, Kirill Panin wrote:
>
> Thanks for your response.
> Do you think it makes sense to disallow cube+cube operations and only
> allow cube+point or point+point instead? Dot and cross products would be
> similarly only defined for point+point if someone were to implement th
Hi!
I'm reviewing code at toast_64bit_v2.
Michael, isn't there a typo?
static const toast_external_info
toast_external_infos[TOAST_EXTERNAL_INFO_SIZE] = {
[VARTAG_ONDISK_INT8] = {
.toast_pointer_size = TOAST_POINTER_INT8_SIZE,
.maximum_chunk_size = TOAST_MAX_CHUNK_SIZE_INT8,
.to_external_data = on
On Mon, Jul 7, 2025 at 2:37 PM shveta malik wrote:
>
> On Fri, Jul 4, 2025 at 3:53 PM vignesh C wrote:
> >
> > On Tue, 1 Jul 2025 at 15:20, shveta malik wrote:
> > > On Mon, Jun 30, 2025 at 3:21 PM Nisha Moond
> > > wrote:
> > > >
> > > > Please find the attached v20250630 patch set addressing
Attaching the rebased patch, some regression tests for SIMD hex-coding,
and a script to test bytea performance (usage info in the script).
The results obtained using the script on an m7g.4xlarge are shown below.
Read Operation
table (MB) | HEAD (ms) | SVE (ms) | improvement (%)
--
On 06.07.25 00:27, Tom Lane wrote:
Peter Eisentraut writes:
On 04.06.25 08:15, Peter Eisentraut wrote:
For an explanation, the background is that MSVC has a "traditional"
preprocessor and a new "conforming" one. The latter is available
starting in VS 2019, but it's not the default. We have s
> On Mon, Jul 07, 2025 at 07:12:50PM +0530, Ashutosh Bapat wrote:
>
> My current proposal is ALTER SYSTEM ... SET + pg_reload_conf() with
> pending mark + pg_apply_pending_conf(, parameters>). The third function would take a GUC name as parameter
> and complete the pending application change. If t
Hello,
during testing we found following issue when update records with big values.
2025-07-07 14:40:30.434 MSK [125435] PANIC: oversized WAL record
2025-07-07 14:40:30.434 MSK [125435] DETAIL: WAL record would be
1073742015 bytes (of maximum 1069547520 bytes); rmid 10 flags 64.
tested commi
On Fri, Jul 4, 2025 at 5:18 PM Álvaro Herrera wrote:
>
> On 2025-Jul-04, Japin Li wrote:
>
> > I've opted to directly use %X/%08X for LSN formatting in this patch, with an
> > accompanying comment near LSN_FORMAT_ARGS.
>
> Thank you! I support this approach and intend to work on getting this
> pa
Nazir Bilal Yavuz writes:
> On Mon, 7 Jul 2025 at 13:51, Peter Eisentraut wrote:
>> Hmm. We have the (allegedly) same VS version in Cirrus CI, and it's
>> never shown a problem like this.
> CI uses the latest VS 2019 (v16.11.48), it looks like buildfarm member
> drongo uses VS 2019 v16.3.1. I c
On 7/5/25 12:35, Dmitry Dolgov wrote:
>> On Fri, Jul 04, 2025 at 05:23:29PM +0200, Tomas Vondra wrote:
2) pending GUC changes
Perhaps this should be a separate utility command, or maybe even just
a new ALTER SYSTEM variant? Or even just a function, similar to what
the "o
On 7/5/25 09:09, Cédric Villemain wrote:
> Hi Tomas,
>
>
> I haven't yet had time to fully read all the work and proposals around
> NUMA and related features, but I hope to catch up over the summer.
>
> However, I think it's important to share some thoughts before it's too
> late, as you migh
I’ve tested the patch across several thousand test cases, and no faults of
any kind have been observed.
Additionally, I independently built a closed banking transaction system to
verify consistency during REINDEX CONCURRENTLY while multiple backends were
writing simultaneously. The results showed n
On Mon, 07 Jul 2025 at 14:18, Álvaro Herrera wrote:
> On 2025-Jul-05, Masahiko Sawada wrote:
>
>> On Fri, Jul 4, 2025 at 8:01 PM Álvaro Herrera wrote:
>> >
>> > On 2025-Jul-04, Japin Li wrote:
>> >
>> > > I've opted to directly use %X/%08X for LSN formatting in this patch,
>> > > with an
>> > >
On 2025-Jul-02, Evgeny wrote:
> Álvaro, Andrey, Alexander, hello!
>
> Since the master branch became the PG19dev and PG18 is now stable, I have
> directed this patch into PG19. Could we continue with it now?
Sure, I pushed your patch now.
> Álvaro, should I rename the SimpleLruZeroPageExt funct
On 2025-Jul-07, Ashutosh Bapat wrote:
> I am wondering whether we should question the restriction on using
> format macros because of translations.
Sure Mr. Quixote, the windmills are over there.
> In fact, these format macros can actually aid translations e.g. if the
> translation sees LSN_FORM
Hi,
On Mon, Jul 07, 2025 at 02:56:29PM +0900, Michael Paquier wrote:
> On Mon, Jun 30, 2025 at 01:36:12PM +, Bertrand Drouvot wrote:
> > * Do we need to serialize the stats based on their names (as for
> > PGSTAT_KIND_REPLSLOT)? This question is the same as "is the ordering
> > preserved
>
On 07.07.25 16:13, Tom Lane wrote:
Nazir Bilal Yavuz writes:
On Mon, 7 Jul 2025 at 13:51, Peter Eisentraut wrote:
Hmm. We have the (allegedly) same VS version in Cirrus CI, and it's
never shown a problem like this.
CI uses the latest VS 2019 (v16.11.48), it looks like buildfarm member
dro
On Mon, Jul 7, 2025 at 12:03 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Sun, Jul 6, 2025 at 10:51 PM Masahiko Sawada wrote:
>
> >
> > On Sun, Jul 6, 2025 at 8:03 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > >
> > > Dear hackers,
> > >
> > > As a confirmation purpose, I did performance testing with four
>
Hi,
On 2025-07-05 07:09:00 +, Cédric Villemain wrote:
> In my work on more careful PostgreSQL resource management, I've come to the
> conclusion that we should avoid pushing policy too deeply into the
> PostgreSQL core itself. Therefore, I'm quite skeptical about integrating
> NUMA-specific ma
On Mon, 14 Apr 2025 at 05:40, Ashutosh Bapat
wrote:
>
> I was wondering whether we should mention MERGE somewhere in the error
> message like "cannot merge into table ...". But the error message is
> reported depending upon the actual operation being performed and
> whether it's being published by
A 002_pg_upgrade.pl run got swapped order of tags "notnull_tbl1_upg nn" and
"notnull_parent_upg nn" for the schema diff test that commit
172259afb563d35001410dc6daad78b250924038 added in v18:
@@ -436873,14 +436873,14 @@
ALTER TABLE public.insert_tbl
ADD CONSTRAINT ne_insert_tbl_con CHECK (((
On Mon, Jul 07, 2025 at 06:31:33PM -0400, Peter Geoghegan wrote:
> On Mon, Jul 7, 2025 at 6:02 PM Noah Misch wrote:
>> In your test, just detach the injection point while the backend under test is
>> waiting at the injection point. All of
>> src/test/modules/injection_points/specs/*.spec use that
On Mon, Jul 7, 2025 at 11:38 PM Tom Lane wrote:
>
> > Also added a flag to select number of direct values to show
>
> Hmm ... I agree with having a way to control the length of that output,
> but I don't think that specifying a count is the most useful way to
> do it. Particularly with a default
On Sun, Jul 06, 2025 at 08:00:09PM -0700, Noah Misch wrote:
> I think the choice to make there is whether to call PQconninfo() once per
> prompt emission or to cache the value, invalidating that cache e.g. once per
> SyncVariables(). My first thought was to cache, but the decision is not too
> imp
On 19/03/2024 09:28, Peter Eisentraut wrote:
Does anyone know what precision we can expect from gettimeofday()?
Can we expect the full microsecond precision usually?
Having read through this thread, is there any chance at all that we
might be able to implement feature F555, “Enhanced seco
Hi,
On 2025-06-30 15:31:14 -0400, Burd, Greg wrote:
> > On Jun 30, 2025, at 12:27 PM, Andres Freund wrote:
> > On 2025-06-05 14:32:10 -0400, Andres Freund wrote:
> >> On 2025-06-05 12:47:52 -0400, Tom Lane wrote:
> >>> Andres Freund writes:
> I think this is a big enough pitfall that it's,
Hi,
On 2025-06-30 13:57:28 -0500, Jim Nasby wrote:
> +#if defined(HAVE_LIBURING_QUEUE_INIT_MEM) && defined(IORING_SETUP_NO_MMAP)
> && 1
>
> Is that && 1 intentional?
It was for testing both branches...
> Nit:
> + "mmap(%zu) to determine io_uring_queue_init_mem() support has failed: %m",
> IMHO
On Wed, Jul 2, 2025 at 7:33 PM Melanie Plageman
wrote:
> > I think this might actually be an underlying design problem with the
> > patch -- heap_page_set_vm_and_log() seems to want to be in charge of
> > both what we do with the heap page and what we do with the
> > corresponding VM bit, but that
On 2025-Jul-07, Álvaro Herrera wrote:
> Meanwhile, crake is failing the cross-version upgrade test because of
> this change, and I'm not sure what solution I'm going to offer. Maybe
> use the AdjustUpgrade.pm infrastructure to set all the pg_lsn column
> values to NULL if the old version is earli
On Mon, Jul 07, 2025 at 05:31:30PM -0400, Peter Geoghegan wrote:
> I have successfully simulated "wait no more than once" by adding C
> code to nbtree that looks like this:
>
> if (likely(!P_ISDELETED(opaque) &&
>opaque->btpo_next == lastcurrblkno))
>
Hannu Krosing writes:
> Here is the latest patch with documentation only for the utility
> itself. Old general discussion moved to PostgreSQL Wiki with link to
> it in "See Also " section
Thanks for continuing to work on this!
> Also added a flag to select number of direct values to show
Hmm ..
On 27/6/2025 12:01, Andrei Lepikhov wrote:
On 6/2/2024 13:51, Ashutosh Bapat wrote:
On Fri, Dec 15, 2023 at 5:22 AM Ashutosh Bapat
wrote:
First patch is no longer required. Here's rebased set
The patches are raw. make check has some crashes that I need to fix. I
am waiting to hear whether this
On Thu, Jul 3, 2025 at 11:54 AM Tom Lane wrote:
> I hadn't noticed (or maybe I forgot) this thread, so when the
> same problem was reported at [1] I just went ahead and pushed the
> submitted patch, which is only cosmetically different from your 0001.
> Apologies for treading on your toes.
No wor
On Mon, Jul 7, 2025 at 5:41 AM Nazir Bilal Yavuz wrote:
> It seems CFBot is using these patches [1], resharing actual patch [2]
> with the hopes that it will be used by CFBot.
Whoops, thanks for reposting that. I plan to get this pushed today so
that it doesn't start blocking the Meson work.
--J
I'm working on adding test coverage to _bt_lock_and_validate_left,
which was enhanced by Postgres 18 commit 1bd4bc85ca. In particular,
coverage of its unhappy path: the path where multiple concurrent page
splits necessitate that the scan (which generally moves to the left)
moves to the right multip
John Naylor writes:
> I see that now. If extensions follow the practice of including system
> headers before Postgres headers, it should be fine. I've attached v2
> which removes the useless #undef and drafts an explanatory commit
> message.
Works for me.
regards, tom lan
On Mon, Jul 7, 2025 at 12:29 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Sawada-san,
>
> > What does each duration mean in these results? Can we interpret the
> > test case of max_conflict_retention_duration=120s that when 7 clients
> > and 15 clients are working on the publisher and the subscriber
On Mon, Jul 7, 2025 at 6:02 PM Noah Misch wrote:
> In your test, just detach the injection point while the backend under test is
> waiting at the injection point. All of
> src/test/modules/injection_points/specs/*.spec use that technique.
That appears to work (without the kludge I added to nbtse
On 7/7/25 16:51, Cédric Villemain wrote:
>>> * Others might use it to integrate PostgreSQL's own resources (e.g.,
>>> "areas" of shared buffers) into policies.
>>>
>>> Hope this perspective is helpful.
>>
>> Can you explain how you want to manage this by an extension defined at
>> the SQL level, wh
On 2025-07-07 Mo 12:01 PM, Tom Lane wrote:
Peter Eisentraut writes:
On 07.07.25 16:13, Tom Lane wrote:
Huh. Can we trawl the release notes for VS and see if this was
acknowledged as a bug fix, and if so when did it happen?
But this one [0] seems to indicate you might need at least 16.5 for
Peter Eisentraut writes:
> On 07.07.25 16:13, Tom Lane wrote:
>> Huh. Can we trawl the release notes for VS and see if this was
>> acknowledged as a bug fix, and if so when did it happen?
> But this one [0] seems to indicate you might need at least 16.5 for this.
Ah, that says
Starting in
After the changes introduced by Michael Paquier (commited as
732061150b004385810e522f8629f5bf91d977b7) I had to rebase my patches. Among
other things pg_xml_error_occurred() was already called except after
xsltSaveResultToString(). From what I understand, it's not really necessary
to mangle the enc
On 2025-Jul-07, Álvaro Herrera wrote:
> I think this should work, but I'm going to run against each of these
> versions to verify it before pushing.
Seems to work okay, so pushed. Crake will tell us if something's still
amiss.
--
Álvaro HerreraBreisgau, Deutschland — https://www.Ente
Hi,
It seems that not all parameters passed by pointer to static functions
defined in src/backend/utils/adt/jsonb_util.c are actually modified by
these functions. I propose a simple patch that adds const modifiers to
such parameters to make it clear that their values remain intact during
th
On Mon, 7 Jul 2025 at 11:38, Jim Jones wrote:
>
> I'm wondering if the current behaviour with DEFAULT columns should be
> mentioned in the docs.
Hmm, perhaps. On the INSERT page, under "conflict_action", we currently say
Note that the effects of all per-row BEFORE INSERT triggers are
ref
Dilip Kumar writes:
>> IMHO we can just query the 'max_slot_wal_keep_size' after
>> start_postmaster() and check what is the final resultant value. So now
>> we will only throw an error if the final value is not -1. And we can
>> remove the hook from the server all together. Thoughts?
> I coul
On 07.07.25 19:52, Dean Rasheed wrote:
> perhaps that should say
>
> Note that any values that were supplied by defaults, as well as
> the effects of all per-row BEFORE INSERT triggers are reflected
> in excluded values, since that may have contributed to the row
> being excluded
On Sat, 5 Jul 2025 at 08:32, Vik Fearing wrote:
>
> On 30/06/2025 17:04, jian he wrote:
>
> reasons for adding array_random is:
> 1. This is better than array_fill. This can fill random and constant
> values (random, min and max the same).
> 2. Building a multi-dimensional PL/pgSQL function equiv
On Fri, Jul 4, 2025 at 3:53 PM vignesh C wrote:
>
> On Tue, 1 Jul 2025 at 15:20, shveta malik wrote:
> > On Mon, Jun 30, 2025 at 3:21 PM Nisha Moond
> > wrote:
> > >
> > > Please find the attached v20250630 patch set addressing above comments
> > > and other comments in [1],[2],[3] and [4].
> >
On Tue, 2025-07-01 at 08:06 -0700, Jeff Davis wrote:
> Attached rebased v3.
And here's v4.
I changed the global variable to only hold the LC_CTYPE (not
LC_COLLATE), because windows doesn't support a _locale_t that
represents multiple categories with different locales.
This patch series is design
Tender Wang 于2025年7月3日周四 17:48写道：
>
>
> Andrei Lepikhov 于2025年7月3日周四 17:23写道：
>
>> On 3/7/2025 04:02, Tender Wang wrote:
>> >
>> >
>> > Andrei Lepikhov mailto:lepi...@gmail.com>> 于2025年7
>> > 月2日周三 22:29写道：
>> >
>> > On 30/6/2025 04:38, Tender Wang wrote:
>> > > Do you think it's wo
Hi,
On Tue, Jul 08, 2025 at 09:36:53AM +0900, Michael Paquier wrote:
> On Mon, Jul 07, 2025 at 03:07:12PM +, Bertrand Drouvot wrote:
>
> > I think the question is: if the extension owner does not increment it, do
> > we want
> > to do it in core on their behalf? I'm not sure as it's still up
There is well known Postgres problem that logical replication subscriber
can not caught-up with publisher just because LR changes are applied by
single worker and at publisher changes are made by
multiple concurrent backends. The problem is not logical replication
specific: physical replication
Dilip Kumar writes:
> On Fri, Jul 4, 2025 at 9:56 PM Tom Lane wrote:
>> So on the whole it seems like a research project requiring nontrivial
>> effort and probably yielding only marginal gains. It's certainly not
>> going to yield a back-patchable fix for this performance regression.
> Yeah th
Hi,
Thanks for the review.
On Sun, Jul 6, 2025 at 7:12 PM wenhui qiu wrote:
>
> Hi
> > Thanks, LGTM.
> I think it's possible to register to https://commitfest.postgresql.org/54,
> https://commitfest.postgresql.org/53 will closed soon
>
I've created the commitfest entry here:
https://commitfest
On Sat, May 24, 2025 at 7:29 AM Tomas Vondra wrote:
>
> Hello Iwata-san,
>
...
> autovacuum.c
> --
> - Why does this need a custom autovacuum launcher, or what's the purpose
> of this code? is there a special autovacuum launcher for VCI indexes?
>
> - Again, explicit references to
> I wrote:
>> Fujii Masao writes:
>>> Or GUC ignore_system_indexes also should be treated in the same way
>>> as transaction_timeout?
>
>> Yes, I'd say we ought to mark that GUC as don't-accept-in-bootstrap
>> too. I've not done any research about what other GUCs can break
>> initdb, but now I
On Mon, Jul 7, 2025 at 7:43 PM Michael Paquier wrote:
> That's a property that Noah was looking after when he's worked on his
> specs with the VACUUM/GRANT frictions, something that one would get
> with a debugger: keep waiting and allow the point to be detached in
> parallel.
I'm finding that th
Hi,
On 2025-07-04 13:05:05 +0200, Jakub Wartak wrote:
> On Tue, Jul 1, 2025 at 9:07 PM Tomas Vondra wrote:
> > I don't think the splitting would actually make some things simpler, or
> > maybe more flexible - in particular, it'd allow us to enable huge pages
> > only for some regions (like shared
On Mon, Jul 07, 2025 at 08:00:01AM +0300, Alexander Lakhin wrote:
> I'm sorry for not being accurate enough -- I forgot to mention that I
> replicated the config from culicidae, and now I see that "fsync=on"
> is needed to reproduce the failure for me (though maybe).
Even with that, the situation
On Mon, Jul 07, 2025 at 03:07:12PM +, Bertrand Drouvot wrote:
> On Mon, Jul 07, 2025 at 02:56:29PM +0900, Michael Paquier wrote:
>> On Mon, Jun 30, 2025 at 01:36:12PM +, Bertrand Drouvot wrote:
>
> Yeah, I think that this is needed for the custom wait events. But do we need
> to handle the
Vik Fearing writes:
> Having read through this thread, is there any chance at all that we
> might be able to implement feature F555, “Enhanced seconds precision”?
Don't see how we could do that without an on-disk compatibility break
for timestamps. Also, AFAICS there's no way to stuff nanosecon
On Mon, Jul 07, 2025 at 09:40:20PM -0400, Peter Geoghegan wrote:
> I'm finding that the FreeBSD Meson CI target consistently fails with
> this setup, though. And with just about any variant I can think of;
> seems to fail quite reliably. The initial SELECT backwards scan
> statement will complete w
Hi,
On 2025-06-30 12:27:10 -0400, Andres Freund wrote:
> On 2025-06-05 14:32:10 -0400, Andres Freund wrote:
> > On 2025-06-05 12:47:52 -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > > I think this is a big enough pitfall that it's, obviously assuming the
> > > > patch
> > > > has a sen
Hi,
> If I understand correctly, we only need to check the specific bit
> to determine whether a hash element needs relocation:
>
> diff --git a/src/backend/utils/hash/dynahash.c
> b/src/backend/utils/hash/dynahash.c
> index 1ad155d446e..32fbae71995 100644
> --- a/src/backend/utils/hash/dynahash
On Wed, 2025-06-11 at 12:15 -0700, Jeff Davis wrote:
> > v1-0008-Set-process-LC_COLLATE-C-and-LC_CTYPE-C.patch
> >
> > As I mentioned earlier in the thread, I don't think we can do this
> > for
> > LC_CTYPE, because otherwise system error messages would not come
> > out
> > in
> > the right enco
1 - 100 of 101 matches
Mail list logo
