On Sat, Apr 12, 2025 at 5:26 AM Jonathan S. Katz wrote:
> The Core Team would like to extend our congratulations to Jacob
> Champion, who has accepted an invitation to become our newest PostgreSQL
> committer.
>
> Please join us in wishing Jacob much success and few reverts!
Congratulations Jacob
Hi
po 14. 4. 2025 v 7:54 odesílatel jian he
napsal:
> hi.
>
> CREATE TABLE tp(c int, a int, b int) PARTITION BY RANGE (b);
> CREATE TABLE tp_1(c int, a int, b int);
> ALTER TABLE tp ATTACH PARTITION tp_1 FOR VALUES FROM (0) TO (1);
> CREATE INDEX t_a_idx ON tp_1(a);
> CREATE INDEX tp_a_idx ON tp
On Mon, Apr 7, 2025 at 4:50 PM Richard Guo wrote:
> Hence, I propose the attached patch for the fix.
>
> BTW, there is a XXX comment there saying that maybe we can make the
> remaining join quals part of the inner scan's filter instead of the
> join filter. I don't think this is possible in all c
Thanks for the feedback, attached an updated patch that changes most
of those "Did not find" messages to empty tables. I did not change two
sets, listDbRoleSettings and listTables both have comments describing
that these are deliberately this way.
I wanted to post this update to close this loop fo
Andrew Dunstan:
On 2025-04-12 Sa 10:10 PM, Noah Misch wrote:
On Sat, Apr 12, 2025 at 07:51:06PM +0200, Wolfgang Walther wrote:
With injection points enabled, I get the following errors in test_aio:
[15:14:45.408](0.000s) not ok 187 - worker: first hard IO error is
reported:
expected stderr
On 12/4/25 18:59, Thomas Munro wrote:
It's hard to know how to set io_workers=3.
Hmmm enable the below behaviour if "io_workers=auto" (default) ?
Sometimes being able to set this kind of parameters manually helps
tremendously with specific workloads... :S
[snip]
Here's a patch to repla
Hi,
On April 13, 2025 7:27:33 PM GMT+02:00, Wolfgang Walther
wrote:
>Andrew Dunstan:
>>
>> On 2025-04-12 Sa 10:10 PM, Noah Misch wrote:
>>> On Sat, Apr 12, 2025 at 07:51:06PM +0200, Wolfgang Walther wrote:
With injection points enabled, I get the following errors in test_aio:
I noticed a while ago that the new fast-path locking code uses integer
division to figure out the fast-path locking group slot. To me, this
seems a bit unnecessary as FastPathLockGroupsPerBackend is always a
power-of-two value, so we can use bitwise-AND instead.
I don't think FAST_PATH_REL_GROUP
Hi,
On Wed, Mar 26, 2025 at 2:14 PM Stepan Neretin wrote:
>
> The first thing we both noticed is that the macro calls a function that won't
> be available without an additional header. This seems a bit inconvenient.
Well, I rebased the patch onto the latest `master`
(b51f86e49a7f119004c0ce5d0be
Dear Michael,
Thanks for creating the patch! Let me confirm two points:
Apart from functions related with injection_points, this can be called even when
postgres has been built with -Dinjection_points=false. This is intentional
because
this function does not have any side-effect and just refers
On Sun, Apr 13, 2025 at 11:51:57AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > Tom and Michael, do you still object to the test addition, or not? If there
> > are no new or renewed objections by 2025-04-20, I'll proceed to add the
> > test.
>
> While I still don't love it, I don't have a be
On Mon, Apr 14, 2025 at 5:45 AM Jose Luis Tallon
wrote:
> On 12/4/25 18:59, Thomas Munro wrote:
> > It's hard to know how to set io_workers=3.
>
> Hmmm enable the below behaviour if "io_workers=auto" (default) ?
Why not just delete io_workers? If you really want a fixed number,
you can set i
Hi all,
One thing that's been lacking in injection points is the possibility
to look at the state of the injection points in shared memory through
some SQL. This was on my tablets for some time, but I have not taken
the time to do the actual legwork.
The attached patch adds a SRF that returns a
On Fri, Apr 11, 2025 at 8:31 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > > I think a relatively elegant solution is to extend ProcSignalBarrier
> > > mechanism to track not only pss_barrierGeneration, as a sign that
> > > everything was processed, but also something like
> > > pss_barrier
Hi Vignesh,
FYI, the patch v20250325-0004 failed to apply (atop 0001,0002,0002)
due to recent master changes.
Checking patch src/backend/commands/sequence.c...
error: while searching for:
(long long) minv, (long long) maxv)));
/* Set the currval() state only if iscalled = true */
if (iscalled)
{
Congrats Jacob.
On Mon, Apr 14, 2025 at 8:32 AM Ashutosh Bapat
wrote:
> Hearty congratulations Jacob.
>
> On Mon, Apr 14, 2025 at 6:55 AM Richard Guo
> wrote:
> >
> > On Sat, Apr 12, 2025 at 5:26 AM Jonathan S. Katz
> wrote:
> > > The Core Team would like to extend our congratulations to Jacob
Many Congratulations, Jacob.
On Mon, Apr 14, 2025 at 11:00 AM Kashif Zeeshan wrote:
>
> Congrats Jacob.
>
> On Mon, Apr 14, 2025 at 8:32 AM Ashutosh Bapat
> wrote:
>>
>> Hearty congratulations Jacob.
>>
>> On Mon, Apr 14, 2025 at 6:55 AM Richard Guo wrote:
>> >
>> > On Sat, Apr 12, 2025 at 5:2
Hi,
During previous commitfest this topic already has been discussed
within the "Forbid to DROP temp tables of other sessions" thread [1].
Unfortunately its name doesn't reflect the real problem, so I decided
to start a new thread, as David G. Johnston advised.
Here are the summary results of the
On Sat, 12 Apr 2025 at 01:56, Jonathan S. Katz wrote:
>
> The Core Team would like to extend our congratulations to Jacob
> Champion, who has accepted an invitation to become our newest PostgreSQL
> committer.
>
> Please join us in wishing Jacob much success and few reverts!
Many Congratulations,
Em sex., 11 de abr. de 2025 às 08:27, Ranier Vilela
escreveu:
> Thanks Michael, for looking at this.
>
>
> Em sex., 11 de abr. de 2025 às 02:09, Michael Paquier
> escreveu:
>
>> On Thu, Apr 10, 2025 at 03:10:02PM -0300, Ranier Vilela wrote:
>> > While it is arguable that this is a false warning,
Hi Vignesh,
Here are some review comments for patch v20250325-0001.
==
src/test/regress/expected/sequence.out
1.
+SELECT last_value, log_cnt, is_called FROM
pg_sequence_state('sequence_test');
+ last_value | log_cnt | is_called
++-+---
+ 99 | 32 | t
And in case there *is* ACL present then each user mentioned in the ACL
adds more overhead
Also the separate GRANT calls cause bloat as the
pg_largeoject_metadata row gets updated for each ALTER USER or GRANT
The following is for 10 million LOs with 1 and 3 users being GRANTed
SELECT on each objec
In the thread that led up to commit 0dca5d68d [1], we'd convinced
ourselves that the new implementation was faster than the old.
So I was sad to discover that there are common cases where it's
a good bit slower. We'd focused too much on test methods like
do $$
begin
for i in 1..1000 loop
On 2025-04-13 Su 1:51 PM, Andres Freund wrote:
Hi,
On April 13, 2025 7:27:33 PM GMT+02:00, Wolfgang Walther
wrote:
Andrew Dunstan:
On 2025-04-12 Sa 10:10 PM, Noah Misch wrote:
On Sat, Apr 12, 2025 at 07:51:06PM +0200, Wolfgang Walther wrote:
With injection points enabled, I get the follo
hi.
CREATE TABLE tp(c int, a int, b int) PARTITION BY RANGE (b);
CREATE TABLE tp_1(c int, a int, b int);
ALTER TABLE tp ATTACH PARTITION tp_1 FOR VALUES FROM (0) TO (1);
CREATE INDEX t_a_idx ON tp_1(a);
CREATE INDEX tp_a_idx ON tp(a);
pg_dump --schema=public --if-exists --clean --no-statistics
-
On Sun, Apr 06, 2025 at 11:00:54AM -0700, Noah Misch wrote:
> I pushed that as commit 8e7e672 (2024-10-25). I now think DELAY_CHKPT_START
> is superfluous here, per this proc.h comment:
>
> * (In the
> * extremely common case where the data being modified is in shared buffers
> * and we acquir
On Fri, Apr 11, 2025 at 10:54 AM Zhijie Hou (Fujitsu)
wrote:
>
> Hi,
>
> While testing publication DDLs, I noticed an unexpected behavior where the
> MERGE command can be executed on tables lacking replica identity keys,
> regardless of whether they are part of a publication that publishes updates
On Wed, Feb 05, 2025 at 09:19:22AM +0900, Michael Paquier wrote:
> On Mon, Feb 03, 2025 at 09:30:33PM -0800, Jeff Davis wrote:
>> One extra benefit of supporting arguments is that it would be a more
>> flexible way to change the local state around the injection point.
>> Right now the only way is b
Hi all,
(well, Andres)
93bc3d75d8e1 has introduced a couple of new injection points, but
these don't follow the convention in-place where points are named
more-or-less-like-that. Please find attached a patch to make all
these more consistent.
Thoughts or comments?
--
Michael
diff --git a/src/bac
On Fri Apr 4, 2025 at 7:34 PM CEST, Heikki Linnakangas wrote:
Let's move that 'in_restore_command' business to the caller. It's weird
modularity for the function to implicitly behave differently for some
callers.
I definitely agree with the sentiment, and it was what I originally
planned to d
Hi.
Per Coverity.
CID 1608916: (#1 of 1): Resource leak (RESOURCE_LEAK)
52. leaked_storage: Variable buf going out of scope leaks the storage
buf.data points to.
The function *record_in* has a new report about resource leak.
I think Coverity is right.
The normal path of the function frees the me
Hearty congratulations Jacob.
On Mon, Apr 14, 2025 at 6:55 AM Richard Guo wrote:
>
> On Sat, Apr 12, 2025 at 5:26 AM Jonathan S. Katz wrote:
> > The Core Team would like to extend our congratulations to Jacob
> > Champion, who has accepted an invitation to become our newest PostgreSQL
> > commit
Hi Vignesh,
Some review comments for patch v20250325-0002
==
Commit message
1.
Furthermore, enhancements to psql commands (\d and \dRp) now allow for better
display of publications containing specific sequences or sequences included
in a publication.
~
That doesn't seem as clear as it migh
> On Fri, Mar 28, 2025 at 09:23:13AM GMT, Filip Janus wrote:
> > +else
> > +if (nbytesOriginal - file->pos != 0)
> > +/* curOffset must be corrected also if compression is
> > + * enabled, nbytes was changed by compression but we
> > + * have to use t
On 11.04.2025 20:09, David G. Johnston wrote:
However, I do think we are at something committable, though I'd make
one, maybe two, changes to v8.
Thank you for supporting this patch.
Valid until -> Password valid until: the timestamp value already
forces a wide column, adding the word Passwor
Dear pgsql-hackers,
As we prepare for the PostgreSQL Development Conference 2025 (PGConf.dev 2025),
scheduled for May 13–16 in Montreal, Canada, we are excited to host a poster
session showcasing the contributions and projects within our community.
If you’re planning to attend PGConf.dev 2025,
On Mon, Apr 7, 2025 at 1:10 PM Michael Paquier wrote:
>
> On Thu, Apr 03, 2025 at 12:36:59AM +0900, Ryo Kanbayashi wrote:
> > I'll reflect your notice and suggestion to the patch current I'm
> > working on :)
>
> Thanks for that.
>
> And I have forgotten to add you as a reviewer of what has been
>
On 2025-04-13 Su 8:12 AM, Álvaro Herrera wrote:
On 2025-Apr-12, Andrew Dunstan wrote:
Seems odd that this one is necessary at all. Doesn't a StringInfo always
have a trailing null byte?
AFAICT what this is doing that's significant, is increment StringInfo->len.
Before doing it, the NUL byte
On 2025-04-12 Sa 10:10 PM, Noah Misch wrote:
On Sat, Apr 12, 2025 at 07:51:06PM +0200, Wolfgang Walther wrote:
With injection points enabled, I get the following errors in test_aio:
[15:14:45.408](0.000s) not ok 187 - worker: first hard IO error is reported:
expected stderr
[15:14:45.409](0.0
On Sat, Apr 05, 2025 at 07:09:58PM -0700, Noah Misch wrote:
> On Sun, Apr 06, 2025 at 07:42:02AM +0900, Michael Paquier wrote:
> > On Sat, Apr 05, 2025 at 12:13:39PM -0700, Noah Misch wrote:
> > > Since the 2025-02 releases made non-toy-size archive recoveries fail
> > > easily,
> > > that's not e
Noah Misch writes:
> Tom and Michael, do you still object to the test addition, or not? If there
> are no new or renewed objections by 2025-04-20, I'll proceed to add the test.
While I still don't love it, I don't have a better proposal.
regards, tom lane
Hi，
I think this point is of no significance at all. Besides, this is a
document that has been around for over ten years. Everyone has become
accustomed to this kind of expression. This is just a case of being full
but having nothing to do with anything.
On Sat, 12 Apr 2025 at 10:31, David G. Joh
Hi all,
Apologies — the patch I sent earlier did not appear as expected on the mailing
list archives because of wrong attachment style.
I'll resend it properly as an inline patch shortly.
Thanks for your understanding!
Best regards,
Mingwei Jia
v7-0013-use-clog-in-XidInMVCCSnapshot.patch
On 2025-Apr-12, Andrew Dunstan wrote:
> Seems odd that this one is necessary at all. Doesn't a StringInfo always
> have a trailing null byte?
AFAICT what this is doing that's significant, is increment StringInfo->len.
Before doing it, the NUL byte is not part of the message; afterwards it
is.
--
Hi,
With "pg_restore --format=", we are not giving any error because in code,
we are checking length of arg but pg_dump is reporting an error for the
same option.
For the consistency purpose, pg_dump and pg_restore both should report an
error for the test case below.
*Ex: (output after this patch
45 matches
Mail list logo
