Hi,
On Tue, Jul 15, 2025 at 12:59:04PM +0530, Rahila Syed wrote:
> Hi,
>
> If a dshash table is used to store tranche names and IDs, where would the
> tranche name for this table
> be registered?
I guess it could be a new BuiltinTrancheId for this dsa but not sure what Nathan
and Sami have in mi
On Tue, 2025-07-15 at 17:34 -0700, Jeff Davis wrote:
> Currently, users who don't make any explicit choice about collation end
> up with primary key indexes that use a libc natural language collation.
> This default is exactly wrong: [...]
>
> So I think we need to do something. That could be bette
On Wed, 16 Jul 2025 at 01:39, Michael Paquier wrote:
>
> > create schema s1;
> > create table s1.t as select id from generate_series(1, 10) as id;
> > create schema s2;
> > create table s1.t as select id from generate_series(1, 100) as id;
>
> I suspect that you mean s2.t and not s1.t here.
>
On Mon, Jun 30, 2025 at 02:45:49PM +0300, Sami Imseih wrote:
> Only changes to the tests due to the revert of nested query
> tracking in f85f6ab051b
@@ -35,6 +36,7 @@ typedef struct QueryDesc
/* These fields are provided by CreateQueryDesc */
CmdType operation;
Hi Hackers,
I noticed that pg_createsubscriber sets recovery target params for
correct recovery before converting a physical replica to a logical
one but does not reset them afterward. It can lead to recovery
failures in certain scenarios.
For example, if recovery begins from a checkpoint where no
On Tue, Jul 15, 2025 at 10:37 PM Masahiko Sawada wrote:
>
> I've attached updated patches that implement the idea we've discussed.
> The patches still need to be polished but the implemented ideas seem
> good. Feedback is very welcome.
>
Thank You for the patches. I just tried my hands on ptach00
On Mon, Jul 14, 2025 at 10:03 AM vignesh C wrote:
>
> On Fri, 11 Jul 2025 at 14:26, shveta malik wrote:
> >
I have picked this up again for final review, started with 0001, I
think mostly 0001 looks good to me, except few comments
1.
+ lsn = PageGetLSN(page);
+ last_value = seq->last_value;
+ lo
Hi Michael,
On Tue, Jul 15, 2025 at 9:44 PM Michael Paquier wrote:
>
> I have no idea yet about the fate of the other TOAST patches I have
> proposed for this commit fest, but let's move on with this part of the
> refactoring by splitting the TOAST regression tests for LZ4 and pglz,
> with the ne
On Wed, Jun 11, 2025 at 11:42:02AM +0900, Michael Paquier wrote:
> The split of the tests is not completely clean as presented in your
> patch, though. Your patch only does a copy-paste of the original
> file. Some of the basic tests of compression.sql check the
> interactions between the use of
Currently the patch set include some regression test additions. I
wanted to expand the test coverage and ended up an idea: generate new
test cases from the existing window function regression test
(window.sql).
Attached "insert_ignore_nulls.sh" script reads window.sql and inserts
"ignore nulls" be
On Wed, Jul 16, 2025 at 2:24 AM vignesh C wrote:
>
> On Mon, 14 Jul 2025 at 21:36, Fujii Masao wrote:
> >
> >
> >
> > On 2025/04/15 13:37, vignesh C wrote:
> > > Hi,
> > >
> > > Currently, when a warning is emitted by the publisher, the
> > > corresponding log message does not include the log pre
Hi,
The v1-0002 in [1] will call ReportBackgroundWorkerExit() which will send
SIGUSR1 to 'bgw_notify_pid', but it may already exit in HandleChildCrash(), is
this ok?
[1]
https://commitfest.postgresql.org/patch/5844/
--
Regards,
ChangAo Chen
On Tue, Jul 15, 2025 at 2:24 PM vignesh C wrote:
>
> Couple of comments:
> 1) This change is not required:
> #include "utils/snapmgr.h"
> #include "utils/syscache.h"
> #include "utils/usercontext.h"
> +#include "utils/injection_point.h"
>
> 2) This can not only happen in error case but also in
On Wed, Jul 9, 2025 at 3:32 PM Richard Guo wrote:
> On Mon, Jun 30, 2025 at 4:26 PM Richard Guo wrote:
> > On Wed, May 28, 2025 at 6:28 PM Richard Guo wrote:
> > > This patchset does not apply anymore due to 2c0ed86d3. Here is a new
> > > rebase.
>
> > This patchset does not apply anymore, due
On 2025/05/21 16:27, Fujii Masao wrote:
On 2025/05/20 11:40, 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 inconven
On Tue, Jul 01, 2025 at 10:57:11AM +0300, Nazir Bilal Yavuz wrote:
> On Mon, 30 Jun 2025 at 18:01, Andres Freund wrote:
>> One thing I don't yet like is that I think we should report if the primary is
>> alive *before* reporting the diff and skipping reporting it if the primary
>> crashed. It's no
(The problem and possible solutions are not specific to primary keys,
but I'm focusing on PKs for the purposes of this email.)
Currently, users who don't make any explicit choice about collation end
up with primary key indexes that use a libc natural language collation.
This default is exactly wro
Hi Joel,
Thanks for sharing the patch.
I have a few questions based on a cursory first look.
> If a single listener is found, we signal only that backend.
> Otherwise, we fall back to the existing broadcast behavior.
The idea of not wanting to wake up all backends makes sense to me,
but I don’t
On Thu, Jul 10, 2025 at 12:21:03AM +0530, Mahendra Singh Thalor wrote:
> On Wed, 9 Jul 2025 at 02:58, Noah Misch wrote:
> > On Fri, Apr 04, 2025 at 04:11:05PM -0400, Andrew Dunstan wrote:
> > > Thanks. I have pushed these now with a few further small tweaks.
> >
> > This drops all databases:
> >
>
On Wed, Jul 16, 2025 at 08:06:44AM +0800, Junwang Zhao wrote:
> Sorry I didn't mention the reason why I think WITHOUT OIDS should be removed.
>
> WITHOUT OIDS has been a backward-compatible syntax for 6 years, so I
> think maybe not too many users use it nowadays. Besides, there are
> some hints i
On Wed, Jul 16, 2025 at 12:49 AM Nathan Bossart
wrote:
>
> On Tue, Jul 15, 2025 at 11:06:11PM +0800, Junwang Zhao wrote:
> > WITH OIDS was removed in v12, I'm wondering if we could remove the
> > WITHOUT OIDS support for v19.
>
> AFAICT this would produce less helpful error messages and might even
Hi hackers.
I happened to notice that many contrib module indexes do not implement
an aminsertcleanup function:
e.g. amroutine->aminsertcleanup = NULL;
But, unlike many of the other interface functions, the aminsertcleanup
does not say "/* can be NULL */" in the typedef struct IndexAmRoutine
[1].
On Tue, Jul 15, 2025 at 11:11 PM Tom Lane wrote:
>
> Junwang Zhao writes:
> > WITH OIDS was removed in v12, I'm wondering if we could remove the
> > WITHOUT OIDS support for v19.
>
> Why?
Sorry I didn't mention the reason why I think WITHOUT OIDS should be removed.
WITHOUT OIDS has been a backw
On Tue, Jul 15, 2025 at 7:52 PM Tom Lane wrote:
> I'm not sure how likely such scenarios are, but it doesn't seem
> zero-risk. And if we do hundreds of these, the odds of trouble
> will increase.
I agree that it's not zero-risk -- hardly anything ever is. Still
seems worth considering.
--
Pete
On Tue, Jul 15, 2025 at 11:38:09AM -0500, Nathan Bossart wrote:
> On Tue, Jul 15, 2025 at 12:05:07PM -0400, Shayon Mukherjee wrote:
>> Happy to move this to other thread, if it makes more sense, let me know.
>
> Yes, please.
+1 for moving the discussion to the autovacuum thread. Nathan has
propo
Peter Geoghegan writes:
> On Tue, Jul 15, 2025 at 7:27 PM Tom Lane wrote:
>> I'd be a bit worried about
>> creating a back-patching mine-field. But maybe these are all
>> in spots we're unlikely to touch?
> That seems like much less of a problem for a purely subtractive change
> such as this.
Hi,
While discussing the next steps for AIO writes in Postgres, Andres
suggested that a good starting point would be to begin evicting more
than one buffer at a time in some of the buffer access strategies that
perform writes. This would make it easier to later combine these
writes and, eventually
On Tue, Jul 15, 2025 at 04:48:05PM +0200, Alexander Kukushkin wrote:
> I totally understand the wish to make pg_stat_statements useful for
> workloads that create/drop a ton of temporary tables.
> However, when pursuing this goal we impacted other types of totally valid
> workloads when tables with
On Tue, Jul 15, 2025 at 7:27 PM Tom Lane wrote:
> There are a lot of them, for sure.
It's *very* common for switch statements to have a "can't happen"
elog(ERROR) as their default block. Many of these default blocks also
initialize related variables to placate the compiler.
> I'd be a bit worrie
Peter Geoghegan writes:
> It would be nice to eliminate all existing "keep compiler quiet"
> variable initializations that follow an elog/ereport with elevel >=
> ERROR. My guess is that we have several hundred.
There are a lot of them, for sure. I'd be a bit worried about
creating a back-patchi
On Tue, Jul 15, 2025 at 09:14:27AM +, Hayato Kuroda (Fujitsu) wrote:
> I put pg_logical_emit_message() after injection_points_wakeup(), but your
> patch
> puts it before. I verified even your patch can reproduce the issue, but is
> there
> a reason?
> (This is not a comment which must be fixe
On Tue, Jul 15, 2025 at 6:58 PM Tom Lane wrote:
> Good question. It's not very clear what set of compiler versions
> people are still using, but maybe it'd be okay to stop worrying
> about suppressing such warnings.
It would be nice to eliminate all existing "keep compiler quiet"
variable initia
Peter Geoghegan writes:
> In the past, it was often necessary to work around MSVC's inability to
> see that a block containing elog(ERROR) doesn't actually need to
> initialize variables that'll never actually be used in code that comes
> after that block. We still have many "keep compiler quiet"
>> On Mon, Jul 14, 2025 at 03:18:10PM +, Jack Ng wrote:
>> Just brain-storming here... would moving NBuffers to shared memory solve
>this specific issue? Though I'm pretty sure that would open up a new set of
>synchronization issues elsewhere, so I'm not sure if there's a net gain.
>
>It's in f
On Sat, Jul 12, 2025 at 1:55 PM Andres Freund wrote:
> I had played with using pg_assume here too, but I couldn't really convince
> myself that it's a good idea...
In the past, it was often necessary to work around MSVC's inability to
see that a block containing elog(ERROR) doesn't actually need
On Wed, Jul 2, 2025 at 4:12 PM Jacob Champion
wrote:
> I'll work on proving that code paths other than PQconsumeInput() are
> affected. If they are, I'll start a patch for pqReadData().
Here's one way for a server implementation to hang the client during
PQconnectPoll(): accept the SSLRequest and
On Wed, Jul 16, 2025 at 1:16 AM Michael Paquier wrote:
> On Wed, Jul 16, 2025 at 12:38:58AM +0300, Alexander Korotkov wrote:
> > I recently got notification this is in Open Items.
> > https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items
> > What is your opinion on this: do we need additional
On Wed, Jul 16, 2025 at 12:38:58AM +0300, Alexander Korotkov wrote:
> I recently got notification this is in Open Items.
> https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items
> What is your opinion on this: do we need additional hook, fair to
> leave this "as is" or another option?
I'm OK wi
On Tue, Jul 15, 2025 at 09:19:50PM +0300, Alexander Korotkov wrote:
> Thank you for your efforts on this subject. Actually, I was planning
> to work on pushing this after the release freeze ends for v18. I'd
> like to do this at least for tests as they were initially committed by
> me.
>
> Anywa
On Wed, Jun 4, 2025 at 11:52 PM Alexander Korotkov wrote:
> On Wed, Jun 4, 2025 at 6:15 PM Alexander Pyhalov
> wrote:
> > Alexander Korotkov писал(а) 2025-06-04 14:29:
> > > On Wed, Jan 29, 2025 at 11:59 AM Maxim Orlov wrote:
> > >>
> > >> One important note here. This patch will change cast beh
On Tue, Jul 15, 2025, at 22:56, Joel Jacobson wrote:
> On Tue, Jul 15, 2025, at 09:20, Joel Jacobson wrote:
>> On Sun, Jul 13, 2025, at 01:18, Tom Lane wrote:
>>> "Joel Jacobson" writes:
The attached proof-of-concept patch proposes a straightforward
optimization for the single-listener c
Hi, Mechael!
On Fri, Jun 27, 2025 at 3:55 PM Alexander Korotkov wrote:
> On Fri, Jun 27, 2025 at 3:26 AM Michael Paquier wrote:
> > On Thu, Jun 26, 2025 at 08:54:55AM +0200, Andrei Lepikhov wrote:
> > > Before diving into the pg_hint_plan code, I wonder why you don't have
> > > similar issues wi
On Tue, Jul 1, 2025 at 12:33 AM Jelte Fennema-Nio wrote:
> I think maybe we
> should show the search/filter bar by default, because I keep
> forgetting it exists and I continue to use regular Ctrl+F instead.
Hmm, I think I agree.
> I quite dislike the current topic system.
Me too. :)
> Unsurpr
On Tue, Jul 15, 2025 at 4:50 PM Mircea Cadariu wrote:
> As an experiment, I added an elog(WARNING,...) just above the main changed
> line in the patch, and then ran the tests (make installcheck). This resulted
> in lines logged next to some of the SELECT statements in the following files
> in s
On Tue, Jul 1, 2025 at 12:52 AM Daniel Gustafsson wrote:
>
> > On 1 Jul 2025, at 09:33, Jelte Fennema-Nio wrote:
>
> > I quite dislike the current topic system. Partially because it's
> > impossible to filter by a topic (like you can now do with tags), but
> > primarily because the actual availab
On Tue, Jul 15, 2025 at 2:04 PM Jelte Fennema-Nio wrote:
>
> On Mon, 30 Jun 2025 at 22:48, Jacob Champion
> wrote:
> > I would also like to request that CFMs be given the ability to add and
> > edit (but maybe not delete?) tags.
>
> This should be possible now.
Thanks! I've added "My First Patch
On Mon, 30 Jun 2025 at 22:48, Jacob Champion
wrote:
> I would also like to request that CFMs be given the ability to add and
> edit (but maybe not delete?) tags.
This should be possible now.
Hi,
On 07/07/2025 01:22, Peter Geoghegan wrote:
However, there's no reason why "ScanKeyData
notnullkeys[INDEX_MAX_KEYS]" needs to be an array at all. In practice,
_bt_first will only need a single temp notnullkeys ScanKeyData, since
there can never be more than a single deduced NOT NULL constrai
On Tue, Jul 15, 2025, at 09:20, Joel Jacobson wrote:
> On Sun, Jul 13, 2025, at 01:18, Tom Lane wrote:
>> "Joel Jacobson" writes:
>>> The attached proof-of-concept patch proposes a straightforward
>>> optimization for the single-listener case. It introduces a shared-memory
>>> hash table mapping (
On Tue, Jul 15, 2025 at 2:19 PM Peter Geoghegan wrote:
> * gistkillitems() correctly checks if the page's LSN has changed in
> the period between when we initially read the leaf page and the period
> when/after we accessed the heap. But (unlike nbtree), it fails to
> account for unlogged relations
On Wed, Jul 2, 2025 at 10:44 AM shihao zhong wrote:
> >> Actually, I think there's a problem with this approach...
>
> You're right. I forgot we can reset the table options. While we could
> use a placeholder and resolve it on-demand, that seems like too much
> work.
>
>
Hi all,
I started a conv
Hello
We have lists of backend types scattered through the tree. I found two
current ones, and Euler Taveira wants to add a couple more[1]. His
patch is actually blocked on not adding more, so this seems worth doing.
Bikeshedding welcome (for a limited time).
[1] https://postgr.es/m/313aa202-b5
On Sat, Jul 12, 2025 at 7:50 PM Peter Geoghegan wrote:
> Why wouldn't we want to relieve all AMs of that responsibility?
> Leaving it up to index AMs has resulted in subtle bugs [2][3], and
> AFAICT has no redeeming quality. If affected index AMs were *forced*
> to do *exactly* the same thing as e
Both hash and GiST indexes set LP_DEAD bits for kill_prior_tuple,
using an approach based on that of nbtree. hash gained this ability in
commit 6977b8b7f4, while GiST gained it in commit 013ebc0a7b.
gistkillitems() and _hash_kill_items() both have similar bugs:
* gistkillitems() correctly checks
Hi, Michael!
On Tue, Jul 15, 2025 at 6:31 AM Michael Paquier wrote:
> On Mon, Jun 30, 2025 at 05:51:51PM +0530, vignesh C wrote:
> > Thanks, Kuroda-san. I’ve prepared a similar test that doesn’t rely on
> > injection points. The issue reproduced consistently across all
> > branches up to PG13. Yo
On Tue, Jul 15, 2025 at 8:19 AM Shayon Mukherjee wrote:
> On Jun 23, 2025, at 10:14 AM, Robert Treat wrote:
> Glad to hear you are still interested, slightly disheartened by the
> general lack of concern around operational safety in this thread. I
> actually think what you have done covers a lot
On Mon, 14 Jul 2025 at 21:36, Fujii Masao wrote:
>
>
>
> On 2025/04/15 13:37, vignesh C wrote:
> > Hi,
> >
> > Currently, when a warning is emitted by the publisher, the
> > corresponding log message does not include the log prefix. This makes
> > it harder to correlate such messages with other lo
On Tue, Jul 15, 2025 at 12:06:00PM -0500, Sami Imseih wrote:
> On Tue, Jul 15, 2025 at 11:57 AM Nathan Bossart
> wrote:
>> I was imagining putting the array in one big DSA allocation instead of
>> carting around a pointer for each tranche name. (Sorry, I realize I am
>> hand-waving over some of t
On Tue, Jul 8, 2025 at 7:41 PM shveta malik wrote:
>
> On Sun, Jul 6, 2025 at 8:33 PM Masahiko Sawada wrote:
> >
> > On Thu, Jul 3, 2025 at 3:32 PM shveta malik wrote:
> > >
> > > On Wed, Jul 2, 2025 at 9:46 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Wed, Jun 18, 2025 at 1:07 PM shveta
On Tue, Jul 15, 2025 at 11:57 AM Nathan Bossart
wrote:
>
> On Tue, Jul 15, 2025 at 11:52:19AM -0500, Sami Imseih wrote:
> >> Another random thought: I worry that the dshash approach might be quite a
> >> bit slower, and IIUC we just need to map an integer to a string. Maybe we
> >> should just us
On Tue, Jul 15, 2025 at 11:52:19AM -0500, Sami Imseih wrote:
>> Another random thought: I worry that the dshash approach might be quite a
>> bit slower, and IIUC we just need to map an integer to a string. Maybe we
>> should just use a DSA for LWLockTrancheNames. IOW we'd leave it as a char**
>> b
> Another random thought: I worry that the dshash approach might be quite a
> bit slower, and IIUC we just need to map an integer to a string. Maybe we
> should just use a DSA for LWLockTrancheNames. IOW we'd leave it as a char**
> but put it in shared memory.
To use DSA just for this purpose, we
Hi,
On 2025-03-06 02:47:38 +0200, Heikki Linnakangas wrote:
> > I was chatting with Heikki about this patch and he mentioned that he
> > recalls a
> > patch that did some work to unify the signal replacement, procsignal.h and
> > CHECK_FOR_INTERRUPTS(). Thomas, that was probably from you? Do you
On Tue, Jul 15, 2025 at 11:06:11PM +0800, Junwang Zhao wrote:
> WITH OIDS was removed in v12, I'm wondering if we could remove the
> WITHOUT OIDS support for v19.
AFAICT this would produce less helpful error messages and might even break
applications, which I don't think is worth it to save ~90 li
On Tue, Jul 15, 2025 at 12:05:07PM -0400, Shayon Mukherjee wrote:
> Happy to move this to other thread, if it makes more sense, let me know.
Yes, please.
--
nathan
> On Jul 15, 2025, at 10:57 AM, Nathan Bossart wrote:
>
> At a quick glance, this sounds very similar to the problems discussed in
> the following threads:
>
>
> https://postgr.es/m/CAGRkXqTo%2BaK%3DGTy5pSc-9cy8H2F2TJvcrZ-zXEiNJj93np1UUw%40mail.gmail.com
> https://postgr.es/m/aFR
Hi,
A rebased version would be good, there are some not-entirely-trivial
conflicts.
> One notable change is that I merged storage/interrupt.[ch] with
> postmaster/interrupt.[ch], so the awkwardness of having two files with same
> name is gone.
I don't particularly like that. postmaster/interrupt
On 2025/07/16 0:08, Fujii Masao wrote:
On 2025/07/15 19:34, shveta malik wrote:
On Tue, Jul 15, 2025 at 2:56 PM cca5507 wrote:
Hi, hackers
I found the $SUBJECT, the main reason is that RegisteredBgWorker::rw_pid has
not been cleaned.
Attach a patch to fix it.
Thanks for the report!
On Tue, 15 Jul 2025 at 04:17, Robert Treat wrote:
>
> On Mon, Jul 14, 2025 at 3:22 PM David G. Johnston
> > The pg_overexplain extends EXPLAIN with new options that provide...
> > Suggest instead:
> > The pg_overexplain module provides EXPLAIN with new options intended to
> > assist with debuggin
Junwang Zhao writes:
> WITH OIDS was removed in v12, I'm wondering if we could remove the
> WITHOUT OIDS support for v19.
Why?
regards, tom lane
Greg Sabino Mullane writes:
> On Mon, Jul 14, 2025 at 3:21 AM Dean Rasheed
> wrote:
>> Is it really worth adding a core function for that?
> Yes, I think it is. It is also trivial to get a random int from 50 to 100
> with
> 50 + floor(random() * 51)
> but random(50,100) is so much nicer.
I won'
On 2025/07/15 19:34, shveta malik wrote:
On Tue, Jul 15, 2025 at 2:56 PM cca5507 wrote:
Hi, hackers
I found the $SUBJECT, the main reason is that RegisteredBgWorker::rw_pid has
not been cleaned.
Attach a patch to fix it.
Thanks for the report!
This issue appears to have been introduce
Hi hackers,
WITH OIDS was removed in v12, I'm wondering if we could remove the
WITHOUT OIDS support for v19.
attach is the trivial patch for $subject.
--
Regards
Junwang Zhao
v1-0001-chore-remove-WITHOUT-OIDS-syntax.patch
Description: Binary data
On Mon, Jul 14, 2025 at 3:21 AM Dean Rasheed
wrote:
> But it's completely trivial to emulate random(min_date, max_date), just by
> doing
>
> min_date + random(0, max_date - min_date)
>
> Is it really worth adding a core function for that?
>
Yes, I think it is. It is also trivial to get a rando
At a quick glance, this sounds very similar to the problems discussed in
the following threads:
https://postgr.es/m/CAGRkXqTo%2BaK%3DGTy5pSc-9cy8H2F2TJvcrZ-zXEiNJj93np1UUw%40mail.gmail.com
https://postgr.es/m/aFRxC1W_kZU9OjJ9%40nathan
--
nathan
Hi,
I totally understand the wish to make pg_stat_statements useful for
workloads that create/drop a ton of temporary tables.
However, when pursuing this goal we impacted other types of totally valid
workloads when tables with the same name exist in different schemas.
Example:
create schema s1;
cr
Hi,
On Fri, Jul 11, 2025 at 11:59:39AM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-07-10 08:21:56 +, Bertrand Drouvot wrote:
> > - Let's define a list of "cheap" and a list of "expensive" wait events
> > - Change the code path to increment counters only for the "expensive" ones
> > - Optimi
Hello All
Postgresql dblinks and dblink_fdw allow for the use of Server and user mapping
to be able to store the user/password of a connection and save it in an
encrypted manner.
Logical replication subscription syntax regarding connection info allows for
the user/password to be supplied withi
On 2025-Jul-15, jian he wrote:
> On Tue, Jul 15, 2025 at 2:10 PM jian he wrote:
> > accidently found another existing bug.
> > CREATE SCHEMA test;
> > CREATE DOMAIN test.d1 AS integer NOT NULL DEFAULT 11;
> > COMMENT ON CONSTRAINT a2 ON DOMAIN test.d1 IS 'test';
> > ALTER DOMAIN test.d1
> >
Hi,
On 2025-07-14 22:07:38 +0100, Dean Rasheed wrote:
> (The cfbot reports the same warnings, but you have to scroll through a
> lot of output to see them. It would be nice if the commitfest app had
> an indicator to show if there were any compiler warnings.)
FWIW, for many warnings the CompilerW
Hi,
On 2025-07-14 03:28:16 +0900, Masahiko Sawada wrote:
> I've reviewed the 0001 and 0002 patches. The API implemented in the
> 0002 patch looks good to me, but I'm concerned about the capsulation
> of copy state data. With the v42 patches, we pass the whole
> CopyToStateData to the extension cod
> On Jun 23, 2025, at 10:14 AM, Robert Treat wrote:
>>
Sorry for the late response, been busy at work :D.
>
> Glad to hear you are still interested, slightly disheartened by the
> general lack of concern around operational safety in this thread. I
> actually think what you have done covers
Hello hackers,
I'd like to discuss an issue I observed where TOAST tables do not properly
inherit `vacuum_truncate` settings from their parent tables during
autovacuum operations, leading to unexpected and prolonged truncation
phases that can cause significant lock contention on production systems
On Mon, Jul 14, 2025 at 3:13 PM Amit Kapila wrote:
>
> On Sun, Jul 13, 2025 at 6:06 PM Konstantin Knizhnik
> wrote:
> >
> > On 13/07/2025 1:28 pm, Amit Kapila wrote:
> > > On Tue, Jul 8, 2025 at 12:06 PM Konstantin Knizhnik
> > > wrote:
> > >> There is well known Postgres problem that logical
Thanks for the thoughts, Tom.
On Mon, Jul 14, 2025 at 11:29 PM Tom Lane wrote:
> Amit Langote writes:
> > Not quite -- the optimization doesn’t require changes to the tuple
> > header or representation. The existing deforming code already stops
> > once all requested attributes are filled, using
Hi hackers,
While testing behavior of 'vacuum' functionality under high load
we've noticed that the exclusive lock with 'LOCKTAG_DATABASE_FROZEN_ID'
tag could be held for a prolonged time, thus causing contention with
other sessions.
This lock is obtained by the 'vac_update_datfrozenxid' functio
Hi,
I believe the behaviour of the choose_custom_plan function should be
adjusted slightly.
The CachedPlanSource can operate in either auto mode or force a specific
plan type. Currently, the force_generic_plan option declares all plans
as generic, except one-shot plans, of course. However, t
Hi,
Reset the PID in ResetBackgroundWorkerCrashTimes() may also works, but I'm
not sure which is better.
--
Regards,
ChangAo Chen
On Tue, Jul 15, 2025 at 2:56 PM cca5507 wrote:
>
> Hi, hackers
>
> I found the $SUBJECT, the main reason is that RegisteredBgWorker::rw_pid has
> not been cleaned.
>
> Attach a patch to fix it.
>
Thank You for reporting this. The problem exists and the patch works
as expected.
In the patch, we
On Mon, Jul 14, 2025 at 9:10 PM Fabrice Chapuis wrote:
>
> Thanks for this feedback,
> I'll remove the check on the sync_replication_slots parameter.
> I think it is interesting as you suggest to start with the idea of the
> pg_alter_replication_slot API, I will make a new proposal by opening a n
Hi,
On Fri, Jul 11, 2025 at 04:32:13PM -0500, Sami Imseih wrote:
> > > and instead reuse the existing static hash table, which is
> > > capped at 128 custom wait events:
> > >
> > > ```
> > > #define WAIT_EVENT_CUSTOM_HASH_MAX_SIZE 128
> > > ```
> >
> > That's probably still high enough, thoughts?
On Tue, 15 Jul 2025 at 12:08, Japin Li wrote:
>
> IIRC, the standby will indefinitely attempt to connect for replication,
> even
> without restore_command configured.
>
That's correct. However right now it just results in an attempt to open the
WAL segment in pg_wal and failing, what is cheap.
C
On Tue, 15 Jul 2025 at 11:24, Alexander Kukushkin wrote:
> Hi,
>
> On Mon, 14 Jul 2025 at 11:24, Japin Li wrote:
>
> The configuration is as expected. My test script simulates two distinct hosts
> by utilizing local archive storage.
>
> For physical replication across distinct hosts without sh
On 2025/07/10 14:11, Yugo Nagata wrote:
On Thu, 10 Jul 2025 13:23:47 +0900
Fujii Masao wrote:
On 2025/07/10 10:30, Yugo Nagata wrote:
You're right. I must have overlooked something. I think I saw "TO" being
suggested after "FOREIGN SERVER" when no foreign servers were defined.
The attac
On Mon, 14 Jul 2025 17:25:22 -0400
Greg Sabino Mullane wrote:
[…]
> > Other than picking an arbitrary value (i.e. 5000), any thoughts about how
> > to build a case around a specific value ?
>
>
> Do you have actual examples of queries / situations that are harmed by the
> current settings? Let
HI
>What is really painful right now, logical walsenders can only look into
pg_wal, and unfortunately replication slots don't give 100% guarantee for
WAL >retention because of max_slot_wal_keep_size.
>That is, using restore_command for logical walsenders would be really
helpful and solve some probl
Hi, hackers
I found the $SUBJECT, the main reason is that RegisteredBgWorker::rw_pid has
not been cleaned.
Attach a patch to fix it.
--
Regards,
ChangAo Chen
v1-0001-logical-replication-launcher-did-not-automaticall.patch
Description: Binary data
Hi,
On Mon, 14 Jul 2025 at 11:24, Japin Li wrote:
> The configuration is as expected. My test script simulates two distinct
> hosts
> by utilizing local archive storage.
>
> For physical replication across distinct hosts without shared WAL archive
> storage, WALs are archived locally (in my test
Dear Michael,
> I like the addition of an extra pg_logical_emit_message() in test 046
> anyway, down to v17, in the test 046 for all the branches. Even if
> the reproduction is sporadic, we have seen it pretty quickly in the CI
> and in the buildfarm so it would not go unnoticed for a long time i
HI Japin
Thank you for your working on this.It is useful ,when a standby node has
hardware issue repaired ，wal log usually has been archived.The
wal_keep_size parameter is difficult to estimate accurately, as hardware
repair or replacement times are often unpredictable. If the machine can be
fix
1 - 100 of 109 matches
Mail list logo
