On 2025-09-03 08:38, Fujii Masao wrote:
On Mon, Sep 1, 2025 at 7:12 PM Jim Jones
wrote:
On 01.09.25 11:09, Fujii Masao wrote:
> The patch looks good to me. Barring any objections, I'm thinking to
> commit the patch.
LGTM.
I've pushed the patch. Thanks!
Thank you!
--
Regards,
--
Atsush
Em ter., 2 de set. de 2025 às 16:44, Tom Lane escreveu:
> Ranier Vilela writes:
> > In libpq-fe.h has an artifact pre C99, pqbool.
> > IMO this is not more necessary, once Postgres supports C99
> > and bool becomes standard.
>
> > So get ride of pqbool and use bool instead.
>
> We can't really r
On Tue, Sep 02, 2025 at 04:54:59PM -0500, Nathan Bossart wrote:
> Committed.
Gah, the commit message lists your name under the Discussion tag, and I
missed adding the link to the archives. Please forgive the brain fade.
--
nathan
Daniel Gustafsson writes:
>> On 25 Aug 2025, at 02:54, Chao Li wrote:
>> This patch fixes a trivial bug where an extra whitespace was added
>> when dumping an array, for example:
>> ...
>> The unnecessary whitespace is now removed.
> What about external parsers written for this format which migh
On Tue, Sep 02, 2025 at 09:09:54PM +0100, Mikhail Kot wrote:
> The error originates from pgstat_shmem.c file where shhashent is left in
> half-initialized state if pgstat_init_entry(), calling dsa_allocate0(), errors
> out with OOM. Then shhashent causes a segmentation fault on access. I propose
>
> On Sep 3, 2025, at 10:16, Alexandra Wang wrote:
>
>
>
I have a few more other small comments:
1 - 0002
```
diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
index 6e8fd42c612..ff104c95311 100644
--- a/src/backend/parser/parse_expr.c
+++ b/src/backend/parser/
On Mon, Sep 01, 2025 at 02:35:56PM -0400, Peter Geoghegan wrote:
> I remember that when I worked on what became commit 9b42e71376 back in
> 2019 (which fixed a similar problem caused by the INCLUDE index
> patch), Tom suggested that we do things this way defensively (without
> being specifically aw
On Tue, 2 Sept 2025 at 17:05, Amit Kapila wrote:
>
> On Fri, Aug 29, 2025 at 9:38 AM Masahiko Sawada wrote:
> >
> > I've attached the updated patch.
> >
>
> Few comments:
> =
> 1.
> + * When XLogLogicalInfoActive() is true, guarantee that a subtransaction's
> + * xid can only be seen
I found there are many cases of following pattern:
ptr_1 = dsa_allocate();
ptr_2 = dsa_get_address(xxx, ptr_1);
ptr_2->yyy = zzz;
Inside dsa_get_address(dsa_area *area, dsa_pointer dp):
/* Convert InvalidDsaPointer to NULL. */
if (!DsaPointerIsValid(dp))
return NULL;
So
Hi,
I've encountered the following segmentation fault lately. It happens when
Postgres is experiencing high memory pressure. There are multiple OOM errors in
the log as well.
Core was generated by `postgres: neondb_owner neondb ::1(46658) BIND
'.
Program terminated with signal SIGSEGV,
Hi,
The attached patchset implements checkpointer write combining -- which
makes immediate checkpoints at least 20% faster in my tests.
Checkpointer achieves higher write throughput and higher write IOPs
with the patch.
Besides the immediate performance gain with the patchset, we will
eventually
Hi,
On Tue, Aug 26, 2025 at 06:38:41AM +, Bertrand Drouvot wrote:
> On Mon, Aug 25, 2025 at 08:28:04PM -0400, Andres Freund wrote:
> > FWIW, I think this was done wrongly for the per-backend IO stats too. I've
> > seen the increased overhead in profiles
>
> That's indeed something that could
Peter Eisentraut writes:
> Overall, the question to what extent fmgr functions are allowed to
> modify objects pointed to by their input arguments doesn't seem to be
> addressed anywhere.
I think it's generally understood that an fmgr function must not
modify pass-by-reference inputs, because t
On 2025-09-01 Mo 11:44 AM, Florents Tselai wrote:
On 1 Sep 2025, at 4:35 PM, Euler Taveira wrote:
On Mon, Sep 1, 2025, at 7:35 AM, Florents Tselai wrote:
While working on this https://commitfest.postgresql.org/patch/6020/
I discovered that when changing for func/func-aggregate.sgml, the HT
Hello, Álvaro!
Alvaro Herrera :
> If you want to post secondary patches, please rename them to end in
> something like .txt or .nocfbot or whatever. See here:
> https://wiki.postgresql.org/wiki/Cfbot#Which_attachments_are_considered_to_be_patches?
Sorry, I missed that.
But now it is possible to
hi.
in previous patches v6-0001 to v6-0003, we added support for ALTER TABLE ADD
COLUMN with fast defaults for domains having non-volatile constraints.
inspired by another patch of mine: https://commitfest.postgresql.org/patch/5907
I believe it's doable to perform only a table scan when using ALT
Hello!
Antonin Houska :
> Are you sure the test is complete? I see no occurrence of the REPACK command
> in it.
Oops, send invalid file. The correct one in attachment.
Add_test_for_REPACK_CONCURRENTLY_with_concurrent_modifications.patch_
Description: Binary data
Hi hackers,
In our documentation we recommend disabling memory overcommit to prevent
the OOM killer from kicking in, see [1]. Accordingly, we expect
PostgreSQL to handle OOM situations gracefully. In my experience there
are unfortunately several severe problems with that approach:
1. PostgreSQL c
On Tue, Sep 02, 2025 at 02:41:23PM +0530, Amul Sul wrote:
> The updated version is attached. In addition to the *_opt_error()
> functions, it also renames pg_lsn_in_internal to pg_lsn_in_safe and
> incorporates soft error handling.
Looks globally sensible to me. I was wondering for a bit if the J
Hi,
On Wed, Sep 03, 2025 at 02:47:51PM +0900, Michael Paquier wrote:
> On Tue, Sep 02, 2025 at 12:42:54PM -0400, Andres Freund wrote:
> > I think that's the wrong direction to go. Diffing stats is far from cheap
> > and
> > gets more expensive the more detail you add to stats.
>
> Even if we onl
Dear Vignesh,
Thanks for updating the patch. Few comments:
01.
```
/* Find the leader apply worker and signal it. */
logicalrep_worker_wakeup(MyLogicalRepWorker->subid, InvalidOid);
```
Sequencesync worker does not need to send a signal to the apply worker.
Should we skip in the c
On Wed, 3 Sept 2025 at 07:47, Michael Paquier wrote:
>
> The same error message is repeated twice. How about using some gotos
> and one single ereport instead of two? The same can be said for
> numeric_div_safe() and numeric_mod_safe(), for the division-by-0
> messages.
In numeric_div_safe() an
> On Sep 2, 2025, at 10:59, Chao Li wrote:
>
> jsonbsubs doesn’t need to check is_slice flag as well, I will explain that in
> my next email tougher with my new comments.
Now jsonb_check_json_needed() loops over all indirections:
static bool
jsonb_check_jsonpath_needed(List *indirection)
{
On Wed, 20 Aug 2025 14:10:28 +0900
Yugo Nagata wrote:
> On Fri, 8 Aug 2025 12:21:25 +0900
> Yugo Nagata wrote:
>
> > On Fri, 1 Aug 2025 00:28:30 +0900
> > Yugo Nagata wrote:
> >
> > > Hi,
> > >
> > > On Tue, 24 Jun 2025 17:05:33 +0900
> > > Yugo Nagata wrote:
> > >
> > > > Instead, I'm thi
On Tue, Sep 2, 2025 at 9:46 AM Michael Paquier wrote:
>
> On Mon, Sep 01, 2025 at 12:21:18PM +0100, Dean Rasheed wrote:
> > On Mon, 1 Sept 2025 at 10:36, Amul Sul wrote:
> >> I believe we should update all *_opt_error functions to use the new
> >> soft error reporting infrastructure instead of bo
On Tue, 2 Sept 2025 at 02:03, Julien Rouhaud wrote:
> One not too uncommon scenario is an extension in a dedicated schema that
> creates additional objects dynamically, for instance creating new partitions
> using triggers on one of the extension table.
Interesting. I didn't know there were ext
> On Sep 3, 2025, at 10:20, Alexandra Wang wrote:
>
> This change would give an incorrect result for an accessor like
> "[0].a" when the jsonb column data is a jsonb object instead of a
> jsonb array. I've added two new test cases to cover this scenario:
>
> In jsonb.sql, the newly added test
Hi,
On Tue, Sep 2, 2025 at 10:38 AM Yura Sokolov wrote:
>
> 29.08.2025 01:31, Matheus Alcantara пишет:
> > On Thu Aug 21, 2025 at 8:14 PM -03, Matheus Alcantara wrote:
> >> I'll work on this considering the initial Daniil comments at [1]
> >>
> >> [1]
> >> https://www.postgresql.org/message-id/C
Hi,
On 2025-09-03 21:50:42 +0300, Konstantin Knizhnik wrote:
> On 03/09/2025 8:37 PM, Dmitry Mityugov wrote:
> Size of PgAioHandle is144 bytes. I wonder how critical for us is to save 9
> bytes for it (3 bytes vs 3 integers)?
Not that it makes that huge a difference, but due to alignment consider
Ilia Evdokimov writes:
> I’ve attached v3 of the patch. This version adds a check for NULL values
> when comparing MCV entries, ensuring correctness in edge cases.
Um ... what edge cases would those be? We do not put NULL into
MCV arrays.
regards, tom lane
Hi Atsushi and Ashutosh,
Thank you for reviewing the patch. Attached is v7, incorporating the
feedback. Please see my responses in-line below.
On Fri, Aug 22, 2025 at 6:45 AM Ashutosh Bapat
wrote:
>
> On Fri, Aug 22, 2025 at 7:37 AM torikoshia wrote:
> >
> > | Now that pg_get_multixact_stats()
On Wed Sep 3, 2025 at 4:28 PM -03, Arseniy Mukhin wrote:
>> Since we still need to scan those pages, couldn't we mark finished
>> transactions as committed/aborted?
>> This way we may to not hold datfrozenxid for a long time and will allow
>> both safe clog truncation and safe async queue notificat
Thanks for the comments!
On Tue Sep 2, 2025 at 4:37 AM -03, Yura Sokolov wrote:
> 29.08.2025 01:31, Matheus Alcantara пишет:
>> On Thu Aug 21, 2025 at 8:14 PM -03, Matheus Alcantara wrote:
>>> I'll work on this considering the initial Daniil comments at [1]
>>>
>>> [1]
>>> https://www.postgresql.
On Wed, 2025-09-03 at 11:55 -0400, Andres Freund wrote:
> 32 parallel seq scans of a large relations, with default shared
> buffers, fully
> cached in the OS page cache, seems like a pretty absurd workload.
It's the default settings, and users often just keep going with the
defaults as long as it
On 03/09/2025 8:37 PM, Dmitry Mityugov wrote:
Quite inspiring discussion. The patch is brilliantly good but it adds
a bunch of explicit type casts, and it's not always easy to remember
what cast to use in a particular case, and that may eventually lead to
errors in the future. Just wanted to
Hi,
On 2025-09-03 15:33:30 -0400, Peter Geoghegan wrote:
> On Wed, Sep 3, 2025 at 2:47 PM Andres Freund wrote:
> > I still don't think I fully understand why the impact of this is so large.
> > The
> > branch misses appear to be the only thing differentiating the two cases, but
> > with resowner
On Mon Sep 1, 2025 at 11:06 AM -03, Jacques Combrink wrote:
> TLDR:
> active listener on one database causes notify on another database to get
> stuck.
> At no point could I get a stuck notify if I don't have a listener on at
> least one other database than the one I am notifying on. See the Extra
On Wed, Sep 3, 2025 at 2:47 PM Andres Freund wrote:
> I still don't think I fully understand why the impact of this is so large. The
> branch misses appear to be the only thing differentiating the two cases, but
> with resowners neutralized, the remaining difference in branch misses seems
> too la
On Wed, Sep 3, 2025 at 2:14 PM Matheus Alcantara
wrote:
> IIUC we don't store notifications of aborted transactions on the
> queue. On PreCommit_Notify we add the notifications on the queue
> and on Commit_Notify() we signal the backends.
>
> Or I'm missing something here?
My understandin
Hi,
On 2025-09-03 16:25:56 -0400, Peter Geoghegan wrote:
> On Wed, Sep 3, 2025 at 4:06 PM Andres Freund wrote:
> > The issue to me is that this kind of query actually *can* substantially
> > benefit from prefetching, no?
>
> As far as I can tell, not really, no.
It seems to here - I see small wi
Committed.
--
nathan
On 2025-09-03 07:47:37 +0200, Peter Eisentraut wrote:
> So, can we declare that we don't support this compiler anymore?
+1
On Wed, Sep 3, 2025 at 8:16 PM Andres Freund wrote:
> > I don't see that level of improvement with DIO. For me it's 6054.921
> > ms with prefetching, 8766.287 ms without it.
>
> I guess your SSD has lower latency than mine...
It's nothing special: a 4 year old Samsung 980 pro.
> This actually mi
On Wed, Sep 3, 2025 at 2:32 AM Konstantin Knizhnik wrote:
> But sooner or later vacuum will be called for this index and will
> traverse this page, will not it?
> There is not other way to reuse this page without deleting it or I am
> missing something?
That's true. But VACUUM won't even attempt
On Thu, Sep 4, 2025 at 2:42 AM Tom Lane wrote:
> Daniel Gustafsson writes:
> > On 3 Sep 2025, at 07:47, Peter Eisentraut wrote:
> >> So, can we declare that we don't support this compiler anymore?
> >> (gcc is readily available and seems to work alright, so I'm not saying the
> >> OS is no long
Hello everyone,
This is my first patch! I tried my best to follow the patch submission guides.
The small patch (against postgres:master for PG19-3) changes postgres to permit
"passfile"s with open permissions.
I'll do my best to explain my reasoning:
## Context
When a "passfile" is configured bu
Hi, Mikhail,
If pgstat_init_entry() errors on OOM, what would it returns to shheader, NULL?
That would bring trouble to dshash_delete_entry().
Thanks,
Steven
发件人: Mikhail Kot
已发送: 2025 年 9 月 04 日 星期四 05:39
收件人: pgsql-hackers@lists.postgresql.org
抄送: t...@myrrc
On Sat, Aug 30, 2025 at 4:16 AM Melanie Plageman
wrote:
>
> Hi,
>
> If you call XLogNeedsFlush() immediately after calling XLogFlush() in
> FlushBuffer(), it can return true.
>
> With this diff:
>
> diff --git a/src/backend/storage/buffer/bufmgr.c
> b/src/backend/storage/buffer/bufmgr.c
> index 35
Hello, Amit!
> Now, I
> would like to know the opinion of others who were involved in the
> initial commit, so added Peter E. to see what he thinks of the same.
Peter answered in [0]:
> I don’t remember. I was just the committer.
I’ve attached a new version of the proposed solution.
The first co
Well, commit 38b602b certainly doesn't do us any favors here since it
removed NamedLWLockTrancheArray. Given the lack of reports from the field,
I suspect the best path forward is to add an ERROR for unsafe accesses and
to fix the documentation, as discussed upthread.
--
nathan
On Thu, Sep 4, 2025 at 10:47 AM Jeff Davis wrote:
> Andres suggested that the case I brought up at the top of the thread is
> due to lock contention, so a lock free queue also sounds like a
> potential improvement. If the code is working and can be applied to
> REL_18_STABLE, then I can try it.
N
On Fri, Aug 29, 2025 at 8:48 PM Álvaro Herrera wrote:
>
> > > Alternatively, maybe the right fix is to move the parse-analysis
> > > work into CreateStatistics altogether. I think there is not a
> > > very good argument for ProcessUtilitySlow doing all that stuff.
> > > It's supposed to mainly ju
Hi,
On Tue, Apr 8, 2025 at 11:33 PM Laurenz Albe wrote:
> Well, it didn't make v18.
>
> But this patch got enough votes in favor that I am not going to withdraw it.
Thank you for discussing it.
diff --git a/src/backend/utils/misc/guc_tables.c
b/src/backend/utils/misc/guc_tables.c
index f7c9882f
On Tue, Sep 02, 2025 at 09:43:40AM -0500, Nathan Bossart wrote:
> Do you think a new pg_upgrade test for security labels is worth the
> trouble? It seems doable, but it'd be an awfully expensive test for this.
> On the other hand, I'm not sure there's any coverage for pg_upgrade with
> security la
On Wed, Sep 3, 2025 at 6:11 PM chiranmoy.bhattacha...@fujitsu.com
wrote:
>
> Hi all,
>
> Since the CommitFest is underway, could we get some feedback to improve the
> patch?
On that note, I was hoping you could give us feedback on whether the
improvement in PG18 made any difference at all in you
Hi,
2025-08-21 16:39 に kasaharatt wrote:
2025-08-14 17:56 に kasaharatt wrote:
Hi,
2025-08-14 13:26 に Shinya Kato wrote:
Hi,
On Wed, Aug 13, 2025 at 5:44 PM kasaharatt
wrote:
> Approach 2:
> - log_autovacuum_min_duration: Changed behavior, which controls only
> autovacuum
2025-09-04 13:13 に Shinya Kato wrote:
Hi,
On Thu, Sep 4, 2025 at 11:31 AM kasaharatt
wrote:
The changes(*) to guc_tables.c have been pushed into HEAD,
so you may need to fix the patch.
(*)
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=63599896545c7869f7dd28cd593e8b548983d613
Hi,
I spent a fair bit more time analyzing this issue.
On 2025-08-28 21:10:48 -0400, Andres Freund wrote:
> On 2025-08-28 19:57:17 -0400, Peter Geoghegan wrote:
> > On Thu, Aug 28, 2025 at 7:52 PM Tomas Vondra wrote:
> > I'm not sure that Thomas'/your patch to ameliorate the problem on the
> >
On Thu, 2025-09-04 at 10:22 +1200, Thomas Munro wrote:
> This seems like a non-problem. Robustness against SIGSTOP of random
> backends is not a project goal or reasonable goal, is it?
I think you misinterpreted -- I wasn't suggesting that sending SIGSTOP
is a use case. I just meant that it showe
On Wed, Sep 03, 2025 at 02:48:40PM +0200, Peter Eisentraut wrote:
> Taking a look at your previous patch with the changes from long to int64, I
> think there is something that still doesn't fit.
>
> For example, taking a look at the callers of hash_estimate_size(int64,
> Size), they pass either in
Hi,
On Thu, Sep 4, 2025 at 11:31 AM kasaharatt wrote:
> The changes(*) to guc_tables.c have been pushed into HEAD,
> so you may need to fix the patch.
>
> (*)
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=63599896545c7869f7dd28cd593e8b548983d613
Thank you for reporting and I f
Hi,
On 2025-09-03 11:50:05 -0700, Jeff Davis wrote:
> On Wed, 2025-09-03 at 11:55 -0400, Andres Freund wrote:
> > 32 parallel seq scans of a large relations, with default shared
> > buffers, fully
> > cached in the OS page cache, seems like a pretty absurd workload.
>
> It's the default settings,
On 28.08.25 15:29, Daniel Gustafsson wrote:
On 28 Aug 2025, at 08:53, Peter Eisentraut wrote:
I addressed all those, and did another cleanup pass over the script. (The
formatting is from pgperltidy.)
A tiny nitpick is that all the other generator scripts (that I looked at) in
the tree use
On 9/3/25 08:47, Jeff Davis wrote:
>
> Has there already been a discussion about leaving the default as
> io_method=worker? There was an Open Item for this, which was closed as
> "Won't Fix", but the links don't explain why as far as I can see.
>
There was a discussion in the first thread mentio
On 01.09.25 09:21, John Naylor wrote:
On Thu, Aug 28, 2025 at 1:53 PM Peter Eisentraut wrote:
Ok, good suggestions. I addressed all those, and did another cleanup
pass over the script. (The formatting is from pgperltidy.)
I have no further comments on v3.
I have committed this with a few
> On 3 Sep 2025, at 10:37, Peter Eisentraut wrote:
>
> On 28.08.25 15:29, Daniel Gustafsson wrote:
>>> On 28 Aug 2025, at 08:53, Peter Eisentraut wrote:
>>> I addressed all those, and did another cleanup pass over the script. (The
>>> formatting is from pgperltidy.)
>> A tiny nitpick is that a
hi.
The attached patch makes the last two statements below fail.
CREATE TABLE notnull_tbl1 (a int, b int);
INSERT INTO notnull_tbl1 VALUES (NULL, 1), (300, 3);
ALTER TABLE notnull_tbl1 ADD CONSTRAINT nn NOT NULL a NOT VALID; -- ok
ALTER TABLE notnull_tbl1 ALTER COLUMN a ADD GENERATED ALWAYS AS
IDE
On 28.08.25 20:03, David E. Wheeler wrote:
On Aug 28, 2025, at 09:29, Daniel Gustafsson wrote:
A tiny nitpick is that all the other generator scripts (that I looked at) in
the tree use GetOptions() with named parameter rather than dereference ARGV
directly:
+my $input_fname = $ARGV[0];
+my $o
Hi Tom!
On 02.09.2025 20:10, Tom Lane wrote:
> David Geier writes:
>
> If you are aware of such places, please submit patches to fix them,
> because they are bugs with or without overcommit. Overcommit does
> *not* prevent the kernel from returning ENOMEM, so this seems like
> an extremely spec
We (I) missed expanding virtual generated columns in
get_relation_constraints() in plancat.c. That way, some opportunities
for constraint exclusion will be missed if a constraint contains virtual
generated columns, as can be shown in the attached test case (thanks to
Richard Guo). Simple fix
On Wed, Sep 3, 2025 at 7:52 PM Amul Sul wrote:
>
--- a/src/include/utils/numeric.h
+++ b/src/include/utils/numeric.h
-extern int32 numeric_int4_opt_error(Numeric num, bool *have_error);
.
+extern int32 numeric_int4_safe(Numeric num, Node *escontext);
would any extensions using these function
On 2025-Sep-02, Jeff Davis wrote:
> The good news is that io_uring seemed to solve the problem.
> Unfortunately, that's platform-specific, so it can't be the default.
Why not? We have had wal_sync_method with a platform-dependent default
for a very long time.
--
Álvaro Herrera PostgreS
Hi,
On 2025-09-02 23:47:48 -0700, Jeff Davis wrote:
> Has there already been a discussion about leaving the default as
> io_method=worker? There was an Open Item for this, which was closed as
> "Won't Fix", but the links don't explain why as far as I can see.
> I tested a concurrent scan-heavy wo
On Tue, Aug 26, 2025 at 9:40 AM Jacob Champion
wrote:
> Great, thanks! The full diff of the Meson configure output for each
> task also looks good. So I'll plan to push v7.
Pushed, finally, and all the Cirrus tasks look happy. Thank you very
much for this improvement!
--Jacob
Hi,
On 2025-09-03 17:53:55 +0200, Álvaro Herrera wrote:
> On 2025-Sep-02, Jeff Davis wrote:
>
> > The good news is that io_uring seemed to solve the problem.
> > Unfortunately, that's platform-specific, so it can't be the default.
>
> Why not? We have had wal_sync_method with a platform-depende
On 03.09.25 13:42, Daniel Gustafsson wrote:
On 3 Sep 2025, at 07:47, Peter Eisentraut wrote:
- Hundreds of compiler warnings (They are not necessarily wrong, but it shows
that no one has taken care to tune the warnings or the code in any way
recently.)
Should these be posted somewhere bef
On Wed, Sep 3, 2025 at 6:59 PM Andrei Klychkov
wrote:
>
> Hi Jim,
>
> Thanks a lot for reviewing! Nice catch, TIL!
> Version 2 of the patch is attached, please check it out.
> In a nutshell, the issue actually wasn't in the flatten_set_variable_args()
> function as initially suspected, but rather
On Wed, 2025-09-03 at 10:34 +0200, Tomas Vondra wrote:
> I'll try to reproduce this, but if it's due to the same IPC overhead,
> that would be surprising (for me). In the index case it makes sense,
> because the reads are random enough to prevent I/O combining. But for
> a
> sequential workload I'd
Daniel Gustafsson writes:
> On 3 Sep 2025, at 07:47, Peter Eisentraut wrote:
>> So, can we declare that we don't support this compiler anymore?
>> (gcc is readily available and seems to work alright, so I'm not saying the
>> OS is no longer viable.)
> +1 based on the findings above.
+1, given
On Wed, Sep 03, 2025 at 11:11:24AM +, chiranmoy.bhattacha...@fujitsu.com
wrote:
> Since the CommitFest is underway, could we get some feedback to improve
> the patch?
I see that there was some discussion about a Neon implementation upthread,
but I'm not sure we concluded anything. For popcou
On 10.12.24 03:02, Thomas Munro wrote:
And if we included overtly, rather than covertly in
postgres_ext.h, why would we still want a third name for int64_t? We
could change the three lo_*64() declarations to use the standard type
directly, but keep the historical typedef marked deprecated.
Bu
Dear Hayato,
> So, your python process establishes two connections, for publisher
> (replication connection)
> and subscriber (normal connection). It receives changes from the publisher,
> constructs SQL statements from the received results, and sends to subscriber's
> backend, is it right?
Actu
On 01.09.25 05:25, Michael Paquier wrote:
So, taking a step back, I don't know what would be a good fit for
these duplicates of the "next power" routines upper-bounded on input
when attached to pg_bitutils.h. However, I do see that we can get rid
of pg_log2() and dynahash.h with a consistent int
Ranier Vilela writes:
> In libpq-fe.h has an artifact pre C99, pqbool.
> IMO this is not more necessary, once Postgres supports C99
> and bool becomes standard.
> So get ride of pqbool and use bool instead.
We can't really remove that typedef ever, because application code
might be using it. Un
Hi hackers,
This patch removes the functions that are incrementing the backend IO stats.
Instead, it now copies the IO pending stats to the backend IO pending stats when
the pending IO stats are flushed. This behaves the same way as for some relation
and database stats (see pgstat_relation_flush_
On 03.09.25 11:39, Richard Guo wrote:
On Wed, Sep 3, 2025 at 5:41 PM Peter Eisentraut wrote:
I have committed this with a few of the small changes mentioned nearby.
copperhead reported just now a test failure in test_oat_hooks:
SET debug_discard_caches = 0;
+ERROR: unrecognized configurat
On Fri, Aug 29, 2025 at 5:57 AM Stefan Kaltenbrunner
wrote:
> done -
Thank you!
> though gaibasauris is actually on bookworm...
Oh, good to know. The system description currently says
Debian GNU/Linux 11 (bullseye) gcc 10.2.1 x86_64
--Jacob
Hi Tomas!
I've finally got time again to work on PostgreSQL.
On 03.11.2023 21:48, Tomas Vondra wrote:
> On 2/22/23 13:22, Tomas Vondra wrote:
>> ...
>>
No opinion on these options, but worth a try. Alternatively, we could
try the usual doubling approach - start with a low threshold (and
On Mon, Sep 1, 2025, at 7:35 AM, Florents Tselai wrote:
> While working on this https://commitfest.postgresql.org/patch/6020/
> I discovered that when changing for func/func-aggregate.sgml, the HTML
> wasn’t marked for update.
>
> IIUC the doc/Makefile should be updated as attached, right ?
>
Go
Hello, I was working on my own patch for the same thing, until I found this was
already there.
I think this would be very useful for a lot of people.
Do you need any help moving this forward Anderas? I have both tests and docs
written, although not for the FOR UPDATE part.
> On 25 Jun 2025, at
On Tue, Sep 2, 2025 at 5:26 AM Alexander Korotkov wrote:
> I have another idea. What if we allow MergeAppend paths only when at
> least one subpath is preordered. This trick also allow us to exclude
> MergeAppend(Sort) dominating Sort(Append). I see the regression tests
> changes now have much
On Wed, Sep 3, 2025 at 9:47 AM Andrey Borodin wrote:
>
> > On 3 Sep 2025, at 11:37, Alexander Korotkov wrote:
> >
> > Could you, please, recheck?
>
> That patch also adds CondVar sleep in critical section. That patch is how we
> understood that such sleep is dangerous.
>
> Actual patch to deteac
When working on the REPACK command, we see an ERROR caused by unexpected
change of CurrentResourceOwner [1]. I think the problem is that
reorderbuffer.c does not restore the original value after calling
RollbackAndReleaseCurrentSubTransaction(). The attached patch tries to handle
the call like othe
On Wed, Sep 3, 2025 at 6:47 PM shveta malik wrote:
>
> On Wed, Sep 3, 2025 at 11:58 AM Ajin Cherian wrote:
> >
> > Attaching v10 with the above changes.
> >
>
> The patch does not apply on HEAD. Can you please rebase?
Rebased and made a small change as well to use TopMemoryContext rather
than cr
Mihail Nikalayeu wrote:
> While testing MVCC-safe version with stress-tests
> 007_repack_concurrently_mvcc.pl I encountered some random crashes with
> such logs:
>
> 25-09-02 12:24:40.039 CEST client backend[261907]
> 007_repack_concurrently_mvcc.pl ERROR: relcache reference
> 0x7715b9f394a8 is
发件人: Michael Paquier
已发送: 2025 年 9 月 03 日 星期三 17:43
收件人: Steven Niu
抄送: Mikhail Kot; pgsql-hackers@lists.postgresql.org; t...@myrrc.dev
主题: Re: 回复: Fix segfault while accessing half-initialized hash table in
pgstat_shmem.c
On Wed, Sep 03, 2025 at 07:22:00
Hi Jim,
Thanks a lot for reviewing! Nice catch, TIL!
Version 2 of the patch is attached, please check it out.
In a nutshell, the issue actually wasn't in the flatten_set_variable_args()
function as initially suspected, but rather in the configuration file
writing logic in the write_auto_conf_file(
On 3/9/2025 11:12, Richard Guo wrote:
On Tue, Sep 2, 2025 at 7:56 PM Andrei Lepikhov wrote:
No questions, it is good enough optimisation. I'm worried only about
implementation: It creates one more RelOptInfo that may look like a
baserel, but we can't find it by find_base_rel or even find_join_r
On 02.09.25 04:57, David Rowley wrote:
On Thu, 24 Jul 2025 at 23:03, Peter Eisentraut wrote:
Please review my patch at
https://www.postgresql.org/message-id/ccb273c9-7544-4748-8638-30feba212...@eisentraut.org
https://commitfest.postgresql.org/patch/5934/
Now that we're building with C11, her
On 2025-09-03 We 1:47 AM, Peter Eisentraut wrote:
I've been trying out the Solaris compiler (Oracle Developer Studio
12.6, on Solaris), mainly to test out some C11 support details.
Observations:
[ various issues]
I mean, at least the AIX enthusiasts popped up right away when we
broke t
1 - 100 of 118 matches
Mail list logo
