On Sat, Mar 1, 2025 at 10:50 AM Sutou Kouhei wrote:
>
> Hi,
>
> Our 0001/0002 patches were merged into master. I've rebased
> on master. Can we discuss how to proceed rest patches?
>
> The contents of them aren't changed but I'll show a summary
> of them again:
>
> 0001-0003 are for COPY TO and 00
Gurjeet Singh writes:
> On Sat, Mar 1, 2025 at 10:26 PM Tom Lane wrote:
>> This looks reasonably in line with project style ...
> Should I create a commitfest entry for this patch, or is it
> uncontroversial enough and small enough to not warrant that?
The controversy would be more about whethe
On Sat, Mar 1, 2025 at 10:26 PM Tom Lane wrote:
>
> Gurjeet Singh writes:
> > I propose the following change to the generation script,
> > generate-lwlocknames.pl
> > ...
> > which produces the lock names in this format
>
> > #define ShmemIndexLock (&MainLWLockArray[1].lock)
> > #
Gurjeet Singh writes:
> I propose the following change to the generation script,
> generate-lwlocknames.pl
> ...
> which produces the lock names in this format
> #define ShmemIndexLock (&MainLWLockArray[1].lock)
> #define OidGenLock (&MainLWLockArray[2].lock)
>
Currently the contents of lwlocknames.h look like this:
#define ShmemIndexLock (&MainLWLockArray[1].lock)
#define OidGenLock (&MainLWLockArray[2].lock)
#define XidGenLock (&MainLWLockArray[3].lock)
#define ProcArrayLock (&MainLWLockArray[4].lock)
#define SInvalReadLock (&MainLWLockArray[5].lock)
.
On Mon, Jan 27, 2025 at 4:17 PM jian he wrote:
>
> hi.
>
> There are two ways we can use to represent the new copy format: json.
> 1.
> typedef struct CopyFormatOptions
> {
> boolbinary;/* binary format? */
> boolfreeze;/* freeze rows on loading? */
I've spent quite a bit of time recently trying to get this patch set into a
reasonable state. It's still a little rough around the edges, and the code
for the generated scripts is incomplete, but I figured I'd at least get
some CI testing going.
--
nathan
>From 0af23114cfe5d00ab0b69ff804bb92d58d
>
> Independently of that, do we want to switch over to storing
> reltuples as a string instead of converting it? I still feel
> uncomfortable about the amount of baggage we added to pg_dump
> to avoid that.
I'm obviously a 'yes' vote for string, either fixed width buffer or
pg_strdup'd, for the
Peter Geoghegan writes:
> Is everybody in agreement about committing and back patching this fix,
> which simply disables the optimization altogether?
> I myself don't see a better way, but thought I'd ask before proceeding
> with review and commit.
If you don't see a clear path forward, then "dis
On Fri, Feb 28, 2025 at 12:53 PM Matthias van de Meent
wrote:
> Rebased again, now on top of head due to f7a8fc10.
Is everybody in agreement about committing and back patching this fix,
which simply disables the optimization altogether?
I myself don't see a better way, but thought I'd ask before
jian he writes:
> So I duplicated StoreAttrDefault and removed pg_attribute.atthasdef,
> pg_attrdef related code.
> and it works fine.
I think the fundamental problem here is that StoreAttrDefault
shouldn't be involved in this in the first place. It looks like
somebody did that in the hopes of a
On Thu, Feb 27, 2025 at 7:57 PM Peter Geoghegan wrote:
> On Thu, Feb 27, 2025 at 3:42 PM Robert Haas wrote:
> > Good documentation could help.
Attached revision adds an example that shows how "Index Searches: N"
can vary. This appears in "14.1.2. EXPLAIN ANALYZE".
Other changes in this revision
Hi,
The 0001* patch improved the accounting for the shared memory allocated for
a
hash table during hash_create.
pg_shmem_allocations tracks the memory allocated by ShmemInitStruct, which,
for shared hash tables, only covers memory allocated for the hash
directory
and control structure via ShmemIn
Tom-
I understand that you are concerned about future maintenance costs vs
benefits of this change. I hope that I can address those concerns. An
important thing to note is that there are two different structures that
represent numeric values:
* NumericData is an opaque structure that is def
On Sat, 1 Mar 2025 at 17:33, Tom Lane wrote:
> But IMO you still haven't made an acceptable case
> for deciding that these data structures aren't private to numeric.c.
> What behaviors do you actually need that aren't accessible via the
> existing exported functons?
FWIW in pg_duckdb we would def
Jeff Davis writes:
> On Sat, 2025-03-01 at 13:52 -0500, Greg Sabino Mullane wrote:
>> Also, anything trained to parse pg_dump output will have to learn
>> about the new SELECT pg_restore_ calls with their multi-line formats
>> (not 100% sure we don't have that anywhere, as things like "SELECT
>> s
On Sat, 2025-03-01 at 13:52 -0500, Greg Sabino Mullane wrote:
> > Can you expand on some of those cases?
>
> Certainly. I think one of the problems is that because this patch is
> solving a pg_upgrade issue, the focus is on the "dump and restore"
> scenarios. But pg_dump is used for much more than
Tom-
I think that I can allay your concerns. Please give me a day or so to
put together my more complete thoughts on the matter. I'll be in touch.
-Ed
On Sat, Mar 1, 2025 at 11:33 AM Tom Lane wrote:
> Ed Behn writes:
> >> There is actually no new code. Code is simply moved
On Fri, 2025-02-28 at 14:56 -0600, Nathan Bossart wrote:
> On Fri, Feb 28, 2025 at 12:54:03PM -0800, Jeff Davis wrote:
> > (Aside: I assume everyone here agrees that pg_upgrade should
> > transfer
> > the stats by default.)
>
> That feels like a safe assumption to me... I'm curious what the use-
Alexander Lakhin writes:
> 01.03.2025 20:04, Tom Lane wrote:
>> I was suspecting those float conversions as a likely cause, but
>> what do you think is wrong exactly? I see nothing obviously
>> buggy in pg_strtof().
> From my understanding, pg_strtof () can't stand against endptr == NULL.
D'oh
> Can you expand on some of those cases?
Certainly. I think one of the problems is that because this patch is
solving a pg_upgrade issue, the focus is on the "dump and restore"
scenarios. But pg_dump is used for much more than that, especially "dump
and examine".
Although pg_dump is meant to be a
Alexander Lakhin writes:
> It looks like 8f427187d broke pg_dump on Cygwin:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2025-02-26%2010%3A03%3A07
Yeah, Andrew and I have been puzzling over that off-list. pg_dump
is definitely exiting unceremoniously.
> As far as I can
Hello Tom,
01.03.2025 20:04, Tom Lane wrote:
Alexander Lakhin writes:
It looks like 8f427187d broke pg_dump on Cygwin:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2025-02-26%2010%3A03%3A07
Yeah, Andrew and I have been puzzling over that off-list. pg_dump
is definitel
On Fri, Feb 28, 2025 at 3:09 PM Thom Brown wrote:
> "pg_overexplain"? I love this name! And the idea sounds like a natural
> evolution, so +1.
Thanks. I thought about things like pg_hyperexplain or
pg_explain_debug, but in the end I didn't like any of them better than
overexplain. :-)
> One thin
I noticed that the patch needs rebasing, so here is the rebased version.
Hopefully it makes to the commitfest.
Doruk Yılmaz
From 74a74fd02bce786093c19a23bef9444d0b8ef41d Mon Sep 17 00:00:00 2001
From: Doruk
Date: Thu, 15 Aug 2024 23:34:26 +0300
Subject: [PATCH v4] pg_replication_origin_session_se
On Sat, Mar 01, 2025 at 08:57:52AM +0800, wenhui qiu wrote:
> Based on the comments, the pcnt_unfrozen value could potentially be 0,
> which would indicate that everything is frozen. Therefore, is it necessary
> to handle the case where the value is 0.？
How so? If it's 0, then the insert thre
Hello Jeff,
26.02.2025 04:00, Jeff Davis wrote:
I plan to commit the patches soon.
It looks like 8f427187d broke pg_dump on Cygwin:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2025-02-26%2010%3A03%3A07
As far as I can see, it exits prematurely here:
flo
Ed Behn writes:
>> There is actually no new code. Code is simply moved from numeric.c to
>> numeric.h.
I will absolutely not hold still for that. It would mean that any
time we want to think about messing with the contents of numerics,
we need to examine more or less the whole Postgres code base
Upon further review, I've updated the patch. This avoids possible name
conflicts with other functions. See attached.
On Sat, Feb 8, 2025 at 3:24 PM Ed Behn wrote:
> I've created a patch (attached) to implement the changes discussed below.
>
> This change moves the definition of the NumericVar st
On Fri, 28 Feb 2025 at 23:31, Mark Dilger wrote:
> The only obvious definition of "wrong" for this is that gin index scans
> return different result sets than table scans over the same data. Using your
> much smaller reproducible test case, and adding rows like:
Yeach, you are 100% right. Act
On Sat, Mar 1, 2025 at 2:43 PM Tom Lane wrote:
>
> I do not believe that case should require a table rewrite.
> Both the default and the check constraint are immutable,
> so we ought to be able to apply the check once and then
> use the default as the attmissingval.
>
> > Attach a patch to fix thi
On Fri, 28 Feb 2025 at 19:26, Robert Haas wrote:
>
> Prior to PostgreSQL 10, EXPLAIN had just 2 options: VACUUM and
> ANALYZE. Now, we're up to 12 options, which is already quite a lot,
> and there's plenty more things that somebody might like to do.
> However, not all of those things necessarily
On Fri, Feb 28, 2025 at 2:40 PM Robert Haas wrote:
> Maybe we should rethink the decision not to transfer relfilenodes for
> sequences. Or have more than one way to do it. pg_upgrade
> --binary-upgrade --binary-upgrade-even-for-sequences, or whatever.
Sorry, I meant: pg_dump --binary-upgrade --bi
On Mon, Feb 3, 2025 at 4:23 AM Peter Smith wrote:
>
> A recent commit [1] added a new section "29.6. Generated Column
> Replication" to the documentation [2]. But, no "Examples" were
> included.
>
> I've created this new thread to make a case for adding an "Examples"
> subsection to that page.
>
>
On Sat, Mar 1, 2025 at 6:24 AM Nazir Bilal Yavuz wrote:
> I think I found the problem, sd0j's fstype is not a swap. It worked like that:
>
> $ disklabel -E sd0
> $ umount /usr/obj
> $ disklabel -E sd0 # prompts are: m -> j -> \n -> \n -> swap -> w -> q
> $ disklabel -E sd0
> $ swapon /dev/sd0j # r
On Sat, Mar 1, 2025 at 9:20 AM Noah Misch wrote:
>
> On Fri, Feb 28, 2025 at 12:07:26PM -0500, Tom Lane wrote:
> >
> > PGCAC holds trademarks on both "PostgreSQL" and "Postgres". We've
> > been given legal advice that both terms need to be in current use
> > to preserve the trademarks. Which the
On Thu, Feb 13, 2025 at 6:48 AM Masahiko Sawada wrote:
>
> Thank you for updating the patch! The patch looks mostly good to me.
>
+ /*
+ * Prior to PostgreSQL 18, max_replication_slots was used to set the
+ * number of replication origins. For backward compatibility, -1 indicates
+ * to use the f
Hi everyone,
I have finally been able to test the patch in a Kubernetes environment with
CloudNativePG, thanks to Niccolò Fei and Marco Nenciarini, who created a
pilot patch for CloudNativePG (
https://github.com/cloudnative-pg/cloudnative-pg/pull/6546).
In the meantime, Kubernetes is likely addi
On 28.02.2025 14:48, Alena Rybakina wrote:
Hi!
On 21.02.2025 00:09, Alena Rybakina wrote:
Hi!
On 09.02.2025 18:38, Alexander Korotkov wrote:
Also, aren't we too restrictive while requiring is_simple_values_sequence()?
For instance, I believe cases like this (containing Var) could be transfo
On Fri, 24 Jan 2025 at 13:00, Aleksander Alekseev
wrote:
>
> Thank you. Here is the corrected patch.
>
This looks pretty good to me. I have a just a couple of minor comments:
* The loop in bytea_integer() can be written more simply as a "for"
loop. Given that it's only a few lines of code, it mi
On Fri, Feb 28, 2025 at 11:27 PM Fujii Masao
wrote:
> On 2025/02/28 9:24, Ryo Kanbayashi wrote:
> > I have rewrote my patch on TAP test sttyle :)
> > File for build are also updated.
>
> Thanks for updating the patch!
Thanks for review:)
>
> +'tests': [
> + 't/001_ecpg_notice.pl',
> +
>> > I don't think "another extension might use it someday" makes a very strong
>> > case,
>> > particularly for something that requires a new dependency.
>>
>> The x86-simdsort library is an optional dependency in Postgres. Also the new
>> list sort implementation which uses the x86-simdsort lib
On Fri, Feb 28, 2025 at 12:12 PM Thom Brown wrote:
> Rebased and attached.
Thanks, committed. Sorry for the mistake and thanks for the patch.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi
pá 28. 2. 2025 v 7:29 odesílatel Pavel Stehule
napsal:
> Hi
>
> čt 27. 2. 2025 v 21:45 odesílatel Tom Lane napsal:
>
>> Pavel Stehule writes:
>> > čt 27. 2. 2025 v 20:52 odesílatel Tom Lane napsal:
>> >> So taken together, our results are all over the map, anywhere
>> >> from 7% speedup to
44 matches
Mail list logo
