On Tue, Dec 10, 2024 at 02:29:09AM +1300, Thomas Munro wrote:
> Here are some things I have learned about pathname encoding:
>
> * Some systems enforce an encoding: macOS always requires UTF-8, ext4
> does too if you turn on case insensitivity, zfs has a utf8only option,
> and a few less interesti
On Thu, Apr 17, 2025 at 6:14 PM Zhijie Hou (Fujitsu)
wrote:
>
> Hi,
>
> The recently added tests for slotsync on two-phase enabled slots failed[1] due
> to a broken assertion triggered while decoding the COMMIT PREPARED record on
> the promoted standby.
>
> -
> Analysis
> -
>
> if
Daniel Gustafsson writes:
> Agreed, moving to heap allocated structures for these callsites seem much
> better. Something like the attached should be enough I think?
I confirm this silences those warnings on my Fedora 41 box.
I'm content to do it like this, but maybe Jacob wants to
investigate a
On Fri, Apr 18, 2025 at 3:54 AM Thomas Munro wrote:
> I contemplated that once before, when I wrote a quick demo patch[1] to
> implement huge_pages=on for FreeBSD (ie explicit rather than
> transparent). I used a different function, not the Linuxoid one but
Oops, I forgot to supply that link[1].
>> In the "Asynchronous Command Processing" section of libpq.sgml,
>> there's a line which misses a comma at the end. Attached patch should
>> fix it. I am going to push attached patch into master and
>> REL_17_STABLE branches if there's no objection.
>
> +1
The patch pushed. thanks.
Best regar
Hello,
As part of testing this change I believe I found a scenario where the
parallel build seems to trigger OOMs for larger indexes. Specifically,
the calls for ginEntryInsert seem to leak memory into
TopTransactionContext and OOM/crash the outer process.
For serial build, the calls for ginEntryIn
On Fri, Jan 17, 2025 at 04:06:20PM -0800, Jeff Davis wrote:
> Committed 0001 and 0002.
> Upon reviewing the discussion threads, I removed the Unicode "adjust to
> Cased" behavior when titlecasing. As Peter pointed out[1], it doesn't
> match the documentation or expectations for INITCAP().
While c
Dear Kuroda-san,
17.04.2025 10:10, Hayato Kuroda (Fujitsu) wrote:
Dear Alexander,
While analyzing the BF failure [1], I noticed that the same issue may happen
here,
which means apply worker waited something. According to the log, apply worker
(PID 2820)
stucked so that logical replication cou
On 6/24/23 13:23, Tomas Vondra wrote:
I really hope what I just wrote makes at least a little bit of sense.
Here is a continuation of your work:
1. non-matched estimation sophisticated to provide meaningful numbers.
2. unmatched_frac is stored in sjinfo that let us to summarise these
generated
On 2025-04-17 Th 10:56 AM, Tom Lane wrote:
Andrew Dunstan writes:
Back in 2022 in commit 55828a6b6084 we disabled a bunch of tests due to
a timing issue. Nothing seems to have been done since ... do we still
want to keep these commented out lines around? This "temporary" fix
seems to have str
Hello,
On Thu, Apr 17, 2025, at 7:01 PM, Tender Wang wrote:
> create table t1(a int not null);
> ALTER TABLE t1 ADD CONSTRAINT d PRIMARY KEY(a), ALTER a DROP NOT NULL;
>
> in v17.4, ALTER TABLE successes, but in v18, it reports below error:
> ERROR: primary key column "a" is not marked NOT NULL
On Thu Apr 17, 2025 at 2:15 AM CDT, Jelte Fennema-Nio wrote:
> On Thu, 17 Apr 2025 at 03:57, Tristan Partin wrote:
>> I spent some time exploring the Meson build a bit, and I realized that
>> C++ support in PGXS is tied to LLVM enablement. Checking the autotools
>> build in the configure.ac script
Hi,
I found an inconsistent behavior in v17.4 and v18 after not-null
constraints were committed.
create table t1(a int not null);
ALTER TABLE t1 ADD CONSTRAINT d PRIMARY KEY(a), ALTER a DROP NOT NULL;
in v17.4, ALTER TABLE successes, but in v18, it reports below error:
ERROR: primary key colu
On Tue, Apr 15, 2025 at 6:11 AM Andres Freund wrote:
> There very well could be a CFI - but it better be somewhere where the
> in-memory state is consistent. Otherwise an error inside raised in the CFI
> would lead the in-memory state inconsistent which then would cause problems
> when cleaning up
On Wed, Apr 16, 2025 at 12:31 AM Thomas Munro wrote:
> More or less, yeah, just put the whole ReadStream object in shared
> memory, pin an LWLock on it and call it a parallel-aware or shared
> ReadStream. But how do you make the locking not terrible?
>
> My "work stealing" brain dump was imaginin
Andrew Dunstan writes:
> Back in 2022 in commit 55828a6b6084 we disabled a bunch of tests due to
> a timing issue. Nothing seems to have been done since ... do we still
> want to keep these commented out lines around? This "temporary" fix
> seems to have stretched the definition of that term mo
Thanks for your review, Melih and Rahila.
On 2025-04-17 21:25, Rahila Syed wrote:
Hi,
The attached patch is how I think we should do it.
Thank you for the patch.
I tested this patch and it works fine. I agree with the changes made
in it.
Regarding v2 patch,
- int
Back in 2022 in commit 55828a6b6084 we disabled a bunch of tests due to
a timing issue. Nothing seems to have been done since ... do we still
want to keep these commented out lines around? This "temporary" fix
seems to have stretched the definition of that term more than somewhat.
(noticed whe
On Thu, Apr 17, 2025 at 8:44 PM Zhijie Hou (Fujitsu) wrote:
>
> Hi,
>
> The recently added tests for slotsync on two-phase enabled slots
> failed[1] due to a broken assertion triggered while decoding the
> COMMIT PREPARED record on the promoted standby.
Here is the missing link:
[1]
https:/
Hi,
The recently added tests for slotsync on two-phase enabled slots failed[1] due
to a broken assertion triggered while decoding the COMMIT PREPARED record on
the promoted standby.
-
Analysis
-
if ((txn->final_lsn < two_phase_at) && is_commit)
{
/*
Hi,
> The attached patch is how I think we should do it.
>
Thank you for the patch.
I tested this patch and it works fine. I agree with the changes made in it.
Regarding v2 patch,
- int level = 0;
Retaining the level variable will enhance the code rea
HI *Maxim Orlov*
Thank you for your working on this ，I like your idea ，but I have a
suggestion ,autovacuum_max_workers is not need change requires restart , I
think those guc are can like
autovacuum_max_workers
+#max_parallel_index_autovac_workers = 0 # this feature disabled by default
+ # (c
> On 17 Apr 2025, at 01:28, Tom Lane wrote:
>
> Jacob Champion writes:
>> On Wed, Apr 16, 2025 at 4:04 PM Tom Lane wrote:
>>> Looking through all of the callers of freeJsonLexContext, quite
>>> a lot of them use local JsonLexContext structs, and probably some
>>> of them are more performance-cr
In the "Asynchronous Command Processing" section of libpq.sgml,
there's a line which misses a comma at the end. Attached patch should
fix it. I am going to push attached patch into master and
REL_17_STABLE branches if there's no objection.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http:
Hi,
torikoshia , 17 Nis 2025 Per, 12:35 tarihinde
şunu yazdı:
> I guess few people would notice this difference, but I think it's better
> to avoid changing it unless there's a good reason to do so.
> Personally, I also feel the original formatting better -- especially
> because the "xx more chil
> On 17 Apr 2025, at 01:12, Tom Lane wrote:
>
> Michael Paquier writes:
>> On Wed, Apr 16, 2025 at 04:19:02PM +0200, Daniel Gustafsson wrote:
>>> Agreed, while it's perfectly safe today the end method should not make
>>> assumptions about the use of the private_data pointer upon return and shoul
Hi Dmitry,
On Mon, Apr 14, 2025 at 12:50 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Mon, Apr 14, 2025 at 10:40:28AM GMT, Ashutosh Bapat wrote:
> >
> > However, when we put back the patches to shrink buffers, we will evict
> > the extra buffers, and shrink - if all the processes haven
17.04.2025 00:24, Hannu Krosing пишет:
> But regarding weather to use RAFT I would just define a "coordinator
> API" and leave it up to the specific coordinator/consensus extension
> to decide how the consensus is achieved
>
>
> So to summarize:
>
> # Core should provide
>
> - way tomove to new
On 2025-04-17 07:31, David Rowley wrote:
On Thu, 17 Apr 2025 at 02:20, torikoshia
wrote:
Regarding the implementation:
In the initial patch attached, I naïvely incremented the level just
before emitting the log line.
However, it might be cleaner to simply initialize the level variable
to
1 fr
Hi Vignesh,
No comments for patch v20250416-0001
No comments for patch v20250416-0002
No comments for patch v20250416-0003
Here are some comments for patch v20250416-0004
==
src/backend/catalog/system_views.sql
1.
+CREATE VIEW pg_publication_sequences AS
+SELECT
+P.pubname AS pu
On Wed, Apr 16, 2025 at 10:30 AM shveta malik wrote:
>
> On Wed, Mar 26, 2025 at 4:17 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > Here's a rebased version of the patch series.
> >
>
Few comments for patch004:
Config.sgml:
1)
+
+Maximum duration (in milliseconds) for which conflict
+
Hi Vignesh,
Some review comments for patch v20250416-0005 (docs)
==
doc/src/sgml/catalogs.sgml
(52.55. pg_subscription_rel)
1.
State code:
i = initialize,
- d = data is being copied,
- f = finished table copy,
- s = synchronized,
+ d = data is
> On 17 Apr 2025, at 01:44, David Rowley wrote:
> To reduce the above 3 options down to two, I just pushed the ones that
> were new to v18. The attached patch handles the ones that were added
> prior to v18.
>
> The options now are:
> 1) Commit the attached to master
> 2) Do nothing.
>
> I'd l
On Thu, 17 Apr 2025 at 03:57, Tristan Partin wrote:
> I spent some time exploring the Meson build a bit, and I realized that
> C++ support in PGXS is tied to LLVM enablement. Checking the autotools
> build in the configure.ac script indicates that that is not the case for
> it.
Thank you for look
Dear Alexander,
While analyzing the BF failure [1], I noticed that the same issue may happen
here,
which means apply worker waited something. According to the log, apply worker
(PID 2820)
stucked so that logical replication could not restart.
Regress log:
```
### Restarting node "pub"
# Running
35 matches
Mail list logo
