Re: Jumble the CALL command in pg_stat_statements

On Wed, Sep 13, 2023 at 11:09:19PM +, Imseih (AWS), Sami wrote: > I do have a patch for this with test cases, > 0001-v1-Jumble-the-SET-command.patch > If you feel this needs a separate discussion I can start one. Agreed tha tthis should have its own thread with a proper subject. > In the pat

Re: Partial aggregates pushdown

fujii.y...@df.mitsubishielectric.co.jp писал 2023-09-28 07:40: I'm not sure that I like this mechanics of adding sort group clauses - it seems we do in core additional work, which is of use only for one extension, but at least it seems to be working. We cannot deparse the original sort group cl

Re: [PGdocs] fix description for handling pf non-ASCII characters

On Thu, 28 Sep 2023 12:54:33 +0900 Michael Paquier wrote: > I was looking at this thread overall, the three v3 flavors of the doc > changes and v4. > > -application_name value. Other characters > will be > -replaced with question marks (?). > +application_name value. > +

Re: Eager page freeze criteria clarification

On Fri, Sep 8, 2023 at 12:07 AM Andres Freund wrote: > > Hi, > > On 2023-09-06 10:35:17 -0400, Robert Haas wrote: > > On Wed, Sep 6, 2023 at 1:09 AM Andres Freund wrote: > > > Yea, it'd be useful to have a reasonably approximate wall clock time for > > > the > > > last modification of a page. We

Re: [PoC] pg_upgrade: allow to upgrade publisher node

On Mon, Sep 25, 2023 at 2:06 PM Amit Kapila wrote: > > > > [1] > > > https://www.postgresql.org/message-id/CAA4eK1%2BLtWDKXvxS7gnJ562VX%2Bs3C6%2B0uQWamqu%3DUuD8hMfORg%40mail.gmail.com > > > > I see. IIUC, without that commit e0b2eed [1], it may happen that the > > slot's on-disk confirmed_flush L

Re: Synchronizing slots from primary to standby

On Wed, Sep 27, 2023 at 3:13 PM Drouvot, Bertrand wrote: > > On 9/19/23 6:50 AM, shveta malik wrote: > > > > 1) patch001: wait for physical-standby confirmation logic is now > > integrated with WalSndWaitForWal(). Now walsender waits for physical > > standby's confirmation to take changes upto Rec

Re: pg_upgrade and logical replication

On Mon, 25 Sept 2023 at 10:05, Amit Kapila wrote: > > On Fri, Sep 22, 2023 at 4:36 AM Michael Paquier wrote: > > > > On Thu, Sep 21, 2023 at 02:35:55PM +0530, Amit Kapila wrote: > > > It is because after upgrade of both publisher and subscriber, the > > > subscriptions won't work. Both publisher

Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

On Thu, Sep 28, 2023 at 12:58:51PM +0900, Kyotaro Horiguchi wrote: > The attached is a quick mock-up, but providing an approximation of my > thoughts. (For example, end_of_backup_reached could potentially be > extended to the ArchiveRecoveryRequested case and we could simplify > the condition..) I

Re: Set enable_seqscan doesn't take effect?

On Wednesday, September 27, 2023, jacktby jacktby wrote: > postgres=# SET enable_seqscan = off; > SET > postgres=# explain select * from t; >QUERY PLAN > - > Seq Scan on t (cost=100.0

Re: [PGdocs] fix description for handling pf non-ASCII characters

v4 LGTM. == Kind Regards, Peter Smith. Fujitsu Australia

Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

Sorry, it seems that I posted at the wrong position.. At Thu, 28 Sep 2023 12:58:51 +0900 (JST), Kyotaro Horiguchi wrote in > At Fri, 10 Mar 2023 15:59:04 +0900, Michael Paquier > wrote in > > My apologies for the long message, but this deserves some attention, > > IMHO. > > > > So, any thou

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 6:35 PM Andres Freund wrote: > > if insert LSN - RedoRecPtr < insert LSN - page LSN > > page is older than the most recent checkpoint start, so freeze it > > regardless of whether or not it would emit an FPI > > > > What aggressiveness levels should there be? What sho

Re: Requiring recovery.signal or standby.signal when recovering with a backup_label

At Fri, 10 Mar 2023 15:59:04 +0900, Michael Paquier wrote in > My apologies for the long message, but this deserves some attention, > IMHO. > > So, any thoughts? Sorry for being late. However, I agree with David's concern regarding the unnecessary inconvenience it introduces. I'd like to main

Re: [PGdocs] fix description for handling pf non-ASCII characters

On Thu, Sep 28, 2023 at 03:23:30AM +, Hayato Kuroda (Fujitsu) wrote: > Hmm, cfbot got angry because it tried to apply both of patches. To avoid it, > I repost renamed patch. > (I'm happy if we can specify the target branch of patches) I was looking at this thread overall, the three v3 flavors

Re: Set enable_seqscan doesn't take effect?

> 2023年9月28日 01:07，Andres Freund 写道： > > Hi, > > On 2023-09-28 00:37:41 +0800, jacktby jacktby wrote: >> postgres=# SET enable_seqscan = off; >> SET >> postgres=# explain select * from t; >> QUERY PLAN >> -

Re: Set enable_seqscan doesn't take effect?

> 2023年9月28日 01:07，Andres Freund 写道： > > Hi, > > On 2023-09-28 00:37:41 +0800, jacktby jacktby wrote: >> postgres=# SET enable_seqscan = off; >> SET >> postgres=# explain select * from t; >> QUERY PLAN >>

RE: [PGdocs] fix description for handling pf non-ASCII characters

> I attached two patches - one is for HEAD, and another one is for REL_16_STABLE > branch. As shown below, PG16 has the same behavior. Hmm, cfbot got angry because it tried to apply both of patches. To avoid it, I repost renamed patch. (I'm happy if we can specify the target branch of patches) S

Re: Streaming I/O, vectored I/O (WIP)

On 31/08/2023 07:00, Thomas Munro wrote: Currently PostgreSQL reads (and writes) data files 8KB at a time. That's because we call ReadBuffer() one block at a time, with no opportunity for lower layers to do better than that. This thread is about a model where you say which block you'll want next

RE: [PGdocs] fix description for handling pf non-ASCII characters

Dear Tom, Thank you for giving a comment! New patch is available in [1]. > I'd be inclined to keep the text as simple as possible and not focus on > the distinction between bytes and characters. > Okay, in the latest version, the word "byte" was removed. [1]: https://www.postgresql.org/message

RE: [PGdocs] fix description for handling pf non-ASCII characters

Dear Peter, Thank you for reviewing! > > > > > A. A patch which completely follows your comments. The name is > > > > > "v3-0001-...patch". Cfbot tests it. > > > > > B. A patch which completely follows Peter's comments [1]. The > > > > > name is "Peter_v3-txt". > > > > > C. A patch which foll

RE: [PGdocs] fix description for handling pf non-ASCII characters

Dear Karl, Thank you for giving comments! PSA new version. I attached two patches - one is for HEAD, and another one is for REL_16_STABLE branch. As shown below, PG16 has the same behavior. ``` psql (16beta3) Type "help" for help. postgres=# SET application_name TO 'あああ'; SET postgres=# SHOW app

Re: RFC: Logging plan of the running query

On 28/9/2023 09:04, torikoshia wrote: On 2023-09-25 18:49, Andrey Lepikhov wrote: On 25/9/2023 14:21, torikoshia wrote: On 2023-09-20 14:39, Lepikhov Andrei wrote: Hmm, as a test, I made sure to call ProcessLogQueryPlanInterrupt() on all CFI using v28-0002-Testing-attempt-logging-plan-on-ever

Re: Index range search optimization

On Wed, Sep 27, 2023 at 9:41 AM Alexander Korotkov wrote: > Fixed typo inficating => indicating as pointed by Pavel. > Peter, what do you think about the current shape of the patch? I'll try to get to this tomorrow. I'm rather busy with moving home at the moment, unfortunately. -- Peter Geoghe

Re: RFC: Logging plan of the running query

On 2023-09-25 18:49, Andrey Lepikhov wrote: On 25/9/2023 14:21, torikoshia wrote: On 2023-09-20 14:39, Lepikhov Andrei wrote: Hmm, as a test, I made sure to call ProcessLogQueryPlanInterrupt() on all CFI using v28-0002-Testing-attempt-logging-plan-on-ever-CFI-call.patch, and then ran the foll

Re: [PGdocs] fix description for handling pf non-ASCII characters

On Thu, Sep 28, 2023 at 11:19 AM Tom Lane wrote: > > ... trailing bytes that could be mistaken for ASCII are precisely > the property that causes us to reject an encoding as not backend-safe. Oh, that is good to know. Thanks for the information. == Kind Regards, Peter Smith. Fujitsu Australi

Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()

Hi, On 2023-09-28 07:53:45 +0900, Michael Paquier wrote: > On Wed, Sep 27, 2023 at 10:29:25AM -0700, Andres Freund wrote: > > Frankly, it seems like a quite bad idea to have such a high limit for > > pgstat_track_activity_query_size. The overhead such a high value has will > > surprise people... >

Re: Eager page freeze criteria clarification

On 2023-09-27 19:09:41 -0400, Melanie Plageman wrote: > On Wed, Sep 27, 2023 at 3:25 PM Robert Haas wrote: > > > > On Wed, Sep 27, 2023 at 12:34 PM Andres Freund wrote: > > > One way to deal with that would be to not track the average age in > > > LSN-difference-bytes, but convert the value to so

Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c)

On Thu, 28 Sept 2023 at 02:37, Ranier Vilela wrote: >> Please check [1] for the mention of: >> >> "The fastest way to get your patch rejected is to make unrelated >> changes. Reformatting lines that haven't changed, changing unrelated >> comments you felt were poorly worded, touching code not nece

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 5:42 PM Melanie Plageman wrote: > On Wed, Sep 27, 2023 at 5:27 PM Peter Geoghegan wrote: > > What about my idea of holding back when some tuples are already frozen > > from before? Admittedly that's still a fairly raw idea, but something > > along those lines seems promisi

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 6:07 PM Andres Freund wrote: > > I would be sure to look out for new inserts that "unfreeze" pages, too > > -- ideally you'd have instrumentation that caught that, in order to > > get a general sense of the extent of the problem in each of your > > chosen representative wor

Re: [PGdocs] fix description for handling pf non-ASCII characters

Peter Smith writes: > I had in mind something like a SHIFT-JIS encoding where a single > "character" may include some trail bytes that happen to be in the > ASCII printable range. AFAIK because the new logic is processing > bytes, not characters, I thought the end result could be a mix of > escape

Re: [PGdocs] fix description for handling pf non-ASCII characters

On Thu, Sep 28, 2023 at 10:30 AM Karl O. Pinc wrote: > > On Thu, 28 Sep 2023 09:49:03 +1000 > Peter Smith wrote: > > > On Wed, Sep 27, 2023 at 11:59 PM Karl O. Pinc > > wrote: > > > > > > On Wed, 27 Sep 2023 12:58:54 + > > > "Hayato Kuroda (Fujitsu)" wrote: > > > > > > > > Should the commit

Re: Set enable_seqscan doesn't take effect?

On Thu, 28 Sept 2023 at 13:47, jacktby jacktby wrote: > > postgres=# SET enable_seqscan = off; > SET > postgres=# explain select * from t; >QUERY PLAN > - > Seq Scan on t (cost=100.00.

Re: Add test module for Table Access Method

On Sat, Jun 03, 2023 at 07:42:36PM -0400, Fabrízio de Royes Mello wrote: > So in order to improve things a bit in this area I'm proposing to add a > test module for Table Access Method similar what we already have for Index > Access Method. > > This code is based on the "blackhole_am" implemented

Re: Eager page freeze criteria clarification

Hi, On 2023-09-27 17:43:04 -0700, Peter Geoghegan wrote: > On Wed, Sep 27, 2023 at 5:20 PM Melanie Plageman > wrote: > > > Can you define "unfreeze"? I don't know if this newly invented term > > > refers to unsetting a page that was marked all-frozen following (say) > > > an UPDATE, or if it refe

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 5:20 PM Melanie Plageman wrote: > > Can you define "unfreeze"? I don't know if this newly invented term > > refers to unsetting a page that was marked all-frozen following (say) > > an UPDATE, or if it refers to choosing to not freeze when the option > > was available (in t

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 5:27 PM Peter Geoghegan wrote: > > On Wed, Sep 27, 2023 at 1:45 PM Andres Freund wrote: > > I am much more concerned about cases where > > opportunistic freezing requires an FPI - it'll often *still* be the right > > choice to freeze the page, but we need a way to prevent

Re: Fail hard if xlogreader.c fails on out-of-memory

On Tue, Sep 26, 2023 at 06:28:30PM -0700, Noah Misch wrote: > On Wed, Sep 27, 2023 at 11:06:37AM +1300, Thomas Munro wrote: >> What Michael wants to do now is remove the 2004-era assumption that >> malloc failure implies bogus data. It must be pretty unlikely in a 64 >> bit world with overcommitte

Re: [PGdocs] fix description for handling pf non-ASCII characters

On Thu, 28 Sep 2023 09:49:03 +1000 Peter Smith wrote: > On Wed, Sep 27, 2023 at 11:59 PM Karl O. Pinc > wrote: > > > > On Wed, 27 Sep 2023 12:58:54 + > > "Hayato Kuroda (Fujitsu)" wrote: > > > > > > Should the committer be interested, your patch applies cleanly > > > > and the docs build

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 7:39 PM Peter Geoghegan wrote: > > On Wed, Sep 27, 2023 at 4:09 PM Melanie Plageman > wrote: > > At the risk of seeming too execution-focused, I want to try and get more > > specific. Here is a description of an example implementation to test my > > understanding: > > > >

Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()

On Fri, 8 Sept 2023 at 19:14, Richard Guo wrote: > explain select * from partsupp join lineitem on l_partkey > ps_partkey; > QUERY PLAN > -- > Gather (cost=0.00..1807085.44 r

Re: [PGdocs] fix description for handling pf non-ASCII characters

On Wed, Sep 27, 2023 at 11:59 PM Karl O. Pinc wrote: > > On Wed, 27 Sep 2023 12:58:54 + > "Hayato Kuroda (Fujitsu)" wrote: > > > > Should the committer be interested, your patch applies cleanly > > > and the docs build as expected. > > > > Yeah, but cfbot accepted previous version. Did you ha

Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()

On Fri, 8 Sept 2023 at 09:41, Robert Haas wrote: > > On Tue, Sep 5, 2023 at 8:07 AM Richard Guo wrote: > > Yeah, this seems an omission in commit 45be99f8. > > It's been a while, but I think I omitted this deliberately because I > didn't really understand the value of it and wanted to keep the >

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 4:09 PM Melanie Plageman wrote: > At the risk of seeming too execution-focused, I want to try and get more > specific. Here is a description of an example implementation to test my > understanding: > > In table-level stats, save two numbers: younger_than_cpt/older_than_cpt

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 3:25 PM Robert Haas wrote: > > On Wed, Sep 27, 2023 at 12:34 PM Andres Freund wrote: > > One way to deal with that would be to not track the average age in > > LSN-difference-bytes, but convert the value to some age metric at that > > time. If we e.g. were to convert the b

Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()

On Wed, Sep 27, 2023 at 10:29:25AM -0700, Andres Freund wrote: > I don't think going for size_t is a viable path for fixing this. I'm pretty > sure the initial patch would trigger a type mismatch from guc_tables.c - we > don't have infrastructure for size_t GUCs. Nothing marked as PGDLLIMPORT uses

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 2:26 PM Peter Geoghegan wrote: > On Wed, Sep 27, 2023 at 1:45 PM Andres Freund wrote: > > I think we need to make vacuums on large tables much more aggressive than > > they > > are now, independent of opportunistic freezing heuristics. It's idiotic that > > on large table

Re: Streaming I/O, vectored I/O (WIP)

On Thu, Sep 28, 2023 at 9:13 AM Andres Freund wrote: > On 2023-09-27 21:33:15 +0300, Heikki Linnakangas wrote: > > Looking at the later patch that introduces the streaming read API, seems > > that it finishes all the reads, so I suppose we don't need an abort > > function. Does it all get cleaned

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 1:45 PM Andres Freund wrote: > On 2023-09-27 13:14:41 -0700, Peter Geoghegan wrote: > > As a general rule, I think that we're better of gambling against > > future FPIs, and then pulling back if we go too far. The fact that we > > went one VACUUM operation without the workl

Re: Annoying build warnings from latest Apple toolchain

I wrote: > I've not yet looked at the meson build infrastructure to > see if it needs a corresponding change. I think it doesn't, as long as all the relevant build targets write their dependencies with "frontend_code" before "libpq". (The need for this is, of course, documented nowhere. The state

Re: Checks in RegisterBackgroundWorker.()

Here's a new version of these patches. I fixed one comment and ran pgindent, no other changes. -- Heikki Linnakangas Neon (https://neon.tech) From 1984e81c4191427fa2e358a664291edbf8d566ea Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Wed, 27 Sep 2023 23:39:09 +0300 Subject: [PATCH v2

Re: Eager page freeze criteria clarification

Hi, On 2023-09-27 13:14:41 -0700, Peter Geoghegan wrote: > On Wed, Sep 27, 2023 at 1:03 PM Andres Freund wrote: > > I suspect that medium term the better approach would be to be much more > > aggressive about setting all-visible, including as part of page-level > > visibility checks, and to deal

Re: Annoying build warnings from latest Apple toolchain

I wrote: > Since updating to Xcode 15.0, my macOS machines have been > spitting a bunch of linker-generated warnings. ... > some program links complain > ld: warning: ignoring duplicate libraries: '-lpgcommon', '-lpgport' I found that this is being caused by the libpq_pgport hack in Makefile.glob

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 1:03 PM Andres Freund wrote: > I suspect that medium term the better approach would be to be much more > aggressive about setting all-visible, including as part of page-level > visibility checks, and to deal with the concern of vacuum not processing such > pages soon by not

Re: Streaming I/O, vectored I/O (WIP)

Hi, On 2023-09-27 21:33:15 +0300, Heikki Linnakangas wrote: > I'm a bit disappointed and surprised by > v1-0009-WIP-Use-streaming-reads-in-vacuum.patch though: > > 4 files changed, 244 insertions(+), 78 deletions(-) > > The current prefetching logic in vacuumlazy.c is pretty hairy, so I hoped >

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 12:34 PM Andres Freund wrote: > What do you mean with "always freeze aggressively" - do you mean 'aggressive' > autovacuums? Or opportunistic freezing being aggressive? I don't know why the > former would be the case? I meant the latter. > > When it grows large enough, we

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 2:36 PM Melanie Plageman wrote: > It seems like the ideal freeze pattern for an insert-only table would be > to freeze as soon as the page is full before any checkpoints which could > force you to emit an FPI. Yes. So imagine we have two freeze criteria: 1. Do not ever op

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 11:36 AM Melanie Plageman wrote: > One big sticking point for me (brought up elsewhere in this thread, but, > AFAICT never resolved) is that it seems like the fact that we mark pages > all-visible even when not freezing them means that no matter what > heuristic we use, we

Re: Eager page freeze criteria clarification

Hi, On 2023-09-27 15:45:06 -0400, Robert Haas wrote: > > One big sticking point for me (brought up elsewhere in this thread, but, > > AFAICT never resolved) is that it seems like the fact that we mark pages > > all-visible even when not freezing them means that no matter what > > heuristic we use,

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 12:45 PM Robert Haas wrote: > > One big sticking point for me (brought up elsewhere in this thread, but, > > AFAICT never resolved) is that it seems like the fact that we mark pages > > all-visible even when not freezing them means that no matter what > > heuristic we use,

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 10:46 AM Andres Freund wrote: > I don't disagree that we should do something in that direction - I just don't > see the raw number of unfrozen pages being useful in that regard. If you have > a database where no pages live long, we don't need to freeze > oppportunistically,

Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)

On 9/27/23 15:38, Tom Lane wrote: > Tomas Vondra writes: >> On 9/26/23 23:50, Tom Lane wrote: >>> Huh. I'm baffled as to what's up there. Is it possible that this is >>> actually a hardware-based difference? I didn't think there was much >>> difference between Pi 3B and Pi 4, but we're running

Re: Eager page freeze criteria clarification

Hi, On 2023-09-27 10:25:00 -0700, Peter Geoghegan wrote: > On Wed, Sep 27, 2023 at 10:01 AM Andres Freund wrote: > > On 2023-09-26 09:07:13 -0700, Peter Geoghegan wrote: > > I don't think doing this on a system wide basis with a metric like #unfrozen > > pages is a good idea. It's quite common to

Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()

Hi, On 2023-09-27 15:42:15 +0100, Peter Eisentraut wrote: > On 27.09.23 09:08, Michael Paquier wrote: > > On Wed, Sep 27, 2023 at 08:41:55AM +0200, Jakub Wartak wrote: > > > Attached patch adjusts pgstat_track_activity_query_size to be of > > > size_t from int and fixes the issue. > > > > This ca

Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 10:01 AM Andres Freund wrote: > On 2023-09-26 09:07:13 -0700, Peter Geoghegan wrote: > I don't think doing this on a system wide basis with a metric like #unfrozen > pages is a good idea. It's quite common to have short lived data in some > tables while also having long-liv

Re: Add pg_basetype() function to obtain a DOMAIN base type

Hi, Steve! On Tue, Sep 19, 2023 at 8:36 PM Steve Chavez wrote: > > Just to give a data point for the need of this function: > > https://dba.stackexchange.com/questions/231879/how-to-get-the-basetype-of-a-domain-in-pg-type > > This is also a common use case for services/extensions that require pos

Re: [PGdocs] fix description for handling pf non-ASCII characters

On Wed, 27 Sep 2023 12:58:54 + "Hayato Kuroda (Fujitsu)" wrote: > > Should the committer be interested, your patch applies cleanly > > and the docs build as expected. > > Yeah, but cfbot accepted previous version. Did you have anything in > your mind? No. I'm letting the committer know e

Re: Set enable_seqscan doesn't take effect?

Hi, On 2023-09-28 00:37:41 +0800, jacktby jacktby wrote: > postgres=# SET enable_seqscan = off; > SET > postgres=# explain select * from t; >QUERY PLAN > - > Seq

Re: Eager page freeze criteria clarification

Hi, On 2023-09-26 09:07:13 -0700, Peter Geoghegan wrote: > On Tue, Sep 26, 2023 at 8:19 AM Andres Freund wrote: > > However, I'm not at all convinced doing this on a system wide level is a > > good > > idea. Databases do often contain multiple types of workloads at the same > > time. E.g., we wa

Re: Unlinking Parallel Hash Join inner batch files sooner

On 11/05/2023 00:00, Jehan-Guillaume de Rorthais wrote: On Wed, 10 May 2023 15:11:20 +1200 Thomas Munro wrote: The reason I didn't do this earlier is that sharedtuplestore.c continues the pre-existing tradition where each parallel process counts what it writes against its own temp_file_limit.

Re: Index range search optimization

On Mon, Sep 25, 2023 at 1:18 PM Alexander Korotkov wrote: > On Mon, Sep 25, 2023 at 12:58 PM Pavel Borisov > wrote: > > One more doubt about naming. Calling function > > _bt_checkkeys(IndexScanDesc scan, IndexTuple tuple, int tupnatts, > > ScanDirection dir, bool *continuescan, bool requiredMatc

Set enable_seqscan doesn't take effect?

postgres=# SET enable_seqscan = off; SET postgres=# explain select * from t; QUERY PLAN - Seq Scan on t (cost=100.00..123.60 rows=1360 width=32) (

Re: Eager page freeze criteria clarification

Hi, (I wrote the first part of the email before Robert and I chatted on a call, I left it in the email for posterity) On 2023-09-26 13:49:32 -0400, Robert Haas wrote: > On Tue, Sep 26, 2023 at 11:11 AM Andres Freund wrote: > > As long as the most extreme cases are prevented, unnecessarily freezi

Re: Index AmInsert Parameter Confused?

> 2023年9月27日 18:08，Matthias van de Meent 写道： > > On Wed, 27 Sept 2023 at 05:03, jacktby jacktby > wrote: >> >> >> >>> 2023年9月27日 00:45，Matthias van de Meent 写道： >>> >>> On Tue, 26 Sept 2023 at 18:38, jacktby jacktby wrote: typedef bool (*aminsert_func

Re: Is this a problem in GenericXLogFinish()?

On 27/09/2023 18:47, Robert Haas wrote: On Wed, Sep 27, 2023 at 11:03 AM Jeff Davis wrote: So it looks like it's intentionally registering a clean buffer so that it can take a cleanup lock for reasons other than cleaning (or even modiying) the page. I would think that there's a better way of ac

Re: Is this a problem in GenericXLogFinish()?

On Wed, Sep 27, 2023 at 11:03 AM Jeff Davis wrote: > So it looks like it's intentionally registering a clean buffer so that > it can take a cleanup lock for reasons other than cleaning (or even > modiying) the page. I would think that there's a better way of > accomplishing that goal, so perhaps w

Re: SLRUs in the main buffer pool - Page Header definitions

On Fri, Sep 8, 2023 at 8:56 AM Stephen Frost wrote: > If we're going to effectively segregate the buffer pool into SLRU parts > vs. everything else and then use the existing strategies for SLRUs and > have that be different from what everything else is using ... then > that doesn't seem like it's

Re: Is this a problem in GenericXLogFinish()?

On Wed, 2023-09-27 at 10:36 -0400, Robert Haas wrote: > On Tue, Sep 26, 2023 at 9:36 PM Jeff Davis wrote: > > That site is pretty trivial to fix, but there are also a couple > > places > > in hash.c and hashovfl.c that are registering a clean page and it's > > not > > clear to me exactly what's go

Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()

On 27.09.23 09:08, Michael Paquier wrote: On Wed, Sep 27, 2023 at 08:41:55AM +0200, Jakub Wartak wrote: Attached patch adjusts pgstat_track_activity_query_size to be of size_t from int and fixes the issue. This cannot be backpatched, and using size_t is not really needed as track_activity_quer

Re: Is this a problem in GenericXLogFinish()?

On Tue, Sep 26, 2023 at 9:36 PM Jeff Davis wrote: > That site is pretty trivial to fix, but there are also a couple places > in hash.c and hashovfl.c that are registering a clean page and it's not > clear to me exactly what's going on. Huh, I wonder if that's just a bug. Do you know where exactly

Re: remaining sql/json patches

Op 9/27/23 om 15:55 schreef Amit Langote: On Thu, Sep 21, 2023 at 9:41 PM Amit Langote wrote: I don't knoe, maybe it's worthwhile to fix this (admittedly trivial) fail in the tests? It's been there for a while. Thanks, Erik diff -U3 /home/aardvark/pg_stuff/pg_sandbox/pgsql.json_table/src

Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c)

At 2023-09-27 10:37:45 -0300, ranier...@gmail.com wrote: > > Forgive my impulsiveness, anyone who loves perfect, well written code, > would understand. I actually find this characterisation offensive. Being scrupulous about not grouping random drive-by changes together with the primary change is

Re: pg_upgrade and logical replication

On Wed, Sep 27, 2023 at 3:37 PM vignesh C wrote: > > On Tue, 26 Sept 2023 at 10:58, vignesh C wrote: > > > > On Wed, 20 Sept 2023 at 16:54, Amit Kapila wrote: > > > > > > On Fri, Sep 15, 2023 at 3:08 PM vignesh C wrote: > > > > > > > > The attached v8 version patch has the changes for the same.

Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)

Tomas Vondra writes: > On 9/26/23 23:50, Tom Lane wrote: >> Huh. I'm baffled as to what's up there. Is it possible that this is >> actually a hardware-based difference? I didn't think there was much >> difference between Pi 3B and Pi 4, but we're running out of other >> explanations. > Hmm, ye

Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c)

Em qua., 27 de set. de 2023 às 04:35, David Rowley escreveu: > On Wed, 27 Sept 2023 at 06:10, Ranier Vilela wrote: > > As suggested, casting is the best option that does not add any overhead > and improves the robustness of the find_base_rel function. > > I propose patch v1, with the additional

Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()

Hi tom, Do you have any comments or suggestions on this issue? Thanks. Richard Guo 于2023年9月8日周五 14:06写道： > > On Fri, Sep 8, 2023 at 3:15 AM Robert Haas wrote: > >> The example query provided here seems rather artificial. Surely few >> people write a join clause that references neither of the

RE: [PGdocs] fix description for handling pf non-ASCII characters

Dear Tom, > No, I'm pretty sure you're mistaken. It's been a long time since > high school English, but the way I think this works is that "that" > introduces a restrictive clause, which narrows the scope of what > you are saying. That is, you say "that" when you want to talk > about only the by

RE: [PGdocs] fix description for handling pf non-ASCII characters

Dear Peter, Thank you for reviewing! > > TBH, I felt the new text descriptions deviated a bit too much from the > originals. IMO only quite a small tweak was needed, so my suggested > text in the comments below reflects that. Good point, my patch may be too much. > Commit message. > > 1. > mi

RE: [PGdocs] fix description for handling pf non-ASCII characters

Dear Karl, Thank you for reviewing! > A related thing that's nice to have is to limit the line > length of the documentation source to 80 characters or less. > 79 is probably best. Since the source text around your patch > conforms to this convention you should also. IIUC it is not hard limit,

Re: should frontend tools use syncfs() ?

On 17.08.23 04:50, Michael Paquier wrote: Yeah, this crossed my mind. Do you know of any existing examples of options with links to a common section? One problem with this approach is that there are small differences in the wording for some of the frontend utilities, so it might be difficult to

Re: Testing autovacuum wraparound (including failsafe)

Sorry for the late reply. On Sun, Sep 3, 2023 at 2:48 PM Noah Misch wrote: > > On Wed, Jul 12, 2023 at 01:47:51PM +0200, Daniel Gustafsson wrote: > > > On 12 Jul 2023, at 09:52, Masahiko Sawada wrote: > > > Agreed. The timeout can be set by manually setting > > > PG_TEST_TIMEOUT_DEFAULT, but I b

Re: Partial aggregates pushdown

fujii.y...@df.mitsubishielectric.co.jp писал 2023-09-27 01:35: Hi Mr.Momjian, Mr.Pyhalov. Tuesday, 26 September 2023 22:15 Alexander Pyhalov : Do you mean that extra->partial_target->sortgrouprefs is not replaced, and so we preserve tlesortgroupref numbers? Yes, that is correct. I'm suspici

Re: Synchronizing slots from primary to standby

On Mon, Sep 25, 2023 at 7:46 PM Hayato Kuroda (Fujitsu) wrote: > > Dear Ajin, Shveta, > > Thank you for rebasing the patch set! Here are new comments for v19_2-0001. > Thank You Kuroda-san for the feedback. Most of these are addressed in v20. Please find my response inline. > 01. WalSndWaitForSt

Re: logfmt and application_context

Hi, Le mercredi 27 septembre 2023 à 10:14 +0200, Daniel Gustafsson a écrit : > Being a common format in ingestion tools makes it interesting though, but I > wonder if those tools aren't alreday supporting CSV such that adding logfmt > won't move the compatibility markers much? Compared to CSV, lo

Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning

On Wed, Sep 27, 2023 at 8:07 PM Ashutosh Bapat wrote: > On Wed, Sep 27, 2023 at 2:30 PM Amit Langote wrote: > > Just out of curiosity, is their not being present in join_info_list > > problematic in some manner, such as missed optimization opportunities > > for child joins? I noticed there is a

Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning

On Wed, Sep 27, 2023 at 2:30 PM Amit Langote wrote: > > Here are some comments. Thanks for your review. > > Please merge 0003 into 0002. Done. > > + /* > +* But the list of operator OIDs and the list of expressions may be > +* referenced somewhere else. Do not free those. > +*/ >

Re: ubsan

Hello Andres, 22.11.2022 02:15, Andres Freund wrote: Hi, On 2022-09-29 18:17:55 -0700, Andres Freund wrote: Attached is a rebased version of this patch. Hopefully with a reasonable amount of comments? I kind of wanted to add a comment to reached_main, but it just seems to end up restating the

Re: Index AmInsert Parameter Confused?

On Wed, 27 Sept 2023 at 05:03, jacktby jacktby wrote: > > > > > 2023年9月27日 00:45，Matthias van de Meent 写道： > > > > On Tue, 26 Sept 2023 at 18:38, jacktby jacktby wrote: > >> > >> typedef bool (*aminsert_function) (Relation indexRelation, > >> Datum *values, > >> bool *isnull, > >> ItemPointer

Re: pg_upgrade and logical replication

On Tue, 26 Sept 2023 at 10:58, vignesh C wrote: > > On Wed, 20 Sept 2023 at 16:54, Amit Kapila wrote: > > > > On Fri, Sep 15, 2023 at 3:08 PM vignesh C wrote: > > > > > > The attached v8 version patch has the changes for the same. > > > > > > > Is the check to ensure remote_lsn is valid correct

Re: Synchronizing slots from primary to standby

Hi, On 9/19/23 6:50 AM, shveta malik wrote: On Wed, Sep 13, 2023 at 5:19 PM Amit Kapila wrote: On Wed, Sep 13, 2023 at 4:54 PM shveta malik wrote: PFA v17. It has below changes: @@ -2498,6 +2500,13 @@ ReorderBufferProcessTXN(ReorderBuffer *rb, ReorderBufferTXN *txn, } else { +

  1   2   >