Hi!
Thank you very much, I'll check it out.
--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/
Hi,
On Fri, 2025-06-20 at 09:46 +0800, James Pang wrote:
> same OS RHEL8, install pgv14.11 and pgv18.beta1_3, both installation
> by RPM from pgdg, and use similar postgresql.conf.
> 18.beta1
> postgres=# \timing on
> Timing is on.
> postgres=# select * from tt where b ~~ 'a%';
> a | b
> ---+-
On Thu, Jun 19, 2025 at 5:11 AM Peter Eisentraut wrote:
> Here is a new patch.
>
> My previous patch was a bit too simple. I had thought that
> check_functions_in_node() does the node walking itself, but that was
> wrong, so the patch only worked at the top-level of the expression. So
> I had to
On Fri, Jun 20, 2025 at 11:09:01PM +0300, Nikita Malakhov wrote:
> I haven't found any comments on this and implemented
> a mechanism of setting custom reloptions for a relation
> created with Table AM, if needed. These options are stored
> in Relcache and are accessed through the rd_options field.
On Sat, Jun 21, 2025 at 1:39 AM Nikita Malakhov wrote:
> Hi hackers!
>
> While developing an alternative Table AM I've stumbled
> upon the impossibility to set custom reloptions to the table
> created by Table AM, like it could be done for Index AM.
>
> I haven't found any comments on this and im
Verified that the patch works w/ clang-19 -O0 and that avx-512 was selected
for
the CRC at runtime. Thanks for fixing this.
Regards,
Deep (VMware)
On Fri, Jun 20, 2025 at 04:53:52PM +0530, Rahila Syed wrote:
> Thank you for implementing these changes.
> The improvements look good and enhance the feature's utility. I have
> already started incorporating
> GetNamedDSA into my code to display memory context statistics.
Great! Thanks for the re
On Fri, Jun 20, 2025 at 10:34:19AM +0900, Michael Paquier wrote:
> Hmm. I like the simplicity of option 2) for the purpose the back
> branches and the post-feature-freeze v18.
Yeah, let's do this for now.
> However, Option 1) would be my go-to option for HEAD (as of v19
> opening for business),
On Fri, Jun 20, 2025 at 11:05:37AM +0900, Michael Paquier wrote:
> On Thu, Jun 19, 2025 at 03:20:27PM -0500, Nathan Bossart wrote:
>> * vacuum_rel() does not look up the main relation's reloptions when
>> processing a TOAST table, which is a problem for manual VACUUMs. The
>> aforementioned bu
Re: Tom Lane
> Yeah, seems quite bogus. It's harmless though, so I don't
> see a need to back-patch, do you?
Other than it being confusing, it doesn't hurt.
Christoph
On Fri, Jun 20, 2025 at 10:15:47AM -0700, Jeff Davis wrote:
> On Fri, 2025-06-20 at 11:31 -0500, Nico Williams wrote:
> > In the slow path you only normalize the _current character_, so you
> > only need enough buffer space for that.
>
> That's a clear win for UTF8 data. Also, if there are no chan
Hi,
On Thu, 19 Jun 2025 at 09:40, Nazir Bilal Yavuz wrote:
>
> Hi,
>
> On Wed, 18 Jun 2025 at 11:58, Peter Eisentraut wrote:
> >
> > On 17.06.25 19:36, Peter Eisentraut wrote:
> > > meson.build currently says
> > >
> > > # We want < 0.56 for python 3.5 compatibility on old platforms. EPEL for
>
Christoph Berg writes:
> Re: Tom Lane
>> Yeah, seems quite bogus. It's harmless though, so I don't
>> see a need to back-patch, do you?
> Other than it being confusing, it doesn't hurt.
OK, applied to master only.
regards, tom lane
On Fri, 2025-06-20 at 17:51 +0300, Alexander Borisov wrote:
> I don't quite see how this compares to the implementation on Rust. In
> the link provided, they use perfect hash, which I get rid of and get
> a x2 boost.
> If you take ICU implementations in C++, I have always considered them
> slow, at
On Fri, 2025-06-20 at 11:31 -0500, Nico Williams wrote:
> In the slow path you only
> normalize the _current character_, so you only need enough buffer
> space
> for that.
That's a clear win for UTF8 data. Also, if there are no changes, then
you can just return the input buffer and not bother allo
>
> * operate more directly on UTF-8 data rather than decoding and re-
> encoding the entire string
Not sure how relevant it is here, but in ZFS in the 00s we implement
form-insensitive, from-preserving functionality with an interesting
optimization that greatly reduced allocations and whic
On 20.06.25 15:29, Fabrice Chapuis wrote:
Regarding the changes made in version 15 for the traitment of the non-
numeric trailing characters, why does parsing continue to be permissive
with parentheses (no need to add a space)? Are we still in standard SQL?
Yes, a parenthesis is a "delimiter t
h. However, the current code path
for vacuum_rel handles table option re-consolidation, rather than the
ExecVacuum caller. This would require moving all parameter checks into
ExecVacuum, which I'm not sure is ideal. For this patch, let's focus
on resolving the inconsistent behavior. We
ups themselves, there are other opportunities
for optimization as well, such as:
* reducing the need for palloc and extra buffers, perhaps by using
buffers on the stack for small strings
* operate more directly on UTF-8 data rather than decoding and re-
encoding the entire string
Absol
Christoph Berg writes:
> pgxs.mk is cleaning up a file "regress.def" if PORTNAME=win, but the
> only reference to that file I could find is in the original commit
> from 1999 adding that "rm" rule (and several commits moving the rule
> around later).
> Given that the PORTNAME is wrong (should be
Hi,
On 2025-06-20 09:46:06 +0800, James Pang wrote:
> same OS RHEL8, install pgv14.11 and pgv18.beta1_3, both installation by RPM
> from pgdg, and use similar postgresql.conf.
>
> 14.11
> Time: 55.082 ms
> postgres=# select * from tt where b ~~ 'a%';
> a | b
> ---+---
> (0 rows)
>
> Time: 54.
r the cleanup lock.
+#
+# Disable any prefetching, parallelism, or other concurrent I/O by vacuum. The
+# pages of the heap must be processed in order by a single worker to ensure
+# test stability (PARALLEL 0 is a future-proofing measure in case we adopt
+# parallel heap vacuuming).
+$psql_pri
On Fri, Jun 20, 2025 at 10:14 PM shihao zhong wrote:
>
> >> However, Option 1) would be my go-to option for HEAD ...
>
> Updated my patch to apply the same rules to all VacuumParams. Also I
> am seeing clusterParams as a pass reference, not sure if we should
> also change that to prevent future is
On Friday, June 20, 2025, Peter Eisentraut wrote:
> On 16.06.25 14:47, Jelte Fennema-Nio wrote:
>
>> # Draft CF
>>
>> There's now an additional Draft CF. People can move patches there as a
>> way of not forgetting about them. CFBot will rerun these patches less
>> frequently (exact behaviour TBD)
Fabrice Chapuis writes:
> Regarding the changes made in version 15 for the traitment of the non-numeric
> trailing characters, why does parsing continue to be permissive with
> parentheses (no need to add a space)?
A parenthesis cannot be part of a larger token, so I don't see
any ambiguity that
On Fri, Jun 20, 2025 at 9:34 AM Michael Paquier wrote:
>
> On Thu, Jun 19, 2025 at 03:30:26PM -0500, Nathan Bossart wrote:
> > After thinking about this some more, I'm wondering if it would be better to
> > pursue option (2) because it's a little less invasive (which is important
> > because this
On Thu, May 22, 2025 at 5:12 PM Amit Langote wrote:
> I have pushed out the revert now.
>
> Note that I’ve only reverted the changes related to deferring locks on
> prunable partitions. I’m planning to leave the preparatory commits
> leading up to that one in place unless anyone objects. For refer
Hi,
On 2025-05-24 09:09:36 +0900, Michael Paquier wrote:
> On Fri, May 23, 2025 at 11:56:59PM +0900, Fujii Masao wrote:
> > On 2025/05/22 8:58, Tom Lane wrote:
> >> Michael Paquier writes:
> >>> Another point perhaps worth considering after a second look: how about
> >>> pg_ci_base.conf? We have
On Fri, Jun 20, 2025 at 05:01:41PM +0300, Aleksander Alekseev wrote:
> Hi,
>
> > Given the quality of BSD indent code, I have _always_ found it easier to
> > modify pgindent. ;-
>
> :D Initially I thought that the problem was simple enough to solve it
> in C, but this turned out not to be true.
>> However, Option 1) would be my go-to option for HEAD ...
Updated my patch to apply the same rules to all VacuumParams. Also I
am seeing clusterParams as a pass reference, not sure if we should
also change that to prevent future issues. But that should be another
patch.
vacuum_tables_options_4
On Fri, Jun 20, 2025 at 04:44:08PM +0300, Aleksander Alekseev wrote:
> Hi Arseniy,
>
> > I tried it with the whole project and almost always it works great.
> > But I noticed two cases where it works probably not as expected:
> >
> > 1) comments which don't have a star on each line. For example:
>
Hi,
> Given the quality of BSD indent code, I have _always_ found it easier to
> modify pgindent. ;-
:D Initially I thought that the problem was simple enough to solve it
in C, but this turned out not to be true.
> It's going to be simpler to modify pgindent then. PFA the updated patch.
I noti
Hi Arseniy,
> I tried it with the whole project and almost always it works great.
> But I noticed two cases where it works probably not as expected:
>
> 1) comments which don't have a star on each line. For example:
> file 'cube.c'
>
> before:
> /* make up a metric in which one box will be 'lower'
On 16.06.25 14:47, Jelte Fennema-Nio wrote:
# Draft CF
There's now an additional Draft CF. People can move patches there as a
way of not forgetting about them. CFBot will rerun these patches less
frequently (exact behaviour TBD). Draft CFs are never "In Progress"
and are open until the final CF
Hi Nathan,
>
> I like this idea, but I took it one step further in the attached patch and
> made the registry entry struct flexible enough to store any type of entry.
> Specifically, I've added a new "type" enum followed by a union of the
> different structs used to store the entry data. I was o
Hello!
This patch fixes CPPFLAGS, LDFLAGS, LIBS when checking AsyncDNS libcurl
support in configure
Custom parameters and paths to libcurl were mistakenly excluded from
CPPFLAGS, LDFLAGS, and LIBS, although AsyncDNS check was OK.
For example, the command `pkg-config --libs libcurl` gives
`
Hi David,
>Typically, in the regression tests we've used enable_sort to force a
>HashAgg. There are certainly times when that's not good enough and you
>might also need to disabe enable_indexscan too, so I understand the
desire to add this GUC.
Thank you for the explanation.
I wasn't aware that e
> On Fri, Jun 20, 2025 at 12:19:31PM +0200, Dmitry Dolgov wrote:
> Thanks! I've reworked the series to implement approach suggested by
> Thomas, and applied your patches to support buffers shrinking on top. I
> had to restructure the patch set, here is how it looks like right now:
The base-commit
On Sat, May 24, 2025 at 09:09:36AM +0900, Michael Paquier wrote:
> On Fri, May 23, 2025 at 11:56:59PM +0900, Fujii Masao wrote:
>> On 2025/05/22 8:58, Tom Lane wrote:
>>> I'd vote for standardizing on pg_regress.c's spelling, as that's got
>>> the most usage history behind it. I'm unexcited about
On Thu, Jun 19, 2025 at 4:34 PM shveta malik wrote:
>
> >
> > Here is the V38 patch set which includes the following changes:
> >
>
> Thank You for the patches. Few comments:
>
> 1)
> +
> +Note that commit timestamps and origin data retained by enabling the
> + linkend="sql-createsubscr
Hi,
On Fri, Jun 20, 2025 at 09:48:47AM +0530, shveta malik wrote:
> On Thu, Jun 19, 2025 at 2:30 PM Bertrand Drouvot
> wrote:
> >
> > I wonder if a way to address the concerns that we shared above is to use a
> > mixed approach like:
> >
> > - Forget the immediately_reserve idea
> > - If a user c
On Thu, Jun 19, 2025 at 2:30 PM Bertrand Drouvot
wrote:
>
> I wonder if a way to address the concerns that we shared above is to use a
> mixed approach like:
>
> - Forget the immediately_reserve idea
> - If a user creates a logical slot then we automatically switch to wal_level =
> logical (if not
On Thu, Jun 19, 2025 at 4:42 PM Shlok Kyal wrote:
...
> > 3.
> > TBH, I was wondering why a new catalog attribute was necessary...
> >
> > Can't you simply re-use the existing attribute "prattrs" attribute.
> > e.g. let's just define negative mea
On Fri, Jun 20, 2025 at 5:48 AM Alexander Korotkov wrote:
>
> >
> > If what I said above is correct, then the following part of the commit
> > message will be incorrect:
> > "As stated in the ReplicationSlotReserveWal() comment, this is not
> > always true. Additionally, this issue has been spotte
On Thursday, June 19, 2025, James Pang wrote:
> same OS RHEL8, install pgv14.11 and pgv18.beta1_3, both installation by
> RPM from pgdg, and use similar postgresql.conf.
>
You will need to show encoding and locale information for the databases
under test.
>
> postgres$#for counter in 1..10
On Thu, Jun 19, 2025 at 03:20:27PM -0500, Nathan Bossart wrote:
> While investigating problems caused by vacuum_rel() scribbling on its
> VacuumParams argument [0], I noticed some other interesting bugs with the
> toast.* reloption code. Note that the documentation for the reloptions has
> the fol
On Thu, Jun 19, 2025 at 03:30:26PM -0500, Nathan Bossart wrote:
> After thinking about this some more, I'm wondering if it would be better to
> pursue option (2) because it's a little less invasive (which is important
> because this will need to be back-patched). In any case, we have a similar
> p
On Wed, Jun 18, 2025 at 8:41 PM Peter Geoghegan wrote:
> Attached patch shows how this could work. It refines the rules around
> NULL row comparison members in _bt_check_rowcompare, and in _bt_first.
> The fundamental idea here is to make _bt_check_rowcompare *consistent*
> with _bt_first. That wa
Dear Kuroda-san,
On Thu, Jun 19, 2025 at 2:05 PM Hayato Kuroda (Fujitsu)
wrote:
> > > Regarding assertion failure, I've found that assert in
> > > PhysicalConfirmReceivedLocation() conflicts with restart_lsn
> > > previously set by ReplicationSlotReserveWal(). As I can see,
> > > ReplicationSlot
On Thu, Jun 19, 2025 at 1:29 PM Amit Kapila wrote:
> On Wed, Jun 18, 2025 at 10:17 PM Alexander Korotkov
> wrote:
> >
> > On Wed, Jun 18, 2025 at 6:50 PM Vitaly Davydov
> > wrote:
> > > > I think, it is a good idea. Once we do not use the generated data, it
> > > > is ok
> > > > just to genera
stcommit(fxid, info, recdata, len);
}
/*
diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend/storage/lmgr/predicate.c
index d82114ffca16..c07fb5883555 100644
--- a/src/backend/storage/lmgr/predicate.c
+++ b/src/backend/storage/lmgr/predicate.c
@@ -191,7 +191,7 @@
* AtPrepare_PredicateLocks(void);
Pavel Stehule writes:
> Own implementation of SQL/XML generating functions like XMLFOREST or
> XMLELEMENT should not be too
> difficult. Significantly more difficult problem is parsing of XML (more
> with namespaces), although some basic
> support for XMLTABLE should not be too hard too.
I don't
čt 19. 6. 2025 v 22:09 odesílatel Bruce Momjian napsal:
> On Thu, Jun 19, 2025 at 09:24:32PM +0200, Jim Jones wrote:
> > On 19.06.25 03:41, Bruce Momjian wrote:
> > > This blog post explains the serious problems the single libxml2 author
> > > is having in maintaining the library:
> > >
> > >
> h
On Thu, Jun 19, 2025 at 5:51 PM Aleksander Alekseev
wrote:
>
> Hi,
>
> Michael (cc:'ed) pointed out [1] that pg_bsd_indent could do a
> slightly better job when it comes to formatting multiline comments. I
> prepared a patch that fixes this.
>
> How to test it:
>
> ```
> ninja -C build
> cp build/
On Wed, Jun 18, 2025 at 02:48:16PM -0400, shihao zhong wrote:
>>> That leads me to think (1) might be the better option, although I'm not too
>>> wild about the subtlety of the fix.
>
> Thanks for your feedback. New patch is attached. I also updated the
> signature of do_analyze_rel for the same r
On Thu, Jun 19, 2025 at 09:24:32PM +0200, Jim Jones wrote:
> On 19.06.25 03:41, Bruce Momjian wrote:
> > This blog post explains the serious problems the single libxml2 author
> > is having in maintaining the library:
> >
> >
> > https://socket.dev/blog/libxml2-maintainer-ends-embargoed-vulne
On 19.06.25 03:41, Bruce Momjian wrote:
> This blog post explains the serious problems the single libxml2 author
> is having in maintaining the library:
>
>
> https://socket.dev/blog/libxml2-maintainer-ends-embargoed-vulnerability-reports
>
> There are few learnings from this:
>
> * libx
On Mon, 19 May 2025 at 09:38, Nathan Bossart wrote:
> Could you retry your tests on v18devel? It might also be useful to
repeat the tests on a variety of hardware to ensure
> it's a win across the board.
Hi Nathan,
Thanks for your clarification. As you requested, I have performed more
tests on
On 6/19/25 08:43, Jeff Davis wrote:
Leaving it in the entry for PARTITION BY seems out of place; shouldn't
it be moved to the entry for EXCLUDE? I also merged your wording with
some similar wording from the entry about UNIQUE. Attached.
I agree this new location makes more sense. The wording lo
On Thu, 19 Jun 2025 at 18:39, David E. Wheeler wrote:
>
> On Jun 19, 2025, at 12:59, Thom Brown wrote:
>
> > No. But given the options, I would personally choose nondeterministic
> > collations now that they are available. I just wish they were more
> > user-friendly as I suspect the majority o
On Wed, Jun 18, 2025 at 2:39 PM Andrey Borodin wrote:
>
>
>
> > On 18 Jun 2025, at 11:33, Arseniy Mukhin
> > wrote:
> >
> > Interesting, I used btree check as reference when started
> > writing brin check, and in btree check there 53
> > ERRCODE_INDEX_CORRUPTED ereports and only 1 ERRCODE_DATA_C
- applied Timur's top-up patch [1] re "session_preload_libraries"
> - removed some dead code
>
> v8-0003 VCI module - documentation
> - removed mentions about compression
Hello Peter!
Thank you for working on VCI updates.
Here are some proposals for small imp
ities
for optimization as well, such as:
* reducing the need for palloc and extra buffers, perhaps by using
buffers on the stack for small strings
* operate more directly on UTF-8 data rather than decoding and re-
encoding the entire string
Regards,
Jeff Davis
On Jun 19, 2025, at 12:59, Thom Brown wrote:
> No. But given the options, I would personally choose nondeterministic
> collations now that they are available. I just wish they were more
> user-friendly as I suspect the majority of people either won't know about
> them, or won't know how to use
On Thu, 19 Jun 2025, 17:33 Jeff Davis, wrote:
> On Thu, 2025-06-19 at 16:36 +0100, Thom Brown wrote:
> > Ease of use, perhaps. It seems easier to use:
> >
> > column_name cftext
> >
> > rather than:
> >
> > CREATE COLLATION case_insensitive_collation (
> > PROVIDER = icu,
> > LOCALE = 'un
On Thu, 2025-06-19 at 18:21 +0200, Vik Fearing wrote:
> >
> > The SQL standard also says in a few other places that normalization
> > should be applied, and we do none of those, so this is probably not
> > a
> > reason to change CASEFOLD at this point.
> >
>
> Works for me.
Sounds good. We can
On Thu, Jun 19, 2025 at 12:33 PM Jeff Davis wrote:
>
> On Thu, 2025-06-19 at 16:36 +0100, Thom Brown wrote:
> > Ease of use, perhaps. It seems easier to use:
> >
> > column_name cftext
> >
> > rather than:
> >
> > CREATE COLLATION case_insensitive_collation (
> > PROVIDER = icu,
> > LOCALE
On Thu, 2025-06-19 at 16:36 +0100, Thom Brown wrote:
> Ease of use, perhaps. It seems easier to use:
>
> column_name cftext
>
> rather than:
>
> CREATE COLLATION case_insensitive_collation (
> PROVIDER = icu,
> LOCALE = 'und-u-ks-level2',
> DETERMINISTIC = FALSE
> );
We could auto-c
On 19/06/2025 16:47, Peter Eisentraut wrote:
On 17.06.25 17:37, Vik Fearing wrote:
For (which includes LOWER() and UPPER()), the text says in
Section 6.35 GR 7.e:
If the character set of is UTF8, UTF16, or UTF32,
then FR is replaced by
Case:
i) If the S IS NORMALIZED eval
On Thu, Jun 19, 2025 at 11:37 AM Thom Brown wrote:
> On Thu, 19 Jun 2025 at 15:51, Peter Eisentraut wrote:
> > On 19.06.25 06:03, Thom Brown wrote:
> > > Late to the party, but is there an argument for porting this to the
> > > citext type? Or supplementing the extension with an additional type
>
On Wed, 2025-06-18 at 11:25 -0700, Paul Jungwirth wrote:
> Hi Hackers,
>
> In pg17 we added support for cross-partition EXCLUDE constraints, as
> long as they included all
> partition key columns and compared them with equality (see
> 8c852ba9a4). I updated the docs for
> exclusion constraints,
On Thu, 19 Jun 2025 at 15:51, Peter Eisentraut wrote:
>
> On 19.06.25 06:03, Thom Brown wrote:
> > Late to the party, but is there an argument for porting this to the
> > citext type? Or supplementing the extension with an additional type
> > ("cftext"? *shrug*). It currently uses lower(), so our
"David G. Johnston" writes:
> At this point why does it matter what the docs says?
Yeah, I cannot get excited about changing this. The current protocol
spec accurately documents what we do. It is not incumbent on us to
document what non-Postgres implementations of this protocol could
hypothetic
čt 19. 6. 2025 v 11:00 odesílatel Álvaro Herrera
napsal:
> On 2025-Jun-18, Bruce Momjian wrote:
>
> > This blog post explains the serious problems the single libxml2 author
> > is having in maintaining the library:
> >
> >
> https://socket.dev/blog/libxml2-maintainer-ends-embargoed-vulnerability-
Peter Eisentraut writes:
> On 19.06.25 08:40, Nazir Bilal Yavuz wrote:
>> Thanks for the patches! I didn't check them yet but I encountered some
>> errors while using meson 0.57.0 and 0.57.1 but 0.56.2, 0.57.2 and
>> 0.58.0 worked successfully. These errors seem to be related to these
>> specific
On Thu, Jun 19, 2025 at 05:05:25PM +0200, Daniel Gustafsson wrote:
> I also dug out an archeologically old MacBook Pro running macOS High Sierra
> 10.13.6 with an i5 using Apple LLVM version 10.0.0 (clang-1000.10.44.4), and
> it
> too fails to reproduce any issue.
It's not going to be reproducibl
> On 19 Jun 2025, at 16:36, Andres Freund wrote:
> So for some reason this apparently can only be reproduced on older macos - we
> know it's not the older compiler, because I couldn't reproduce it on the same
> compile version as alexander, on an m1 that was running sequoia. That's really
> reall
On 19.06.25 06:03, Thom Brown wrote:
Late to the party, but is there an argument for porting this to the
citext type? Or supplementing the extension with an additional type
("cftext"? *shrug*). It currently uses lower(), so our current
recommendation for dealing with all unicode characters is t
On 17.06.25 17:37, Vik Fearing wrote:
For (which includes LOWER() and UPPER()), the text says in
Section 6.35 GR 7.e:
If the character set of is UTF8, UTF16, or UTF32,
then FR is replaced by
Case:
i) If the S IS NORMALIZED evaluates to True,
then NORMALIZE (FR)
ii
On Thursday, June 19, 2025, Tatsuo Ishii wrote:
>
> > FWIW my reading of the protocol docs is that BackendKeyData is
> > optional.
>
> If majority of developers think so, do we want to update the protocol
> docs? For me the docs is not clear enough.
>
At this point why does it matter what the do
Hi,
On 2025-06-19 17:02:18 +0300, Konstantin Knizhnik wrote:
> On 18/06/2025 7:08 pm, Andres Freund wrote:
> > Hi,
> >
> > On 2025-06-18 10:32:08 +0300, Konstantin Knizhnik wrote:
> > > On 17/06/2025 6:08 pm, Andres Freund wrote:
> > > > I don't think it can - this must be an independent bug from
> On 19 Jun 2025, at 16:02, Konstantin Knizhnik wrote:
> By the way - still not been able to reproduce assertion failure at most
> recent MacPro (Apple M4 Pro) with Sequoia 15.5.
I tried to reproduce this on an older quad core i7 MacBook Pro running Sonoma
14.7.5 using Apple clang version 15.0.
On 18/06/2025 7:08 pm, Andres Freund wrote:
Hi,
On 2025-06-18 10:32:08 +0300, Konstantin Knizhnik wrote:
On 17/06/2025 6:08 pm, Andres Freund wrote:
I don't think it can - this must be an independent bug from the one that Tom
and I were encountering.
I see... It's a pity.
Indeed.
Konstant
Hi,
Hi,
On 2025-06-18 10:58:22 +0200, Peter Eisentraut wrote:
> On 17.06.25 19:36, Peter Eisentraut wrote:
> > meson.build currently says
> >
> > # We want < 0.56 for python 3.5 compatibility on old platforms. EPEL for
> > # RHEL 7 has 0.55. < 0.54 would require replacing some uses of the fs
> >
On 18.06.25 22:57, Robert Treat wrote:
I also wondered why you differentiated SQL script file vs archive in
the change here:
- of a cluster into an archive. The archive contains
+ of a cluster into an SQL script file or an archive. The output contains
but then did not differentiate them h
> Or disconnect.
You cannot disconnect without canceling the query at least using psql.
You can kill psql to disconnect but it's possible that the backend
keeps on running the query.
> Or pg_cancel_backend().
In order to issue pg_cancel_backend() the user needs to know the
backend pid which was
On Thu, 19 Jun 2025 at 13:51, Tatsuo Ishii wrote:
> > FWIW my reading of the protocol docs is that BackendKeyData is
> > optional.
>
> If majority of developers think so, do we want to update the protocol
> docs? For me the docs is not clear enough.
I think the docs currently definitely suggests
On 2025/06/19 14:42, jian he wrote:
On Wed, Jun 18, 2025 at 10:21 AM Fujii Masao
wrote:
I ran into another issue related to comments on NOT NULL constraints.
When using CREATE TABLE ... (LIKE ... INCLUDING ALL), the NOT NULL constraints
are copied, but their comments are not. For example:
Dear Amit, Alexander,
> > Regarding assertion failure, I've found that assert in
> > PhysicalConfirmReceivedLocation() conflicts with restart_lsn
> > previously set by ReplicationSlotReserveWal(). As I can see,
> > ReplicationSlotReserveWal() just picks fresh XLogCtl->RedoRecPtr lsn.
> > So, it d
>
> Here is the V38 patch set which includes the following changes:
>
Thank You for the patches. Few comments:
1)
+
+Note that commit timestamps and origin data retained by enabling the
+retain_conflict_info
+option will not be preserved during the upgrade. As a
+result, the up
Hi Michael,
> /* text_name()
> * Converts a text type to a Name type.
> */
>
> Not related to this patch, sorry for the regression, just noticed
> a nit while looking at the diffs of what you have here.. This one, as
> well as name_text(), uses a comment block that is inconsistent with
> the fo
On Wed, Jun 18, 2025 at 10:17 PM Alexander Korotkov
wrote:
>
> On Wed, Jun 18, 2025 at 6:50 PM Vitaly Davydov
> wrote:
> > > I think, it is a good idea. Once we do not use the generated data, it is
> > > ok
> > > just to generate WAL segments using the proposed function. I've tested
> > > this
On 2025-Jun-18, Bruce Momjian wrote:
> This blog post explains the serious problems the single libxml2 author
> is having in maintaining the library:
>
>
> https://socket.dev/blog/libxml2-maintainer-ends-embargoed-vulnerability-reports
>
> There are few learnings from this:
>
> * libxml
On 19/06/2025 13:03, Tatsuo Ishii wrote:
I think that's fine, if the server does not want to support query
cancellation. The current protocol description certainly does not
support the idea that it is a hard error *not* to send BackendKeyData.
Isn't it scary if the server does not allow a quer
> I think that's fine, if the server does not want to support query
> cancellation. The current protocol description certainly does not
> support the idea that it is a hard error *not* to send BackendKeyData.
Isn't it scary if the server does not allow a query cancel? For
example, if the server
Hi,
On Wed, Jun 18, 2025 at 03:22:59PM +0530, shveta malik wrote:
> On Wed, Jun 18, 2025 at 2:39 PM Bertrand Drouvot
> wrote:
> >
> > IIUC the idea is to "just" increase WAL level to 'logical' so that one
> > could then
> > be allowed to make use of logical decoding from the standby. The primary
On Tue, Jun 17, 2025 at 4:26 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Mon, Jun 16, 2025 at 7:37 PM Amit Kapila wrote:
> >
> >
> > 3. Isn't the new check for logical slots in
> > check_new_cluster_subscription_configuration() somewhat redundant with
> > the previous check done in check_new_cluster_log
On Wed, Jun 18, 2025 at 10:56 AM Amit Kapila wrote:
>
> On Wed, Jun 18, 2025 at 8:52 AM shveta malik wrote:
> >
> > On Tue, Jun 17, 2025 at 12:01 PM Amit Kapila
> > wrote:
> > >
> > > This whole paragraph sounds like a duplicate of its previous section,
> > > and the line alignment in the first
Hi,
Thanks for your valuable feedback on the patch.
Will check on the cases mentioned by you and do the needful.
Best Regards
Shubhankar K.
Member Technical Staff
Zoho Corporation
On Sat, 14 Jun 2025 09:03:25 +0530 Andy Fan wrote
---
Shubhankar Anand Kulkarni < mailto:shubhankar
On Wed, Jun 18, 2025 at 09:15:07AM +0200, Jelte Fennema-Nio wrote:
> On Wed, 18 Jun 2025 at 08:23, Anthonin Bonnefoy
> wrote:
>> Since \bind_named is also new, we can also rename it to make it
>> consistent with close meta-command. So what about renaming \bind_named
>> to \bindprepared and \close
1 - 100 of 19382 matches
Mail list logo
