On 2024-07-18 16:01:19 -0400, Tom Lane wrote:
> Alena Rybakina writes:
> > I fixed it. The code remains the same.
>
> I see the cfbot is again complaining that this patch doesn't apply.
>
> In hopes of pushing this over the finish line, I fixed up the (minor)
> patch conflict and also addressed
> * Doc build error and malformatting.
>
Looking into it.
> * I'm not certain that we want all changes to relation stats to be non-
> transactional. Are there transactional use cases? Should it be an
> option? Should it be transactional for pg_set_relation_stats() but non-
> transactional for pg
On Fri, Jul 19, 2024 at 5:47 PM Tatsuo Ishii wrote:
> >> IMO the file name should match the ID of the sect1 element with the
> leading
> >> "functions-" removed, naming the directory "functions". Thus when
> viewing
> >> the web page the corresponding sgml file is determinable.
> >
> > I'd go fo
>> IMO the file name should match the ID of the sect1 element with the leading
>> "functions-" removed, naming the directory "functions". Thus when viewing
>> the web page the corresponding sgml file is determinable.
>
> I'd go for shorter myself (ie "func/"), mainly due to the precedent
> of the
David:
>Only now just grasping that you are trying to group something that is
definitionally random. That just doesn't make sense to me.
Oh, sorry for the confusion. Yeah, totally. I didn't mean to draw specific
attention to GROUP BY -- as you've pointed out elsewhere this issue also
exists with
On Fri, Jul 19, 2024 at 2:45 PM Nathan Bossart
wrote:
>
> +/* dim[i] = 1 + upperIndx[i] - lowerIndx[i]; */
> +if (pg_add_s32_overflow(1, upperIndx[i], &dim[i]))
> +ereport(ERROR,
> +(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
> +
You're right, thanks!
Wen Yi
wen...@qq.com
---Original---
From: "David G. Johnston"
On Fri, 2024-07-19 at 16:03 -0400, Robert Haas wrote:
> On Fri, Jul 19, 2024 at 2:41 PM Laurenz Albe wrote:
> > I'd be alright with the hint, but I'd say "during making an *incremental*
> > standby backup", because that's the only case where it can happen.
> >
> > I think it would also be suffici
On Fri, Jul 19, 2024 at 2:21 PM Paul George wrote:
> Great, thanks for the links and useful past discussions! I figured I
> wasn't the first to stumble across this, and it's interesting to see the
> issue arise with ORDER BY [VOLATILE FUNC] as well.
>
> My question was not so much about changing
On Thu, 2024-07-18 at 02:09 -0400, Corey Huinker wrote:
> v23:
>
> Split pg_set_relation_stats into two functions: pg_set_relation_stats
> with named parameters like it had around v19 and
> pg_restore_relations_stats with the variadic parameters it has had in
> more recent versions, which processe
On Thu, Jul 18, 2024 at 09:57:23AM +0200, Daniel Gustafsson wrote:
>> On 17 Jul 2024, at 23:32, Nathan Bossart wrote:
>> On Wed, Jul 17, 2024 at 11:16:59PM +0200, Daniel Gustafsson wrote:
>
>>> +static void
>>> +dispatch_query(const ClusterInfo *cluster, AsyncSlot *slot,
>>>
>>> + pg_fr
Great, thanks for the links and useful past discussions! I figured I wasn't
the first to stumble across this, and it's interesting to see the issue
arise with ORDER BY [VOLATILE FUNC] as well.
My question was not so much about changing behavior as it was about
understanding what is desired, especi
On Sat, Jul 20, 2024 at 7:56 AM Andres Freund wrote:
> On 2024-07-19 15:36:29 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2024-07-19 11:06:47 -0400, Tom Lane wrote:
> > >> 2. Do we really want to encourage people to build with -flto?
> >
> > > The only case I know where we do rely o
I've been looking into optimizing pg_upgrade's once-in-each-database steps
[0], and I noticed that we are opening a connection to every database in
the cluster and running a query like
SELECT count(*) FROM pg_catalog.pg_subscription WHERE subdbid = %d;
Then, later on, we combine all of th
"David G. Johnston" writes:
> +many for placing these under a subdirectory.
> IMO the file name should match the ID of the sect1 element with the leading
> "functions-" removed, naming the directory "functions". Thus when viewing
> the web page the corresponding sgml file is determinable.
I'd g
On Jul 19, 2024, at 15:46, Nathan Bossart wrote:
> The lack of consistent terminology seems at least potentially confusing for
> readers. My first reaction is that "shared library" is probably fine.
That’s the direction I was leaning, as well, but I thought I heard somewhere
that the project u
On Fri, Jul 19, 2024 at 1:01 PM Tatsuo Ishii wrote:
> > Do we want to use a "func-" prefix on the file names? I could
> > imagine dispensing with that as unnecessary;
>
> If we don't use the prefix and we generate new file names from sect1
> tag, we could have file name collision: for example, j
Hi,
> So ... there is quite a disconnect between what this patch actually
> does (i.e., probe to see if "-Wl,-export_dynamic" is accepted) and
> the title of this thread. [...]
The thread title is indeed somewhat misleading, I was initially
puzzled by it too. The actual idea, if I understood it
On 2024-07-18 Th 6:51 PM, Thomas Munro wrote:
On Wed, Jul 17, 2024 at 2:27 AM Andrew Dunstan wrote:
Here's the latest version of this patch. It removes all use of
background_psql(). Instead it uses libpq's async interface, which seems
to me far more robust. There is one remaining use of intera
On Fri, Jul 19, 2024 at 2:41 PM Laurenz Albe wrote:
> I'd be alright with the hint, but I'd say "during making an *incremental*
> standby backup", because that's the only case where it can happen.
>
> I think it would also be sufficient if we document that possibility.
> When I got the error, I lo
> Do we want to use a "func-" prefix on the file names? I could
> imagine dispensing with that as unnecessary;
If we don't use the prefix and we generate new file names from sect1
tag, we could have file name collision: for example, json.sgml because
there's sect1 tag "functions-json".
> or anot
Hi,
On 2024-07-19 15:36:29 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-07-19 11:06:47 -0400, Tom Lane wrote:
> >> 2. Do we really want to encourage people to build with -flto?
>
> > The only case I know where we do rely on compilation units providing some
> > level of boundaries i
On 7/19/24 17:16, Jelte Fennema-Nio wrote:
> On Thu, 18 Jul 2024 at 22:47, Tomas Vondra
> wrote:
>> That being said, it this makes using pgbouncer easier (or even possible
>> in some applications where it currently does not work), I'd vote to get
>> this committed.
>
> It definitely is a pain
On Fri, Jul 19, 2024 at 03:27:49PM -0400, David E. Wheeler wrote:
> I´m trying to understand the standard terms for extension libraries.
> There seem too a bewildering number of terms used to refer to a shared
> object library, for example:
>
> [...]
>
> What is the standard term for these things
On Fri, 2024-07-19 at 21:06 +0200, Laurenz Albe wrote:
> Perhaps I should moderate my statement: if a change affects only a
> newly
> introduced code point (which is unlikely to be used in a database),
> and we
> think that the change is very important, we could consider applying
> it.
> But that s
Given the lack of interest, I plan to mark the commitfest entry for this
patch set as "Withdrawn" shortly.
--
nathan
Andres Freund writes:
> On 2024-07-19 11:06:47 -0400, Tom Lane wrote:
>> 2. Do we really want to encourage people to build with -flto?
> The only case I know where we do rely on compilation units providing some
> level of boundaries is on compilers where we don't know how to emit a compiler
> bar
Hi,
On 2024-07-19 11:06:47 -0400, Tom Lane wrote:
> 2. Do we really want to encourage people to build with -flto?
>
> I fear that #2 is actually a pretty serious concern. I think there
> are a lot of places where we've assumed semi-implicitly that
> compilation file boundaries are optimization b
Hackers,
I’m trying to understand the standard terms for extension libraries. There seem
too a bewildering number of terms used to refer to a shared object library, for
example:
* LOAD[1]:
* “shared library”
* “shared library file”
* dynamic_library_path[2]:
* “dynamically loadable module
On Mon, Jul 08, 2024 at 02:29:16PM -0500, Nathan Bossart wrote:
> One thing that still bugs me is that there is no feedback sent to the user
> when autovacuum_max_workers is set higher than autovacuum_worker_slots. I
> think we should at least emit a WARNING, perhaps from the autovacuum
> launcher
Robert Haas writes:
> On Thu, Jul 4, 2024 at 5:52 PM Andres Freund wrote:
>> As-is they can't be backpatched, unless I am missing something? Afaict they
>> introduce rather thorough ABI breaks? And API breaks, actually?
> Aside from that, this looks quite invasive for back-patching, and the
> nu
On 18.07.2024 23:01, Tom Lane wrote:
Alena Rybakina writes:
I fixed it. The code remains the same.
I see the cfbot is again complaining that this patch doesn't apply.
In hopes of pushing this over the finish line, I fixed up the (minor)
patch conflict and also addressed the cosmetic complaint
On 2024/04/23 15:44, kuroda.keis...@nttcom.co.jp wrote:
Hi hackers,
I proposal adding privileges test to improve
test coverage of pg_stat_statements.
+1
Here are the review comments:
meson.build needs to be updated as well, like the Makefile.
For the privileges test, should we explicitl
On Tue, 2024-07-16 at 10:42 -0700, Jeff Davis wrote:
> The IMMUTABLE marker for functions is quite simple on the surface, but
> could be interpreted a few different ways, and there's some historical
> baggage that makes it complicated.
>
> There are a number of ways in which IMMUTABLE functions ca
I took a look at 0003.
+/* dim[i] = 1 + upperIndx[i] - lowerIndx[i]; */
+if (pg_add_s32_overflow(1, upperIndx[i], &dim[i]))
+ereport(ERROR,
+(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
+ errmsg("array upper bound
On Thu, Jul 4, 2024 at 5:52 PM Andres Freund wrote:
> As-is they can't be backpatched, unless I am missing something? Afaict they
> introduce rather thorough ABI breaks? And API breaks, actually?
Aside from that, this looks quite invasive for back-patching, and the
number of bug reports so far su
On Fri, 2024-07-19 at 12:59 -0400, Robert Haas wrote:
Thanks for looking at this.
> On Fri, Jul 19, 2024 at 11:32 AM David Steele wrote:
> > I think it would be enough just to add a hint such as:
> >
> > HINT: this is possible when making a standby backup with little or no
> > activity.
>
> Tha
On Tue, Jul 16, 2024 at 8:04 AM Yasir wrote:
> Please ignore the above 4 lines in my review. See my comments in blue.
OK, so I think it's unclear what the next steps are for this patch.
1. On June 3rd, Michael Paquier said that Tom Lane proposed that,
after doing what the patch currently does, w
On Thu, Jul 18, 2024 at 09:08:30PM -0400, Joseph Koshakow wrote:
> As a reminder:
> - 0001 is reviewed.
> - 0002 is reviewed and a bug fix.
> - 0003 is currently under review and a bug fix.
> - 0004 needs a review.
I've committed/back-patched 0002. I plan to review 0003 next.
--
nathan
On 2024/07/19 22:03, Fujii Masao wrote:
On 2024/07/17 22:21, torikoshia wrote:
On 2024-07-03 02:07, Fujii Masao wrote:
However, if we support REJECT_LIMIT, I'm not sure if the ON_ERROR option is
still necessary.
I remembered another reason for the necessity of ON_ERROR.
ON_ERROR define
On Fri, Jul 19, 2024 at 11:32 AM David Steele wrote:
> I think it would be enough just to add a hint such as:
>
> HINT: this is possible when making a standby backup with little or no
> activity.
That could work (with "this" capitalized).
> My guess is in production environments this will be unc
On Fri, 2024-07-19 at 09:44 +0200, Laurenz Albe wrote:
> But the greatness of the step depends on our readiness to be careful
> with such changes.
You and Noah have been clear on that point, which is enough to make
*me* careful with any Unicode updates in the future. I'll suggest once
more that yo
"David G. Johnston" writes:
> On Thu, Jul 18, 2024 at 8:06 PM Tatsuo Ishii wrote:
>>> I'm opposed to having a separate file for every function. I think
>>> breaking up func.sgml into one piece per sect1 is about right.
>> That will create at least 30 func-xx.sgml files.
>> I am afraid that's too
On Thu, 2024-07-18 at 16:39 -0700, Noah Misch wrote:
> I'm with a different kind of packager. I don't tolerate index scans
> returning
> wrong answers.
I doubt that. We've all been tolerating the risk of index scans
returning wrong results in some cases.
Consider:
a. Some user creates an expres
On 7/19/24 21:52, Robert Haas wrote:
On Mon, Jul 15, 2024 at 11:27 AM Laurenz Albe wrote:
On Sat, 2024-06-29 at 07:01 +0200, Laurenz Albe wrote:
I played around with incremental backup yesterday and tried $subject
The WAL summarizer is running on the standby server, but when I try
to take an
Re: Tom Lane
> I fear that #2 is actually a pretty serious concern. I think there
> are a lot of places where we've assumed semi-implicitly that
> compilation file boundaries are optimization barriers, particularly
> around stuff like LWLocks and semaphores. I don't really want to
> spend time ch
On Thu, 18 Jul 2024 at 22:47, Tomas Vondra
wrote:
> That being said, it this makes using pgbouncer easier (or even possible
> in some applications where it currently does not work), I'd vote to get
> this committed.
It definitely is a pain point for some setups. A speaker brought it up
at FOSDEM
On Fri, Jul 19, 2024 at 10:22 AM Christoph Berg wrote:
> I'd argue this is exactly what I mean by "this system has a problem".
> Telling the user about that makes sense.
That's a fair position.
> > cautious about this than most people on this thread: log_checkpoints
> > won't generate more than
Aleksander Alekseev writes:
> It seems to me that the patch is not going to become any better and it
> doesn't need any more attention from the reviewers. Thus I changed the
> status of the CF entry to "Ready for Committer".
So ... there is quite a disconnect between what this patch actually
does
On Mon, Jul 15, 2024 at 11:27 AM Laurenz Albe wrote:
> On Sat, 2024-06-29 at 07:01 +0200, Laurenz Albe wrote:
> > I played around with incremental backup yesterday and tried $subject
> >
> > The WAL summarizer is running on the standby server, but when I try
> > to take an incremental backup, I ge
Hi Torikoshia,
On Wed, Jul 17, 2024 at 9:21 PM torikoshia wrote:
>
> On 2024-07-03 02:07, Fujii Masao wrote:
> > However, if we support REJECT_LIMIT, I'm not sure if the ON_ERROR
> > option is still necessary.
>
> I remembered another reason for the necessity of ON_ERROR.
>
> ON_ERROR defines how
On Fri, Jul 19, 2024 at 7:20 AM Paul George wrote:
>
> I wanted to surface a discussion in [1] regarding the expected behavior of
> GROUP BY with VOLATILE expressions. There seems to be a discrepancy between
> how volatile functions (RANDOM(), also confirmed with TIMEOFDAY()) and
> subqueries are
Late to the party, but +1 from me on this default change also
On Fri, 19 Jul 2024 at 11:54, Laurenz Albe wrote:
> On Thu, 2024-07-18 at 12:25 +0200, Michael Banck wrote:
> > this patch is still on the table, though for v18 now.
> >
> > Nathan mentioned up-thread that he was hesitant to commit th
>
> Are there any others who have an opinion on this?
Big +1 to having it on by default. It's already one of the first things I
turn on by default on any system I come across. The log spam is minimal,
compared to all the other stuff that ends up in there. And unlike most of
that stuff, this is ou
On Jul 9, 2024, at 10:45, David E. Wheeler wrote:
>> one tiny complaint would be maybe we need `reset datestyle`.
>
> That’s fair. Done.
Here’s a rebase on 5784a49. I also updated the commitfest item[1] to link to a
new pull request[2], since I seem to have turned the other one into the tz
co
Re: Robert Haas
> I've definitely seen systems where this setting would have generated
> regular output, because I see a lot of systems that are chronically
> overloaded.
I'd argue this is exactly what I mean by "this system has a problem".
Telling the user about that makes sense.
> cautious abou
Hackers,
I wanted to surface a discussion in [1] regarding the expected behavior of
GROUP BY with VOLATILE expressions. There seems to be a discrepancy between
how volatile functions (RANDOM(), also confirmed with TIMEOFDAY()) and
subqueries are evaluated in groups. In the examples below, volatile
On Fri, Jul 19, 2024 at 9:24 AM Christoph Berg wrote:
> I have not seen any server yet where normal, legitimate operation
> would routinely trigger the message. (If it did, people should likely
> have used SKIP LOCKED or NOWAIT instead.) It would only increase the
> log volume on systems that have
On Jun 27, 2024, at 18:07, David E. Wheeler wrote:
>> Minor nit - misspelled “considerd"
>
> Thank you, Jeremy. V3 attached.
Rebase on 5784a49 attached. I presume this topic needs quite a bit of review
and consensus from the committers more generally.
Best,
David
v4-0001-Add-API-an-ABI-gu
On Jul 10, 2024, at 11:19, David E. Wheeler wrote:
> Oh, and the time and date were wrong, too, because I blindly used the same
> conversion for dates as for timestamps. Fixed in v2.
>
> PR: https://github.com/theory/postgres/pull/7
> CF: https://commitfest.postgresql.org/49/5119/
Rebase on 57
On Jul 19, 2024, at 01:42, Michael Paquier wrote:
> Sorry for the delay. Finally came back to it, and applied the tests.
> Thanks!
Awesome, thank you!
> It was fun to see that HEAD was silenced with the first patch of this
> thread that tweaked the behavior with arrays.
Uh, what? Sorry I don’
Hi Scott,
I realize some of the background was snipped on what I sent to the
hacker list, I'll try to fill in the details.
Short background is very large database ran out of space during vacuum
full taking down the server. There is a replica which was applying the
WALs and so it too ran out
On 7/19/24 04:23, Michael Paquier wrote:
> On Fri, Jul 19, 2024 at 12:17:44AM +0200, Tomas Vondra wrote:
>> shall we do something about this patch? It seems to be in a pretty good
>> shape (pretty much RFC, based on quick review), the cfbot is still
>> happy, and there seems to be agreement this is
Hi Pavel,
First, thanks for your dedication to this effort. I always find it
hard to make time for things like psql backslash command improvements,
but I'm glad that we have people in our community who work on such
things.
Second, I think that the threshold question for this patch is: will
users,
On 7/19/24 07:02, Peter Smith wrote:
> ...
>>
>> To conclude, I think this probably makes the comments more confusing. If
>> we want to make it clearer, I'd probably start by clarifying what the
>> "stopping" state means. Also, it's a bit surprising we may not actually
>> go through the "stopping"
Re: Laurenz Albe
> The major criticism is Tom's that it might unduly increase the log volume.
>
> I'm not trying to rush things, but I see little point in kicking a trivial
> patch like this through many commitfests. If no committer wants to step
> up and commit this, it should be rejected.
That
Hello,
I think the fix for the check triggers should be as the attached. Very
close to what you did, but you were skipping some operations that needed
to be kept. AFAICS this patch works correctly for the posted cases.
I haven't looked at the action triggers yet; I think we need to create
one t
On 7/19/24 09:11, Hao Zhang wrote:
> Hi hackers,
> I'm doing work related to creating an index with parallel workers. I found
> that SnapshotAny
> is used in table_beginscan_parallel() when indexInfo->ii_Concurrent Is set
> to false. So can we
> not pass the snapshot from the parallel worker creato
On Thursday, July 18, 2024, Wen Yi wrote:
>
>
> pg_get_functiondef
> --
>
> In my expectations, it should be:
>
> oid | pg_get_functiondef
>
> --+--
On 2024/07/17 22:21, torikoshia wrote:
On 2024-07-03 02:07, Fujii Masao wrote:
However, if we support REJECT_LIMIT, I'm not sure if the ON_ERROR option is
still necessary.
I remembered another reason for the necessity of ON_ERROR.
ON_ERROR defines how to behave when encountering an error
On Thu, Jul 18, 2024 at 5:12 PM Amit Kapila wrote:
>
> I'll continue my review and testing of the patch but I thought of
> sharing what I have done till now.
>
+ /*
+ * Do not allow changing the option if the subscription is enabled. This
+ * is because both failover and two_phase options of the
Hello Kouhei-san,
I think it'd be helpful if you could post a patch status, i.e. a message
re-explaininig what it aims to achieve, summary of the discussion so
far, and what you think are the open questions. Otherwise every reviewer
has to read the whole thread to learn this.
FWIW I realize there
On 2024/07/19 2:58, Tom Lane wrote:
Fujii Masao writes:
"because of recovery target settings" isn't always accurate.
For example, if the DBA shuts down the server during recovery,
POSTMASTER_SHUTDOWN_IN_RECOVERY can be returned regardless of
the recovery target settings. Should we change the
On Sat, 2021-04-10 at 08:58 +0200, Pavel Stehule wrote:
> I am sending a strongly updated patch for schema variables.
>
> I rewrote an execution of a LET statement. In the previous implementation I
> hacked
> STMT_SELECT. Now, I introduced a new statement STMT_LET, and I implemented a
> new
> ex
Hi,
On Fri, 2024-07-19 at 14:01 +0900, Etsuro Fujita wrote:
> I pushed the fix and back-patched to v15. Thanks for the report!
Thanks a lot!
Regards,
--
Devrim Gündüz
Open Source Solution Architect, PostgreSQL Major Contributor
Twitter: @DevrimGunduz , @DevrimGunduzTR
signature.asc
Descripti
Hi,
> So I tested both HEAD and v12 on current and current-5, both successful.
> That should cover current-1 and current-2, too. If you want me to test
> any other macOS versions inbetween, or any other PG versions, I can do that.
>
> I would really like to upstream those kind of patches and see t
> On 7/18/24 12:37, masahiro.ik...@nttdata.com wrote:
> >> Let me share my opinion on those questions ...
> > ...>
> >> For ndistinct, I think we don't show this because it doesn't go
> >> through clauselist_selectivity, which is the only thing I modified in the
> >> PoC.
> >> But I guess we might
On Thu, 2024-07-18 at 12:25 +0200, Michael Banck wrote:
> this patch is still on the table, though for v18 now.
>
> Nathan mentioned up-thread that he was hesitant to commit this without
> further discussion. Laurenz, Stephen and I are +1 on this, but when it
> comes to committers having chimed i
Hi,
> There are currently 124 commitfest entries needing a reviewer.
> Of those, 38 have activity this month, and the other 86 are a bit more stale,
> some going back to last year.
It's worth noting that some patches marked as "Needs review" in fact
got some review and now require actions from t
On Thu, Jul 18, 2024 at 4:24 PM David Rowley wrote:
>
> On Thu, 18 Jul 2024 at 22:28, Ashutosh Bapat
> wrote:
> >
> > On Thu, Jul 18, 2024 at 3:33 PM David Rowley wrote:
> > > hmm? please tell me what word other than "can" best describes
> > > something that is possible to happen but does not al
Hi, Thankyou for taking the time to look at this and reply.
>
> I did look at this, and while the explanation in the current comment may
> seem a bit confusing, I'm not sure the suggested changes improve the
> situation very much.
>
> This suggests the two comments somehow disagree, but it does no
[Added cross post to pgsql-hackers@lists.postgresql.org - background is
multi-TB database needs recovered via pgdumpall & reload, thoughts on
ways to make pg_dump scale to multi-thread to expedite loading to a new
cluster. Straight dump to a file is impractical as the dump will be
>200TB; hack
On Fri, 2024-07-19 at 11:53 +0900, Sutou Kouhei wrote:
> In
> "July Commitfest: Entries Needing Review" on Thu, 18 Jul 2024 14:17:38
> -0400,
> Corey Huinker wrote:
>
> > If you know your patch isn't going to get reviewed in this commitfest,
> > please consider moving it to the next commitf
On Fri, Jul 19, 2024 at 10:45 AM Amit Kapila wrote:
>
> > ==
> > src/include/replication/slot.h
> >
> > 1.
> > -extern void ReplicationSlotAlter(const char *name, bool failover);
> > +extern void ReplicationSlotAlter(const char *name, bool *failover,
> > + bool *two_phase);
> >
> > Use const?
On Fri, Jul 19, 2024 at 12:07 PM David G. Johnston
wrote:
>
> On Thu, Jul 18, 2024 at 8:06 PM Tatsuo Ishii wrote:
>>
>> > I'm opposed to having a separate file for every function. I think
>> > breaking up func.sgml into one piece per sect1 is about right. If that
>> > proves cumbersome still we c
Hi,
On Wed, 17 Jul 2024 at 13:13, Ashutosh Bapat
wrote:
>
> If you are willing to work on this further, please add it to the commitfest.
Since general consensus is more towards having an environment variable
to override Meson configure option, I converted solution-3 to
something more like a patc
Hi hackers,
I am trying to design a new "pg_get_functiondef" function extension, like this:
CREATE FUNCTION pg_get_functiondef(OID, VARIADIC OID[]) RETURNS TABLE (OID oid,
pg_get_functiondef text)
AS 'pg_get_functiondef', 'pg_get_functiondef_mul'
LANGUAGE C;
And I have read the
On Thu, Jul 18, 2024 at 7:52 AM Zhijie Hou (Fujitsu)
wrote:
>
> Attach the V5 patch set which changed the following.
Thanks for the patch. Tested that previous reported issues are fixed.
Please have a look at below scenario, I was expecting it to raise
'update_differ' but it raised both 'update_d
On Fri, 19 Jul 2024 at 04:59, Peter Smith wrote:
>
> Hi, here are some review comments for patch v19-0003
>
> ==
> src/backend/catalog/pg_publication.c
>
> 1.
> /*
> * Translate a list of column names to an array of attribute numbers
> * and a Bitmapset with them; verify that each attribute
On Fri, Jul 19, 2024 at 5:48 AM Tom Lane wrote:
>
> jian he writes:
> > [ v5-0001-add-regex-functions-argument-names-to-pg_proc.patch ]
>
> I'm not sure whether we've bikeshedded this to death yet, but
> personally I'm content with the naming choices here (which basically
> are those already show
On Wed, 17 Jul 2024 at 01:45, Alexander Korotkov wrote:
>
> Jian He gave a try to ChangeVarNodes() [1]. That gives some
> improvement, but the vast majority of complexity is still here. I
> think the reason for complexity of SJE is that it's the first time we
> remove relation, which is actually
On 01/07/2024 17:19, Daniel Gustafsson wrote:
On 5 Jun 2024, at 10:19, Andreas Karlsson wrote:
When Heikki made the resource owners extensible in commit
b8bff07daa85c837a2747b4d35cd5a27e73fb7b2 the API for JIT plugins changed when
ResourceOwnerForgetJIT() was moved from the generic JIT code
On Thu, 2024-07-18 at 13:03 -0400, Tom Lane wrote:
> In the second place, I cannot understand why pg_c_utf8 is being
> held to a mutability standard that we have never applied to any
> other locale-related functionality --- and indeed could not do
> so, since in most cases that functionality has be
Hi hackers,
I'm doing work related to creating an index with parallel workers. I found
that SnapshotAny
is used in table_beginscan_parallel() when indexInfo->ii_Concurrent Is set
to false. So can we
not pass the snapshot from the parallel worker creator to the parallel
worker? like this:
```
Initia
94 matches
Mail list logo
