Re: Implement generalized sub routine find_in_log for tap test

On Fri, 9 Jun 2023 at 08:31, Michael Paquier wrote: > > On Tue, Jun 06, 2023 at 06:43:44PM +0530, vignesh C wrote: > > Please find the attached patches that can be applied on back branches > > too. v5*master.patch can be applied on master, v5*PG15.patch can be > > applied on PG15, v5*PG14.patch

Re: Implement generalized sub routine find_in_log for tap test

On Fri, Jun 9, 2023 at 8:29 AM Michael Paquier wrote: > > On Tue, Jun 06, 2023 at 05:53:40PM +0530, Bharath Rupireddy wrote: > > Yes. A simpler way of doing it would be to move advance_wal() in > > 019_replslot_limit.pl to Cluster.pm, something like the attached. CI > > members don't complain

Re: Add a perl function in Cluster.pm to generate WAL

On Wed, Aug 24, 2022 at 6:42 AM Kyotaro Horiguchi wrote: > > At Tue, 16 Aug 2022 18:40:49 +0200, Alvaro Herrera > wrote in > > On 2022-Aug-16, Andrew Dunstan wrote: > > > > > I don't think there's a hard and fast rule about it. Certainly the case > > > would be more compelling if the functions

Re: 回复：回复：Fix missing initialization of delayChkptEnd

On Wed, Jun 07, 2023 at 10:25:25AM +0800, 蔡梦娟(玊于) wrote: > In my new patch for pg14, I add the assertion on delayChkptEnd in > ProcArrayClearTransaction, and also add patches for release branch > from 10 to 13, please check. Thanks for the patches. I finally got back to that, double-checked all

Re: Let's make PostgreSQL multi-threaded

I don't have an objection, but I do wonder: can one (or perhaps a few) queries/workloads be provided where threading would be significantly beneficial? (some material there could help get people on-board with the idea and potentially guide many of the smaller questions that arise along the way)

Re: index prefetching

On 6/10/23 22:34, Andres Freund wrote: > Hi, > > On 2023-06-09 12:18:11 +0200, Tomas Vondra wrote: >>> 2) prefetching from executor Another question is whether the prefetching shouldn't actually happen even higher - in the executor. That's what Andres suggested during the

Re: Cleaning up nbtree after logical decoding on standby work

On Fri, Jun 9, 2023 at 12:23 PM Peter Geoghegan wrote: > > I'm not sure there is that concensus (for me half the changes shouldn't be > > done, the rest should be in 17), but in the end it doesn't matter that much. I pushed this just now. I have also closed out the open item. > > > ---

Re: abi-compliance-checker

Andres Freund writes: > Independently, I'm a bit confused as to why we export pgresStatus in > exports.txt - I don't see any reason for that. Looks like it might be leftover > from before fa0f24165c0? It looks like before fa0f24165, the *only* way to convert ExecStatusType to text was to access

Re: index prefetching

Hi, On 2023-06-09 12:18:11 +0200, Tomas Vondra wrote: > > > >> 2) prefetching from executor > >> > >> Another question is whether the prefetching shouldn't actually happen > >> even higher - in the executor. That's what Andres suggested during the > >> unconference, and it kinda makes sense.

Re: Skip collecting decoded changes of already-aborted transactions

Hi, On 2023-06-09 14:16:44 +0900, Masahiko Sawada wrote: > In logical decoding, we don't need to collect decoded changes of > aborted transactions. While streaming changes, we can detect > concurrent abort of the (sub)transaction but there is no mechanism to > skip decoding changes of

Re: Do we want a hashset type?

On 6/10/23 17:46, Andrew Dunstan wrote: > > On 2023-06-09 Fr 07:56, Joel Jacobson wrote: >> On Fri, Jun 9, 2023, at 13:33, jian he wrote: >> > Hi, I am quite new about C. >> > The following function I have 3 questions. >> > 1. 7691,4201, I assume they are just random prime ints? >> >> Yes,

Re: abi-compliance-checker

Hi, On 2023-06-10 12:48:46 -0700, Andres Freund wrote: > > + > > + > > + > > Hm - why is all of this stuff even ending up in the external ABI? It should > all be internal, unless I am missing something? > > I might be looking the wrong way, but to me it sure looks like none of

Re: Do we want a hashset type?

On 6/9/23 12:58, Joel Jacobson wrote: > On Thu, Jun 8, 2023, at 12:19, Tomas Vondra wrote: >> Would you be interested in helping with / working on some of that? I >> don't have immediate need for this stuff, so it's not very high on my >> TODO list. > > Sure, I'm willing to help! > > I've

Re: abi-compliance-checker

Hi, On 2023-06-06 18:30:38 +0200, Peter Eisentraut wrote: > On 30.05.23 06:32, Peter Eisentraut wrote: > > I think the way to use this would be to compute the ABI for the .0 > > release (or rc1 or something like that) and commit it into the tree. And > > then compute the current ABI and compare

Re: Let's make PostgreSQL multi-threaded

On Mon, Jun 5, 2023 at 4:52 PM Heikki Linnakangas wrote: > > If there are no major objections, I'm going to update the developer FAQ, > removing the excuses there for why we don't use threads [1]. I think it is not wise to start the wholesale removal of the objections there. But I think it is

Re: Do we want a hashset type?

in funcion. hashset_in int32 value = strtol(str, , 10); there is no int32 value range check? imitate src/backend/utils/adt/int.c. the following way is what I came up with. int64 value = strtol(str, , 10); if (errno == ERANGE || value < INT_MIN || value > INT_MAX) ereturn(fcinfo->context, (Datum)

Re: Do we want a hashset type?

On 2023-06-09 Fr 07:56, Joel Jacobson wrote: On Fri, Jun 9, 2023, at 13:33, jian he wrote: > Hi, I am quite new about C. > The following function I have 3 questions. > 1. 7691,4201, I assume they are just random prime ints? Yes, 7691 and 4201 are likely chosen as random prime numbers. In

Re: Cleaning up threading code

On 6/10/23 01:26, Andres Freund wrote: On 2023-06-10 14:23:52 +1200, Thomas Munro wrote: I'm not talking about other stuff like C11 atomics, memory models, and the thread_local storage class, which are all very good and interesting topics for another day. Hm. I agree on C11 atomics and memory

Re: Views no longer in rangeTabls?

Julien Rouhaud writes: > On Sat, Jun 10, 2023 at 08:56:47AM -0400, Tom Lane wrote: >> - rte->relkind = 0; > and also handle that field in (read|out)funcs.c Oh, right. Ugh, that means a catversion bump. It's not like we've never done that during beta, but it's kind of an annoying cost for a

Re: Views no longer in rangeTabls?

On Sat, Jun 10, 2023 at 08:56:47AM -0400, Tom Lane wrote: > > Well, if we're gonna do it we should do it for v16, rather than > change the data structure twice. It wouldn't be hard exactly: > > /* > * Clear fields that should not be set in a subquery RTE. Note that we > * leave the

Re: Views no longer in rangeTabls?

David Steele writes: > On 6/10/23 09:57, Amit Langote wrote: >> I too have been thinking that setting relkind might be a good idea, even >> if only as a crosscheck that only view relations can look like that in >> the range table. > +1. Even better if we can do it for PG16. Well, if we're

Re: Let's make PostgreSQL multi-threaded

On Fri, 9 Jun 2023 at 18:29, Stephen Frost wrote: > Greetings, > > * Dave Cramer (davecramer@postgres.rocks) wrote: > > One thing I can think of is upgrading. AFAIK dump and restore is the only > > way to change the on disk format. > > Presuming that eventually we will be forced to change the on

Re: Views no longer in rangeTabls?

On 6/10/23 09:57, Amit Langote wrote: On Sat, Jun 10, 2023 at 15:51 David Steele > wrote: On 6/9/23 19:14, Tom Lane wrote: > > If you see "rte->rtekind == RTE_SUBQUERY && OidIsValid(rte->relid)", > it's dead certain that relid refers to a view, so

Re: Views no longer in rangeTabls?

On Sat, Jun 10, 2023 at 15:51 David Steele wrote: > On 6/9/23 19:14, Tom Lane wrote: > > David Steele writes: > >> Thank you, this was very helpful. I am able to get the expected result > >> now with: > > > >> /* We only care about tables/views and can ignore subqueries, etc. */ > >> if

Re: Views no longer in rangeTabls?

On 6/9/23 19:14, Tom Lane wrote: David Steele writes: Thank you, this was very helpful. I am able to get the expected result now with: /* We only care about tables/views and can ignore subqueries, etc. */ if (!(rte->rtekind == RTE_RELATION || (rte->rtekind == RTE_SUBQUERY &&