On Wed, Jun 25, 2025 at 01:12:02PM -0400, shihao zhong wrote:
> Just want to make sure, are we not going to include my original test
> to catch the future regression? Also, could someone please let me know
> how to check if the test is stable or not?
On stable branches, you could reuse the patch I
On Wed, Jun 25, 2025 at 08:58:05PM +0300, Aleksander Alekseev wrote:
>> These files were moved to src/backend/lib
>
> That is - src/common. Sorry for the confusion.
No problem, good catches. Agreed to remove these references in the
README of backend/lib/. Will fix if there are no objections.
--
On Thu, Jun 26, 2025 at 6:22 AM Michael Paquier wrote:
>
> On Wed, Jun 25, 2025 at 10:19:55PM +0530, vignesh C wrote:
> > Currently, the logic attempts to read the complete WAL record based on
> > the size obtained before the crash—even though only a partial record
> > was written. It then checks
On Mon, Jun 2, 2025 at 2:31 PM jian he wrote:
> On Thu, May 29, 2025 at 11:06 AM Richard Guo wrote:
> > Yeah, ATPrepAlterColumnType does seem like a better place. But we
> > need to ensure that ATColumnChangeRequiresRewrite sees the expanded
> > version of the expression — your proposed change f
Dear Alexander,
>
> Good idea. But I think we should associate the "updated" flag
> directly to the fact that one slot (no matter logical or physical)
> changed its last_saved_restart_lsn. See the attached patch. I'm
> going to push it if no objections.
+ /*
+* Tr
Dear Kuroda-san,
> Dear Ishii-san,
>
> Actually Saito-san has already been registered [1]. And cfbot said OK.
>
> [1]: https://commitfest.postgresql.org/patch/5775/
Thank you for pointing it out. Also I see Peter has been already
registered as a committer. Great.
Best regards,
--
Tatsuo Ishii
On 26/6/2025 07:40, Michael Paquier wrote:
Anyway, it seems to me that we may need to do something here before
the release. Note that if the consensus is "you should update your
module and not rely on the past behavior", I'm OK with that. I just
wanted to raise the issue before this goes GA. A
In the PG18 docs, I see:
https://www.postgresql.org/docs/18/protocol-message-formats.html
StartupMessage (F)
:
Int32(196608)
The protocol version number. The most significant 16 bits are the
major version number (3 for the protocol described here). The
least significant 16 bits are th
On Wed, Jun 25, 2025 at 10:31:35AM +0900, Michael Paquier wrote:
> On Tue, Jun 24, 2025 at 11:30:13AM -0500, Nathan Bossart wrote:
>> On Tue, Jun 24, 2025 at 10:18:18AM +0900, Michael Paquier wrote:
>> > Knowing that I'm indirectly responsible for this mess, I would like to
>> > take care of that m
On Wed, Jun 25, 2025 at 09:28:50AM +, Andy Fan wrote:
> Michael Paquier writes:
>> On Wed, Jun 25, 2025 at 07:47:27AM +, Andy Fan wrote:
>>> When I am reading the code, I first thought I can do something in
>>> HeapTupleheaderSetXminCommitted, then I realized we have SetHintBits.
>>> After
On 2025/06/25 20:46, Álvaro Herrera wrote:
On 2025-Jun-25, Fujii Masao wrote:
From 516e647e7d1fdafc64dba092389963f32cd688e5 Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date: Wed, 25 Jun 2025 10:02:56 +0900
Subject: [PATCH v2] Make CREATE TABLE LIKE copy comments on NOT NULL
constraints wh
Hi Greg
On 25.06.25 17:17, Greg Sabino Mullane wrote:
> Seems transaction_read_only might be a more useful thing to examine?
> That's the side-effect, if you will, that people really care about
> when in hot standby mode (and of course, we can get into TRO other ways).
Good point. But wouldn't it
Daniel Gustafsson writes:
> I spent a little bit of time reading over all the implementations and cross
> referencing the API for conformity, and came up with the attached. The 0001
> patch is the one from upstream, and each subsequent commit is fixing one
> function for all the implementations.
On 2025/06/25 22:36, Álvaro Herrera wrote:
On 2025-Jun-25, Álvaro Herrera wrote:
Yeah, I think in this case we need to extract the constraint name so
that we have it available to print the COMMENT command, rather than
making any assumptions about it. In fact I suspect this would fail if
the
On 2025-Jun-26, Fujii Masao wrote:
> CREATE TABLE ctlt1_inh (LIKE ctlt1 INCLUDING CONSTRAINTS INCLUDING COMMENTS)
> INHERITS (ctlt1);
> \d+ ctlt1_inh
> -SELECT description FROM pg_description, pg_constraint c WHERE classoid =
> 'pg_constraint'::regclass AND objoid = c.oid AND c.conrelid =
> '
On 2025-Jun-26, Fujii Masao wrote:
> However, with the patch applied, I encountered a segmentation fault in pg_dump
> as follows:
Ah, thanks for the test case. Yeah, I removed one 'if' condition too
many from Jian's patch. We just need to test the constraint name for
nullness and then things se
Hi,
On Tue, 24 Jun 2025 at 07:13, Masahiko Sawada wrote:
>
Thank you for working on this!
> On Tue, Jun 24, 2025 at 4:21 AM Melanie Plageman
> wrote:
> >
> > Hi,
> >
> > In dc6acfd910b8, I added some counters to track and log in
> > autovacuum/vacuum output the number of pages newly set
> > al
Hi,
Buildfarm identified one issue at [1] where it could not identify a
partial WAL record spanning across 2 pages was written due to
immediate shutdown.
Consider a scenario where a WAL record is split across multiple WAL
pages. If the server crashes before the entire WAL record is written,
the r
On Wed, Jun 25, 2025 at 11:04 PM Fujii Masao
wrote:
> >>
> >> This commit corrects the behavior by ensuring CREATE TABLE LIKE to also
> >> copy
> >> the comments on NOT NULL constraints when INCLUDING COMMENTS is specified.
> >
> > LGTM. I'd add a line in the test showing that these comments are
101 - 119 of 119 matches
Mail list logo
