On Thu, Apr 24, 2025 at 9:56 PM Amit Kapila wrote:
>
> On Fri, Apr 25, 2025 at 8:14 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Fri, Apr 25, 2025 at 5:44 AM Masahiko Sawada wrote:
> > > On Tue, Apr 22, 2025 at 12:06 AM Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > When an
On Thu, 24 Apr 2025 at 14:39, Amit Kapila wrote:
>
> On Wed, Apr 23, 2025 at 10:28 PM Masahiko Sawada
> wrote:
> >
> > >
> > > Fair enough. OTOH, we can leave the 13 branch considering following:
> > > (a) it is near EOL, (b) bug happens in rare cases (when the DDLs like
> > > ALTER PUBLICATION
On Fri, Apr 25, 2025 at 8:14 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Fri, Apr 25, 2025 at 5:44 AM Masahiko Sawada wrote:
> > On Tue, Apr 22, 2025 at 12:06 AM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > Hi,
> > >
> > > When analyzing some issues in another thread[1], I found a bug that
> > > fast fo
On Thu, Apr 24, 2025 at 6:11 PM Zhijie Hou (Fujitsu)
wrote:
> > Few comments for patch004:
> > Config.sgml:
> > 1)
> > +
> > +Maximum duration (in milliseconds) for which conflict
> > +information can be retained for conflict detection by the apply
> > worker.
> > +
On Fri, Apr 25, 2025 at 5:44 AM Masahiko Sawada wrote:
(Resending this email after compressing the attachment)
> On Tue, Apr 22, 2025 at 12:06 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > Hi,
> >
> > When analyzing some issues in another thread[1], I found a bug that
> > fast forward decoding could
On Mon, Apr 7, 2025 at 10:04 PM Heikki Linnakangas wrote:
> I'm surprised how big the difference is, because I actually expected the
> compiler to detect the memory-zeroing loop and replace it with some
> fancy vector instructions (does powerpc have any?).
It certainly does, and we've played with
Daniel Gustafsson 于2025年4月16日周三 22:20写道：
> > On 14 Apr 2025, at 15:34, Tender Wang wrote:
> >
> > Hi,
> >
> > While reading the estimate_multivariate_ndistinct(),
> > I think "If a match it found, *varinfos is
> > * updated to remove the list of matched varinfos"
> > should be "If a match is f
On Wed, Apr 23, 2025 at 11:59:26AM -0400, Robert Haas wrote:
> That's nice to know, but I think the key question is not so much what
> the feature costs when it is used but what it costs when it isn't
> used. If we implement a system where we don't let
> dictionary-compressed zstd datums leak out o
On Thu, Apr 24, 2025 at 10:48 AM Masahiko Sawada wrote:
>
> On Thu, Apr 24, 2025 at 2:24 AM Nisha Moond wrote:
> >
> > On Thu, Apr 24, 2025 at 12:28 PM Amit Kapila
> > wrote:
> > >
> > > On Wed, Apr 23, 2025 at 11:04 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Tue, Apr 22, 2025 at 3:00
On Thu, Apr 24, 2025 at 03:34:29PM +, David Steele wrote:
> Done. This means there are no commas in the upper bound but I don't think
> it's a big deal and it more closely matches other GUC messages.
One thing that I have double-checked is if we have similar messages
for GUCs that are defined
On Mar 19, 2025, at 13:29, David E. Wheeler wrote:
> I think this should at least be documented, but generally feels unexpected to
> me. I’ve attached a patch that fleshes out the docs, along with an example of
> setting `extension_control_path` and `dynamic_library_path` to use the
> location
On Apr 24, 2025, at 11:18, Matheus Alcantara wrote:
> In v2 I've moved the logic to remove the /extension to
> parse_extension_control_file(), do you think that this Assert on this
> function would still be wrong? IIUC we should always have /extension at
> the end of "control_dir" at this place,
On Thu, 24 Apr 2025 at 23:52, Jelte Fennema-Nio wrote:
> How about we add a *compile time*
> option that allows the person that compiles libpq to choose which cert
> store it should use if sslrootcert=system is provided. Something like
> --system-cert-store=openssl and --system-cert-store=winstore
On Thu, 24 Apr 2025 at 18:46, Jacob Champion
wrote:
>
> On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut wrote:
> > I'm generally in favor of making sslmode=verify-full the effective
> > default somehow.
>
> +many
Yes, +many
> Not to derail things too much, but I'd also like a postgress://
> sc
On Wed, 23 Apr 2025 at 17:47, George MacKerron wrote:
> I’d suggest two new special sslrootcert values:
>
> (1) sslrootcert=openssl
>
> This does exactly what sslrootcert=system does now, but is less confusingly
> named for Windows users. sslrootcert=system becomes a deprecated synonym for
> thi
Hi,
On Tue, Apr 22, 2025 at 12:06 AM Zhijie Hou (Fujitsu)
wrote:
>
> Hi,
>
> When analyzing some issues in another thread[1], I found a bug that fast
> forward
> decoding could lead to premature advancement of catalog_xmin, resulting in
> required catalog data being removed by vacuum.
>
> The is
On Fri, 21 Mar 2025 at 17:14, Matthias van de Meent
wrote:
> Attached is v10, which polishes the previous patches, and adds a patch
> for nbtree to use the new visibility checking strategy so that it too
> can release its index pages much earlier, and adds a similar
> visibility check test to nbtr
On 2025-Apr-09, jian he wrote:
> hi.
>
> attached patch is for address pg_dump inconsistency
> when parent is "not null not valid" while child is "not null".
Here's my take on this patch. We don't really need the
notnull_parent_invalid flag; in flagInhAttrs we can just set "islocal"
to convince
Hi,
I also tested the patch on Linux mint 22.1 with the btrfs and ext4
partitions. I generated some data and the outcome looks good:
postgres=# \db+
List of tablespaces
Name | Owner | Location | Access
privile
Peter Eisentraut writes:
> There are approximately 6 buildfarm members with RHEL 7 or CentOS 7, so
> in that sense, "support" means that everything is expected to work
> there. And some amount of work has been done recently to keep that
> support alive.
Yeah. Devrim's choice of what to packa
> pgstat_progress_start_command() is called twice: First with
> cmdtype=PROGRESS_COMMAND_CLUSTER, second with
> PROGRESS_COMMAND_CREATE_INDEX. The first happens in cluster_rel() the second
> in cluster_rel() -> rebuild_relation() -> finish_heap_swap() ->
> reindex_relation() -> reindex_index().
>
>
Hi! Recently we faced a problem in out production psql installation, which was that we had to cancel all requests to the db, including performance monitoring requests, that uses ps_stat_statements. But we could not cancel the request in usual way, and had to kill -9 the pg process of it. We've noti
On Thu, Apr 24, 2025 at 2:24 AM Nisha Moond wrote:
>
> On Thu, Apr 24, 2025 at 12:28 PM Amit Kapila wrote:
> >
> > On Wed, Apr 23, 2025 at 11:04 PM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Apr 22, 2025 at 3:00 AM Amit Kapila
> > > wrote:
> > > >
> > > > On Mon, Apr 21, 2025 at 8:44 AM Z
On Wed, Apr 23, 2025 at 8:47 AM George MacKerron wrote:
> I’d suggest two new special sslrootcert values:
>
> (1) sslrootcert=openssl
>
> This does exactly what sslrootcert=system does now, but is less confusingly
> named for Windows users. sslrootcert=system becomes a deprecated synonym for
> t
On Thu, Apr 24, 2025 at 5:30 AM Amit Kapila wrote:
>
> On Wed, Apr 23, 2025 at 9:35 PM Masahiko Sawada wrote:
> >
> > On Wed, Apr 23, 2025 at 5:46 AM Amit Kapila wrote:
> > >
> > > BTW, did we consider the idea to automatically transition to 'logical'
> > > when the first logical slot is created
Isaac Morland writes:
> On Thu, 24 Apr 2025 at 05:53, Ashutosh Bapat
> wrote:
>> If there's any problem, IMO, ALTER TABLE ... RENAME ... should rename the
>> sequence too since the identity sequences are created implicitly when the
>> table is created, so they should be renamed implicitly. We sho
On Thu, 24 Apr 2025 at 05:53, Ashutosh Bapat
wrote:
> If there's any problem, IMO, ALTER TABLE ... RENAME ... should rename the
> sequence too since the identity sequences are created implicitly when the
> table is created, so they should be renamed implicitly. We should not
> require WITH SEQUE
On Wed, Apr 23, 2025 at 1:13 PM Christoph Berg wrote:
> Uhm, so far the plan was to have one "libpq-oauth" package, not several.
I think the system is overconstrained at that point. If you want to
support clients that delay-load the ABI they're compiled against,
_and_ have them continue to work s
On Thu, Apr 24, 2025 at 5:00 AM Peter Eisentraut wrote:
> I'm generally in favor of making sslmode=verify-full the effective
> default somehow.
+many
On Thu, Apr 24, 2025 at 3:53 AM Christoph Berg wrote:
> For
> postgresql://-style strings, we would ideally have something like http://
> vs http
> On 24 Apr 2025, at 19:10, Tom Lane wrote:
>
> I thought about that but intentionally left it as-is, because that
> would force zeroing of the space reserved for the hashtable name too.
> That's unnecessary, and since it'd often be odd-sized it might result
> in a less efficient fill loop.
W
On Thu, Apr 24, 2025 at 7:59 AM Tom Lane wrote:
> I'm still content with the idea of deciding that 3.6 is now our
> cutoff.
Seems like no one is pushing hard for an earlier version, yet, so
here's a patch with your suggested wording from upthread. I'm not sure
if this meets Peter's request for pr
On 2/14/25 02:42, Michael Paquier wrote:
On Fri, Jan 24, 2025 at 01:36:45PM +, David Steele wrote:
+ timeline = strtoull(*newval, &endp, 0);
+
+ if (*endp != '\0' || errno == EINVAL || errno == ERANGE)
{
GUC_check_errdetail
On Thu, Apr 24, 2025 at 7:21 AM Christoph Berg wrote:
>
> Re: Matheus Alcantara
> > I've tested with the semver extension and it seems to work fine with
> > this patch. Can you please check on your side to see if it's also
> > working?
>
> Hi Matheus,
>
> thanks for the patch, it does indeed work.
On Thu, Apr 24, 2025 at 04:51:08PM +0200, Álvaro Herrera wrote:
> On 2025-Apr-24, Bruce Momjian wrote:
>
> > Do we think most people are _not_ going to use pg_upgrade now that we
> > are defaulting to checksums being enabled by default in PG 18? And if
> > so, do we think we are ever going to hav
On 2025-Apr-24, Bruce Momjian wrote:
> Do we think most people are _not_ going to use pg_upgrade now that we
> are defaulting to checksums being enabled by default in PG 18? And if
> so, do we think we are ever going to have a storage-format-changing
> release where pg_upgrade cannot be used?
Pe
Hi Alexander,
Thank you for the review. I apologize for a late reply. I missed your email.
> 1) As ReplicationSlotsComputeRequiredLSN() is called each time we need
> to advance the position of WAL needed by replication slots, the usage
> pattern probably could be changed. Thus, we probably need
On 2/10/25 16:56, Tomas Vondra wrote:
On 2/10/25 10:09, Andrei Lepikhov wrote:
On 8/2/2025 20:50, Tomas Vondra wrote:
The main profit here - you see all the stats involved in estimations
(and their state), even if final plan doesn't contain estimated stuff at
all.
OK, that seems very underwh
Tender Wang 于2025年4月14日周一 14:17写道：
> Hi,
>
> While I debug hashjoin codes, in estimate_multivariate_bucketsize(), I
> find that
> the list_copy(hashclauses) below is unnecessary if we have a single join
> clause.
>
> List *clauses = list_copy(hashclauses);
> ...
>
> I adjust the place of l
Hi, Greg and David
Thank you for your feedback.
On Thu, 24 Apr 2025 at 08:26, Greg Sabino Mullane wrote:
> On Thu, Apr 24, 2025 at 7:31 AM David Rowley wrote:
>
> On Thu, 24 Apr 2025 at 21:27, Japin Li wrote:
> > I propose that PostgreSQL prevent redundant index creation by:
>
>
> In an
Andrey Borodin writes:
> While fixing this maybe use MemoryContextAllocZero() instead of subsequent
> MemSet()?
I thought about that but intentionally left it as-is, because that
would force zeroing of the space reserved for the hashtable name too.
That's unnecessary, and since it'd often be odd
On Thu, Apr 24, 2025 at 08:37:56AM -0400, Bruce Momjian wrote:
> On Thu, Apr 24, 2025 at 08:35:10AM -0400, Greg Sabino Mullane wrote:
> > On Thu, Apr 24, 2025 at 8:12 AM Bruce Momjian wrote:
> >
> > Do we think most people are _not_ going to use pg_upgrade now that we
> > are defaulting t
On 3/28/25 09:19, Alexander Pyhalov wrote:
Andy Fan писал(а) 2024-10-17 03:33:
I've updated patch. One more interesting case which we found - when
fractional path is selected, it still can be more expensive than sorted
cheapest total path (as we look only on indexes whith necessary
pathkeys, n
Re: Nathan Bossart
> Here is what I have staged for commit. I'll aim to commit these patches
> sometime next week to give time for additional feedback.
I confirm my PG13 test table gets analyzed now with the patch.
Christoph
On Thu, Apr 24, 2025 at 08:51:41AM -0400, Greg Sabino Mullane wrote:
> On Thu, Apr 24, 2025 at 8:37 AM Bruce Momjian wrote:
>
> When I wrote pg_upgrade, I assumed at some point the value of changing the
> storage format would outweigh the value of allowing in-place upgrades. I
> gues
On Thu, Apr 24, 2025 at 8:37 AM Bruce Momjian wrote:
> When I wrote pg_upgrade, I assumed at some point the value of changing the
> storage format would outweigh the value of allowing in-place upgrades. I
> guess that hasn't happened yet.
>
It reminds me of TDE, which is an good example of that
Hi,
Attached a rebased version of the patch.
--
Regards,
--
Atsushi Torikoshi
Seconded from NTT DATA GROUP CORPORATION to SRA OSS K.K.From 112467238f585bb3398d86ac6e1a71caa6549fb4 Mon Sep 17 00:00:00 2001
From: Atsushi Torikoshi
Date: Thu, 24 Apr 2025 20:50:41 +0900
Subject: [PATCH v44] Add fu
On Wed, Apr 23, 2025 at 9:35 PM Masahiko Sawada wrote:
>
> On Wed, Apr 23, 2025 at 5:46 AM Amit Kapila wrote:
> >
> > BTW, did we consider the idea to automatically transition to 'logical'
> > when the first logical slot is created and transition back to
> > 'replica' when last logical slot gets
On Thu, Apr 24, 2025 at 08:35:10AM -0400, Greg Sabino Mullane wrote:
> On Thu, Apr 24, 2025 at 8:12 AM Bruce Momjian wrote:
>
> Do we think most people are _not_ going to use pg_upgrade now that we
> are defaulting to checksums being enabled by default in PG 18?
>
>
> I cannot imagine t
On Thu, Apr 24, 2025 at 8:12 AM Bruce Momjian wrote:
> Do we think most people are _not_ going to use pg_upgrade now that we
> are defaulting to checksums being enabled by default in PG 18?
I cannot imagine this would stop anyone from upgrading. It's one additional
flag, which was already a req
On Thu, Apr 24, 2025 at 7:31 AM David Rowley wrote:
> On Thu, 24 Apr 2025 at 21:27, Japin Li wrote:
> > I propose that PostgreSQL prevent redundant index creation by:
> In any case, who are we to define what a duplicate index is?
I think this part is easier than you make it sound: everythin
Do we think most people are _not_ going to use pg_upgrade now that we
are defaulting to checksums being enabled by default in PG 18? And if
so, do we think we are ever going to have a storage-format-changing
release where pg_upgrade cannot be used?
Maybe it is too late to ask this, but I am askin
Hello,
While developing a patch and running regression tests I noticed that the
postmaster could fail to shut down right after crash restart. It could
get stuck in the PM_WAIT_BACKENDS state forever.
As far as I understand, the problem occurs when a shutdown signal is
received before getting
On 24.04.25 12:53, Christoph Berg wrote:
Now you can say `psql -h db.example.com -p 5433 dbfoo`, but for
specifying the sslmode, you have to rewrite at least the last argument
to use connection string syntax, `psql "dbname=dbfoo sslmode=verify-full`.
This needs be be less cumbersome. (And the nam
On 24.04.25 13:16, Jelte Fennema-Nio wrote:
On Thu, 24 Apr 2025 at 10:54, Peter Eisentraut wrote:
The cut-off in practice for these things is usually RHEL. PG18
currently still supports RHEL 7, which appears to come with Python 3.6.
Seeing that the small problem with the test script was easily
On Thu, 24 Apr 2025 at 21:27, Japin Li wrote:
> I propose that PostgreSQL prevent redundant index creation by:
>
> - Checking for identical existing indexes during CREATE INDEX.
> - Failing with an error (like Oracle's ORA-01408) if a duplicate is found.
> - Providing a GUC parameter (allow_redund
On 23.04.25 00:24, Tomas Vondra wrote:
The patch that flips the default has been committed.
I also started a PG18 open items page and made a note that we follow up
on the upgrade experience, as was discussed in this thread.
https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items
Regarding t
> On 24 Apr 2025, at 00:42, Tom Lane wrote:
>
> - hashp = (HTAB *) DynaHashAlloc(sizeof(HTAB) + strlen(tabname) + 1);
> + hashp = (HTAB *) MemoryContextAlloc(CurrentDynaHashCxt,
> + sizeof(HTAB) + strlen(tabname) + 1);
This seems correct to me.
While fixing this maybe use MemoryContextAllocZ
On Thu, 24 Apr 2025 at 10:54, Peter Eisentraut wrote:
> The cut-off in practice for these things is usually RHEL. PG18
> currently still supports RHEL 7, which appears to come with Python 3.6.
> Seeing that the small problem with the test script was easily fixed, I
> think we should stick with th
Re: George MacKerron
> > Before we can make this change, I think we would have to improve the
> > UX. psql does not even have any --switch for it. PostgreSQL serving
> > non-SSL and SSL on the same port doesn't make the UX better... :-/
>
> How do you think the UX could be improved? Maybe by using
On Thu, Apr 24, 2025 at 2:54 PM Nisha Moond wrote:
>
> Please find the updated patch for Approach 3, which implements the
> idea suggested by Swada-san above.
>
Thank You for the patch.
1)
CreateDecodingContext:
if (ctx->twophase && !slot->data.two_phase)
{
+ /*
+ * Do not allow two-phase
> On Linux/*ix, there would be 3 things that are all the same.
>
> If the Windows Openssl store is that bad, wouldn't the smarter thing
> to do for PG19 to use winstore by default? The Openssl one would still
> be available when requested explicitly. This would avoid the
> proliferation of default
Re: Matheus Alcantara
> I've tested with the semver extension and it seems to work fine with
> this patch. Can you please check on your side to see if it's also
> working?
Hi Matheus,
thanks for the patch, it does indeed work.
diff --git a/src/backend/commands/extension.c b/src/backend/commands/
On Tue, Apr 22, 2025 at 12:36 PM Zhijie Hou (Fujitsu)
wrote:
>
> When analyzing some issues in another thread[1], I found a bug that fast
> forward
> decoding could lead to premature advancement of catalog_xmin, resulting in
> required catalog data being removed by vacuum.
>
> The issue arises be
Hi,
I was a bit confused by this comment in keyGetItem() (ginget.c)
/*
* Normally, none of the items in additionalEntries can have a curItem
* larger than minItem. But if minItem is a lossy page, then there
* might be exact items on the same page among additionalEntries.
*/
AFAIS the code before
Hi Jason,
On Wed, Apr 23, 2025 at 6:06 PM Jason Song wrote:
> Hi hackers,
>
> I was wondering if there's any built-in functionality in PostgreSQL where
> renaming a table with an identity column would also rename the
> auto-generated sequence associated with that identity column.
>
> In my case,
On Thu Apr 24, 2025 at 01:59:10 GMT +03, Tom Lane wrote:
> Hm. I wonder if we couldn't get rid of the
> HAVE_XMLSTRUCTUREDERRORCONTEXT conditionalization. If the
> libxml2 versions that lacked that were "old" in 2011, surely
> they are extinct in the wild by now. I'm thinking that we
> really do
Sami Imseih wrote:
> >> pgstat_progress_start_command should only be called once by the entry
> >> point for the
> >> command. In theory, we could end up in a situation where start_command
> >> is called multiple times during the same top-level command;
>
> > Not only in theory - it actually hap
Hi, hackers
Currently, PostgreSQL permits creating multiple indexes on the same columns
in the same order for a table, potentially leading to redundant indexes.
For example:
CREATE INDEX ON t(id);
CREATE INDEX ON t(id);
While permitted, this leads to:
- Increased storage consu
On Thu, Apr 24, 2025 at 12:28 PM Amit Kapila wrote:
>
> On Wed, Apr 23, 2025 at 11:04 PM Masahiko Sawada
> wrote:
> >
> > On Tue, Apr 22, 2025 at 3:00 AM Amit Kapila wrote:
> > >
> > > On Mon, Apr 21, 2025 at 8:44 AM Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > > > On Sat, Apr 19, 2025 at 2:1
On Wed, Apr 23, 2025 at 10:28 PM Masahiko Sawada wrote:
>
> >
> > Fair enough. OTOH, we can leave the 13 branch considering following:
> > (a) it is near EOL, (b) bug happens in rare cases (when the DDLs like
> > ALTER PUBLICATION ... ADD TABLE ... or ALTER TYPE ... that don't take
> > a strong l
On 22.04.25 18:04, Tom Lane wrote:
Jacob Champion writes:
As for picking a version... 3.6 will have been EOL for almost three
years by the time 18 releases. It seems like we would drop it happily,
were it not for RHEL8.
Agreed, but RHEL8 is out there and I don't think we can just drop
support
On 4/23/25 18:13, Sami Imseih wrote:
Also, another strange behavior of the way portal cleanup occurs is that
in extended-query-protocol and within a transaction, ExecutorEnd for the
last query is not actually called until the next command. This just seems
odd to me especially for extensions th
hi, two more minor issues.
src/bin/pg_dump/pg_dump.c
if (fout->remoteVersion >= 18)
need change to
if (fout->remoteVersion >= 19)
+-- Test index visibility with partitioned tables
+CREATE TABLE part_tbl(id int, data text) PARTITION BY RANGE(id);
+CREATE TABLE part1 PARTITION OF part_tbl
73 matches
Mail list logo
