I've been working on integrating Mark's "Index AM API cleanup" patch set
with the existing gist strategy number mapping from Paul's application
time patch set. Here is what I've come up with.
The previously committed patch (v19.1) already changed the gist strategy
number mapping to use the (R
pá 24. 1. 2025 v 23:11 odesílatel Jim Jones
napsal:
>
> On 24.01.25 22:01, Chapman Flack wrote:
> > It seems to me the key connection there is that the ISO SQL standard
> > defines XMLDOCUMENT by equivalence to what `document { $expr }` means
> > in the W3 XML Query standard.
>
>
> It seems I mis
This seems like a great idea !
Maybe we can start out by adding some basic CI tests on the mirror
repository to sort of 'dry run' the new process?
I'll be happy to submit a PR with some basic tests on the repository.
Regards,
Akshat Jaimini
On Thu, Jan 23, 2025 at 6:48 PM Jelte Fennema-Nio
wro
On Wed, Jan 15, 2025 at 10:24 AM Andrei Lepikhov wrote:
> On 1/13/25 10:39, Andrei Lepikhov wrote:
> > On 1/13/25 01:39, Alexander Korotkov wrote:
> > It can be resolved with a single-line change (see attached). But I need
> > some time to ponder over the changing behaviour when a clause may match
Jeff Davis writes:
> v6 attached. I plan to commit this soon.
The documentation for this function is giving the PDF docs build
indigestion:
[WARN] FOUserAgent - Glyph "?" (0x3a3, Sigma) not available in font "Courier".
[WARN] FOUserAgent - Glyph "?" (0x3c3, sigma) not available in font "Courier"
Hello Álvaro,
23.01.2025 17:04, Álvaro Herrera wrote:
OK thanks, looks good, I have pushed it now with some trivial
amendments.
Please look at the script that produces an error starting from b663b9436:
CREATE TABLE st (a int, primary key (a));
CREATE TABLE pt (a int,
FOREIGN KEY (a) REFERENC
On Fri, Jan 24, 2025 at 10:07 PM Heikki Linnakangas wrote:
> On my laptop, this is the worst case I could come up with:
>
> create table skiptest as select g / 10 as a, g%10 as b from
> generate_series(1, 1000) g;
> vacuum freeze skiptest;
> create index on skiptest (a, b);
>
> set enable_seqs
On 03/01/2025 21:43, Peter Geoghegan wrote:
The newly revised "skipskip" optimization seems to get the regressions
down to only a 5% - 10% increase in runtime across a wide variety of
unsympathetic cases -- I'm now validating performance against a test
suite based on the adversarial cases present
On Fri, 2025-01-24 at 17:04 -0800, James Hunter wrote:
> Generating "high memory" vs. "low memory" paths would be tricky,
> because the definition of "high" vs. "low" depends on the entire path
> tree, not just on a single path node. So I think it would quickly
> lead
> to a state-space explosion,
On 2025-01-24 Fr 7:50 PM, Andrew Dunstan wrote:
Here's the hot fix (which passed my test with a directory with pgsql
in its path):
https://github.com/PGBuildFarm/client-code/commit/f6c6dd52d2959814452454890fb9838429c5c3e8
Oops, wrong address on previous email. Julien, please update
On Tue, Jan 21, 2025 at 1:26 PM Jeff Davis wrote:
>
> On Fri, 2025-01-10 at 10:00 -0800, James Hunter wrote:
> > How should “query_work_mem” work? Let’s start with an example:
> > suppose
> > we have an OLAP query that has 2 Hash Joins, and no other operators
> > that use work_mem.
>
> So we plan
On Wed, Jan 22, 2025 at 1:13 PM Tomas Vondra wrote:
>
> On 1/10/25 19:00, James Hunter wrote:
> > ...
> > I wouldn’t change the existing planning logic (at least not in the
> > initial implementaton). So the existing planning logic would choose
> > between different SQL operators, still on the ass
On 2025-01-24 Fr 7:09 PM, Robins Tharakan wrote:
On Sat, 25 Jan 2025 at 10:11, Tom Lane wrote:
Yeah, that's about what I expected. As a workaround until Andrew
updates the BF client, you could do
- $libdir = "$tmp_loc/lib/postgresql";
+ $libdir =
On Thu, 2025-01-23 at 13:29 -0800, Jeff Davis wrote:
> I had previously proposed[1] a GUC to control abbreviated keys, and
> it
> was rejected. Now that we've seen both a performance problem and a
> bug
> in the underlying dependency, perhaps we should reconsider.
Users may:
* trust libc strxfrm,
On Sat, 25 Jan 2025 at 10:11, Tom Lane wrote:
> Yeah, that's about what I expected. As a workaround until Andrew
> updates the BF client, you could do
>
> - $libdir = "$tmp_loc/lib/postgresql";
> + $libdir = "$tmp_loc/lib";
>
> at about line 429 of PGBuild/Utils.pm
>
Robins Tharakan writes:
> On Sat, 25 Jan 2025 at 08:59, Tom Lane wrote:
>> alligator and lapwing are not reporting the
>> relevant log file, but what we do see is an install failure that
>> could well be down to a compile failure.
> You're probably right about that.
> This is what I see in the i
On 2025-01-24 Fr 6:08 PM, Tom Lane wrote:
I wrote:
Oh ... wait a second. After further code reading I see that
the BF client sets NO_TEMP_INSTALL if check_install_is_complete
succeeds. So evidently, that is successfully suppressing
"make install" on most animals, but not these two. How come
On Wed, Jan 8, 2025 at 7:39 AM Euler Taveira wrote:
>
> On Thu, Dec 19, 2024, at 10:31 AM, Peter Eisentraut wrote:
>
> On 10.12.24 19:41, Euler Taveira wrote:
> > I'm attaching a patch that adds max_replication_origins. It basically
> > replaces
> > all of the points that refers to max_replication
On Sat, 25 Jan 2025 at 08:59, Tom Lane wrote:
> alligator and lapwing are not reporting the
> relevant log file, but what we do see is an install failure that
> could well be down to a compile failure.
>
You're probably right about that.
This is what I see in the install.log
(/home/postgres/proj
On Fri, Jan 24, 2025 at 06:59:42PM +, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane writes:
>> You might be able to work around this with auth_extra,
>> a la 1e3f461e8 and other past fixes.
Yes, forgot about this part with SSPI this time. Thanks for the poke.
> Here's a (blind, but at least do
I wrote:
> Oh ... wait a second. After further code reading I see that
> the BF client sets NO_TEMP_INSTALL if check_install_is_complete
> succeeds. So evidently, that is successfully suppressing
> "make install" on most animals, but not these two. How come?
Got it: we can see on alligator that
I wrote:
> Yeah, but to get to that point you have to get past "make install",
Oh ... wait a second. After further code reading I see that
the BF client sets NO_TEMP_INSTALL if check_install_is_complete
succeeds. So evidently, that is successfully suppressing
"make install" on most animals, but
Andrew Dunstan writes:
> On 2025-01-24 Fr 4:07 PM, Tom Lane wrote:
>> Looking at the buildfarm client script, it looks to me like it
>> will unconditionally try to run TAP tests in every contrib directory
>> that has a "t" subdirectory. Up to now, none of those needed to
>> be conditional ... but
On 1/24/25 14:47, Rahila Syed wrote:
>
> Hi,
>
>
> Just idea; as an another option, how about blocking new requests to
> the target process (e.g., causing them to fail with an error or
> returning NULL with a warning) if a previous request is still pending?
> Users can simply
On 2025-01-24 Fr 4:07 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 2025-01-24 Fr 10:57 AM, Tom Lane wrote:
Looks like alligator needs some help here too.
That's an issue with the new TAP test - alligator isn't running the
TestSepgsql module. lapwing has also had a TAP test failure.
Hmm. Ne
On 24.01.25 22:01, Chapman Flack wrote:
> It seems to me the key connection there is that the ISO SQL standard
> defines XMLDOCUMENT by equivalence to what `document { $expr }` means
> in the W3 XML Query standard.
It seems I missed one sentence. My bad.
Next try... :)
The xmldocument functio
> On 24 Jan 2025, at 21:07, Andrew Dunstan wrote:
> On 2025-01-22 We 4:25 AM, Dave Page wrote:
>> Anyway, no fix was committed as far as I know. I would suggest it should be
>> back-patched as well.
>
> I'm quite partial to the approach suggested upthread by Andres (a separate
> pg_gssapi.h f
The meson configure check seems to fail on my machine:
error: too many arguments to function call, expected 0, have 1
10 | svuint64_t popcnt = svcntb(val);
| ~~ ^~~
error: returning '__SVInt64_t' from a function with incompa
On Fri, Jan 24, 2025 at 7:44 AM Nathan Bossart wrote:
>
> On Mon, Jan 06, 2025 at 03:27:18PM -0600, Nathan Bossart wrote:
> > On Mon, Dec 30, 2024 at 03:45:03PM -0500, Bruce Momjian wrote:
> >> On Mon, Dec 30, 2024 at 12:02:47PM -0800, Jeff Davis wrote:
> >>> I suggest that we make a new thread ab
Hi John,
Thanks for your summary and here are responses:
> #1 - The choice of AVX-512. There is no such thing as a "CRC instruction
> operating
> on 8 bytes", and the proposed algorithm is a multistep process using carryless
> multiplication and requiring at least 256 bytes of input. The Chrom
On Fri, Jan 24, 2025 at 3:02 PM Melanie Plageman
wrote:
> This thought exercise made me realize something is wrong with my
> current patch, though. If you set the failure tolerance
> (vacuum_eager_scan_max_fails) to 0 right now, it disables eager
> scanning altogether. That might be unexpected. Yo
Hi,
On 2025-01-24 14:56:45 -0500, Tom Lane wrote:
> Alexander Lakhin writes:
> > There is also a reference to a discussion of the failure there:
> > https://www.postgresql.org/message-id/657815a2-5a89-fcc1-1c9d-d77a6986b...@gmail.com
> > (In short, I observed that that test suffers from bgwriter'
On 01/24/25 14:59, Jim Jones wrote:
> In the XML Query standard, a "document node" represents a relaxed
> version of an XML document structure. This corresponds to what
> PostgreSQL's single XML type allows, meaning that any valid non-null
> PostgreSQL XML value can be returned unchanged. Other sys
Andrew Dunstan writes:
> On 2025-01-24 Fr 10:57 AM, Tom Lane wrote:
>> Looks like alligator needs some help here too.
> That's an issue with the new TAP test - alligator isn't running the
> TestSepgsql module. lapwing has also had a TAP test failure.
Hmm. Neither of those animals should be try
On Wed, Jan 22, 2025 at 1:48 AM Richard Guo wrote:
> This approach would require injecting multiple intermediate
> aggregation nodes into the path tree, for which we currently lack the
> necessary architecture. As a result, I didn't pursue this idea
> further. However, I'm really glad you mentio
On Fri, 24 Jan 2025 at 20:07, Andrew Dunstan wrote:
>
> On 2025-01-22 We 4:25 AM, Dave Page wrote:
>
>
>
> On Wed, 22 Jan 2025 at 09:17, Daniel Gustafsson wrote:
>
>> > On 10 Jul 2024, at 19:06, Imran Zaheer wrote:
>>
>> (Reviving an old thread to give them a chance to finish before v18)
>>
>>
> I was referring to the order of the fields in the structure itself,
> but that's no big deal one way or the other.
I understand your point now. I will group them with the
related counters in the next rev and will use
> This should be one comment for the whole block, or this should use the
> sin
I wrote:
> OK. Nobody has spoken against the 0001 patch (replace errors with
> return-a-null), so I think I'll go ahead and commit that one.
> Then I'll return to this thread with a fleshed-out patch for 0002.
0001 is pushed, and as promised, here's a version of 0002 extended
to cover all the str
On 2025-01-22 We 4:25 AM, Dave Page wrote:
On Wed, 22 Jan 2025 at 09:17, Daniel Gustafsson wrote:
> On 10 Jul 2024, at 19:06, Imran Zaheer wrote:
(Reviving an old thread to give them a chance to finish before v18)
> For now maybe we can do the future proofing for gssapi & open
Hi,
Attached is a new version of this patchset:
- HandleFatalError now doesn't expect to be called if already in FatalError or
ImmediateShutdown and contains a comment and assertions to that effect
- Fatal errors when in pmState > PM_WAIT_BACKENDS go to PM_WAIT_DEAD_END
directly. The previou
Thanks for the review! Attached v10 addresses the review feedback
except that about the GUC/table option meaning and format.
On Thu, Jan 23, 2025 at 2:22 PM Robert Haas wrote:
>
> On Thu, Jan 23, 2025 at 1:31 PM Robert Haas wrote:
> >
> > On Wed, Jan 22, 2025 at 5:48 PM Melanie Plageman
> > wro
Hi
On 24.01.25 17:18, Chapman Flack wrote:
> Or even: ... An XML Query "document node" is a relaxed version
> of XML document structure that corresponds exactly to what
> PostgreSQL's one XML type is already allowed to contain, so
> any non-null PostgreSQL XML value can be returned unchanged.
> Mo
Alexander Lakhin writes:
> There is also a reference to a discussion of the failure there:
> https://www.postgresql.org/message-id/657815a2-5a89-fcc1-1c9d-d77a6986b...@gmail.com
> (In short, I observed that that test suffers from bgwriter's activity.)
Hmm, that's an interesting theory, but it fai
Hi,
On 2025-01-24 21:00:00 +0200, Alexander Lakhin wrote:
> 24.01.2025 18:42, Tom Lane wrote:
> > I realized just now that drongo has been intermittently failing like this:
> >
> > 147/256 postgresql:recovery / recovery/035_standby_logical_decoding
> > ERROR 2116.16s (ex
On 2025-01-24 Fr 10:24 AM, Tom Lane wrote:
Andrew Dunstan writes:
I don't think we need a new file for this. pg_backup_utils.c is already
there for routines common to pg_restore and pg_dump.
I'm not even on board with having a new function, because I doubt
we should try to share this code in
On 2025-01-24 Fr 10:57 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 2025-01-24 Fr 7:25 AM, Peter Eisentraut wrote:
This has been committed. And I understand there is a buildfarm client
update available for the affected buildfarm members.
This should only be rhinoceros. Joe can pull this f
Hi,
On 2025-01-24 14:23:26 -0500, Andres Freund wrote:
> On 2025-01-24 11:42:15 -0500, Tom Lane wrote:
> There's a failure before this one:
> [05:23:54.643](0.013s) not ok 23 - activeslot slot invalidation is logged
> with vacuum on pg_class
>
>
> > This has been happening for some time, in all t
On Wed, Jan 22, 2025 at 11:42 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Wed, Jan 22, 2025 at 04:46:00PM -0800, Masahiko Sawada wrote:
> > I would like to summarize the proposed approaches thus far:
>
> Thanks!
>
> > Regarding the user interface, there are three approaches:
> >
> > 1. Implementing
Hi,
Thanks for noticing the pattern.
On 2025-01-24 11:42:15 -0500, Tom Lane wrote:
> I realized just now that drongo has been intermittently failing like this:
>
> 147/256 postgresql:recovery / recovery/035_standby_logical_decoding
> ERROR 2116.16s (exit status 255 or si
On Thu, Jan 23, 2025 at 3:24 AM Ashutosh Bapat
wrote:
>
> On Thu, Jan 23, 2025 at 6:16 AM Masahiko Sawada wrote:
> >
> > On Fri, Jan 10, 2025 at 12:33 AM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Jan 9, 2025 at 3:29 AM Ashutosh Bapat
> > > wrote:
> > > >
> > > > On Tue, Dec 31, 2024 at 10
Hello Tom,
24.01.2025 18:42, Tom Lane wrote:
I realized just now that drongo has been intermittently failing like this:
147/256 postgresql:recovery / recovery/035_standby_logical_decoding
ERROR 2116.16s (exit status 255 or signal 127 SIGinvalid)
---
Tom Lane writes:
> Michael Paquier writes:
>> On Thu, Jan 23, 2025 at 08:25:45PM +, Dagfinn Ilmari Mannsåker wrote:
>>> Here's a patch for that.
>
>> Thanks. I had a bit of time today and applied it.
>
> BF member drongo doesn't like the new test for amcheck.
> Looks like it has to do with
On 11/20/24 17:44, David Steele wrote:
On 10/3/24 05:11, David Steele wrote:
On 10/3/24 07:45, Michael Paquier wrote:
1) is something that has more value than 2), IMO, because there is no
need for a manual step when a backup is taken by the replication
protocol. Well, custom backup solutions
Am Donnerstag, dem 23.01.2025 um 21:36 +0800 schrieb Japin Li:
Thanks for your review again. I am going to work on the other items,
but this one might need further discussion:
> 5.
> Does the following work as expected?
>
> postgres=# select crypt('hello',
> '$5$$6$rounds=1$/Zg436s2vmTwsoSz'
On 2025-Jan-24, Bernd Helmle wrote:
> So we behave exactly the same way as px_crypt_md5(): It stops after the
> first '$' after the magic byte preamble. For shacrypt, this could be
> the next '$' after the closing one of the non-mandatory 'rounds'
> option, but with your example this doesn't happe
I realized just now that drongo has been intermittently failing like this:
147/256 postgresql:recovery / recovery/035_standby_logical_decoding
ERROR 2116.16s (exit status 255 or signal 127 SIGinvalid)
- 8< --
On Fri, Jan 24, 2025 at 9:15 AM Melanie Plageman
wrote:
> So, in this case, there is only one table in question, so 1 autovacuum
> worker (and up to 2 maintenance parallel workers for index vacuuming).
> The duration I provided is just the absolute duration from start of
> vacuum to finish -- not
>
> Thoughts?
>
I don't have anything to add to what Nathan said, but thought I should say
so since this thread was broken off from my earlier thread. Eagerly
awaiting feedback.
On 01/24/25 10:49, Chapman Flack wrote:
> The SQL-standard `XMLDOCUMENT` function applied to an XML value
> /expr/ has effects equivalent to the XML Query expression
> `document { /expr/ }`, specified to replace any document nodes
> in the input with their children and wrap the whole result in one
On 01/24/25 08:48, Jim Jones wrote:
> In the SQL/XML specification, the XMLDocument (X030) function is
> designed to return a document node from a given XML value expression.
Maybe we can take advantage of the way that specifications usually
don't mandate an implementation, but only results equiva
On Fri, Jan 24, 2025 at 8:23 PM Andrew Dunstan wrote:
>
>
> On 2025-01-23 Th 4:06 PM, Robert Haas wrote:
> > On Thu, Jan 23, 2025 at 3:51 PM Andres Freund wrote:
> >> I wonder if it's a mistake that a role membership that has WITH ADMIN on
> >> another role is silently removed if the member role
Michael Paquier writes:
> On Thu, Jan 23, 2025 at 08:25:45PM +, Dagfinn Ilmari Mannsåker wrote:
>> Here's a patch for that.
> Thanks. I had a bit of time today and applied it.
BF member drongo doesn't like the new test for amcheck.
Looks like it has to do with SSPI authentication producing
Andrew Dunstan writes:
> I don't think we need a new file for this. pg_backup_utils.c is already
> there for routines common to pg_restore and pg_dump.
I'm not even on board with having a new function, because I doubt
we should try to share this code in the first place. Who's to
say that pg_dum
On Thu, Jan 23, 2025 at 03:10:16PM -0500, Tom Lane wrote:
> That line of reasoning leads to the same conclusion, that another
> built-in role might be a suitable solution --- unless said role is
> so powerful that the service providers might want to block access
> to it too. Probably limiting it t
Andrew Dunstan writes:
> On 2025-01-24 Fr 7:25 AM, Peter Eisentraut wrote:
>> This has been committed. And I understand there is a buildfarm client
>> update available for the affected buildfarm members.
> This should only be rhinoceros. Joe can pull this fix:
> https://github.com/PGBuildFarm/
On Fri, Jan 24, 2025 at 11:46 PM Junwang Zhao wrote:
>
> On Fri, Jan 24, 2025 at 9:31 PM Ashutosh Bapat
> wrote:
> >
> > On Sun, Jan 19, 2025 at 6:45 PM Junwang Zhao wrote:
> > >
> > > Hi Ashutosh,
> > >
> > > On Wed, Jan 1, 2025 at 5:02 PM Ashutosh Bapat
> > > wrote:
> > > >
> > > > On Wed, Ja
On Fri, Jan 24, 2025 at 09:53:09AM -0500, Andrew Dunstan wrote:
> On 2025-01-23 Th 4:06 PM, Robert Haas wrote:
>> On Thu, Jan 23, 2025 at 3:51 PM Andres Freund wrote:
>> > I wonder if it's a mistake that a role membership that has WITH ADMIN on
>> > another role is silently removed if the member r
Maxim Orlov writes:
> I tend to agree with you here about the semantics of such casts. But
> consistency and "predictability" of
> behaviour for the casts are a bit more important in my view. At least,
> based on my experience. So, I'm
> for 0002 patch.
OK. Nobody has spoken against the 0001 pat
On Fri, Jan 24, 2025 at 9:31 PM Ashutosh Bapat
wrote:
>
> On Sun, Jan 19, 2025 at 6:45 PM Junwang Zhao wrote:
> >
> > Hi Ashutosh,
> >
> > On Wed, Jan 1, 2025 at 5:02 PM Ashutosh Bapat
> > wrote:
> > >
> > > On Wed, Jan 1, 2025 at 2:22 PM Ashutosh Bapat
> > > wrote:
> > > >
> > > > On Sat, Dec
On Mon, Jan 06, 2025 at 03:27:18PM -0600, Nathan Bossart wrote:
> On Mon, Dec 30, 2024 at 03:45:03PM -0500, Bruce Momjian wrote:
>> On Mon, Dec 30, 2024 at 12:02:47PM -0800, Jeff Davis wrote:
>>> I suggest that we make a new thread about the vacuumdb changes and
>>> focus this thread and patch seri
Hi,
Thanks for looking into this!
On Fri, 24 Jan 2025 at 17:20, Bertrand Drouvot
wrote:
>
> I did not look at the code yet but did a few tests.
> I can see diff between pg_stat_wal and pg_stat_io, for example:
>
> "
> postgres=# select pg_stat_reset_shared();
> pg_stat_reset_shared
> --
pá 24. 1. 2025 v 14:48 odesílatel Jim Jones
napsal:
>
> On 24.01.25 13:48, Pavel Stehule wrote:
> > Lot of users use XML functions without XMLDOCUMENT now. The doc should to
> > help with a reply to question where and when I need (I can) use this
> > function. This should
> > be in context of Pos
I also noticed that \d on an index doesn't warn about the invisible state
whereas \d on a table does:
[local]:5444 postgres@postgres=# SELECT indexrelid::regclass,
indisvalid, indisvisible FROM pg_index WHERE indexrelid =
'repli_pkey'::regclass \gx
-[ RECORD 1 ]+---
indexrelid | repli_pk
On Wed, Jan 22, 2025 at 10:18 PM Robert Pang wrote:
>
> On Wed, Jan 15, 2025 at 12:05 PM Andres Freund wrote:
> >
> > If you have wal_recycle=true, this overhead will only be paid the first
> > time a
> > WAL segment is used, of course, not after recycling.
>
> Today, our pg_stat_wal view [1] do
On Thu, Jan 23, 2025 at 6:35 PM Mahendra Singh Thalor
wrote:
>
> On Thu, 23 Jan 2025 at 14:59, jian he wrote:
> >
> > hi.
> > The four patches attached are to solve the
> > TODO1: We need to think for --exclude-database=PATTERN for pg_restore.
> > it is based on your
> > v11_pg_dumpall-with-dire
Look like an overlook for me. Apparently no one has encountered this use
case before.
Patch seems good to me with no visible defects. Deparse support was also
added. As well as a
test case. But do we really need copy/paste code for a T_ArrayCoerceExpr
case? To be more specific,
can we "reuse" T_Re
On 2025-01-23 Th 4:06 PM, Robert Haas wrote:
On Thu, Jan 23, 2025 at 3:51 PM Andres Freund wrote:
I wonder if it's a mistake that a role membership that has WITH ADMIN on
another role is silently removed if the member role is removed. We e.g. do
*not* do that for pg_auth_members.grantor:
ERR
On 1/24/25 14:58, Laurenz Albe wrote:
On Fri, 2025-01-24 at 13:34 +, Bertrand Drouvot wrote:
+ Since indexes have a default fillfactor of 90, this should be around 0.9 for
+ newly built indexes
I think 0.9 should be replaced by 90 (that's the actual kind of output we'd
get).
Damn! I m
On Fri, Jan 24, 2025 at 2:37 PM Alvaro Herrera wrote:
> I ran Kuzmenkov's test case with Watari-san's patch. Planning time goes
> from 2700ms to 600ms or so.
Thank you, good to know that it helps this case as well.
On Fri, Jan 24, 2025 at 11:32 AM Benoit Lobréau
wrote:
> The completion for the INVISIBLE / VISIBLE keyword is missing in psql.
I think this should to the trick ?
diff --git a/src/bin/psql/tab-complete.in.c b/src/bin/psql/tab-complete.in.c
index 81cbf10aa28..43ea8e55fd0 100644
--- a/src/bin/psql
Hi,
On Fri, Jan 24, 2025 at 11:31:02AM +0300, Nazir Bilal Yavuz wrote:
> v9 is rebased and attached as three patches. The first one is a
> squashed patch for the current version of Andres' proposed fix to pass
> the CI, the second one is for adding WAL stats to pg_stat_io and the
> third one is fo
On Thu, Jan 23, 2025 at 12:16 PM Robert Haas wrote:
>
> On Wed, Jan 22, 2025 at 5:48 PM Melanie Plageman
> wrote:
> > Circling back to benchmarking, I've been running the most adversarial
> > benchmarks I could devise and can share a bit of what I've found.
> >
> > I created a "hot tail" benchmar
On 2025-01-24 Fr 3:04 AM, Srinath Reddy wrote:
On Fri, Jan 24, 2025 at 1:42 AM Andrew Dunstan
wrote:
`git blame` tells me that this switch statement goes back to 2001.
Seeking a reason at this distance is unlikely to be productive.
Probably
we were not nearly as careful th
On 1/24/25 09:00, Andrew Dunstan wrote:
On 2025-01-24 Fr 7:25 AM, Peter Eisentraut wrote:
On 27.08.24 10:12, Peter Eisentraut wrote:
Here is a new patch version.
I simplified the uses of sed and awk inside the Perl script. I also
fixed "make installcheck". I noticed that meson installs sep
On 2025-01-24 Fr 7:25 AM, Peter Eisentraut wrote:
On 27.08.24 10:12, Peter Eisentraut wrote:
Here is a new patch version.
I simplified the uses of sed and awk inside the Perl script. I also
fixed "make installcheck". I noticed that meson installs sepgsql.sql
into the wrong directory, so t
On 1/24/25 08:55, Daniel Gustafsson wrote:
On 23 Jan 2025, at 21:42, Joe Conway wrote:
LGTM
After staring at it a bit more and fixing a few small details I committed this.
\o/
Thanks for getting this over the finish line!
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databa
On Fri, 2025-01-24 at 13:34 +, Bertrand Drouvot wrote:
> + Since indexes have a default fillfactor of 90, this should be around 0.9 for
> + newly built indexes
>
> I think 0.9 should be replaced by 90 (that's the actual kind of output we'd
> get).
>
> But having said that, I'm not sure we sh
> On 23 Jan 2025, at 21:42, Joe Conway wrote:
> LGTM
After staring at it a bit more and fixing a few small details I committed this.
--
Daniel Gustafsson
On 24.01.25 13:48, Pavel Stehule wrote:
> Lot of users use XML functions without XMLDOCUMENT now. The doc should to
> help with a reply to question where and when I need (I can) use this
> function. This should
> be in context of Postgres where every XML expr returns XML value, so
> sentence
> cr
Hi,
>
> Just idea; as an another option, how about blocking new requests to
> the target process (e.g., causing them to fail with an error or
> returning NULL with a warning) if a previous request is still pending?
> Users can simply retry the request if it fails. IMO failing quickly
> seems prefe
Hi,
On Fri, Jan 24, 2025 at 12:34:08PM +0100, Frédéric Yhuel wrote:
> I don't know if you noticed Laurenz's suggestion, because he forgot to CC
> you, but I like it very much. I think we should mention the default
> fillfactor (90 for indexes).
Thanks for mentioning Laurenz's suggestion!
=== 1
On 2025-Jan-24, Aleksander Alekseev wrote:
> Did you consider checking if the referenced patchset addresses the
> issue you described?
I ran Kuzmenkov's test case with Watari-san's patch. Planning time goes
from 2700ms to 600ms or so.
--
Álvaro HerreraBreisgau, Deutschland — https://
On 1/24/25 01:44, Michael Paquier wrote:
On Thu, Jan 23, 2025 at 02:53:39PM +, David Steele wrote:
I discovered this while testing on Postgres versions < 12 where
The tests are probably excessive but I needed something to show that the
verification works as expected.
Even with your patch,
Hi,
> > I think this is closely related to the work Yuya Watari has been doing
> > at
> > https://postgr.es/m/caj2pmkzzhrhgq5uv0y+stkqx7xvgzenmhl98ubkm-oarvk9...@mail.gmail.com
> > Perhaps you could contribute by reviewing that patch series.
>
> Yeah, I'm referencing this one in my email, but it's
Hi Dean,
> IMO big-endian is the most convenient byte-ordering to use here,
> because then the string representation of the bytea is consistent with
> the hex representation of the integer. It's also consistent with the
> integer-to-bit casts, which output the most significant bits first,
> starti
On Sat, 3 Aug 2024 at 23:10, Tom Lane wrote:
> It strikes me that there's also a question of whether json::text
> should translate 'null' like this. I'm inclined to think not,
> since json is in some sense a domain over text, but it's certainly
> debatable.
>
I tend to agree with you here about
pá 24. 1. 2025 v 13:21 odesílatel Jim Jones
napsal:
>
> On 24.01.25 12:31, Pavel Stehule wrote:
> > I don't know what it means - `function returns a document node` in the
> > context of Postgres implementation of XML.
> > I miss the information so it returns an input argument without
> > changing
On 27.08.24 10:12, Peter Eisentraut wrote:
Here is a new patch version.
I simplified the uses of sed and awk inside the Perl script. I also
fixed "make installcheck". I noticed that meson installs sepgsql.sql
into the wrong directory, so that's fixed also. (Many of the
complications in thi
On 24.01.25 12:31, Pavel Stehule wrote:
> I don't know what it means - `function returns a document node` in the
> context of Postgres implementation of XML.
> I miss the information so it returns an input argument without
> changing anything, because in a system, where XML expression
> holds a c
Hi,
My previous patch had whitespace issues.
I recreated the patch.
I will create a commitfest with this patch.
Regards,
Kohei Harikae
installation-meson.patch
Description: installation-meson.patch
1 - 100 of 114 matches
Mail list logo
