Re: Document that server will start even if it's unable to open some TCP/IP ports

On Sat, May 27, 2023 at 03:17:21PM -0700, Gurjeet Singh wrote: > Upon further testing, I saw that server will not start only if it is > unable to open the port on _all_ the interfaces/addresses. It it's > able to open the port on at least one, the server will start. This surprised me. I would've

Re: RFC: Adding \history [options] [filename] to psql (Snippets and Shared Queries)

On Mon, Jun 5, 2023 at 8:58 AM Kirk Wolak wrote: > > Everyone, > After recently deep diving on some readline features and optimizing my bash > environment to have a static set of "snippets" that I can always find... > > it takes just a couple of history API calls to add some interesting >

Re: Avoid unncessary always true test (src/backend/storage/buffer/bufmgr.c)

On Mon, Jun 5, 2023 at 4:24 AM Ranier Vilela wrote: > Em seg., 5 de jun. de 2023 às 08:06, Ranier Vilela > escreveu: >> Em dom., 4 de jun. de 2023 às 23:37, Richard Guo >> escreveu: >>> On Sun, Jun 4, 2023 at 8:42 PM Ranier Vilela wrote: Hi, Per Coverity. At function

Re: Improve logging when using Huge Pages

On Mon, Jun 12, 2023 at 02:37:15PM -0700, Nathan Bossart wrote: > Fair enough. I know I've been waffling in the GUC versus function > discussion, but FWIW v7 of the patch looks reasonable to me. + Assert(strcmp("unknown", GetConfigOption("huge_pages_status", false, false)) != 0); Not

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Tue, Jun 6, 2023 at 2:13 PM John Naylor wrote: > > On Mon, Jun 5, 2023 at 5:32 PM Masahiko Sawada wrote: > > > > > Sometime in the not-too-distant future, I will start a new thread > > > focusing on bitmap heap scan, but for now, I just want to share some > > > progress on making the radix

Re: Support logical replication of DDLs

On Thu, Jun 8, 2023 at 5:32 PM shveta malik wrote: > > On Thu, Jun 8, 2023 at 10:36 AM Amit Kapila wrote: > > Please find new set of patches addressing below: > a) Issue mentioned by Wang-san in [1], > b) Comments from Peter given in [2] > c) Comments from Amit given in the last 2 emails. > As

Re: add non-option reordering to in-tree getopt_long

On Tue, Jun 13, 2023 at 12:00:01PM +0900, Kyotaro Horiguchi wrote: > POSIXLY_CORRECT appears to be intended for debugging or feature > validation. If we know we can always rearrange argv on those > platforms, we don't need it. I would suggest that we turn on the new > feature at the compile time

Re: Atomic ops for unlogged LSN

On Mon, Jun 12, 2023 at 07:24:18PM -0400, Stephen Frost wrote: > * Nathan Bossart (nathandboss...@gmail.com) wrote: >> Is it? I see uses in GiST indexing (62401db), so it's not immediately >> obvious to me how it is debugging-only. If it is, then I think this patch >> ought to clearly document

Re: pg_stat_io for the startup process

At Mon, 12 Jun 2023 21:13:35 -0700, Andres Freund wrote in > Thanks for looking - I already had pushed the commit by the time I read your > email, otherwise I'd have mentioned you reviewing it... Oops! But I anticipated that and that's no problem (I should have confirmed commits.). Thanks for

Re: index prefetching

On Thu, Jun 8, 2023 at 9:10 PM Tomas Vondra wrote: > We already do prefetching for bitmap index scans, where the bitmap heap > scan prefetches future pages based on effective_io_concurrency. I'm not > sure why exactly was prefetching implemented only for bitmap scans, but > I suspect the

RE: TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 927, PID: 568639)

On Tuesday, June 13, 2023 12:04 PM Amit Kapila wrote: > > On Wed, Jun 7, 2023 at 6:02 PM Tomas Vondra > wrote: > > > > > > Well, I think the issue is pretty clear - we end up with an initial > > snapshot that's in between the ASSIGNMENT and NEW_CID, and because > > NEW_CID has both xact and

Re: pg_stat_io for the startup process

Hi, On 2023-06-13 12:54:19 +0900, Kyotaro Horiguchi wrote: > I think that the reason is that we only pass true only when we're in a > sort of idle time. Addition to that XLOG_RUNNING_XACTS comes so > infrequently to cause noticeable degradation. If it causes > sufficiently frequent updates, we

Re: Views no longer in rangeTabls?

On Sat, Jun 10, 2023 at 10:27 PM Tom Lane wrote: > 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

Re: TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 927, PID: 568639)

On Wed, Jun 7, 2023 at 6:02 PM Tomas Vondra wrote: > > > Well, I think the issue is pretty clear - we end up with an initial > snapshot that's in between the ASSIGNMENT and NEW_CID, and because > NEW_CID has both xact and subxact XID it fails because we add two TXNs > with the same LSN, not

Re: pg_stat_io for the startup process

At Fri, 9 Jun 2023 21:28:23 -0700, Andres Freund wrote in > Hi, > > On 2023-05-22 13:36:42 +0900, Kyotaro Horiguchi wrote: > > At Sun, 21 May 2023 15:14:23 -0700, Andres Freund > > wrote in > > > Hi, > > > > > > I don't really feel confident we're going to get the timeout approach > > >

Re: ERROR: wrong varnullingrels (b 3) (expected (b)) for Var 2/1

Richard Guo writes: > Oh, wait ... It occurred to me that we may have this same issue with > Memoize cache keys. In get_memoize_path we collect the cache keys from > innerpath's ppi_clauses and innerrel's lateral_vars, and the latter may > contain nullingrel markers that need adjustment. As an

Re: ERROR: wrong varnullingrels (b 3) (expected (b)) for Var 2/1

On Mon, Jun 12, 2023 at 10:02 PM Tom Lane wrote: > Richard Guo writes: > > Yeah, that makes sense. process_subquery_nestloop_params is a better > > place to do this adjustments. +1 to v2 patch. > > Pushed, then. Oh, wait ... It occurred to me that we may have this same issue with Memoize

Re: add non-option reordering to in-tree getopt_long

At Fri, 9 Jun 2023 16:22:57 -0700, Nathan Bossart wrote in > While working on 2dcd157, I noticed cfbot failures for Windows due to tests > with commands that had non-options specified before options. For example, > "createuser myrole -a myadmin" specified a non-option (myrole) before the >

RE: Time delayed LR (WAS Re: logical replication restrictions)

Dear hackers, > At PGcon and other places we have discussed the time-delayed logical > replication, > but now we have understood that there are no easy ways. Followings are our > analysis. At this point, I have not planned to develop the PoC anymore, unless better idea or infrastructure will

RE: Partial aggregates pushdown

Hi Mr.Momjian. Thank you for advises. > From: Bruce Momjian > Sent: Monday, June 12, 2023 10:38 PM > > I understand what the problem is. I will put a mechanism maintaining > > compatibility into the patch. > > I believe there are three approaches. > > Approach 1-1 is preferable because it does

Re: Shouldn't construct_array_builtin and deconstruct_array_builtin agree on types?

Michael Paquier writes: > On Mon, Jun 12, 2023 at 11:06:18PM +0200, Peter Eisentraut wrote: >> They only support the types that they were actually being used with. If you >> need another type, feel free to add it. > FWIW, I agree with Tomas that this is an oversight that should be > fixed in

Re: query_id, pg_stat_activity, extended query protocol

On Mon, Jun 12, 2023 at 09:03:24PM +0300, kaido vaikla wrote: > I have noticed, if query comes from PostgreSQL JDBC Driver, then query_id > is not present in pg_stat_activity. Erik Wienhold figured out that reason > can be in extended query protocol ( >

Re: Setting restrictedtoken in pg_regress

On Tue, Jun 13, 2023 at 08:29:19AM +0900, Michael Paquier wrote: > I am actually a bit confused with the return value of > CreateRestrictedProcess() on failures in restricted_token.c. Wouldn't > it be cleaner to return INVALID_HANDLE_VALUE rather than 0 in these > cases? My suspicion is that

Re: [PATCH] Slight improvement of worker_spi.c example

On Sat, Jun 03, 2023 at 06:35:00PM -0400, Michael Paquier wrote: > It does not have to be complicated, but I definitely agree that we'd > better spend some efforts in improving it as a whole especially > knowing that this is mentioned on the docs as an example that one > could rely on. +1. I

Re: Setting restrictedtoken in pg_regress

On Mon, Jun 12, 2023 at 04:12:22PM -0700, Nathan Bossart wrote: > On Tue, Aug 30, 2022 at 03:02:54PM +0200, Daniel Gustafsson wrote: >> In pg_regress we set restrictedToken when calling CreateRestrictedProcess, >> but >> we never seem to use that anywhere. Not being well versed in Windows I

Re: Atomic ops for unlogged LSN

Greetings, * Nathan Bossart (nathandboss...@gmail.com) wrote: > On Thu, May 25, 2023 at 07:41:21AM +0900, Michael Paquier wrote: > > On Wed, May 24, 2023 at 02:49:58PM -0700, Andres Freund wrote: > >> So we indeed loose some "barrier strength" - but I think that's fine. For > >> one, > >> it's a

Re: Shouldn't construct_array_builtin and deconstruct_array_builtin agree on types?

On Mon, Jun 12, 2023 at 11:06:18PM +0200, Peter Eisentraut wrote: > They only support the types that they were actually being used with. If you > need another type, feel free to add it. FWIW, I agree with Tomas that this is an oversight that should be fixed in v16, saving from the need to have a

Re: Setting restrictedtoken in pg_regress

On Tue, Aug 30, 2022 at 03:02:54PM +0200, Daniel Gustafsson wrote: > In pg_regress we set restrictedToken when calling CreateRestrictedProcess, but > we never seem to use that anywhere. Not being well versed in Windows I might > be missing something, but is it needed or is it a copy/pasteo from

Re: Atomic ops for unlogged LSN

On Thu, May 25, 2023 at 07:41:21AM +0900, Michael Paquier wrote: > On Wed, May 24, 2023 at 02:49:58PM -0700, Andres Freund wrote: >> So we indeed loose some "barrier strength" - but I think that's fine. For >> one, >> it's a debugging-only value. Is it? I see uses in GiST indexing (62401db), so

Re: Let's make PostgreSQL multi-threaded

On Mon, Jun 12, 2023 at 12:24:30PM -0700, Andres Freund wrote: > Those points seems pretty much unrelated to the potential gains from switching > to a threading model. The main advantages are: > > 1) We'd gain from being able to share state more efficiently (using normal >pointers) and more

Re: Meson build updates

On Mon Jun 12, 2023 at 4:24 PM CDT, Peter Eisentraut wrote: > On 12.06.23 20:48, Tristan Partin wrote: > > Attached you will find a v3 with the offending commits removed. I did > > leave the overrides in since you didn't mention it in your last email. > > Patches 1-14 look ok to me. (But I didn't

Re: Improve logging when using Huge Pages

On Tue, May 02, 2023 at 11:17:50AM +0900, Michael Paquier wrote: > On Thu, Apr 20, 2023 at 02:16:17PM -0700, Nathan Bossart wrote: >> AFAICT this would involve adding a bool to BackendParameters and using it >> in save_backend_variables() and restore_backend_variables(), which is an >> additional

Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG

On 6/12/23 10:44, Joe Conway wrote: 1/ how do we fix the misbehavior reported due to libperl in existing stable branches I was mostly trying to concentrate on #1, but 2 & 3 are worthy of discussion. Hmm, browsing through the perl source I came across a reference to this (from

Re: index prefetching

On Thu, 2023-06-08 at 17:40 +0200, Tomas Vondra wrote: > Hi, > > At pgcon unconference I presented a PoC patch adding prefetching for > indexes, along with some benchmark results demonstrating the (pretty > significant) benefits etc. The feedback was quite positive, so let me > share the current

Re: Meson build updates

On 12.06.23 20:48, Tristan Partin wrote: Attached you will find a v3 with the offending commits removed. I did leave the overrides in since you didn't mention it in your last email. Patches 1-14 look ok to me. (But I didn't test anything, so some caveats about whether the non-cosmetic

Re: Let's make PostgreSQL multi-threaded

On 10/06/2023 21:01, Hannu Krosing wrote: 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

Re: Shouldn't construct_array_builtin and deconstruct_array_builtin agree on types?

On 12.06.23 22:38, Tomas Vondra wrote: I noticed that these two function, introduced in d746021de18b, disagree on what types they support. I ran into this for INT4OID. Sure, I can just lookup the stuff and use the regualr deconstruct_array, but the asymmetry seems a bit strange. Is that

Re: Order changes in PG16 since ICU introduction

On 09.06.23 02:36, Jeff Davis wrote: Patches 0001, 0002: These patches implement the built-in provider and automatically change provider=icu to provider=builtin when the locale is C. I object to adding a new provider for PG16 (patch 0001). This is clearly a new feature, which wasn't even

Shouldn't construct_array_builtin and deconstruct_array_builtin agree on types?

Hi, I noticed that these two function, introduced in d746021de18b, disagree on what types they support. For construct_array_builtin, we support these types: - CHAROID: - CSTRINGOID: - FLOAT4OID: - INT2OID: - INT4OID: - INT8OID: - NAMEOID: - OIDOID: - REGTYPEOID: - TEXTOID: - TIDOID:

Re: Do we want a hashset type?

On Mon, Jun 12, 2023, at 21:58, Tomas Vondra wrote: > But those are numbers for large keys - if you restrict the input to > 4B-16B (which is what we planned to do by focusing on int, bigint and > uuid), there's no significant difference: Oh, sorry, I completely failed to read the meaning of the

Re: Documentation for building with meson

On 10.06.23 06:00, Andres Freund wrote: From c5e637a54c2b83e5bd8c4155784d97e82937eb51 Mon Sep 17 00:00:00 2001 From: Samay Sharma Date: Mon, 6 Feb 2023 16:09:42 -0800 Subject: [PATCH v9 2/5] Add data layout options sub-section in installation docs This commit separates out blocksize, segsize

Re: Do we want a hashset type?

On 6/12/23 19:34, Joel Jacobson wrote: > On Sat, Jun 10, 2023, at 22:12, Tomas Vondra wrote: 1) better hash table implementation > > I noticed src/include/common/hashfn.h provides implementation > of the Jenkins/lookup3 hash function, and thought maybe > we could simply use it in hashset?

Re: Let's make PostgreSQL multi-threaded

Hi, On 2023-06-12 16:23:14 +0400, Pavel Borisov wrote: > Is the following true or not? > > 1. If we switch processes to threads but leave the amount of session > local variables unchanged, there would be hardly any performance gain. False. > 2. If we move some backend's local variables into

Re: Meson build updates

On Mon Jun 12, 2023 at 12:20 PM CDT, Andres Freund wrote: > Hi, > > On 2023-06-12 11:54:42 -0500, Tristan Partin wrote: > > On Fri Jun 9, 2023 at 1:36 PM CDT, Andres Freund wrote: > > > The biggest change to make them more usable would be to properly > > > reconfigure > > > when the contents of

query_id, pg_stat_activity, extended query protocol

I have noticed, if query comes from PostgreSQL JDBC Driver, then query_id is not present in pg_stat_activity. Erik Wienhold figured out that reason can be in extended query protocol ( https://www.postgresql.org/message-id/1391613709.939460.1684777418...@office.mailbox.org ) My question is, is it

Re: Do we want a hashset type?

On Sat, Jun 10, 2023, at 22:12, Tomas Vondra wrote: >>> 1) better hash table implementation I noticed src/include/common/hashfn.h provides implementation of the Jenkins/lookup3 hash function, and thought maybe we could simply use it in hashset? However, I noticed that according to SMHasher [1],

Re: Meson build updates

Hi, On 2023-06-12 11:54:42 -0500, Tristan Partin wrote: > On Fri Jun 9, 2023 at 1:36 PM CDT, Andres Freund wrote: > > The biggest change to make them more usable would be to properly reconfigure > > when the contents of machine file change. IIRC configure is rerun, but the > > changes aren't

Re: [RFC] building postgres with meson - v12

Hi, Small update for posterity: On 2022-09-09 16:58:36 -0700, Andres Freund wrote: > I've run this through enough attempts by now that I'm quite confident that the > problem does not occur when the errormode does not include > SEM_NOOPENFILEERRORBOX. I'll want a few more runs to be certain,

Re: Meson build updates

On Fri Jun 9, 2023 at 1:36 PM CDT, Andres Freund wrote: > Hi, > > On 2023-06-09 13:15:27 -0500, Tristan Partin wrote: > > On Fri Jun 9, 2023 at 11:41 AM CDT, Andres Freund wrote: > > > I like the current version better - depending on the meson version makes > > > it > > > easy to find what needs

Re: Inconsistent results with libc sorting on Windows

On Fri, Jun 9, 2023 at 11:18 AM Daniel Verite wrote: > Juan José Santamaría Flecha wrote: > > > Just to make sure we are all seeing the same problem, does the attached > > patch fix your test? > > The problem of the random changes in sorting disappears for all libc > locales in

Re: RFC: Logging plan of the running query

On Sun, Jun 11, 2023 at 11:07 PM torikoshia wrote: > > On 2023-06-06 03:26, James Coleman wrote: > > On Mon, Jun 5, 2023 at 4:30 AM torikoshia > > wrote: > >> > >> On 2023-06-03 02:51, James Coleman wrote: > >> > Hello, > >> > > >> > Thanks for working on this patch! > > > > Sure thing! I'm

Re: Do we want a hashset type?

On Sat, Jun 10, 2023, at 17:46, Andrew Dunstan wrote: > Maybe you can post a full patch as well as incremental? Attached patch is based on tvondra's last commit 375b072. > Stylistically I think you should reduce reliance on magic numbers (like 13). > Probably need some #define's? Great idea,

Re: Add support for AT LOCAL

On 2023-Jun-06, Laurenz Albe wrote: > At a quick glance, it looks like you resolve "timezone" at the time > the query is parsed. Shouldn't the resolution happen at query > execution time? Sounds like it -- consider the case where the timestamp value is a partition key and one of the partition

Re: abi-compliance-checker

On Mon Jun 12, 2023 at 10:10 AM CDT, Tristan Partin wrote: > On Sat Jun 10, 2023 at 9:17 AM CDT, Peter Eisentraut wrote: > > I have rearranged this a bit. There are now two build options, called > > abidw and abidiff. The abidw option produces the xml file, that you > > would then at

Re: abi-compliance-checker

On Sat Jun 10, 2023 at 9:17 AM CDT, Peter Eisentraut wrote: > I have rearranged this a bit. There are now two build options, called > abidw and abidiff. The abidw option produces the xml file, that you > would then at appropriate times commit into the tree as the base. The > abidiff option

Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG

(moving to hackers) On 6/12/23 05:13, Heikki Linnakangas wrote: On 10/06/2023 22:28, Joe Conway wrote: On 6/10/23 15:07, Joe Conway wrote: On 6/10/23 14:42, Tom Lane wrote: Joe Conway writes: 5/ The attached fixes the issue for me on pg10 and passes check-world. Comments? The call in

Re: Major pgbench synthetic SELECT workload regression, Ubuntu 23.04+PG15

On Fri, Jun 9, 2023 at 3:28 AM Gregory Smith wrote: > On Thu, Jun 8, 2023 at 9:21 PM Andres Freund wrote: >> >> You might need to add --no-children to the perf report invocation, otherwise >> it'll show you the call graph inverted. > > > My problem was not writing kernel symbols out, I was only

Re: Wrong results from Parallel Hash Full Join

On Sun, Jun 11, 2023 at 11:24 PM Michael Paquier wrote: > > On Wed, Jun 07, 2023 at 05:16:12PM -0400, Melanie Plageman wrote: > > On Fri, May 19, 2023 at 8:05 PM Tom Lane wrote: > >> Considering that this is a parallel plan, I don't think there's any > >> mystery about why an ORDER-BY-less query

Re: ERROR: wrong varnullingrels (b 3) (expected (b)) for Var 2/1

Richard Guo writes: > Yeah, that makes sense. process_subquery_nestloop_params is a better > place to do this adjustments. +1 to v2 patch. Pushed, then. regards, tom lane

Re: Partial aggregates pushdown

On Mon, Jun 12, 2023 at 08:51:30AM +, fujii.y...@df.mitsubishielectric.co.jp wrote: > Hi Mr.Bruce, Mr.Pyhalov, hackers. > > Thank you for comments. I will try to respond to both of your comments as > follows. > I plan to start revising the patch next week. If you have any comments on the >

Re: Do we want a hashset type?

On 2023-06-12 Mo 09:00, Tomas Vondra wrote: What was the json/jsonb story, was it ever an extension before being included in core? I don't recall what the exact story was, but I guess the "json" type was added to core very long ago (before we started to push back a bit), and we added some

Re: Do we want a hashset type?

On 6/12/23 14:46, Andrew Dunstan wrote: > > On 2023-06-11 Su 16:15, Joel Jacobson wrote: >> On Sun, Jun 11, 2023, at 17:03, Tomas Vondra wrote: >>> On 6/11/23 12:26, Joel Jacobson wrote: I think there are some good arguments that speaks in favour of including it in core: >> ... >>>

Re: Do we want a hashset type?

On 6/11/23 22:15, Joel Jacobson wrote: > On Sun, Jun 11, 2023, at 17:03, Tomas Vondra wrote: >> On 6/11/23 12:26, Joel Jacobson wrote: >>> I think there are some good arguments that speaks in favour of including it >>> in core: > ... >> >> I agree with all of that, but ... >> >> It's just past

Re: Do we want a hashset type?

On 2023-06-11 Su 16:15, Joel Jacobson wrote: On Sun, Jun 11, 2023, at 17:03, Tomas Vondra wrote: On 6/11/23 12:26, Joel Jacobson wrote: I think there are some good arguments that speaks in favour of including it in core: ... I agree with all of that, but ... It's just past feature freeze,

Re: Let's make PostgreSQL multi-threaded

Is the following true or not? 1. If we switch processes to threads but leave the amount of session local variables unchanged, there would be hardly any performance gain. 2. If we move some backend's local variables into shared memory then the performance gain would be very near to what we get

Re: Let's make PostgreSQL multi-threaded

On Mon, Jun 12, 2023, at 13:53, Tomas Vondra wrote: > In a way, I think this "split into independently beneficial steps" > strategy is the only option with a meaningful chance of success. +1 /Joel

Re: Let's make PostgreSQL multi-threaded

On 6/10/23 13:20, Dave Cramer wrote: > > > 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 >

RE: Time delayed LR (WAS Re: logical replication restrictions)

Dear hackers, At PGcon and other places we have discussed the time-delayed logical replication, but now we have understood that there are no easy ways. Followings are our analysis. # Abstract To implement the time-dealyed logical replication for more proper approach, the worker must serialize

Re: Order changes in PG16 since ICU introduction

Jeff Davis wrote: > I guess where I'm confused is: why would a user actually want their > database collation to be C.UTF-8? It's slower than C, our > implementation doesn't properly version it (as you pointed out), and > the semantics don't seem great ('Z' < 'a'). Because when

Re: Large files for relations

On 5/28/23 08:48, Thomas Munro wrote: Alright, since I had some time to kill in an airport, here is a starter patch for initdb --rel-segsize. I've gone through this patch and it looks pretty good to me. A few things: +* rel_setment_size, we will truncate the K+1st

RE: Partial aggregates pushdown

Hi Mr.Bruce, Mr.Pyhalov, hackers. Thank you for comments. I will try to respond to both of your comments as follows. I plan to start revising the patch next week. If you have any comments on the following respondences, I would appreciate it if you could give them to me this week. > From: Bruce

Re: check_strxfrm_bug()

On 12/06/2023 01:15, Thomas Munro wrote: There are still at least a couple of functions that lack XXX_l variants in the standard: mbstowcs() and wcstombs() (though we use the non-standard _l variants if we find them in ), but that's OK because we use uselocale() and not setlocale(), because

Re: Remove WindowClause PARTITION BY items belonging to redundant pathkeys

On Mon, Jun 12, 2023 at 12:06 PM David Rowley wrote: > On Fri, 9 Jun 2023 at 20:57, Richard Guo wrote: > > On Fri, Jun 9, 2023 at 8:13 AM David Rowley > wrote: > >> It might be possible to make adjustments in nodeWindowAgg.c to have > >> the equality checks come out as true when there is no

Re: Allow pg_archivecleanup to remove backup history files

On Fri, Jun 09, 2023 at 12:32:15AM +0900, Fujii Masao wrote: > + > + Remove backup history files. > > Isn't it better to document clearly which backup history files to be removed? > For example, "In addition to removing WAL files, remove backup history files > with prefixes