On Wed, Oct 01, 2025 at 03:39:35PM +0900, Michael Paquier wrote:
> + int32 ntuples;
> + ntuples = ((ginxlogUpdateMeta *) rec)->ntuples;
> + appendStringInfo(buf, "ntuples: %d", ntuples);
>
> In 0002. We have a routine for this type of as
On Tue, Oct 7, 2025, at 07:43, Tom Lane wrote:
> "Joel Jacobson" writes:
>> Trying to fix the NetBSD failure.
>> I don't understand why 001_constraint_validation, test 'list_parted2_def
>> scanned' and test 'part_5 verified by existing constraints' should be
>> affected by this patch. I guess I co
Erik Wienhold writes:
> On 2025-10-02 00:25 +0200, Tom Lane wrote:
>> I am not entirely sure that we should commit 0002 though; it may be
>> that the savings is down in the noise anyway once you consider all
>> the other work that happens while printing a big table.
> I see larger gains for queri
David Rowley writes:
> The reason I didn't go down the route of SETOP_VAR was that it's still
> a hack, it's just making it look a bit more official. I suppose the
> correct way to fix all this and get rid of the varno==0 stuff forever
> is to have a proper top-level RTE for the top-level set ope
On Fri, Oct 3, 2025 at 7:31 PM Alexander Korotkov wrote:
> On Thu, Sep 11, 2025 at 1:59 AM Thomas Munro wrote:
> > FWIW I'm working on a patch set that kills all backends without
> > releasing any locks when the postmaster exists. Then CVs and other
> > latch-based stuff should be safe in this c
On Mon, Oct 6, 2025, at 22:11, Joel Jacobson wrote:
> The patch is now using dshash. I've been looking at code in launcher.c
> when implementing it. The function init_channel_hash() ended up being
> very similar to launcher.c's logicalrep_launcher_attach_dshmem().
Noticed a mistake on one line jus
On Sun, Oct 5, 2025 at 11:52 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Mon, Oct 06, 2025 at 10:50:52AM +0530, Ashutosh Bapat wrote:
> > On Fri, Oct 3, 2025 at 11:48 PM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, Oct 3, 2025 at 9:26 AM Ashutosh Bapat
> > > wrote:
> > > >
> > > > On Fri, Oct 3
On Mon, Sep 29, 2025 at 1:52 AM vignesh C wrote:
>
> On Fri, 26 Sept 2025 at 05:29, Masahiko Sawada wrote:
> >
> > On Thu, Jul 3, 2025 at 7:55 AM vignesh C wrote:
> > >
> > > On Wed, 2 Jul 2025 at 13:21, Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > > > On Wed, Jul 2, 2025 at 2:42 PM vignesh C
Hi,
On 2025-10-06 13:22:59 -0400, Bruce Momjian wrote:
> On Mon, Oct 6, 2025 at 01:06:21PM -0400, Andres Freund wrote:
> > On 2025-10-06 12:57:20 -0400, Bruce Momjian wrote:
> > > Add in cache effects for all of these storage devices as outlined in our
> > > docs.
> >
> > As discussed in [1], th
Hi. Added a fatal message about an incorrect track_commit_timestamp parameter for new cluster. Update test.Fail check:Checking for new cluster tablespace directories okChecking for pg_commit_ts "track_commit_timestamp" must be "on" but is set to "o
On Mon, Oct 6, 2025 at 11:14:13AM -0400, Andres Freund wrote:
> > It obviously contradicts the advice to set the value closer to 1.0. But
> > why is that? SSDs are certainly better with random I/0, even if the I/O
> > is not concurrent and the SSD is not fully utilized. So the 4.0 seems
> > off, t
On Mon, Oct 6, 2025 at 11:12:00AM +0200, Tomas Vondra wrote:
> On 10/6/25 11:02, Michael Banck wrote:
> > Hi,
> >
> > On Mon, Oct 06, 2025 at 02:59:16AM +0200, Tomas Vondra wrote:
> >> I started looking at how we calculated the 4.0 default back in 2000.
> >> Unfortunately, there's a lot of info,
Hi,
On 2025-10-06 01:53:05 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2025-10-06 at 01:29 -0400, Tom Lane wrote:
> >> But if what
> >> we're trying to model is net resource demands, with an eye to
> >> minimizing the total system load not execution time of any one query,
> >> maybe
Hi,
On 2025-10-06 02:59:16 +0200, Tomas Vondra wrote:
> So I decided to try doing this on a couple different devices, and see
> what random_page_cost values that gives me. Attached is a script doing
> such benchmark:
>
> (1) initializes a new cluster, with a couple parameters adjusted
>
> (2) cr
On Fri, Oct 3, 2025 at 10:41:56AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > If you look at this more closely, creating postgres-full.xml and running
> > the syntax check perform the same operations, except that the latter
> > throws away the output. So it seems redundant to build a
On Mon, 6 Oct 2025 at 13:59, Richard Guo wrote:
> Barring any objections, I'll plan to push v23 in a couple of days.
Not a complete review, but a customary look:
1. setup_base_grouped_rels() by name and the header comment claim to
operate on base relations, but the code seems to be coded to hand
On 2025-Sep-05, Nazir Bilal Yavuz wrote:
> Hi,
>
> I have been working on generating differential code coverage for
> Postgres and was able to do so with this script [1]. The script checks
> out HEAD and the latest release branch (currently REL_18_STABLE), then
> generates a differential coverage
Hi all,
In a recent debug I found two process conflict on relation extension lock,
one is holding it for MAIN fork extension, while the other one is trying to
do FSM extension. It seems that the extension lock is using the logical relid
of a table as lock tag, but smgrextend is independant among e
On Wed, Oct 1, 2025 at 2:15 PM Michael Banck wrote:
> > > That might be a lot of files to open.
> >
> > I was afraid of that, but let's say modern high-end is 200TB big DB,
> > that's like 200*1024 1GB files, but I'm getting such time(1) timings
> > for 204k files on ext4:
> >
> > $ time ./create
> On 6 Oct 2025, at 11:16, Rahila Syed wrote:
>
> Can you please explain the scenarios in which the record pointer of the WAL
> record written
> by the receiver can move backwards.
> For example, in physical replication, the WAL records are sent after a Flush
> on the primary in ascending
20 matches
Mail list logo
