On Sun, Jun 1, 2025 at 7:52 AM Michael Paquier wrote:
>
> On Sat, May 31, 2025 at 01:26:14PM +0700, Daniil Davydov wrote:
> > Not yet. I proceed from the assumption that if the temp_buffers
> > parameter is set to a large value (some users set it to more than a
> > gigabyte), then the vast majorit
Hi,
On Sun, Jun 1, 2025 at 5:31 PM Dilip Kumar wrote:
>
> On Sun, Jun 1, 2025 at 7:52 AM Michael Paquier wrote:
> >
> > I doubt that it would be a good idea to apply a patch "just" because
> > it looks like a good idea. It is important to prove that something is
> > a good idea first.
>
> I thi
On Fri, May 30, 2025 at 6:32 PM Amul Sul wrote:
>
>
> Kindly take a look at the attached version. I've also added the tests.
> Thanks for your script -- all tests are passing with this patch.
>
hi.
+ * Note that validation should be performed against the referencing
+ * root table only, not its
On Wed, May 28, 2025 at 3:48 PM Michael Paquier wrote:
>
> On Sun, Apr 13, 2025 at 07:06:06PM +0900, Ryo Kanbayashi wrote:
> > I rebased our patch according to 2c7bd2ba507e.
> > https://commitfest.postgresql.org/patch/5387/
>
> Thanks for the new version.
Thanks for review :)
> -# for the conne
hi.
CREATE DOMAIN int_domain1 AS INT CONSTRAINT nn1 NOT NULL CONSTRAINT
nn2 NOT NULL;
will install two not-null pg_constraint entries.
we should have only one?
From 8328340ac98daa3e26ac13cc06348560a468abf0 Mon Sep 17 00:00:00 2001
From: jian he
Date: Sun, 1 Jun 2025 11:32:28 +0800
Subject: [PATC
"Joel Jacobson" writes:
> Explicitly adding deptype='e' entries for all objects created during
> CREATE EXTENSION would significantly improve this situation.
> With this enhancement, pg_dump could easily detect and warn users about
> manually-added objects, or even dump these objects as comments f
Commit 052026c9b9 made heap_vacuum_rel call RelationGetNumberOfBlocks
before it calls vacuum_get_cutoffs -- it swapped the order. This is
wrong, as explained by an intact comment above the call to
vacuum_get_cutoffs.
In short, there is now a brief window during which the relation can be
extended t
On Sun, Jun 1, 2025 at 12:07 PM Peter Geoghegan wrote:
>
> Commit 052026c9b9 made heap_vacuum_rel call RelationGetNumberOfBlocks
> before it calls vacuum_get_cutoffs -- it swapped the order. This is
> wrong, as explained by an intact comment above the call to
> vacuum_get_cutoffs.
>
> In short, th
On Sun, Jun 1, 2025 at 1:51 PM Melanie Plageman
wrote:
> Thanks for the report. That was a dumb mistake. There was no reason
> for me to move the line up as you can see in the diff -- it must have
> been unintentional.
I have to imagine that you moved rel_pages initialization back so that
it took
On Sat, May 31, 2025 at 2:41 AM Eduard Stefes wrote:
>
> On Thu, 2025-05-08 at 05:23 +0700, John Naylor wrote:
>
> > This case is a bit different, since Arm can compute hardware CRC on
> > any input size. The fast path here is only guaranteed to be taken at
> > inputs of 79 bytes or bigger, with t
Hi,
In v18, the "Protocol Version" column shown by \conninfo reports only
the major version (e.g., 3). Wouldn't it be more helpful to show the full
version (e.g., 3.2) using PQfullProtocolVersion()? Since support for
protocol version 3.2 was introduced in v18, users may want to know
exactly which
Hi,
On Tue, May 27, 2025 at 08:30:56AM +0900, Michael Paquier wrote:
> On Mon, May 26, 2025 at 07:49:34AM +, Bertrand Drouvot wrote:
> > That makes me think that it is easy to miss adding a new LWLock in
> > wait_event_names.txt and generate-wait_event_types.pl does not detect that.
>
> Agree
On 2025/06/01 17:34, Etsuro Fujita wrote:
postgres_fdw: Inherit the local transaction's access/deferrable modes.
Previously, postgres_fdw always 1) opened a remote transaction in READ
WRITE mode even when the local transaction was READ ONLY, causing a READ
ONLY transaction using it that refer
On Wed, May 28, 2025 at 7:59 PM Álvaro Herrera wrote:
>
> On 2025-May-28, jian he wrote:
>
> > hi.
> >
> > create table t(a int, constraint cc check(a = 1));
> > ALTER TABLE t ALTER CONSTRAINT cc not valid;
> > ERROR: FOREIGN KEY constraints cannot be marked NOT VALID
> > LINE 1: ALTER TABLE t A
On Mon, Jun 2, 2025 at 12:13 AM Álvaro Herrera wrote:
>
> Hmm, I think it would be more consistent to reject the case of duplicate
> constraints, instead of silently ignoring it. So you'd do it in the
> loop that checks for constraints before creating anything, like
>
>
> diff --git a/src/backend
hi.
attached patch is tab complete for
ALTER CONSTRAINT constraint_name [ DEFERRABLE | NOT DEFERRABLE ] [
INITIALLY DEFERRED | INITIALLY IMMEDIATE ] [ ENFORCED | NOT ENFORCED ]
ALTER CONSTRAINT constraint_name [ INHERIT | NO INHERIT ]
based on ALTER TABLE Synopsis section [0]
[0]: https://www.po
On Sun, Jun 1, 2025 at 6:05 PM jian he wrote:
>
> On Fri, May 30, 2025 at 6:32 PM Amul Sul wrote:
> >
[...]
>
> + * Note that validation should be performed against the referencing
> + * root table only, not its child partitions. See
> + * QueueFKConstraintValidation() for more details.
> */
>
On Mon, Jun 02, 2025 at 12:03:50PM +0900, Fujii Masao wrote:
> I'm not sure this change should be considered a bug fix,
> since the current behavior of postgres_fdw with a local read-only
> transaction isn't clearly documented. Some users might see this
> as a behavioral change rather than a fix. A
I propose that we raise the baseline C standard for PostgreSQL to C11
for PostgreSQL 19. This will allow us to make use of some new features,
clear away a bunch of backward compatibility cruft, unify use of
compiler-specific extensions, and narrow the range of compatibility
concerns for some e
On 2025/05/31 23:23, Daniil Davydov wrote:
Hi,
On Sat, May 31, 2025 at 7:41 PM Fujii Masao wrote:
Here are a few review comments on the patch:
+ for (j = 0; j < nforks; j++)
{
- InvalidateLocalBuffer(bufHdr, true);
+
On Sun, Jun 1, 2025 at 5:51 PM Daniil Davydov <3daniss...@gmail.com> wrote:
>
> Hi,
>
> On Sun, Jun 1, 2025 at 5:31 PM Dilip Kumar wrote:
> >
> > On Sun, Jun 1, 2025 at 7:52 AM Michael Paquier wrote:
> > >
> > > I doubt that it would be a good idea to apply a patch "just" because
> > > it looks l
On Thu, May 29, 2025 at 11:06 AM Richard Guo wrote:
>
> On Fri, May 16, 2025 at 5:35 PM jian he wrote:
> > we have used the USING expression in ATPrepAlterColumnType,
> > ATColumnChangeRequiresRewrite.
> > expanding it on ATPrepAlterColumnType seems to make more sense?
> >
> > @@ -14467,7 +14467,
On 30.05.25 18:12, Fujii Masao wrote:
On 2025/05/31 0:28, Fujii Masao wrote:
Otherwise, maybe "log_lock_failures" would be better.
Yes, this seems better for consistency with log_lock_waits.
Patch attached.
This looks good to me.
On Sunday, June 1, 2025, Fujii Masao wrote:
>
> In v18, the "Protocol Version" column shown by \conninfo reports only
> the major version (e.g., 3). Wouldn't it be more helpful to show the full
> version (e.g., 3.2) using PQfullProtocolVersion()? Since support for
> protocol version 3.2 was introd
On Fri, May 30, 2025 at 3:00 PM Nisha Moond wrote:
>
> Agree that we need to cover the simple pg_dump and pg_restore with the patch.
>
> When pg_dump and pg_restore are used outside of pg_upgrade, there's no
> guarantee that the target system does not have any prepared
> transactions. In such case
Hi Hackers,
Here is a new thread for the next part of SQL:2011 Application Time: UPDATE and DELETE commands with
FOR PORTION OF. This continues the long-running thread that ended with [1].
I don't have a new patch set yet, but I wanted to summarize the discussion at the PGConf.dev
Advanced Pa
31.05.2025 06:00, Alexander Lakhin wrote:
Hello Thomas,
It looks like I managed to restore all the conditions needed to reproduce
that Assert more or less reliably (within a couple of hours), so I can
continue experiments.
I've added the following debugging:
...
With additional logging (the p
On Thu, May 1, 2025 at 5:36 AM Masahiko Sawada wrote:
> HEAD PATCHEDDIFF
> case-1: 3,021 ms 2.818 ms93.29%
> case-2: 5, 697 ms 5.545 ms97.34%
> case-3: 2,833 ms 2.790 ms98.48%
> case-4: 2,564 ms 2.279 ms88.86%
> case
Hi,
On Mon, Jun 2, 2025 at 11:14 AM Dilip Kumar wrote:
>
> > (I haven't figured out how to force postgres to
> > create a visibility map for temp table within the transaction block).
>
> I haven't tested this, but I think if you do bulk copy into a table
> which should mark pages all visible and
On Mon, May 26, 2025 at 12:46 PM Zhijie Hou (Fujitsu)
wrote:
>
> Attaching the V32 patch set which addressed comments in [1]~[5].
>
Review comments:
===
*
+advance_conflict_slot_xmin(FullTransactionId new_xmin)
+{
+ FullTransactionId full_xmin;
+ FullTransactionId next_full_xid;
+
+ A
On 2025/06/02 14:24, David G. Johnston wrote:
On Sunday, June 1, 2025, Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
In v18, the "Protocol Version" column shown by \conninfo reports only
the major version (e.g., 3). Wouldn't it be more helpful to show the full
version (e.
On Sun, May 25, 2025 at 2:39 PM Etsuro Fujita wrote:
> Here is a new version of the patch where I added a comment for a new
> function, fixed indentation, and added the commit message. If there
> are no objections, I will push this as a master-only fix, as noted in
> the commit message.
Pushed a
> On 30 May 2025, at 8:27 AM, Noboru Saito wrote:
>
> Thank you Kuroda-san.
>
>> To confirm, generated pdf with current setting is left slide, and it would
>> become like right side, is it correct? I prefer right one.
>
> Sorry for the lack of explanation.
> That's right, the version on the
> On 30 May 2025, at 5:24 PM, Adam Brusselback
> wrote:
>
> Add me to the +1 for having a built-in scheduler. It's useful for plenty of
> things like automated partition creation (as noted), scheduling backups,
> index maintenance, batch processing jobs, etc...
>
> I wrote jpgAgent (compat
On Sun, Jun 1, 2025, at 08:24, Joel Jacobson wrote:
> On Sat, May 31, 2025, at 23:56, Tom Lane wrote:
>> "Joel Jacobson" writes:
>>> Foreign key constraints created during CREATE EXTENSION
>>> lack a pg_depend entry with deptype='e'.
>>
>> Why would it be a sensible thing for an extension to creat
On 2025-Jun-01, jian he wrote:
> hi.
>
> CREATE DOMAIN int_domain1 AS INT CONSTRAINT nn1 NOT NULL CONSTRAINT
> nn2 NOT NULL;
>
> will install two not-null pg_constraint entries.
> we should have only one?
Hmm, I think it would be more consistent to reject the case of duplicate
constraints, inst
Hello hackers,
Please take a look at the May report on buildfarm failures:
# SELECT br, count(*) FROM failures WHERE dt >= '2025-05-01' AND
dt < '2025-06-01' GROUP BY br;
REL_13_STABLE: 9
REL_14_STABLE: 11
REL_15_STABLE: 8
REL_16_STABLE: 13
REL_17_STABLE: 17
master: 25
-- Total: 83
(Counting tes
I wrote:
> So I propose the attached. For ease of review, I've not re-indented
> the code that needs to move inside PG_TRY blocks. Also, I dropped the
> logic about pfree'ing the string buffers in PLy_elog_impl's PG_FINALLY
> block: that doesn't seem necessary, and continuing to do it would
> req
38 matches
Mail list logo
