Re: Faster "SET search_path"

On Tue, 2023-08-01 at 22:07 -0700, Nathan Bossart wrote: > I wonder if this is a good enough reason to _not_ proceed with this > optimization.  At the moment, I'm on the fence about it. I was wondering the same thing. It's something that could reasonably be explained to users; it's not what I'd

Re: Adding a LogicalRepWorker type field

On Mon, Jul 31, 2023 at 10:47 AM Peter Smith wrote: > > Hi hackers, > > BACKGROUND: > > The logical replication has different worker "types" (e.g. apply > leader, apply parallel, tablesync). > > They all use a common structure called LogicalRepWorker, but at times > it is necessary to know what

Re: Faster "SET search_path"

On Wed, 2 Aug 2023 at 01:07, Nathan Bossart wrote: > On Mon, Jul 31, 2023 at 10:28:31PM -0700, Jeff Davis wrote: > > On Sat, 2023-07-29 at 12:44 -0400, Isaac Morland wrote: > >> Essentially, "just" observe efficiently (somehow) that no change is > >> needed, and skip changing it? > > > > I gave

Re: Faster "SET search_path"

On Mon, Jul 31, 2023 at 10:28:31PM -0700, Jeff Davis wrote: > On Sat, 2023-07-29 at 12:44 -0400, Isaac Morland wrote: >> Essentially, "just" observe efficiently (somehow) that no change is >> needed, and skip changing it? > > I gave this a try and it speeds things up some more. > > There might

Re: Faster "SET search_path"

On Tue, Aug 01, 2023 at 04:59:33PM -0700, Jeff Davis wrote: > + List*pair= lfirst(lc); > + char*name= linitial(pair); > + char*value = lsecond(pair); This is definitely a nitpick, but this List of Lists business

Re: Incorrect handling of OOM in WAL replay leading to data loss

At Tue, 01 Aug 2023 15:28:54 +0900 (JST), Kyotaro Horiguchi wrote in > I thoght that the failure on a stanby results in continuing to retry > reading the next record. However, I found that there's a case where > start process stops in response to OOM [1]. I've examined the calls to

Re: [PATCH] [zh_CN.po] fix a typo in simplified Chinese translation file

> > add the missing leading `l` for log_statement_sample_rate > > -- > Regards > Junwang Zhao -msgstr "如果值设置为0，那么打印出所有查询,以og_statement_sample_rate为准. 如果设置为-1，那么将把这个功能特性关闭." +msgstr "如果值设置为-msgstr "如果值设置为0，那么打印出所有查询,以og_statement_sample_rate为准. 如果设置为-1，那么将把这个功能特性关闭." I think it's pretty

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

Dear Jonathan, Thank you for reading the thread! > Can I take this a step further on the user interface and ask why the > flag would be "--include-logical-replication-slots" vs. being enabled by > default? > > Are there reasons why we wouldn't enable this feature by default on > pg_upgrade, and

Inquiry about Functionality Availability in PostgreSQL

Dear PostgreSQL Development Team, I am inquiring about the availability of certain functionalities in the standard PostgreSQL database. Could you please confirm if the following functionalities are currently available in PostgreSQL: 1. Enforcement of Security Attribute Expiry 2. Restricted Data

Re: Adding a LogicalRepWorker type field

On Wed, Aug 2, 2023 at 8:10 AM Peter Smith wrote: > > > The am_xxx functions are removed now in the v2-0001 patch. See [1]. > > The replacement set of macros (the ones with no arg) are not strictly > necessary, except I felt it would make the code unnecessarily verbose > if we insist to pass

Re: Simplify some logical replication worker type checking

On Tue, Aug 1, 2023 at 12:11 PM Alvaro Herrera wrote: > > On 2023-Aug-01, Peter Smith wrote: > > > PSA a small patch making those above-suggested changes. The 'make > > check' and TAP subscription tests are all passing OK. > > I think the code ends up more readable with this style of changes, so

Re: Adding a LogicalRepWorker type field

On Mon, Jul 31, 2023 at 11:11 PM Amit Kapila wrote: > > +1. BTW, do we need the below functions (am_tablesync_worker(), > am_leader_apply_worker()) after this work? > static inline bool > am_tablesync_worker(void) > { > - return OidIsValid(MyLogicalRepWorker->relid); > + return

Re: Documentation of psql's \df no longer matches reality

On Thu, Mar 2, 2023 at 3:34 PM Tom Lane wrote: > It seems like we should either restore "trigger" as its own > type classification, or remove it from the list of properties > you can filter on, or adjust the docs to describe "t" as a > special filter condition. I'm kind of inclined to the

Re: Adding a LogicalRepWorker type field

Thanks for your detailed code review. Most comments are addressed in the attached v2 patches. Details inline below: On Mon, Jul 31, 2023 at 7:55 PM Bharath Rupireddy wrote: > > On Mon, Jul 31, 2023 at 7:17 AM Peter Smith wrote: > > > > PROBLEM: > > > > IMO, deducing the worker's type by

Re: Inaccurate comments in ReorderBufferCheckMemoryLimit()

On Tue, Aug 1, 2023 at 2:06 PM Masahiko Sawada wrote: > > On Tue, Aug 1, 2023 at 11:33 AM Amit Kapila wrote: > > > > On Mon, Jul 31, 2023 at 8:46 PM Masahiko Sawada > > wrote: > > > > > > While reading the code, I realized that the following code comments > > > might not be accurate: > > > > >

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

On 8/1/23 5:39 AM, Amit Kapila wrote: On Fri, Jul 28, 2023 at 5:48 PM vignesh C wrote: Here is a patch which checks that there are no WAL records other than CHECKPOINT_SHUTDOWN WAL record to be consumed based on the discussion from [1]. Few comments: = 2. + if

Re: Performance degradation on concurrent COPY into a single relation in PG16.

On Wed, 2 Aug 2023 at 12:25, David Rowley wrote: > master @ 3845577cb > latency average = 1575.879 ms > >6.79% postgres [.] pg_strtoint32_safe > > master~1 > latency average = 1968.004 ms > > 14.28% postgres [.] pg_strtoint32_safe > > REL_16_STABLE > latency average =

Re: Extract numeric filed in JSONB more effectively

Hi Matthias: On Wed, Aug 2, 2023 at 7:33 AM Andy Fan wrote: > > > On Tue, Aug 1, 2023 at 7:03 PM Matthias van de Meent < > boekewurm+postg...@gmail.com> wrote: > >> On Tue, 1 Aug 2023 at 06:39, Andy Fan wrote: >> > >> > Hi: >> > >> > Currently if we want to extract a numeric field in jsonb, we

Re: Use of additional index columns in rows filtering

On Mon, Jul 24, 2023 at 11:59 AM Peter Geoghegan wrote: > > That might be true but I'm not sure what to do about that unless we > > incorporate some "robustness" measure into the costing. If every > > measure we have says one plan is better, don't we have to choose it? > > I'm mostly concerned

Re: Support to define custom wait events for extensions

Em ter., 1 de ago. de 2023 às 21:34, Masahiro Ikeda < ikeda...@oss.nttdata.com> escreveu: > On 2023-08-02 08:38, Ranier Vilela wrote: > > Hi, > > > > On Tue, Aug 01, 2023 at 11:51:35AM +0900, Masahiro Ikeda wrote: > >> Thanks for committing the main patch. > > > > Latest head > > Ubuntu 64 bits >

Re: Support to define custom wait events for extensions

On 2023-08-02 08:38, Ranier Vilela wrote: Hi, On Tue, Aug 01, 2023 at 11:51:35AM +0900, Masahiro Ikeda wrote: Thanks for committing the main patch. Latest head Ubuntu 64 bits gcc 13 64 bits ./configure --without-icu make clean make In file included from ../../src/include/pgstat.h:20,

Re: Performance degradation on concurrent COPY into a single relation in PG16.

On Wed, 2 Aug 2023 at 07:38, Dean Rasheed wrote: > Running the new test on slightly older Intel hardware (i9-9900K, gcc > 11.3), I get the following: Thanks for running those tests. I've now pushed the fastpath4.patch after making a few adjustments to the header comments to mention the new stuff

Re: Faster "SET search_path"

On Sat, 2023-07-29 at 21:51 -0700, Nathan Bossart wrote: > On Sat, Jul 29, 2023 at 08:59:01AM -0700, Jeff Davis wrote: > > 0001: Transform the settings in proconfig into a List for faster > > processing. This is simple and speeds up any proconfig setting. > > This looks straightforward.  It might

Re: Correct the documentation for work_mem

Hi, Sorry for the delay in response and thanks for the feedback! > I've reviewed and built the documentation for the updated patch. As it stands > right now I think the documentation for this section is quite clear. Sorry, I am not understanding. What is clear? The current documentation -or-

Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Tue, 2023-08-01 at 14:47 -0700, David G. Johnston wrote: > The overall point stands, it just requires defining a similar "FROM > SESSION" to allow for explicitly specifying the current default > (missing) behavior. That sounds useful as a way to future-proof function definitions that intend to

Re: Incorrect handling of OOM in WAL replay leading to data loss

On Tue, 2023-08-01 at 16:14 +0300, Aleksander Alekseev wrote: > Probably I'm missing something, but if memory allocation is required > during WAL replay and it fails, wouldn't it be a better solution to > log the error and terminate the DBMS immediately? We need to differentiate between: 1. No

Re: Support to define custom wait events for extensions

Hi, On Tue, Aug 01, 2023 at 11:51:35AM +0900, Masahiro Ikeda wrote: > Thanks for committing the main patch. Latest head Ubuntu 64 bits gcc 13 64 bits ./configure --without-icu make clean make In file included from ../../src/include/pgstat.h:20, from controldata_utils.c:38:

Re: Extract numeric filed in JSONB more effectively

On Tue, Aug 1, 2023 at 7:03 PM Matthias van de Meent < boekewurm+postg...@gmail.com> wrote: > On Tue, 1 Aug 2023 at 06:39, Andy Fan wrote: > > > > Hi: > > > > Currently if we want to extract a numeric field in jsonb, we need to use > > the following expression: cast (a->>'a' as numeric). It

Re: stats test intermittent failure

Andres Freund writes: > I integrated the suggested change of the comment and tweaked it a bit > more. And finally pushed the fix. This failure was originally seen on v16 (that is, pre-fork). Shouldn't the fix be back-patched? regards, tom lane

Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Tue, 2023-08-01 at 13:41 -0400, Robert Haas wrote: > In functions and procedures, except for the new > BEGIN ATOMIC stuff, we just store the statements as a string and they > get parsed at execution time. ... > I think that a lot of people would like it if we moved more in the > direction of

Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Tue, Aug 1, 2023 at 2:38 PM Jeff Davis wrote: > On Tue, 2023-08-01 at 11:16 -0700, David G. Johnston wrote: > > They can use ALTER FUNCTION and the existing "FROM CURRENT" > > specification to get back to current behavior if desired. > > The current behavior is that the search_path comes from

Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Tue, 2023-08-01 at 11:16 -0700, David G. Johnston wrote: > They can use ALTER FUNCTION and the existing "FROM CURRENT" > specification to get back to current behavior if desired. The current behavior is that the search_path comes from the environment each execution. FROM CURRENT saves the

Re: stats test intermittent failure

Hi, On 2023-07-31 21:03:07 +0900, Masahiko Sawada wrote: > Regarding the patch, I have a comment: > > -- Test that reuse of strategy buffers and reads of blocks into these reused > --- buffers while VACUUMing are tracked in pg_stat_io. > +-- buffers while VACUUMing are tracked in pg_stat_io. If

Re: POC, WIP: OR-clause support for indexes

Jim, On Tue, Aug 1, 2023 at 1:11 PM Finnerty, Jim wrote: > Peter, I'm very glad to hear that you're researching this! Glad to hear it! > Will this include skip-scan optimizations for OR or IN predicates, or when > the number of distinct values in a leading non-constant index column(s) is >

Re: bug: ANALYZE progress report with inheritance tables

> On 22 Jan 2023, at 17:23, Justin Pryzby wrote: > diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c > index c86e690980e..96710b84558 100644 > ... This CF entry fails to build in the CFBot since the patch isn't attached to the email, and the CFBot can't extract inline

Re: Add GUC to tune glibc's malloc implementation.

> On 29 Jun 2023, at 00:31, Andres Freund wrote: > On 2023-06-28 07:26:03 +0200, Ronan Dunklau wrote: >> I see it as a way to have *some* sort of control over the malloc >> implementation we use, instead of tuning our allocations pattern on top of it >> while treating it entirely as a black box.

Re: document the need to analyze partitioned tables

> On 13 Jul 2023, at 00:21, David Rowley wrote: > > On Wed, 25 Jan 2023 at 21:43, David Rowley wrote: >> While I agree that the majority of partitions are likely to be >> relkind='r', which you might ordinarily consider a "normal table", you >> just might change your mind when you try to INSERT

Re: explain analyze rows=%.0f

> On 3 Jul 2023, at 18:34, Daniel Gustafsson wrote: > >> On 8 Jun 2023, at 19:49, Ibrar Ahmed wrote: >> On Mon, Mar 20, 2023 at 7:56 PM Gregory Stark (as CFM) > > wrote: > >> This patch was marked Returned with Feedback and then later Waiting on >> Author. And it

Re: Partial aggregates pushdown

When it is valid to filter based on a HAVING clause predicate, it should already have been converted into a WHERE clause predicate, except in the special case of an LIMIT TO .k .. ORDER BY case where the HAVING clause predicate can be determined approximately after having found k fully

Re: POC, WIP: OR-clause support for indexes

Peter, I'm very glad to hear that you're researching this! Will this include skip-scan optimizations for OR or IN predicates, or when the number of distinct values in a leading non-constant index column(s) is sufficiently small? e.g. suppose there is an ORDER BY b, and WHERE clause predicates

Re: How to build a new grammer for pg?

On Tue, Aug 1, 2023 at 3:45 PM Andrew Dunstan wrote: > Or to enable some language other than SQL (QUEL anyone?) > A few years ago, I got a minimal POSTQUEL working again to release as a patch for April Fools' Day, which I never did. I should dig that up somewhere :) Anyway, as far as OP's

Re: [PATCH] Support % wildcard in extension upgrade filenames

On Tue, Aug 1, 2023 at 3:23 PM Daniel Gustafsson wrote: > I don't disagree with that, but there is nothing preventing that discussion to > continue here or on other threads. The fact that consensus is that far away > and no patch that applies exist seems to me to indicate that a new CF entry is

RE: [PATCH] Support % wildcard in extension upgrade filenames

> > On 1 Aug 2023, at 20:45, Robert Haas wrote: > > > > On Tue, Aug 1, 2023 at 2:24 PM Daniel Gustafsson > wrote: > >> returned with feedback. Please feel free to resubmit to a future CF > >> when there is a new version of the patch. > > > > Isn't the real problem here that there's no consensus

Re: How to build a new grammer for pg?

On 2023-08-01 Tu 12:50, Chapman Flack wrote: On 2023-08-01 07:58, Julien Rouhaud wrote: On Tue, Aug 01, 2023 at 07:36:36PM +0800, jacktby wrote: Hi, I’m trying to develop a new grammar for pg It's unclear to me whether you want to entirely replace the flex/bison parser with something else

Re: POC, WIP: OR-clause support for indexes

On Mon, Jul 31, 2023 at 9:38 AM Alena Rybakina wrote: > I noticed only one thing there: when we have unsorted array values in > SOAP, the query takes longer than > when it has a sorted array. I'll double-check it just in case and write > about the results later. I would expect the B-Tree

Re: Performance degradation on concurrent COPY into a single relation in PG16.

On Tue, 1 Aug 2023 at 15:01, David Rowley wrote: > > Here's a patch with an else condition when the first digit check fails. > > master + fastpath4.patch: > latency average = 1579.576 ms > latency average = 1572.716 ms > latency average = 1563.398 ms > > (appears slightly faster than

Re: [PATCH] Support % wildcard in extension upgrade filenames

> On 1 Aug 2023, at 20:45, Robert Haas wrote: > > On Tue, Aug 1, 2023 at 2:24 PM Daniel Gustafsson wrote: >> returned with feedback. Please feel free to resubmit to a future CF when >> there >> is a new version of the patch. > > Isn't the real problem here that there's no consensus on what

Re: [PATCH] Support % wildcard in extension upgrade filenames

On Tue, Aug 1, 2023 at 2:24 PM Daniel Gustafsson wrote: > returned with feedback. Please feel free to resubmit to a future CF when > there > is a new version of the patch. Isn't the real problem here that there's no consensus on what to do? Or to put a finer point on it, that Tom seems

Re: add timing information to pg_upgrade

On Tue, Aug 1, 2023 at 9:00 AM Nathan Bossart wrote: > >> On 1 Aug 2023, at 09:45, Peter Eisentraut wrote: > >> But who would use that, other than, you know, you, right now? /me raises hand Or at least, me back when I was hacking on pg_upgrade performance. This, or something like it, would

Re: [PATCH] Support % wildcard in extension upgrade filenames

> On 28 Jun 2023, at 10:29, Daniel Gustafsson wrote: > >> On 31 May 2023, at 21:07, Sandro Santilli wrote: >> On Thu, Apr 27, 2023 at 12:49:57PM +0200, Sandro Santilli wrote: > >>> I'm happy to bring back the control-file switch if there's an >>> agreement about that. >> >> I'm attaching an

Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Tue, Aug 1, 2023 at 10:42 AM Robert Haas wrote: > Now, if we don't go in the direction of resolving everything at parse > time, then I think capturing search_path is probably the next best > thing, or at least the next best thing that I've thought up so far. I'd much rather strongly

Re: Improve the performance of nested loop join in the case of partitioned inner table

> On 4 Jul 2023, at 14:02, David Rowley wrote: > I'm going to mark this as waiting on author in the CF app. It might be > better if you withdraw it and resubmit when you have a patch that > addresses the worst-case regression issue. Since there hasn't been any updates to this thread I am

Re: constants for tar header offsets

On Tue, Aug 1, 2023 at 11:07 AM Tristan Partin wrote: > A new API design would be great, but for right now v2 is good enough and > should be committed. It is much easier to read the code with this patch > applied. > > Marking as "Ready for Committer" since we all seem to agree that this is >

Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Mon, Jul 31, 2023 at 6:10 PM Jeff Davis wrote: > Capturing the environment is not ideal either, in my opinion. It makes > it easy to carelessly depend on a schema that others might not have > USAGE privileges on, which would then create a runtime problem for > other callers. Also, I don't

Re: New Table Access Methods for Multi and Single Inserts

On Tue, Aug 1, 2023 at 9:31 AM Bharath Rupireddy wrote: > Thanks. Finally, I started to spend time on this. Just curious - may > I know the discussion in/for which this patch is referenced? What was > the motive? Is it captured somewhere? It may not have been the only place, but we at least

Re: How to build a new grammer for pg?

On 2023-08-01 07:58, Julien Rouhaud wrote: On Tue, Aug 01, 2023 at 07:36:36PM +0800, jacktby wrote: Hi, I’m trying to develop a new grammar for pg It's unclear to me whether you want to entirely replace the flex/bison parser with something else or just add some new bison rule. Or express

Re: should frontend tools use syncfs() ?

On Mon, Jul 31, 2023 at 11:39:46AM -0700, Nathan Bossart wrote: > I just realized I forgot to update the --help output for these utilities. > I'll do that in the next version of the patch. Done in v3. Sorry for the noise. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com >From

Re: New Table Access Methods for Multi and Single Inserts

On Sun, Jun 4, 2023 at 4:08 AM Andres Freund wrote: > > Hi, > > This patch was referenced in a discussion at pgcon, so I thought I'd give it a > look, even though Bharat said that he won't have time to drive it forward... Thanks. Finally, I started to spend time on this. Just curious - may I

One more problem with JIT

Hi hackers, I am using pg_embedding extension for Postgres which implements HNSW index (some kind of ANN search). Search query looks something like this:     SELECT _id FROM documents ORDER BY openai <=> ARRAY[0.024466066, -0.00042, -0.0012917554,... , -0.008700027] LIMIT 1; I do not

Re: add timing information to pg_upgrade

On Tue, Aug 01, 2023 at 09:58:24AM +0200, Daniel Gustafsson wrote: >> On 1 Aug 2023, at 09:45, Peter Eisentraut wrote: >> On 28.07.23 01:51, Nathan Bossart wrote: > >>> This information can be used to better understand where the time is going >>> and to validate future improvements. >> >> But

Re: POC: Extension for adding distributed tracing - pg_tracing

Hi! Thanks for the improvements! >Here's a new patch with changes from the previous discussion: >- I'm now directly storing nanoseconds duration in the span instead of the instr_time. Using the instr_time macros was a bit awkward as the durations I generate don't necessarily have a starting and

Re: add timing information to pg_upgrade

On Tue, Aug 01, 2023 at 09:46:02AM +0200, Peter Eisentraut wrote: > On 31.07.23 20:37, Nathan Bossart wrote: >> -prep_status("Checking for incompatible \"aclitem\" data type in user >> tables"); >> +prep_status("Checking for \"aclitem\" data type in user tables"); > > Why these changes?

Re: There should be a way to use the force flag when restoring databases

Hi Gurjeet, I have addressed all your comments except for the tests. I have tried adding test cases but I wasn't able to do it as it's in my mind. I am not able to do things like having connections to the database and trying to force the restore, then it will complete successfully otherwise it

Re: logical decoding and replication of sequences, take 2

On 8/1/23 04:59, Amit Kapila wrote: > On Mon, Jul 31, 2023 at 5:04 PM Tomas Vondra > wrote: >> >> On 7/31/23 11:25, Amit Kapila wrote: >>> ... >>> >>> Yeah, I also think this needs a review. This is a sort of new concept >>> where we don't use the LSN of the slot (for cases where copy returned

Re: constants for tar header offsets

On Wed Apr 19, 2023 at 8:09 AM CDT, Robert Haas wrote: On Tue, Apr 18, 2023 at 12:56 PM Dagfinn Ilmari Mannsåker wrote: > It still has magic numbers for the sizes of the fields, should those > also be named constants? I thought about that. It's arguable, but personally, I don't think it's

Re: Pgoutput not capturing the generated columns

On Tue, Aug 1, 2023, at 3:47 AM, Rajendra Kumar Dangwal wrote: > With decoderbufs and wal2json the connector is able to capture the generated > column `full_name` in above example. But with pgoutput the generated column > was not captured. wal2json materializes the generated columns before

Re: pgsql: Fix search_path to a safe value during maintenance operations.

On Mon, Jul 31, 2023 at 5:15 PM Jeff Davis wrote: > > ERROR: role "rhaas" should not execute arbitrary code provided by > > role "jconway" > > HINT: If this should be allowed, use the TRUST command to permit it. > > +1, though I'm not sure we need an extensive trust mechanism beyond > what we

Fix error handling in be_tls_open_server()

Hi, A static analyzer reported a possible pfree(NULL) in be_tls_open_server(). Here is a fix. Also handle an error from X509_NAME_print_ex(). AFAICS, the error "SSL certificate's distinguished name contains embedded null" could not be reached at all, because XN_FLAG_RFC2253 passed to

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

On Tue Aug 1, 2023 at 8:48 AM CDT, Joe Conway wrote: On 7/3/23 12:25, Tristan Partin wrote: > On Sat Jun 24, 2023 at 8:09 AM CDT, Joe Conway wrote: >> Although I have not looked yet, presumably we could have similar >> problems with plpython. I would like to get agreement on this approach >>

Re: Performance degradation on concurrent COPY into a single relation in PG16.

On Wed, 2 Aug 2023 at 01:26, Dean Rasheed wrote: > > On Tue, 1 Aug 2023 at 13:55, David Rowley wrote: > > > > I tried adding the "at least 1 digit check" by adding an else { goto > > slow; } in the above code, but it seems to generate slower code than > > just checking if (unlikely(ptr == s)) {

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

On 7/3/23 12:25, Tristan Partin wrote: On Sat Jun 24, 2023 at 8:09 AM CDT, Joe Conway wrote: Although I have not looked yet, presumably we could have similar problems with plpython. I would like to get agreement on this approach against plperl before diving into that though. Thoughts? I

Re: Performance degradation on concurrent COPY into a single relation in PG16.

On Tue, 1 Aug 2023 at 13:55, David Rowley wrote: > > I tried adding the "at least 1 digit check" by adding an else { goto > slow; } in the above code, but it seems to generate slower code than > just checking if (unlikely(ptr == s)) { goto slow; } after the loop. > That check isn't quite right,

Re: Oversight in reparameterize_path_by_child leading to executor crash

Richard Guo writes: > In this case what we need to do is to adjust the TableSampleClause to > refer to the correct child relations. We can do that with the help of > adjust_appendrel_attrs_multilevel(). One problem is that the > TableSampleClause is stored in RangeTblEntry, and it does not seem

Re: Incorrect handling of OOM in WAL replay leading to data loss

Hi, > As far as I can see, PerformWalRecovery() uses LOG as elevel > [...] > On top of my mind, any solution I can think of needs to add more > information to XLogReaderState, where we'd either track the type of > error that happened close to errormsg_buf which is where these errors > are

Re: Performance degradation on concurrent COPY into a single relation in PG16.

On Tue, 1 Aug 2023 at 13:25, Andres Freund wrote: > There's a lot of larger numbers in the file, which likely reduces the impact > some. And there's the overhead of actually inserting the rows into the table, > making the difference appear smaller than it is. It might be worth special casing the

Re: Performance degradation on concurrent COPY into a single relation in PG16.

On Mon, 31 Jul 2023 at 21:39, John Naylor wrote: > master + pg_strtoint_fastpath1.patch > latency average = 938.146 ms > latency stddev = 9.354 ms > > master + pg_strtoint_fastpath2.patch > latency average = 902.808 ms > latency stddev = 3.957 ms Thanks for checking those two on your machine.

Re: How to build a new grammer for pg?

Hi, On Tue, Aug 01, 2023 at 07:36:36PM +0800, jacktby wrote: > Hi, I’m trying to > develop a new grammar for pg, can +you give me a code example to reference? It's unclear to me whether you want to entirely replace the flex/bison parser with something else or just add some new bison rule. If

How to build a new grammer for pg?

Hi, I’m trying to develop a new grammar for pg, can you give me a code example to reference?

Re: Synchronizing slots from primary to standby

On Fri, Jul 28, 2023 at 8:54 PM Bharath Rupireddy wrote: > > On Thu, Jul 27, 2023 at 10:55 AM Amit Kapila wrote: > > > > I wonder if we anyway some sort of design like this because we > > shouldn't allow to spawn as many workers as the number of databases. > > There has to be some existing or

Re: Extract numeric filed in JSONB more effectively

On Tue, 1 Aug 2023 at 06:39, Andy Fan wrote: > > Hi: > > Currently if we want to extract a numeric field in jsonb, we need to use > the following expression: cast (a->>'a' as numeric). It will turn a numeric > to text first and then turn the text to numeric again. Why wouldn't you use

RE: Fix compilation warnings when CFLAGS -Og is specified

Dear Horiguchi-san, Thanks for replying! > > My gcc version is 4.8.5, and ninja is 1.10.2. > > gcc 4.8 looks very old? > > AFAIS all of those complaints are false positives and if I did this > correclty, gcc 11.3 seems to have been fixed in this regard. I switched to newer gcc (8.3, still

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

On Fri, Jul 28, 2023 at 5:48 PM vignesh C wrote: > > Here is a patch which checks that there are no WAL records other than > CHECKPOINT_SHUTDOWN WAL record to be consumed based on the discussion > from [1]. > Few comments: = 1. Do we really need 0001 patch after the latest change

RE: CDC/ETL system on top of logical replication with pgoutput, custom client

Hi Andres. Owh, I see the error of my way... :( By ignoring commits, and committing individual operation LSNs, I was effectively rolling back the subscription. In the previous example, if I committed the LSN of the first insert of the second transaction (LSN1-500), I was basically telling

Oversight in reparameterize_path_by_child leading to executor crash

For paths of type 'T_Path', reparameterize_path_by_child just does the flat-copy but does not adjust the expressions that have lateral references. This would have problems for partitionwise-join. As an example, consider regression=# explain (costs off) select * from prt1 t1 join lateral

Re: Inaccurate comments in ReorderBufferCheckMemoryLimit()

On Tue, Aug 1, 2023 at 11:33 AM Amit Kapila wrote: > > On Mon, Jul 31, 2023 at 8:46 PM Masahiko Sawada wrote: > > > > While reading the code, I realized that the following code comments > > might not be accurate: > > > > /* > > * Pick the largest transaction (or subtransaction)

Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements

> On 22 Mar 2023, at 09:17, Andrei Zubkov wrote: > New version is attached. This patch is marked RfC but didn't get reviewed/committed during this CF so I'm moving it to the next, the patch no longer applies though so please submit an updated version. -- Daniel Gustafsson

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

Hi, On Thu, Jul 13, 2023 at 5:08 PM Masahiko Sawada wrote: > > On Sat, Jul 8, 2023 at 11:54 AM John Naylor > wrote: > > > > > > On Fri, Jul 7, 2023 at 2:19 PM Masahiko Sawada > > wrote: > > > > > > On Wed, Jul 5, 2023 at 8:21 PM John Naylor > > > wrote: > > > > Well, it's going to be a bit

[PATCH] [zh_CN.po] fix a typo in simplified Chinese translation file

add the missing leading `l` for log_statement_sample_rate -- Regards Junwang Zhao 0001-zh_CN.po-fix-a-typo-in-simplified-Chinese-translatio.patch Description: Binary data

Re: add timing information to pg_upgrade

> On 1 Aug 2023, at 09:45, Peter Eisentraut wrote: > On 28.07.23 01:51, Nathan Bossart wrote: >> This information can be used to better understand where the time is going >> and to validate future improvements. > > But who would use that, other than, you know, you, right now? > > I think the

Re: [PATCH] psql: \dn+ to show size of each schema (and \dA+ for AMs)

> On 24 May 2023, at 23:05, Justin Pryzby wrote: > I'm planning to set this patch as ready This is marked RfC so I'm moving this to the next CF, but the patch no longer applies so it needs a rebase. -- Daniel Gustafsson

Re: add timing information to pg_upgrade

On 31.07.23 20:37, Nathan Bossart wrote: - prep_status("Checking for incompatible \"aclitem\" data type in user tables"); + prep_status("Checking for \"aclitem\" data type in user tables"); Why these changes? I think this is losing precision about what it's doing.

Re: add timing information to pg_upgrade

On 28.07.23 01:51, Nathan Bossart wrote: I've been looking into some options for reducing the amount of downtime required for pg_upgrade, and $SUBJECT seemed like something that would be worthwhile independent of that effort. The attached work-in-progress patch adds the elapsed time spent in

Re: Incorrect handling of OOM in WAL replay leading to data loss

At Tue, 01 Aug 2023 15:28:54 +0900 (JST), Kyotaro Horiguchi wrote in > While we will not agree, we could establish a defalut behavior where > an OOM during recovery immediately triggers an ERROR. Then, we could > introduce a *GUC* that causes recovery to regard OOM as an > end-of-recovery

Pgoutput not capturing the generated columns

Hi PG Users. We are using Debezium to capture the CDC events into Kafka. With decoderbufs and wal2json plugins the connector is able to capture the generated columns in the table but not with pgoutput plugin. We tested with the following example: CREATE TABLE employees ( id SERIAL PRIMARY

Re: Fix compilation warnings when CFLAGS -Og is specified

At Tue, 1 Aug 2023 04:51:55 +, "Hayato Kuroda (Fujitsu)" wrote in > Dear hackers, > > # Background > > Based on [1], I did configure and build with options: > (I used Meson build system, but it could be reproduced by Autoconf/Make) > > ``` > $ meson setup -Dcassert=true -Ddebug=true

Re: Simplify some logical replication worker type checking

On 2023-Aug-01, Peter Smith wrote: > PSA a small patch making those above-suggested changes. The 'make > check' and TAP subscription tests are all passing OK. I think the code ends up more readable with this style of changes, so +1. I do wonder if these calls should appear in a proc_exit

Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication

On Tue, 1 Aug 2023 at 09:44, Peter Smith wrote: > > On Fri, Jul 28, 2023 at 5:22 PM Peter Smith wrote: > > > > Hi Melih, > > > > BACKGROUND > > -- > > > > We wanted to compare performance for the 2 different reuse-worker > > designs, when the apply worker is already busy handling other >

Re: Incorrect handling of OOM in WAL replay leading to data loss

At Tue, 1 Aug 2023 14:03:36 +0900, Michael Paquier wrote in > On Tue, Aug 01, 2023 at 01:51:13PM +0900, Kyotaro Horiguchi wrote: > > I believe a database server is not supposed to be executed under such > > a memory-constrained environment. > > I don't really follow this argument. The backend

Fix pg_stat_reset_single_table_counters function

Hi, My colleague, Mitsuru Hinata (in CC), found the following issue. The documentation of pg_stat_reset_single_table_counters() says pg_stat_reset_single_table_counters ( oid ) → void Resets statistics for a single table or index in the current database or shared across all databases in the