Hi Dilip,
Sorry for the late reply.
On Thu, Jul 3, 2025 at 1:24 PM Dilip Kumar wrote:
>
> On Wed, Jul 2, 2025 at 7:18 PM Amit Langote wrote:
>
> > Just to clarify -- I was hoping that, at least for SELECTs, we
> > wouldn’t need to lock all leaf partitions up front.
> >
> > One of the potential
On Fri, Jul 11, 2025 at 1:46 PM shveta malik wrote:
>
> Thank You for working on this. I started going through the README and
> tried running simple tests, have few concerns:
>
> 1)
> I am not able to understand section 4.2 'WOS-to-ROS conversion'. When
> whiteout-WOS says 'delete 4', what does th
On Thu, Jul 10, 2025 at 9:34 PM jian he wrote:
>
> --
> in jsonb_subscript_make_jsonpath we have
> foreach(lc, *indirection)
> {
> if (IsA(accessor, String))
>
> else if (IsA(accessor, A_Indices))
> else
>
On Fri, Jul 11, 2025 at 9:34 AM Zhang Mingli wrote:
>
> On Jul 11, 2025 at 11:36 +0800, Dilip Kumar , wrote:
>
>
> This seems to be quite useful to me, initially I thought if we can
> print the relation and database name then this could be even better
> but it might be a bad idea to fetch the obje
Hi,
On Jul 11, 2025 at 11:36 +0800, Dilip Kumar , wrote:
>
> This seems to be quite useful to me, initially I thought if we can
> print the relation and database name then this could be even better
> but it might be a bad idea to fetch the object name while we are in
> error callback.
May be conf
Amit Kapila writes:
> Thanks for the patch and verification. It looks good to me as well.
> Shall we commit this today or wait for beta2 as per email by Tom [1]?
> We are on the borderline to see that most of the BF members have run
> with this, but as the change is straightforward, I think we can
Thank You for working on this. I started going through the README and
tried running simple tests, have few concerns:
1)
I am not able to understand section 4.2 'WOS-to-ROS conversion'. When
whiteout-WOS says 'delete 4', what does that mean? 4 is CRID, TXID?
And when does delete-vector X represents
On Fri, Jul 11, 2025 at 8:03 AM vignesh C wrote:
>
> On Thu, 10 Jul 2025 at 11:47, Dilip Kumar wrote:
> >
> > >
> > PFA, patch for v17.
>
> Thanks for working on this, I don't have any more comments.
>
Thanks for the patch and verification. It looks good to me as well.
Shall we commit this today
On Thu, Jul 10, 2025 at 10:36 PM Tom Lane wrote:
>
> I noted a complaint [1] about how hard it is to debug unforeseen
> lock-timeout failures: we give no details about what we were
> waiting for. It's not hard to improve that situation, at least
> to the extent of printing numeric locktag details
Hi,
On Jul 11, 2025 at 10:53 +0800, Tom Lane , wrote:
> Zhang Mingli writes:
> > Do we need to rollback error_context_stack to the previous state if we
> > enter the branch for PG_CATCH()?
>
> No. The PG_TRY mechanism itself deals with that: the next outer
> level of PG_TRY will restore error_co
On Thu, Jul 10, 2025 at 9:33 PM Nathan Bossart wrote:
>
> Thanks all for the feedback. Here is an updated patch set.
>
Thanks now, looks good to me. Additionally IMHO it would be good to
add tests with FLUSH_UNLOGGED TRUE and FLUSH_UNLOGGED FALSE as well, I
have added a simple 2 test for the sam
Zhang Mingli writes:
> Do we need to rollback error_context_stack to the previous state if we enter
> the branch for PG_CATCH()?
No. The PG_TRY mechanism itself deals with that: the next outer
level of PG_TRY will restore error_context_stack to what it had
been. If this were not so, most other
Hi,
On Jul 11, 2025 at 01:06 +0800, Tom Lane , wrote:
> I noted a complaint [1] about how hard it is to debug unforeseen
> lock-timeout failures: we give no details about what we were
> waiting for. It's not hard to improve that situation, at least
> to the extent of printing numeric locktag detai
On Thu, 10 Jul 2025 at 11:47, Dilip Kumar wrote:
>
> On Thu, Jul 10, 2025 at 11:18 AM Dilip Kumar wrote:
> >
> > On Thu, Jul 10, 2025 at 11:11 AM vignesh C wrote:
> > >
> > > On Wed, 9 Jul 2025 at 17:47, Dilip Kumar wrote:
> > > >
> > > > On Wed, Jul 9, 2025 at 5:29 PM Álvaro Herrera
> > > >
On Fri, Jul 11, 2025 at 5:55 AM Andres Freund wrote:
> On 2025-07-10 17:28:50 +0900, Amit Langote wrote:
> > On Thu, Jul 10, 2025 at 8:34 AM Andres Freund wrote:
> > > The performance gain unsurprisingly isn't significant (but seems
> > > repeatably
> > > measureable), but it does cut out a fair
> On Thu, 3 Jul 2025 at 04:11, Tatsuo Ishii wrote:
>> After thinking more, I reached a conclusion it would better to apply
>> attached simple patch to v18 since v18 is already in the beta phase
>> and we want to make changes to it minimal.
>
> I thought that clarifying docs was exactly one of the
On 2025/07/11 2:57, Jeff Davis wrote:
On Wed, 2025-06-25 at 08:18 +0900, Fujii Masao wrote:
For pg_dump and pg_dumpall, I agree with Jeff's idea in [1],
but if the statistics is skipped by default, I don't think
we need a --no-statistics option. So, here's how I think
the options should work:
Greetings!
LISTEN/NOTIFY has known performance issues that aren't documented but
regularly surprise users in production – my customers and I encountered
some of them multiple times.
They were also discussed in the past, e.g.,:
- 2008: https://www.postgresql.org/message-id/5215.1204048...@sss.pgh.
On Fri, Jul 11, 2025 at 6:22 AM Jeff Davis wrote:
> I don't have a great windows development environment, and it appears CI
> and the buildfarm don't offer great coverage either. Can I ask for a
> volunteer to do the windows side of this work?
Me neither but I'm willing to help with that, and hav
On Fri, Jul 11, 2025 at 6:33 AM Jeff Davis wrote:
> On Thu, 2025-07-10 at 12:01 +1200, Thomas Munro wrote:
> > I tried to make a portable PG_C_LOCALE mechanism like that, but it
> > was
> > reverted for reasons needing more investigation... see
> > 8e993bff5326b00ced137c837fce7cd1e0ecae14 (reverte
On Jul 10, 2025, at 18:40, David E. Wheeler wrote:
> Resolved in the attached, which now passes `make check-world` for me.
>
> Also available as a pull request[1].
Now with the `ISO C90 forbids mixed declarations and code` warning cleared up.
Weird that there’s a failure on Bookworm with Meson
On Wed, Jul 9, 2025 at 10:24 PM Noah Misch wrote:
> Looking at .cirrus.tasks.yml, I bet the key factor is that CI task using
> debug_parallel_query=regress. I bet the leader is attached to the injection
> point, but the WARNING is reached in a parallel worker.
Yep, that was it.
> If that matche
On Fri, Jul 11, 2025 at 5:39 AM Dimitrios Apostolou wrote:
> > I applied the patch on PostgreSQL v17 and am testing it now. I chose
> > ftruncate method and I see ftruncate in action using strace while doing
> > pg_restore of a big database. Nothing unexpected has happened so far. I also
> > verif
On Jul 10, 2025, at 14:13, David E. Wheeler wrote:
> Oh, is that what’s happening? What needs to happen to properly support
> pg_upgrade?
Turns out there was an assertion failure that David Johnson spotted in the core
dump of the test output and then in the regress log. Turns out I wasn’t usin
> On 10 Jul 2025, at 19:12, Jacob Champion
> wrote:
> On Thu, Jul 10, 2025 at 2:59 AM Nazir Bilal Yavuz wrote:
>> so it would be easier to catch if
>> one of the features is disabled without anyone noticing.
>
> Seems reasonable.
Agreed.
> If we do this, can we rename the job with a "- Meson
On Thu, Jul 10, 2025 at 06:05:26PM +0530, Nitin Motiani wrote:
> - * pg_largeobject_metadata, after the dump is restored.
> + * pg_largeobject_metadata, after the dump is restored. In
> versions
> + * before v12, this is done via proper large object commands
Thanks for the feedback!
> > Attached is a proof of concept that does not alter the
> > LWLockRegisterTranche API. Instead, it detects when a registration is
> > performed by a normal backend and stores the tranche name in shared memory,
> > using a dshash keyed by tranche ID. Tranche name lookup
Hi,
On 2025-07-10 16:24:08 +0200, Benjamin Coutu wrote:
> I noticed that Andres recently introduced pg_assume into the codebase -
> great addition!
>
> That got me thinking: some projects (like PHP) map the ASSERT macro to
> ASSUME in non-assert builds. The rationale is that ASSERT typically
> exp
On Jul 10, 2025, at 16:38, Florents Tselai wrote:
> Why isn’t this sufficient?
>
> static uint64
> pg_base64_encode_internal(const char *src, size_t len, char *dst, bool url)
> {
> const char *alphabet = url ? _base64url : _base64;
Ah, it is. I hadn’t got that far. I was tripped up to see this
Committed/back-patched.
--
nathan
Hi,
On 2025-07-10 17:28:50 +0900, Amit Langote wrote:
> On Thu, Jul 10, 2025 at 8:34 AM Andres Freund wrote:
> > On 2025-01-22 10:07:51 +0900, Amit Langote wrote:
> > > On Fri, Jan 17, 2025 at 2:05 PM Amit Langote
> > > wrote:
> > > > Here's v5 with a few commit message tweaks.
> > > >
> > > >
We've been kind of drifting along without a specific plan for
when to put out a second beta for v18. The -packagers list
started to complain about the lack of one, since there have
been catalog changes since beta1 and the discrepancies are
problematic for some folks. Hence, we'll do 18beta2 next
> On 10 Jul 2025, at 10:07 PM, David E. Wheeler wrote:
>
> Hi Florents,
>
> On Jul 9, 2025, at 23:25, Florents Tselai wrote:
>
>>> I reviewed and tested v4. To me it looks as good as it will get.
>>> Personally I would change a few minor things here and there and
>>> probably merge all three
Hi,
On 2025-07-10 21:00:21 +0200, Matthias van de Meent wrote:
> On Wed, 9 Jul 2025 at 16:59, Andres Freund wrote:
> > > 3. I noticed that there is AIO code for writev-related operations
> > > (specifically, pgaio_io_start_writev is exposed, as is
> > > PGAIO_OP_WRITEV), but no practical way to e
On Thu, 10 Jul 2025 at 15:06, Dean Rasheed wrote:
>
> > Yes, perhaps we should convert src/tools/testint128.c into a new test
> > extension, src/test/modules/test_int128
>
> Here's an update doing that (in 0001). 0002-0005 are unchanged.
v3 attached, fixing a couple of issues revealed by the cfbo
Hi Florents,
On Jul 9, 2025, at 23:25, Florents Tselai wrote:
>> I reviewed and tested v4. To me it looks as good as it will get.
>> Personally I would change a few minor things here and there and
>> probably merge all three patches into a single commit. This however is
>> up to the committer to
On Wed, 9 Jul 2025 at 16:59, Andres Freund wrote:
>
> Hi,
>
> On 2025-07-09 13:26:09 +0200, Matthias van de Meent wrote:
> > I've been going through the new AIO code as an effort to rebase and
> > adapt Neon to PG18. In doing so, I found the following
> > items/curiosities:
> >
> > 1. In aio/READM
On Thu, 2025-07-10 at 12:01 +1200, Thomas Munro wrote:
> I tried to make a portable PG_C_LOCALE mechanism like that, but it
> was
> reverted for reasons needing more investigation... see
> 8e993bff5326b00ced137c837fce7cd1e0ecae14 (reverted by
> 3c8e463b0d885e0d976f6a13a1fb78187b25c86f).
The revert
On Thu, 2025-07-10 at 11:53 +1200, Thomas Munro wrote:
> On Thu, Jul 10, 2025 at 10:52 AM Jeff Davis
> wrote:
> > The first problem -- how to affect the encoding of strings returned
> > by
> > strerror() on windows -- may be solvable as well. It looks like
> > LC_MESSAGES is not supported at all o
Richard Guo writes:
> I'm just skimming through the changes and happened to spot two minor
> things.
> In 0008:
> if (pq_mq_handle != NULL)
> + {
> shm_mq_detach(pq_mq_handle);
> + pfree(pq_mq_handle);
> + }
> pq_mq_handle = NULL;
> Maybe we could
On Jul 10, 2025, at 13:41, Florents Tselai wrote:
> The basic problem I see with these latest revisions/refactorings is that they
> fail for pg_upgrade afaict.
> Probably this means that some of the rearrangements on the parser/scanner are
> not that flexible.
Oh, is that what’s happening? Wha
On 2025-07-09 We 4:51 PM, Andres Freund wrote:
Hi,
On 2025-07-09 16:10:25 -0400, Tom Lane wrote:
Andrew Dunstan writes:
/*
To turn off/hide the contents of this file:
#define
MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS 0
*/
I don't think we ha
On Wed, 2025-06-25 at 08:18 +0900, Fujii Masao wrote:
> For pg_dump and pg_dumpall, I agree with Jeff's idea in [1],
> but if the statistics is skipped by default, I don't think
> we need a --no-statistics option. So, here's how I think
> the options should work:
>
> * Keep: --schema-only, --
On Wed, 2025-06-18 at 10:21 -0700, Jeff Davis wrote:
> * reject the combination of an "only" option and a "with" option
There seems to be a rough consensus on this point. Should we move ahead
with this small change and see if we can get consensus to go further?
Regards,
Jeff Davis
> On 14 Jun 2025, at 6:08 PM, David E. Wheeler wrote:
>
> On Jun 4, 2025, at 11:27, David E. Wheeler wrote:
>
>> And these should fix the CI failure. I also ran pgindent.
>
> Here’s a quick rebase. I think it’s ready for committer review, but since
> I’ve poked at it quite a bit myself, I
On Thu, 12 Jun 2025, Dimitrios Apostolou wrote:
On Mon, 9 Jun 2025, Thomas Munro wrote:
On Tue, Jun 3, 2025 at 1:58 AM Dimitrios Apostolou wrote:
This sounds like the best solution IMO. People can then experiment with
different settings and filesystems, and that way we also learn in the
Nathan Bossart writes:
> On Thu, Jul 10, 2025 at 06:05:26PM +0530, Nitin Motiani wrote:
>> I looked through the history of this to see how this happened and if it
>> could be an existing issue. Prior to a45c78e3284b, dumpLO used to put large
>> objects in SECTION_PRE_DATA. That commit changed dump
(moving to a new thread)
On Thu, Jul 10, 2025 at 06:05:26PM +0530, Nitin Motiani wrote:
>> There might be an existing issue here, because dbObjectTypePriorities
>> has the following comment:
>>
>> * NOTE: object-type priorities must match the section assignments made in
>> * pg_dump.c; that is, PR
On Thu, Jul 10, 2025 at 2:59 AM Nazir Bilal Yavuz wrote:
> Andres off-list mentioned that if we explicitly enable features for
> *all* of the tasks, then none of the tasks will be testing the auto
> feature option and I agree with Andres. My suggestion is setting
> features to auto for Debian - Me
I noted a complaint [1] about how hard it is to debug unforeseen
lock-timeout failures: we give no details about what we were
waiting for. It's not hard to improve that situation, at least
to the extent of printing numeric locktag details similar to what
you get in deadlock reports. (It'd be nice
Hi Andrew, Thanks for looking into this.
Attached are the log files, regress_log_001_password and
001_password_primary.log
This is the error I see in the regress_log_001_password file.
server started
# Postmaster PID for node "primary" is 15663422
[22:28:33.832](1.867s) ok 1
Thanks all for the feedback. Here is an updated patch set.
--
nathan
>From d862592acfb6470e34da9e993ff942c48cbf4e2f Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 9 Jul 2025 10:05:10 -0500
Subject: [PATCH v9 1/5] Rename CHECKPOINT_FLUSH_ALL to
CHECKPOINT_FLUSH_UNLOGGED.
The new name
On 7/9/2025 3:56 PM, Yura Sokolov wrote:
30.05.2025 14:30, Zhou, Zhiguo пишет:
Hi Hackers,
I am reaching out to solicit your insights and comments on this patch
addressing a significant performance bottleneck in LWLock acquisition
observed on high-core-count systems. During performance analy
Benjamin Coutu writes:
> That got me thinking: some projects (like PHP) map the ASSERT macro to ASSUME
> in non-assert builds. The rationale is that ASSERT typically expresses a
> tautology, something the programmer believes to be always true. So in builds
> where assertions are compiled out, w
On 7/9/25 19:23, Andres Freund wrote:
> Hi,
>
> On 2025-07-09 12:55:51 -0400, Greg Burd wrote:
>> On Jul 9 2025, at 12:35 pm, Andres Freund wrote:
>>
>>> FWIW, I've started to wonder if we shouldn't just get rid of the freelist
>>> entirely. While clocksweep is perhaps minutely slower in a sin
On 7/9/25 08:40, Cédric Villemain wrote:
>> On 7/8/25 18:06, Cédric Villemain wrote:
>>>
>>>
>>>
>>>
>>>
>>>
On 7/8/25 03:55, Cédric Villemain wrote:
> Hi Andres,
>
>> Hi,
>>
>> On 2025-07-05 07:09:00 +, Cédric Villemain wrote:
>>> In my work on more careful Post
On Thu, Jul 10, 2025 at 22:20 Amit Langote wrote:
> Fujita-san,
>
> On Wed, Jul 9, 2025 at 5:07 PM Etsuro Fujita
> wrote:
> > On Tue, Jul 1, 2025 at 11:55 AM Etsuro Fujita
> wrote:
> > > So I would
> > > like to propose to fix this by the following: 1) disable using direct
> > > modify to modif
I agree with the patch. Works in my OSes
On 7/10/25 2:54 AM, Jacob Champion wrote:
On Wed, Jul 9, 2025 at 12:42 PM Tom Lane wrote:
> Nah, let's keep them. We do document for at least some libraries
> how to manually specify the include and link options without
> depending on pkg-config. If
On Thu, Jul 10, 2025 at 9:57 AM Melanie Plageman
wrote:
> A direct translation of this would be to add a boolean parameter to
> visibilitymap_set() like "heap_page_modified" or "set_heap_lsn". Is
> that along the lines you were thinking?
Yeah, something like that. I haven't thought through the de
Hello, everyone!
Added patch to the offer book of review marketplace [0].
Best regards,
Mikhail.
[0]: https://wiki.postgresql.org/wiki/Review_Marketplace#Offer_book
Hello,
I noticed that Andres recently introduced pg_assume into the codebase - great
addition!
That got me thinking: some projects (like PHP) map the ASSERT macro to ASSUME
in non-assert builds. The rationale is that ASSERT typically expresses a
tautology, something the programmer believes to
Hi,
On Wed, Jul 09, 2025 at 03:42:26PM -0400, Andres Freund wrote:
> Hi,
>
> Thanks for working on this!
Indeed, thanks!
> On 2025-07-01 21:07:00 +0200, Tomas Vondra wrote:
> > 1) v1-0001-NUMA-interleaving-buffers.patch
> >
> > This is the main thing when people think about NUMA - making sure t
On Wed, 9 Jul 2025 at 22:31, Dean Rasheed wrote:
>
> On Wed, 9 Jul 2025 at 18:27, Andres Freund wrote:
> >
> > I think we should wire this up to the buildsystem and our testsuite...
> > Having
> > testcode that is not run automatically may be helpful while originally
> > developing something, b
On Mon, Jul 7, 2025 at 11:38 AM Robert Haas wrote:
>
> On Wed, Jul 2, 2025 at 7:33 PM Melanie Plageman
> wrote:
>
> > One thing we could do is check if the heap buffer is dirty before
> > setting the LSN in visibilitymap_set():
>
> I don't think this is the way. visibilitymap_set() shouldn't gues
On Thu, Jul 10, 2025 at 4:53 PM jian he wrote:
>
> src7=# select ('{"a": 1, "b": "c", "d": [1, 2, 3]}'::jsonb).d['1'::int8];
> WARNING: mixed usage of jsonb simplified accessor syntax and jsonb
> subscripting.
> LINE 1: ...t ('{"a": 1, "b": "c", "d": [1, 2, 3]}'::jsonb).d['1'::int8]...
>
Fujita-san,
On Wed, Jul 9, 2025 at 5:07 PM Etsuro Fujita wrote:
> On Tue, Jul 1, 2025 at 11:55 AM Etsuro Fujita wrote:
> > So I would
> > like to propose to fix this by the following: 1) disable using direct
> > modify to modify foreign-table partitions if there are any
> > transition-table trig
On Wed, Jul 9, 2025 at 9:09 PM Amit Kapila wrote:
>
> On Tue, Jul 8, 2025 at 12:18 AM Masahiko Sawada wrote:
> >
> > On Mon, Jul 7, 2025 at 12:03 PM Zhijie Hou (Fujitsu)
> > wrote:
> >
> > I think these performance regressions occur because at some point the
> > subscriber can no longer keep up
On Wednesday, July 9, 2025, sundayjiang(蒋浩天)
wrote:
>
>
> - When creating a function, if it is declared as IMMUTABLE but
> directly calls a non-IMMUTABLE function, the creation should be rejected.
>
This patch is not going to be accepted in core. In short, your desire to
have the server enfo
Dear hackers,
> -- Also, worker and logical replication related parameters were increased
>as needed (see attached scripts for details).
Sorry, I forgot to attach scripts.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
row_filter_measure.sh
Description: row_filter_measure.sh
row_fi
Dear hackers,
> As per the above observations, it is less of a regression of this
> feature but more of a lack of parallel apply or some kind of pre-fetch
> for apply, as is recently proposed [1]. I feel there are use cases, as
> explained above, for which this feature would work without any
> dow
Hi,
I have a couple of comments/questions.
> There might be an existing issue
> here, because dbObjectTypePriorities has the following comment:
>
> * NOTE: object-type priorities must match the section assignments made in
> * pg_dump.c; that is, PRE_DATA objects must sort before
DO_PRE_DATA_BOUN
> On Jul 9, 2025, at 1:23 PM, Andres Freund wrote:
>
> Hi,
>
> On 2025-07-09 12:55:51 -0400, Greg Burd wrote:
>> On Jul 9 2025, at 12:35 pm, Andres Freund wrote:
>>
>>> FWIW, I've started to wonder if we shouldn't just get rid of the freelist
>>> entirely. While clocksweep is perhaps minute
On Thu, Jul 10, 2025 at 2:35 PM Amit Kapila wrote:
>
> On Thu, Jul 10, 2025 at 2:23 PM vignesh C wrote:
> >
> > Few comments:
> > 1) With the current approach invalidation will not happen for logical
> > replication slots during upgrade operation, I felt we could retain
> > this assertion just in
On Wed, Jul 9, 2025 at 4:11 PM vignesh C wrote:
>
> The attached v20250709 version patch has the changes for the same.
>
Thanks for the patches.
In Patch-004: sequencesync.c : I think below function logic can be simplified.
+void
+ProcessSyncingSequencesForApply(void)
+{
+ bool started_tx = fal
On Thu, Jul 10, 2025 at 8:49 AM Amit Kapila wrote:
>
> On Wed, Jul 9, 2025 at 6:50 PM Ashutosh Bapat
> wrote:
> >
> > On Wed, Jul 9, 2025 at 8:30 AM shveta malik wrote:
> > > >
> > > > I have split your top up patch into 2 - one related to the document
> > > > change being the subject of this th
On Wed, Jul 9, 2025 at 9:42 PM Andres Freund wrote:
> On 2025-07-01 21:07:00 +0200, Tomas Vondra wrote:
> > Each patch has a numa_ GUC, intended to enable/disable that part. This
> > is meant to make development easier, not as a final interface. I'm not
> > sure how exactly that should look. It's
On Wed, Jul 9, 2025 at 7:13 PM Andres Freund wrote:
> > Yes, and we are discussing if it is worth getting into smaller pages
> > for such usecases (e.g. 4kB ones without hugetlb with 2MB hugepages or
> > what more even more waste 1GB hugetlb if we dont request 2MB for some
> > small structs: btw,
Hi hackers,
The planner currently calls approx_tuple_count() to estimate
hashjointuples and mergejointuples. That makes sense when
joinrestrictinfo contains additional clauses beyond the hash/merge
equality list. But if all join restriction clauses are exactly those
hash/merge clauses, the es
Hi,
On Tue, 8 Jul 2025 at 12:10, Nazir Bilal Yavuz wrote:
>
> Hi,
>
> On Wed, 2 Jul 2025 at 10:22, Nazir Bilal Yavuz wrote:
> >
> > Also, libcurl is disabled in the OpenBSD CI task until the fix in this
> > thread [1] is committed.
>
> This fix is committed in 7376e60854 so libcurl is enabled fo
On Wed, 9 Jul 2025 23:58:32 +0900
Rintaro Ikeda wrote:
> Hi,
>
> Thank you for the kind comments.
>
> I've updated the previous patch.
Thank you for updating the patch!
> > However, if a large number of errors occur, this could result in a
> > significant increase
> > in stderr output during
On Thu, Jul 10, 2025 at 2:23 PM vignesh C wrote:
>
> Few comments:
> 1) With the current approach invalidation will not happen for logical
> replication slots during upgrade operation, I felt we could retain
> this assertion just in case in the future it gets called from
> elsewhere, do you feel t
On Wed, Jul 9, 2025 at 4:02 PM Alexandra Wang
wrote:
>
> Thanks again for the patch! It was really helpful! I didn't directly
> apply it as I made a few different choices, but I think I have
> addressed all the points you covered in it.
>
> Let me know your thoughts!
>
hi.
in v12-0001 and v12-00
On Thu, 10 Jul 2025 at 11:47, Dilip Kumar wrote:
>
> On Thu, Jul 10, 2025 at 11:18 AM Dilip Kumar wrote:
> >
> > On Thu, Jul 10, 2025 at 11:11 AM vignesh C wrote:
> > >
> > > On Wed, 9 Jul 2025 at 17:47, Dilip Kumar wrote:
> > > >
> > > > On Wed, Jul 9, 2025 at 5:29 PM Álvaro Herrera
> > > >
Hi,
On Wed, Jul 09, 2025 at 04:39:48PM -0500, Sami Imseih wrote:
> Hi,
>
> When querying pg_stat_activity, the function pgstat_get_wait_event is
> called, which internally uses GetLWLockIdentifier and GetLWTrancheName
> to map the LWLock to its tranche name. If the backend does not recognize
> th
On Thu, 10 Jul 2025 at 17:51, Peter Smith wrote:
> On Thu, Jul 10, 2025 at 4:07 PM Japin Li wrote:
> ...
>> I'm still trying to understand the patches.
>>
>> diff --git a/src/include/storage/itemptr.h b/src/include/storage/itemptr.h
>> index 74b87a9..d97d1c5 100644
>> --- a/src/include/storage/it
Hi Andres,
On Thu, Jul 10, 2025 at 8:34 AM Andres Freund wrote:
> On 2025-01-22 10:07:51 +0900, Amit Langote wrote:
> > On Fri, Jan 17, 2025 at 2:05 PM Amit Langote
> > wrote:
> > > Here's v5 with a few commit message tweaks.
> > >
> > > Barring objections, I would like to push this early next
Hi,
On Wed, Jul 09, 2025 at 11:19:00AM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-07-09 07:26:05 +, Bertrand Drouvot wrote:
> > On Tue, Jul 08, 2025 at 10:19:07PM -0400, Andres Freund wrote:
> > > On 2025-06-30 13:36:12 +, Bertrand Drouvot wrote:
>
> TBH, the more I think about this,
On 7/9/25 16:30, Frédéric Yhuel wrote:
On 7/9/25 16:06, Mihail Nikalayeu wrote:
Hello!
No, I think the comment is correct, it is about [0].
[0]: https://github.com/postgres/postgres/blob/
f5a987c0e5f6bbf0cc0420228dc57e7aae4d7e8f/src/backend/commands/
indexcmds.c#L4217
Aaahhh... yes, y
On Thu, Jul 10, 2025 at 4:07 PM Japin Li wrote:
...
> Thanks for updating the patch!
>
> I find another bug when using VCI index as following:
>
> 2025-07-10 12:17:15.087 CST [2027312] PANIC: unexpected index access method
> call : "vci_beginscan"
> 2025-07-10 12:17:15.087 CST [2027312] STATEMEN
> On 5 Jul 2025, at 10:56, Peter Eisentraut wrote:
> This patch version looks good to me.
Thanks for review, I'll get it committed shortly.
--
Daniel Gustafsson
Hi, I am using postgres version 15.5 along with debezium to do CDC using
logical replication slot after the initial snapshot of the db is complete.
Recently, observed a few cases where a record in a table showed up both via
snapshot as well as from the replication slot. (this was a insert dml)
91 matches
Mail list logo
