On Fri, Oct 18, 2024 at 05:20:42PM +0300, Aleksander Alekseev wrote:
> Rebased, v5.
v5-0001 includes the following output:
--- a/src/test/regress/expected/opr_sanity.out
+++ b/src/test/regress/expected/opr_sanity.out
@@ -126,9 +126,12 @@ WHERE p1.oid < p2.oid AND
p1.proretset != p2.proretse
On 20.12.24 16:23, Tom Lane wrote:
Ok, we can fix that, but maybe this is also a good moment to think about
whether that is useful. I could not reproduce the issue with flex
2.5.39. I could find no download of flex 2.5.35. The github site only
offers back to 2.5.39, the sourceforce site back t
On Wed, Jan 8, 2025 at 10:02 PM Peter Eisentraut
wrote:
> On 07.01.25 20:49, Mats Kindahl wrote:
> > This is the first example semantic patch and shows how to capture and
> > fix a common problem.
> >
> > If you use an palloc() to allocate memory for an object (or an array of
> > objects) and by
Dear Tom, Fujii-san,
> > ISTM that ecpg supports COPY TO STDOUT and includes the regression test
> "copystdout" for it. No?
>
> Oh right. (Pokes at it...) It looks like the backend accepts
> "FROM STDOUT" as a synonym for "FROM STDIN", so that's why this
> is checking for both spellings. But I
On Sat, Jan 4, 2025 at 4:23 AM Robert Treat wrote:
>
> On Wed, Dec 18, 2024 at 5:56 AM Amit Kapila wrote:
> >
> > On Thu, Feb 8, 2024 at 9:57 AM Laurenz Albe
> > wrote:
> > >
> > > On Thu, 2024-02-08 at 13:40 +1100, Peter Smith wrote:
> > > > - how to set the replica identity. If a table wit
On Thu, 9 Jan 2025 at 15:30, Alexander Lakhin wrote:
>
> Maybe you could try to reproduce such failures without buildfarm client,
just
> by running select_parallel, for example, with the attached patch applied.
> I mean running `make check` with parallel_schedule like:
> ...
> Or
> TESTS="test_set
Dear Shubham,
Thanks for updating the patch. Few comments.
```
+#include "common/int.h"/* include for strtoi64 */
```
I could build the source code without the inclusion. Can you remove?
```
+ max_slot_wal_keep_size = strtoi64(PQgetvalue(res, 0, 6), NULL, 0);
+
+
Hi,
Thanks for the review!
On Thu, 9 Jan 2025 at 05:59, Michael Paquier wrote:
>
> On Thu, Dec 26, 2024 at 02:41:26PM +0300, Nazir Bilal Yavuz wrote:
> > Thanks! v4 is attached. I quickly tested the pg_stat_get_backend_io()
> > function and it seems it is working.
>
> Thanks a lot for the rebase
Hi,
On Thu, Jan 09, 2025 at 01:03:15PM +0900, Michael Paquier wrote:
> On Wed, Jan 08, 2025 at 11:11:59AM +, Bertrand Drouvot wrote:
> > Yeah, that's more elegant as it also means that the main callback will not
> > change
> > (should we add even more stats in the future). Done that way in v2
On Mon, Jan 6, 2025 at 7:59 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Shubham,
>
> Thanks for creating a patch. I have one comment about it.
>
> check_publisher() assumed that the SQL function
> `pg_catalog.current_setting('max_slot_wal_keep_size')`
> will return the numeric, but it just return
On Mon, Jan 6, 2025 at 3:22 AM Peter Smith wrote:
>
> Hi Shubham.
>
> The patch v6-0001 LGTM.
>
> OTOH, if you want to be picky, the docs wording could be slightly
> modified to be more consistent with the coded warning message.
>
> CURRENT
> Replication failures can occur if required WAL files ar
On 2024-Dec-27, Andrey Borodin wrote:
> > On 19 Dec 2024, at 20:48, Yura Sokolov wrote:
> >
> > Here's version with type change bits16 -> uint16
>
> Thanks! This version looks good to me. I’ll mark the CF entry as RfC.
Thank you, I have pushed this.
--
Álvaro Herrera 48°01'N 7°
> If it's not too much work to coax the compiler to do so, then I don't see a
> strong reason to avoid it. Granted, there are probably much more expensive
> parts of the StringInfo support functions (e.g., palloc()), but these are
> hot enough code paths that IMHO it's worth saving whatever cycles
Hi,
After looking at this ever more today, I think "Server Parameter Settings"
> is confusing as well. I think "Connection Status" instead of
> "Current Status" as is defined in v36 will work better.
> This way we will have "Connection Info" and "Connection Status".
> Connection Status will reflec
On Wed, Jan 8, 2025 at 2:24 PM Amit Kapila wrote:
>
> On Wed, Jan 8, 2025 at 2:15 PM Masahiko Sawada wrote:
> >
> > On Tue, Jan 7, 2025 at 2:49 AM Amit Kapila wrote:
> > > >
> > > > We thought of another approach, which is to create/drop this slot first
> > > > as
> > > > soon as one enables/di
Hi All,
Starting from PG16, it seems that orphaned users can only be managed
by superusers. For example, if userA creates userB, and userB creates
userC, then both userB (the parent of userC) and userA (the
grandparent of userC) would typically have the ability to
manage/administer userC. However,
Hello Robins,
22.12.2024 09:27, Robins Tharakan wrote:
- The only info about leafhopper may be relevant is that it's one of the newest machines (Graviton4) so it comes with
a recent hardware / kernel / stock gcc 11.4.1.
Could you please take a look at leafhopper. which is producing weird tes
On Thu, Jan 02, 2025 at 08:08:42PM -0500, Andres Freund wrote:
> I can't think of a real case where we would want to WAL log the stats
> themselves, rather than re-emitting stats during replay based on the WAL
> record of the "underlying object".
>
> Do you have counter-examples?
I'm not sure if
On Wed, Jan 08, 2025 at 11:11:59AM +, Bertrand Drouvot wrote:
> Yeah, that's more elegant as it also means that the main callback will not
> change
> (should we add even more stats in the future). Done that way in v2 attached.
I've put my hands on v2-0002 to begin with something.
+/* flag bi
On Thursday, January 9, 2025 9:48 AM Masahiko Sawada
Hi,
>
> On Wed, Jan 8, 2025 at 3:00 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Wednesday, January 8, 2025 6:33 PM Masahiko Sawada
> wrote:
> >
> > Hi,
> >
> > > On Wed, Jan 8, 2025 at 1:53 AM Amit Kapila
> > > wrote:
> > > > On Wed, Jan 8
On Wed, Jan 8, 2025 at 9:35 PM Andrew Dunstan wrote:
>
>
>
> I forget now what I was intending here, so I have committed this with minor
> tweaks.
>
>
Thanks Andrew for taking care of this.
--
Best Wishes,
Ashutosh Bapat
On Thursday, January 9, 2025 9:48 AM Masahiko Sawada
wrote:
Hi,
>
> On Wed, Jan 8, 2025 at 3:00 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Wednesday, January 8, 2025 6:33 PM Masahiko Sawada
> wrote:
> >
> > Hi,
> >
> > > On Wed, Jan 8, 2025 at 1:53 AM Amit Kapila
> > > wrote:
> > > > On We
> Of course, a patch for that would be a few orders of magnitude
> larger than what you've got here :-(. But if you're looking
> for a framework for reporting these sorts of details, I'd
> much rather go in that direction than follow the model of
> VACUUM VERBOSE. VACUUM VERBOSE is a kluge with l
On Wed, Jan 8, 2025 at 8:44 AM Dean Rasheed
wrote:
> Attached is a more complete patch
+1, looks good
So in the end, I decided to just add a sentence to each command's
> description, keeping it as
> short as possible.
>
Yes, that makes sense.
Cheers,
Greg
hi.
in create_grouping_expr_infos
tce = lookup_type_cache(exprType((Node *) tle->expr),
TYPECACHE_BTREE_OPFAMILY);
if (!OidIsValid(tce->btree_opf) ||
!OidIsValid(tce->btree_opintype))
return;
/*
*
On Tue, Jan 7, 2025 at 9:54 AM Thomas Munro wrote:
> On Tue, Jan 7, 2025 at 5:23 AM Andrew Dunstan wrote:
> > Do you have a plan for moving ahead with this?
>
> I think that all looks good, and I'll go ahead and commit it in the
> next day or two. Sorry for the delay.
I changed some remaining o
On Thu, Dec 26, 2024 at 02:41:26PM +0300, Nazir Bilal Yavuz wrote:
> Thanks! v4 is attached. I quickly tested the pg_stat_get_backend_io()
> function and it seems it is working.
Thanks a lot for the rebased version. This looks pretty solid. Here
are some comments.
void
-pgstat_count_io_op(IOOb
On Thu, 9 Jan 2025 at 02:30, Guillaume Lelarge wrote:
>
> Hi,
>
> Le mer. 8 janv. 2025 à 17:41, Mahendra Singh Thalor a
> écrit :
>>
>> On Wed, 8 Jan 2025 at 20:07, Mahendra Singh Thalor
>> wrote:
>> >
>> > Hi all,
>> >
>> > On Wed, 8 Jan 2025 at 00:34, Mahendra Singh Thalor
>> > wrote:
>> >
> Unfortunately, these changes do not achieve the intended sampling goal.
> I looked into this more deeply: while the sampled-out queries do not
> appear in pg_stat_statements, an entry is still allocated in the hash
> table after normalization, which, in my view, should not happen when
> sampling
Hi,
I modified the patch according to Tom's suggestion.
--
Regards,
ChangAo Chen
v2-0001-Fix-a-wrong-errdetail-in-AlterRole.patch
Description: Binary data
On Wed, Jan 8, 2025 at 3:00 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Wednesday, January 8, 2025 6:33 PM Masahiko Sawada
> wrote:
>
> Hi,
>
> > On Wed, Jan 8, 2025 at 1:53 AM Amit Kapila
> > wrote:
> > > On Wed, Jan 8, 2025 at 3:02 PM Masahiko Sawada
> > wrote:
> > > >
> > > > On Thu, Dec 19, 2024
On Wed, Jan 8, 2025 at 8:39 AM Peter Eisentraut wrote:
>
> On 07.01.25 18:31, Melanie Plageman wrote:
> >
> > Oh, one thing I forgot to say. Though I increased the indentation of
> > some of the subsections that I moved, I didn't rewrap the lines
> > because they were already not wrapped to 78. I
On Wed, Jan 8, 2025 at 6:35 AM Daniel Gustafsson wrote:
>
> > On 7 Jan 2025, at 21:14, Tom Lane wrote:
>
> > I might be wrong, but I had the idea that our docs website has a
> > capability to provide such redirects. You'd probably need to ask
> > about that on the pgsql-www list, unless somebody
Abhishek Chanda writes:
> Attached is a patch to add support for logging secrets used in TLS
> connection after psql is initialized. This adds a new env var
> SSLKEYLOGFILE on the client side that points to a text file where keys
> will be logged.
I wonder if this poses a security risk, ie someth
Hi,
On 2025-01-07 14:59:58 -0500, Robert Haas wrote:
> On Tue, Jan 7, 2025 at 11:11 AM Andres Freund wrote:
> > The difference between a handle and a reference is useful right now, to have
> > some separation between the functions that can be called by anyone (taking a
> > PgAioHandleRef) and onl
On Wed, Jan 8, 2025 at 3:01 PM Nathan Bossart wrote:
>
> On Wed, Jan 08, 2025 at 02:48:10PM +0100, Frédéric Yhuel wrote:
> > For what it's worth, although I would have preferred the sub-linear growth
> > thing, I'd much rather have this than nothing.
>
> +1, this is how I feel, too. But I also do
On Mon, Jan 6, 2025 at 1:07 PM Jim Nasby wrote:
>
> I’ve been saying “workload management” for lack of a better term, but my
> initial suggestion upthread was to simply stop allowing new transactions to
> start if global work_mem consumption exceeded some threshold. That’s
> simplistic enough t
Hello folks,
Attached is a patch to add support for logging secrets used in TLS
connection after psql is initialized. This adds a new env var
SSLKEYLOGFILE on the client side that points to a text file where keys
will be logged. If a user runs psql multiple times with the same
SSLKEYLOGFILE, new e
On Thu, 2024-12-19 at 09:51 -0800, Jeff Davis wrote:
> But there's a problem: full case folding doesn't preserve the normal
> form, so even if the input is NFC normalized, the output might not
> be.
> If we solve this problem, then we can just say that CASEFOLD()
> preserves the normal form, consis
On Wed, Jan 8, 2025 at 04:24:34PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I think this needs some serious research.
>
> We've discussed this topic before. The spec's definition of IS [NOT]
> NULL for composite values is bizarre to say the least. I think
> there's been an intentional
Nathan Bossart writes:
> AFAICT TAS_SPIN() is only used for s_lock(), which doesn't appear to be
> used by LWLocks. But I did retry my test from upthread without
> pg_stat_statements and was surprised to find a reproducible 4-6%
> regression.
On what hardware?
I just spent an hour beating on my
Hi,
On 2025-01-07 22:09:56 +0200, Heikki Linnakangas wrote:
> On 07/01/2025 18:11, Andres Freund wrote:
> > > I didn't quite understand the point of the prepare callbacks. For example,
> > > when AsyncReadBuffers() calls smgrstartreadv(), the
> > > shared_buffer_readv_prepare() callback will be ca
On Wed, Jan 08, 2025 at 05:25:24PM -0500, Andres Freund wrote:
> On 2025-01-08 16:01:19 -0600, Nathan Bossart wrote:
>> But I did retry my test from upthread without pg_stat_statements and was
>> surprised to find a reproducible 4-6% regression.
>
> Uh, huh. I assume this was readonly pgbench with
Hi,
On 2025-01-08 16:01:19 -0600, Nathan Bossart wrote:
> On Wed, Jan 08, 2025 at 03:07:24PM -0500, Andres Freund wrote:
> > Out of curiosity, have you measured whether this has a positive effect
> > without
> > pg_stat_statements? I think it'll e.g. also affect lwlocks, as they also use
> > perf
On Thu, Aug 15, 2024, at 5:53 PM, Doruk Yilmaz wrote:
> Hello again,
>
> On Tue, Aug 13, 2024 at 12:48 AM Euler Taveira wrote:
> > I'm curious about your use case. Is it just because the internal function
> > has a
> > different signature or your tool is capable of apply logical replication
> >
On Wed, Jan 08, 2025 at 03:07:24PM -0500, Andres Freund wrote:
> Out of curiosity, have you measured whether this has a positive effect without
> pg_stat_statements? I think it'll e.g. also affect lwlocks, as they also use
> perform_spin_delay().
AFAICT TAS_SPIN() is only used for s_lock(), which
Yugo NAGATA writes:
> Thank you for your reviewing and editing the patch!
> I agree with your proposal on the error message handling.
Cool, pushed v4 then.
regards, tom lane
On Wed, Jan 8, 2025 at 8:01 PM Nathan Bossart
wrote:
> On Wed, Jan 08, 2025 at 02:48:10PM +0100, Frédéric Yhuel wrote:
> > For what it's worth, although I would have preferred the sub-linear
> growth
> > thing, I'd much rather have this than nothing.
>
> +1, this is how I feel, too. But I also d
On 08.01.2025 22:39, Ilia Evdokimov wrote:
After the changes in v9-patch, won’t all the necessary queries now be
normalized? Since there are no longer any restrictions in the parser
hook, queries will be normalized as usual, and pgss_planner,
pgss_ExecutorStart, and ExecutorEnd will simply
Bruce Momjian writes:
> I think this needs some serious research.
We've discussed this topic before. The spec's definition of IS [NOT]
NULL for composite values is bizarre to say the least. I think
there's been an intentional choice to keep most NOT NULL checks
"simple", that is we look at the
On Fri, Jan 3, 2025 at 01:39:44PM +, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/17/sql-createdomain.html
> Description:
>
> The manual claims:
>
> The syntax NOT NULL in this command is a Postgr
On 07.01.25 20:49, Mats Kindahl wrote:
This is the first example semantic patch and shows how to capture and
fix a common problem.
If you use an palloc() to allocate memory for an object (or an array of
objects) and by mistake type something like:
StringInfoData *info = palloc(sizeof(St
Hi,
Le mer. 8 janv. 2025 à 17:41, Mahendra Singh Thalor a
écrit :
> On Wed, 8 Jan 2025 at 20:07, Mahendra Singh Thalor
> wrote:
> >
> > Hi all,
> >
> > On Wed, 8 Jan 2025 at 00:34, Mahendra Singh Thalor
> wrote:
> > >
> > > On Mon, 6 Jan 2025 at 23:05, Nathan Bossart
> wrote:
> > > >
> > > >
Hi,
On 2025-01-08 15:04:39 +0100, Jakub Wartak wrote:
> On Mon, Jan 6, 2025 at 5:28 PM Andres Freund wrote:
> > I didn't think that pg_stat_* was quite the right namespace, given that it
> > shows not stats, but the currently ongoing IOs. I am going with pg_aios for
> > now, but I don't particul
Sami Imseih writes:
> I am curious what are the thoughts on introducing a
> CREATE INDEX VERBOSE which can provide this info?
> similar to users scripting VACUUM VERBOSE to log
> more details about the vacuum operation including parallel
> usage.
What I can recall being discussed in the past is t
On Mon, 2025-01-06 at 12:34 -0800, Jeff Davis wrote:
> If we separate out 4, we can use the Bump allocator for 2 & 3.
Attached POC patch, which reduces memory usage by ~15% for a simple
distinct query on an integer key. Performance is the same or perhaps a
hair faster.
It's not many lines of code
Le mer. 8 janv. 2025 à 21:44, Sami Imseih a écrit :
> > I think DEBUG is perfectly appropriate for this sort of message.
>
> I am curious what are the thoughts on introducing a
> CREATE INDEX VERBOSE which can provide this info?
> similar to users scripting VACUUM VERBOSE to log
> more details ab
Le mer. 8 janv. 2025 à 21:35, Tom Lane a écrit :
> Guillaume Lelarge writes:
> > I tend to agree it might be better than Benoit's patch on the index
> > messages, though I'm afraid that DEBUG1 level won't work for many users.
> > DEBUGx are for developers, not users. A better log level for me wo
> I think DEBUG is perfectly appropriate for this sort of message.
I am curious what are the thoughts on introducing a
CREATE INDEX VERBOSE which can provide this info?
similar to users scripting VACUUM VERBOSE to log
more details about the vacuum operation including parallel
usage.
I have not co
David Steele writes:
> On 1/8/25 12:40, Bruce Momjian wrote:
>> Will people now always get a clear error on failure?
> The error will be something like "directory is not empty" when trying to
> drop a database. So not very clear at all.
Conceivably we could adjust rmtree() to print a HINT men
On Wed, Jan 8, 2025 at 11:37 AM Peter Eisentraut wrote:
> I don't know what you mean by
> "accept in the code". I would agree with "tolerate some inconsistency"
> in the code but not with, like, create alias names for all the interface
> names.
"Tolerate inconsistency" was what I had in mind. So
Guillaume Lelarge writes:
> I tend to agree it might be better than Benoit's patch on the index
> messages, though I'm afraid that DEBUG1 level won't work for many users.
> DEBUGx are for developers, not users. A better log level for me would be
> LOG.
Please, no. That would result in spamming t
On Wed, Jan 08, 2025 at 03:23:45PM -0500, Tom Lane wrote:
> I just acquired an M4 Pro, which may also be too small to show any
> effect, but perhaps running the test there would at least give us
> more confidence that there's not a bad effect. Which test case(s)
> would you recommend trying?
Than
Nathan Bossart writes:
> Are there any objections to proceeding with this change? So far, it's been
> tested on a c8g.24xlarge and an Apple M3 (which seems to be too small to
> show any effect). If anyone has access to a larger ARM machine, additional
> testing would be greatly appreciated. I t
On Wed, Jan 8, 2025 at 03:21:27PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Will people now always get a clear error on failure? Crazy idea, but
> > could we have initdb or postmaster start test this?
>
> It'd require adding quite a lot of cycles: I'd guess you'd need to
> create/drop
Hi,
Le mer. 8 janv. 2025 à 18:37, Sami Imseih a écrit :
> > s/parallel vacuum workers for index vacuuming/parallel workers for index
> creation/?
>
> oops, that's my oversight from copying the message from vacuum. fixed.
>
> > I'd add "in parallel" to match its counterpart "serially" above. That
Bruce Momjian writes:
> Will people now always get a clear error on failure? Crazy idea, but
> could we have initdb or postmaster start test this?
It'd require adding quite a lot of cycles: I'd guess you'd need to
create/drop a hundred or a thousand files to be sure of seeing the
problem.
Anot
Hi,
On 2025-01-08 12:12:19 -0600, Nathan Bossart wrote:
> On Tue, Oct 22, 2024 at 02:54:57PM -0500, Nathan Bossart wrote:
> > My colleague Salvatore Dipietro (CC'd) sent me a couple of profiles that
> > showed an enormous amount of s_lock() time going to the
> > __sync_lock_test_and_set() call in
On Wed, Jan 08, 2025 at 02:48:10PM +0100, Frédéric Yhuel wrote:
> For what it's worth, although I would have preferred the sub-linear growth
> thing, I'd much rather have this than nothing.
+1, this is how I feel, too. But I also don't want to add something that
folks won't find useful.
> And I
Hi,
On 2025-01-08 23:27:42 +0800, jian he wrote:
> hi.
> i am wondering ways to do
> ``make check PGOPTIONS="-c debug_parallel_query=regress -c work_mem=50MB"``
> in meson way, especially the PGOPTIONS part.
>
> I have looked at [1] and [2].
> [1]
> https://www.postgresql.org/docs/current/regres
On 07.01.2025 22:29, Sami Imseih wrote:
You are right. This is absolutely unexpected for users. Thank you for
the review.
To fix this, I suggest storing a random number in the [0, 1) range in a
separate variable, which will be used for comparisons in any place. We
will compare 'sample_rate' and
On 07.01.25 23:24, Jacob Champion wrote:
On Thu, Jan 2, 2025 at 2:11 AM Peter Eisentraut wrote:
There is a mix of using "URL" and "URI" throughout the patch. I tried
to look up in the source material (RFCs) what the correct use would
be, but even they are mixing it in nonobvious ways. Maybe t
Hi,
On 2025-01-08 14:48:21 +, Bertrand Drouvot wrote:
> On Wed, Jan 08, 2025 at 03:10:03PM +0200, Heikki Linnakangas wrote:
> > On 08/01/2025 04:10, Andres Freund wrote:
> > > 0002: Make logging of postmaster signalling child processes more
> > > consistent
> > >
> > >I found it somew
Em qua., 8 de jan. de 2025 às 16:23, Vik Fearing
escreveu:
> This is lying to the planner, and you get to enjoy whatever breaks
> because of it. A function that accesses external data is not immutable;
> it is stable at best.
>
I understand that, but it's not documented, so users can think that
On 08.01.25 17:38, Tom Lane wrote:
Peter Eisentraut writes:
On 03.12.24 15:15, jian he wrote:
SELECT attrelid, attname, attgenerated FROM pg_attribute WHERE
attgenerated IN ('v') and (attnotnull or not atthasdef);
I don't understand what the purpose of testing attnotnull is. That is
indepe
Hi,
On 2025-01-08 15:10:03 +0200, Heikki Linnakangas wrote:
> On 08/01/2025 04:10, Andres Freund wrote:
> > I instead opted to somewhat rearrange the shutdown sequence:
> > - I don't love the naming of the various PMState values (existing and new),
> >but a larger renaming should probably be d
On 08/01/2025 20:19, Marcos Pegoraro wrote:
Em qua., 8 de jan. de 2025 às 13:14, Peter Eisentraut
escreveu:
Here is a new patch version where I have gathered various pieces of
feedback and improvement suggestions that are scattered over this
thread. I hope I got them all. I wil
Em qua., 8 de jan. de 2025 às 13:14, Peter Eisentraut
escreveu:
> Here is a new patch version where I have gathered various pieces of
> feedback and improvement suggestions that are scattered over this
> thread. I hope I got them all. I will respond to the respective
> messages directly to give
On 1/8/25 12:40, Bruce Momjian wrote:
On Tue, Jan 7, 2025 at 01:03:05AM +, David Steele wrote:
I'm more concerned about the report we saw on SUSE/NFS [1]. If that
report is accurate it indicates this may not be something we can just
document and move on from -- unless we are willing to enti
On Tue, Oct 22, 2024 at 02:54:57PM -0500, Nathan Bossart wrote:
> My colleague Salvatore Dipietro (CC'd) sent me a couple of profiles that
> showed an enormous amount of s_lock() time going to the
> __sync_lock_test_and_set() call in the AArch64 implementation of tas().
> Upon closer inspection, I
On Tue, Jan 07, 2025 at 03:57:57PM +0900, Tatsuo Ishii wrote:
> So the v2 patch version is 1.3787% slower than master. Do you think we
> need further inlining?
If it's not too much work to coax the compiler to do so, then I don't see a
strong reason to avoid it. Granted, there are probably much m
On Tue, Jan 7, 2025 at 01:03:05AM +, David Steele wrote:
> > > I'm more concerned about the report we saw on SUSE/NFS [1]. If that
> > > report is accurate it indicates this may not be something we can just
> > > document and move on from -- unless we are willing to entirely drop
> > > support
On Wed, Jan 08, 2025 at 10:29:12AM -0500, Tom Lane wrote:
> "=?ISO-8859-1?B?Y2NhNTUwNw==?=" writes:
>> postgres=> alter group g1 drop user r1;
>> ERROR: permission denied to alter role
>> DETAIL: Only roles with the ADMIN option on role "g1" may add members.
>
>> The errmsg is "add members", bu
> s/parallel vacuum workers for index vacuuming/parallel workers for index
> creation/?
oops, that's my oversight from copying the message from vacuum. fixed.
> I'd add "in parallel" to match its counterpart "serially" above. That would
> make it more clear in case one just look for "building in
On Tue, Jan 7, 2025 at 2:24 PM Jacob Champion
wrote:
> Along those lines, though, Michael Paquier suggested that maybe I
> could pull the require_auth prefactoring up to the front of the
> patchset. That might look a bit odd until OAuth support lands, since
> it won't be adding any new useful valu
On 2024-09-17 Tu 4:53 PM, Florents Tselai wrote:
We could, if we're going to do anything at all in this area.
Another possibility would be to provide a second optional
parameter for json{b}_strip_nulls. That's probably a better way to go.
Here's a patch that adds that argument (onl
On Wed, 8 Jan 2025 at 20:07, Mahendra Singh Thalor wrote:
>
> Hi all,
>
> On Wed, 8 Jan 2025 at 00:34, Mahendra Singh Thalor wrote:
> >
> > On Mon, 6 Jan 2025 at 23:05, Nathan Bossart
> > wrote:
> > >
> > > On Thu, Jan 02, 2025 at 02:05:13AM +0530, Mahendra Singh Thalor wrote:
> > > > Here, I a
Peter Eisentraut writes:
> On 03.12.24 15:15, jian he wrote:
>> SELECT attrelid, attname, attgenerated FROM pg_attribute WHERE
>> attgenerated IN ('v') and (attnotnull or not atthasdef);
> I don't understand what the purpose of testing attnotnull is. That is
> independent of attgenerated, I thi
Fujii Masao writes:
> On 2025/01/09 0:42, Tom Lane wrote:
>> There's another problem: the correct syntax is COPY TO STDOUT,
>> and that won't trigger this warning either.
> ISTM that ecpg supports COPY TO STDOUT and includes the regression test
> "copystdout" for it. No?
Oh right. (Pokes at it
On 03.12.24 15:15, jian he wrote:
-- check constraints
CREATE TABLE gtest20 (a int PRIMARY KEY, b int GENERATED ALWAYS AS (a
* 2) VIRTUAL CHECK (b < 50));
INSERT INTO gtest20 (a) VALUES (10); -- ok
INSERT INTO gtest20 (a) VALUES (30); -- violates constraint
ALTER TABLE gtest20 ALTER COLUMN b S
On 16.12.24 15:34, jian he wrote:
hi. some minor issues...
SET EXPRESSION AS
This form replaces the expression of a generated column. Existing data
in the column is rewritten and all the future changes will apply the new
generation expression.
On 11.12.24 07:49, jian he wrote:
On Fri, Nov 29, 2024 at 6:01 PM Peter Eisentraut wrote:
The purpose of check_modified_virtual_generated() for trigger functions
written in C. The prevent someone from inserting real values into the
trigger tuples, because they would then be processed by the re
On 04.12.24 05:55, jian he wrote:
On Fri, Nov 29, 2024 at 6:13 PM Peter Eisentraut wrote:
- Added support for virtual columns in trigger column lists. (For that,
I renamed ExecInitStoredGenerated() to ExecInitGenerated(), which
handles the computation of ri_extraUpdatedCols.)
why not dupli
On 2024-06-28 Fr 8:35 AM, Ashutosh Bapat wrote:
On Wed, Jun 26, 2024 at 8:54 PM Tom Lane wrote:
Ashutosh Bapat writes:
> The usage help mentions exit code 2 specifically while
describing --check
> option but it doesn't mention exit code 1. Neither does the
README. So I
On 2025/01/09 0:42, Tom Lane wrote:
Fujii Masao writes:
On 2025/01/08 23:04, Ryo Kanbayashi wrote:
But it is not working.
ecpg command fails to notice though code like above exits on pgc code.
This issue seems to have been introduced in commit 3d009e45bd.
Indeed :-(
As for COPY FROM S
On 2025/01/08 21:03, Rahila Syed wrote:
I have not been able to reproduce this issue. Could you please clarify which
process you ran
|pg_get_process_memory_context()| on, with the interval of 0.1?
I used the following query for testing:
=# SELECT count(*) FROM pg_stat_activity, pg_get_proc
Fujii Masao writes:
> On 2025/01/08 23:04, Ryo Kanbayashi wrote:
> But it is not working.
> ecpg command fails to notice though code like above exits on pgc code.
> This issue seems to have been introduced in commit 3d009e45bd.
Indeed :-(
> As for COPY FROM STDOUT, while it's possible, mentioni
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_slots on the subscriber. It
> > uses the same default val
"=?ISO-8859-1?B?Y2NhNTUwNw==?=" writes:
> postgres=> alter group g1 drop user r1;
> ERROR: permission denied to alter role
> DETAIL: Only roles with the ADMIN option on role "g1" may add members.
> The errmsg is "add members", but we are doing a drop.
> Here is a small patch to fix it.
Hmm. S
hi.
i am wondering ways to do
``make check PGOPTIONS="-c debug_parallel_query=regress -c work_mem=50MB"``
in meson way, especially the PGOPTIONS part.
I have looked at [1] and [2].
[1]
https://www.postgresql.org/docs/current/regress-run.html#REGRESS-RUN-CUSTOM-SETTINGS
[2] https://wiki.postgresql
1 - 100 of 142 matches
Mail list logo
