> On 18 May 2025, at 01:29, Paul A Jungwirth
> wrote:
>
> Here is a very small comment fix, referencing the wrong function name.
> There's a lot of suffixes flying around right here.
Agreed, that seems like the right fix.
--
Daniel Gustafsson
On Sun, May 18, 2025 at 3:48 AM Shaik Mohammad Mujeeb <
mujeeb...@zohocorp.com> wrote:
> Hi Michael Paquier,
>
> > I don't quite see the value in the comment addition you are suggesting
> > here: all the user-facing features related to query IDs use signed 64b
> > integers, and are documented as s
Hi team,
Hope you are all doing well.
Recently I have encountered a scenario that a user need to dump/restore a
database with 1k ~ 2k large objects. In both dump and restore process, parallel
mode was used with 10 processes. However, in both dump and restore processes,
it seems only 1 proces
Hello Mihail,
On 2025-May-18, Mihail Nikalayeu wrote:
> Hello, everyone!
>
> Rebased version + materials from PGConf.dev 2025 Poster Session :)
I agree with Matthias that this work is important, so thank you for
persisting on it.
I didn't understand why you have a few "v19" patches and also a
> In my tests I build from source from both the 17 stable and head branch
> and use the same build options.
>
OK, I built 17 from REL_17_STABLE, and got the same behavior as the
Homebrew PG17:
* First run: 135 ms
* Subsequent runs: 169 ms, 181 ms, 187 ms, 177 ms, 170 ms
For comparison, with PG18
Hello, Álvaro!
> I didn't understand why you have a few "v19" patches and also a separate
> series of "v19-only-part-3-" patches. Is there duplication? How do
> people know which series comes first?
This was explained in the previous email [0]:
> Patch itself contains 4 parts, some of them may
I wrote:
> Here's a lightly-tested fix for that (against HEAD, but it likely
> works on v17 too).
Pushed that. It did require adjustments for the back branches.
For the archives' sake: I checked which buildfarm animals report
having memset_s(). They are
anaconda | 2025-05-18 08:22:35 | c
Srinath Reddy Sadipiralla writes:
> So is making a patch to have a sql command to reposition the column like
> other databases makes sense? thoughts ?
There have been multiple attempts over the years to separate
physical and logical column positions. They've failed :-(.
You might trawl the mail
On Sun, May 18, 2025 at 1:09 AM Masahiko Sawada wrote:
>
> On Sat, May 10, 2025 at 7:08 AM Amit Kapila wrote:
> >
> > On Sat, May 10, 2025 at 1:05 PM Masahiko Sawada
> > wrote:
> > >
> > > On Sat, May 10, 2025 at 12:00 AM Amit Kapila
> > > wrote:
> > > >
> > > >
> > > > Right, but to an exten
Hello, everyone!
Rebased + fix for compilation due the new INEJCTION_POINT signature.
Best regards,
Mikhail.
v6-0001-Add-an-isolation-test-to-reproduce-a-dirty-snapsh.patch
Description: Binary data
v6-0002-Fix-btree-index-scan-concurrency-issues-with-dirt.patch
Description: Binary data
Thanks, very interesting insights!
Can you try the same test ( with --no-data-checksums) on you mac
> and see if that makes a difference?
>
I disabled checksums on PG18, and retried the tests, with and without
modifying random_page_cost, and for TEMP tables only.
When random_page_cost is the def
While chasing down Valgrind leakage reports, I was disturbed
to realize that some of them arise from a case where the
executor scribbles on the plan tree it's given, which it is
absolutely not supposed to do:
/*
* Initialize result tuple slot and assign its rowtype using the first
On Sun, May 18, 2025 at 12:09:23PM +0530, Shaik Mohammad Mujeeb wrote:
> I noticed that in the recently added files (waiteventset.h and
> pg_localeconv_r.c), the copyright notice still mentions the year range as
> 1996-2024.
>
> Just wanted to check - should this be updated to reflect 1996-2025 in
hi.
somehow, I accidentally saw the TODOs (commits [3]) on jsonb.c and json.c
for functions: to_json_is_immutable and to_jsonb_is_immutable.
The attached patch is to finalize these TODOs.
per coverage [1], [2], there was zero coverage for these two functions.
so I also added extensive tests on i
On Fri, May 16, 2025 at 11:47:12AM -0700, Hari Krishna Sunder wrote:
> Gentle ping on this.
Most of the major PostgreSQL developers were at pgconf.dev held in
Montreal last week, explaining a reduction in the activity of the
mailing lists.
Your initial report was on Monday the 14th, with this pin
On Thu, May 8, 2025 at 11:20 PM Nathan Bossart wrote:
>
> On Thu, May 08, 2025 at 10:38:04PM +0900, Ian Lawrence Barwick wrote:
> > Revised patch attached which adds coverage of that and also for the
> > "constant of the type reg(role|database) cannot be used here" error.
>
> LGTM. I've marked it
Hi Andres,
On Fri, 16 May 2025 at 22:49, Andres Freund wrote:
>
> There have been other odd things on leafhopper, see e.g.:
>
https://www.postgresql.org/message-id/35d87371-f3ab-42c8-9aac-bb39ab5bd987%40gmail.com
> https://postgr.es/m/Z4npAKvchWzKfb_r%40paquier.xyz
>
Any chances this could be li
Michael Paquier writes:
> On Sun, May 18, 2025 at 12:09:23PM +0530, Shaik Mohammad Mujeeb wrote:
>> Just wanted to check - should this be updated to reflect 1996-2025 instead?
> This process is automated by src/tools/copyright.pl on a yearly-basis,
> but it is possible that holes appear when some
On Sun, May 18, 2025 at 11:34:07PM -0400, Tom Lane wrote:
> I had the idea that this was part of our pre-branch checklist,
> but it was not mentioned there. I added it.
Good idea. Thanks.
--
Michael
signature.asc
Description: PGP signature
Hi Hackers,
I noticed that in the recently added files (waiteventset.h and
pg_localeconv_r.c), the copyright notice still mentions the year range as
1996-2024.
Just wanted to check - should this be updated to reflect 1996-2025 instead?
Thanks & Regards,
Shaik Mohammad Mujeeb
Member Technical Sta
On Sat, May 17, 2025 at 2:00 PM Sadeq Dousti wrote:
>>
>> thanks. I don't see regression for a normal table, at least for this test.
>
>
> No, there isn't. I just added them as per your request ;)
>
>
>> In terms of your original test, I tried it out on my Ubuntu machine
>>
>> and with your test a
> I'm now thinking maybe the compilation options for PG 17.5 have been
> different. I'm using the default version that comes with Homebrew, but for
> PG 18, I compiled it myself. Here are the results for `select version();`
> on both:
>
> PostgreSQL 17.5 (Homebrew) on aarch64-apple-darwin24.4.0,
>
fkfk000 writes:
> However, if a user only has a limited number of LOs, like 1k, which seems
> sensible as LOs should be large. In this scenario, there would be only 1
> process work. Therefore, I'm proposing a change. Instead of using a fixed
> number to group LOs with same owner/ACL pair, we c
Hello!
Rebased version.
v9-0004-Modify-the-ExecInitPartitionInfo-function-to-cons.patch
Description: Binary data
v9-0001-Specs-to-reproduce-the-issues-with-CREATE-INDEX-C.patch
Description: Binary data
v9-0002-Modify-the-infer_arbiter_indexes-function-to-cons.patch
Description: Binary data
Hi Vitaly!
On Fri, May 2, 2025 at 8:47 PM Vitaly Davydov wrote:
> Thank you for the attention to the patch. I updated a patch with a better
> solution for the master branch which can be easily backported to the other
> branches as we agree on the final solution.
>
> Two tests are introduced which
Hi,is there any better way to change the order of a column except
1) creating a new table and do insert with select with rearranged columns
2) using views
use case:
there are cases where we might be using delta compression between tuples we
have a table like
"create table temp(x bigint,y char(3),z
26 matches
Mail list logo
