Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures

On Tue, Dec 20, 2022 at 5:40 AM Michael Paquier wrote: > On Tue, Dec 20, 2022 at 09:01:02AM +0900, Michael Paquier wrote: > > Yeah, my mind was considering as well yesterday the addition of a note > > in the docs about something among these lines, so fine by me. > > And applied that, after

Re: Use get_call_result_type() more widely

On Mon, Dec 19, 2022 at 07:41:27PM +0530, Bharath Rupireddy wrote: > I agree with the bucketization. Please see the attached patches. 0001 > - gets rid of explicit tuple desc creation using > get_call_result_type() for functions thought to be not-so-frequently > called. It looks like I am OK with

Re: Use get_call_result_type() more widely

On Mon, Dec 19, 2022 at 05:50:03PM -0500, Robert Haas wrote: > All right, well, I just work here. :-) Just to give some numbers. The original version of the patch doing the full switch removed 500 lines of code. The second version that switches the "non-critical" paths removes 200~ lines. --

Re: Refactor SCRAM code to dynamically handle hash type and key length

On Tue, Dec 20, 2022 at 08:58:38AM +0900, Michael Paquier wrote: > Thanks! I have applied for I have here.. There are other pieces to > think about in this area. FYI, I have spent a few hours looking at the remaining parts of the SCRAM code that could be simplified if a new hash method is

Re: code cleanups

On Thu, Nov 24, 2022 at 12:53 AM Tom Lane wrote: > > Justin Pryzby writes: > > Some modest cleanups I've accumulated. > 0004: Right, somebody injected code in a poorly chosen place > (yet another victim of the "add at the end" anti-pattern). I've pushed 0004. -- John Naylor EDB:

Re: Perform streaming logical transactions by background workers and parallel apply

On Tue, Dec 20, 2022 at 2:20 PM Amit Kapila wrote: > > On Tue, Dec 20, 2022 at 8:17 AM Peter Smith wrote: > > > > Summary > > --- > > > > In summary, everything I have tested so far appeared to be working > > properly. In other words, for overlapping streamed transactions of > > different

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

On Mon, Dec 19, 2022 at 2:14 PM Masahiko Sawada wrote: > > On Tue, Dec 13, 2022 at 1:04 AM Masahiko Sawada wrote: > > Looking at other code using DSA such as tidbitmap.c and nodeHash.c, it > > seems that they look at only memory that are actually dsa_allocate'd. > > To be exact, we estimate the

Re: Common function for percent placeholder replacement

On 19.12.22 10:51, Alvaro Herrera wrote: I think the new one is not great. I wish we could do something more straightforward, maybe like replace_percent_placeholders(base_command, PERCENT_OPT("f", filename), PERCENT_OPT("d",

Re: meson files copyright

On Mon, Dec 19, 2022 at 09:09:25PM +0100, Peter Eisentraut wrote: > On 19.12.22 19:33, Robert Haas wrote: > >On Mon, Dec 19, 2022 at 1:03 PM Tom Lane wrote: > >>Vik Fearing writes: > >>>Perhaps a bit off-topic, but what is the point of the file identifiers? > >> > >>IMO, it helps to tell things

Re: Force streaming every change in logical decoding

On Wed, Dec 14, 2022 at 5:29 PM Amit Kapila wrote: > > On Wed, Dec 14, 2022 at 2:15 PM shiy.f...@fujitsu.com > wrote: > > > > Please see the attached patch. I also fix Peter's comments[1]. The GUC name > > and > > design are still under discussion, so I didn't modify them. > > > > Let me

Re: Force streaming every change in logical decoding

On Wed, Dec 14, 2022 at 2:15 PM shiy.f...@fujitsu.com wrote: > > -while (rb->size >= logical_decoding_work_mem * 1024L) > > +while ((!force_stream && rb->size >= logical_decoding_work_mem * > > 1024L) || > > + (force_stream && rb->size > 0)) > > { > > > > It seems like if

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

On Fri, Dec 16, 2022 at 12:11 PM Hayato Kuroda (Fujitsu) wrote: > > Dear Amit, > > > I also don't see the need for this mechanism for logical replication, > > and in fact, why do we need to even wait for sending the existing WAL? > > Is it meant that logicalrep walsenders do not have to track

Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures

On Tue, Dec 20, 2022 at 09:01:02AM +0900, Michael Paquier wrote: > Yeah, my mind was considering as well yesterday the addition of a note > in the docs about something among these lines, so fine by me. And applied that, after tweaking a few tiny things on a last lookup with a catversion bump.

Re: pgsql: Doc: Explain about Column List feature.

On Tue, Dec 20, 2022 at 3:47 AM Alvaro Herrera wrote: > > On 2022-Sep-15, Alvaro Herrera wrote: > > > On 2022-Sep-15, Alvaro Herrera wrote: > > > > > Looking at the rendered docs again, I notice that section "31.4.5. > > > Combining Multiple Column Lists" is *only* the red-tinted Warning block. >

Re: Add sub-transaction overflow status in pg_stat_activity

On Tue, Dec 20, 2022 at 2:32 AM Robert Haas wrote: > > On Mon, Dec 19, 2022 at 3:48 PM Ted Yu wrote: > > It seems the comment for `backend_subxact_overflowed` missed a word. > > > > Please see the patch. > > Committed this fix, thanks. Thanks, Robert! -- Regards, Dilip Kumar EnterpriseDB:

Re: pgsql: Doc: Explain about Column List feature.

On Mon, Dec 19, 2022 at 10:17 PM Alvaro Herrera wrote: > > On 2022-Sep-15, Alvaro Herrera wrote: > > > On 2022-Sep-15, Alvaro Herrera wrote: > > > > > Looking at the rendered docs again, I notice that section "31.4.5. > > > Combining Multiple Column Lists" is *only* the red-tinted Warning block.

Re: Perform streaming logical transactions by background workers and parallel apply

On Tue, Dec 20, 2022 at 8:17 AM Peter Smith wrote: > > Summary > --- > > In summary, everything I have tested so far appeared to be working > properly. In other words, for overlapping streamed transactions of > different kinds, and regardless of whether zero/some/all of those > transactions

Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures

On Mon, Dec 19, 2022 at 05:51:19PM +0530, Bharath Rupireddy wrote: > A nitpick - can we also specify a use case for the function > pg_dissect_walfile_name(), that is, computing LSN from offset and WAL > file name, something like [1]? Yeah, my mind was considering as well yesterday the addition of

Re: Refactor SCRAM code to dynamically handle hash type and key length

On Mon, Dec 19, 2022 at 02:58:24PM -0500, Jonathan S. Katz wrote: > With the assertion in "scram_build_secret", that value is set from the > "PG_SHA256" constant anyway, so I don't know if it actually gives us > anything other than a reminder? With "scram_mock"salt" the value ultimately > comes

CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions

Attached is my work in progress to implement the changes to the CAST() function as proposed by Vik Fearing. This work builds upon the Error-safe User Functions work currently ongoing. The proposed changes are as follows: CAST(expr AS typename) continues to behave as before. CAST(expr AS

Re: Use get_call_result_type() more widely

On Mon, Dec 19, 2022 at 4:21 PM Tom Lane wrote: > Now that somebody's made an effort to identify which places are > potentially performance-critical, I don't see why we wouldn't use > the fruits of their labor. Yes, somebody else might draw the line > differently, but drawing a line at all seems

Re: Error-safe user functions

On Mon, Dec 19, 2022 at 4:27 PM Tom Lane wrote: > In [1] I wrote > > >>> I'm a little concerned about the cost-benefit of fixing the reg* types. > >>> The ones that accept type names actually use the core grammar to parse > >>> those. Now, we probably could fix the grammar to be non-throwing,

Re: appendBinaryStringInfo stuff

On Tue, 20 Dec 2022 at 11:42, Tom Lane wrote: > I think Peter is entirely right to question whether *this* type's > output function is performance-critical. Who's got large tables with > jsonpath columns? It seems to me the type would mostly only exist > as constants within queries. The patch

Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX

On Sun, 2022-12-18 at 17:38 -0600, Justin Pryzby wrote: > On Sat, Dec 17, 2022 at 04:39:29AM -0800, Ted Yu wrote: > > +   List   *ancestors = get_partition_ancestors(relid); > > +   Oid root = InvalidOid; > > > > nit: it would be better if the variable `root` can

Re: appendBinaryStringInfo stuff

David Rowley writes: > On Tue, 20 Dec 2022 at 09:23, Peter Eisentraut > wrote: >> AFAICT, the code in question is for the text output of the jsonpath >> type, which is used ... for barely anything? > I think the performance of a type's output function is quite critical. I think Peter is

Re: appendBinaryStringInfo stuff

On Tue, 20 Dec 2022 at 09:23, Peter Eisentraut wrote: > AFAICT, the code in question is for the text output of the jsonpath > type, which is used ... for barely anything? I think the performance of a type's output function is quite critical. I've seen huge performance gains in COPY TO

Re: meson files copyright

On 2022-12-19 Mo 15:09, Peter Eisentraut wrote: > On 19.12.22 19:33, Robert Haas wrote: >> On Mon, Dec 19, 2022 at 1:03 PM Tom Lane wrote: >>> Vik Fearing writes: Perhaps a bit off-topic, but what is the point of the file identifiers? >>> >>> IMO, it helps to tell things apart when

Re: Fixing typo in 002_pg_dump.pl

On Mon, Dec 19, 2022 at 09:08:54PM +0100, Peter Eisentraut wrote: > fixed Thanks! -- Michael signature.asc Description: PGP signature

Re: Error-safe user functions

Robert Haas writes: > On Mon, Dec 19, 2022 at 11:44 AM Tom Lane wrote: >> ... I guess you didn't read my remarks upthread about regtypein. >> I do not want to try to make gram.y+scan.l non-error-throwing. > Huh, for some reason I'm not seeing an email about that. Do you have a link? In [1] I

Re: Use get_call_result_type() more widely

Robert Haas writes: > On Mon, Dec 19, 2022 at 2:07 PM Alvaro Herrera > wrote: >> On the other hand, the measurements have shown that going through the >> function is significantly slower. So I kinda like the judgement call >> that Michael and Bharath have made: change to use the function when

Re: (non) translatable string splicing

On Fri, Dec 16, 2022 at 8:25 AM Justin Pryzby wrote: > Due to incomplete translation, that allows some pretty fancy output, > like: > | You must identify the directory where the residen los binarios del clúster > antiguo. I can't see how that could be mejor. :-) -- Robert Haas EDB:

Re: Inconsistency in reporting checkpointer stats

On Wed, Dec 14, 2022 at 2:32 AM Nitin Jadhav wrote: > In order to fix this, the > PendingCheckpointerStats.buf_written_checkpoints should be incremented > in SlruInternalWritePage() similar to > CheckpointStats.ckpt_bufs_written. I have attached the patch for the > same. Please share your

Re: Add sub-transaction overflow status in pg_stat_activity

On Mon, Dec 19, 2022 at 3:48 PM Ted Yu wrote: > It seems the comment for `backend_subxact_overflowed` missed a word. > > Please see the patch. Committed this fix, thanks. -- Robert Haas EDB: http://www.enterprisedb.com

Re: Add sub-transaction overflow status in pg_stat_activity

On Mon, Dec 19, 2022 at 11:57 AM Robert Haas wrote: > On Tue, Dec 13, 2022 at 2:29 AM Julien Rouhaud wrote: > > > > Makes sense. > > > > > > +1 > > > > +1 > > Committed with a bit more word-smithing on the documentation. > > -- > Robert Haas > EDB: http://www.enterprisedb.com > > Hi, It seems

Re: appendBinaryStringInfo stuff

On 19.12.22 09:12, Andres Freund wrote: There are a bunch of places in the json code that use appendBinaryStringInfo() where appendStringInfoString() could be used, e.g., appendBinaryStringInfo(buf, ".size()", 7); Is there a reason for this? Are we that stretched for performance?

Re: meson files copyright

On 19.12.22 19:33, Robert Haas wrote: On Mon, Dec 19, 2022 at 1:03 PM Tom Lane wrote: Vik Fearing writes: Perhaps a bit off-topic, but what is the point of the file identifiers? IMO, it helps to tell things apart when you've got a bunch of editor windows open on some mighty samey-looking

Re: Fixing typo in 002_pg_dump.pl

On 19.12.22 19:53, Ted Yu wrote: I was going over 002_pg_dump.pl and saw a typo in pgdump_runs. Please see the patch. fixed

Re: Refactor SCRAM code to dynamically handle hash type and key length

On 12/16/22 10:08 PM, Michael Paquier wrote: On Thu, Dec 15, 2022 at 04:59:52AM +0900, Michael Paquier wrote: However, that's only half of the picture. The key length and the hash type (or just the hash type to know what's the digest/key length to use but that's more invasive) still need to be

Re: Add sub-transaction overflow status in pg_stat_activity

On Tue, Dec 13, 2022 at 2:29 AM Julien Rouhaud wrote: > > > Makes sense. > > > > +1 > > +1 Committed with a bit more word-smithing on the documentation. -- Robert Haas EDB: http://www.enterprisedb.com

Re: Use get_call_result_type() more widely

On Mon, Dec 19, 2022 at 2:07 PM Alvaro Herrera wrote: > On the other hand, the measurements have shown that going through the > function is significantly slower. So I kinda like the judgement call > that Michael and Bharath have made: change to use the function when > performance is not an

Re: Use get_call_result_type() more widely

On 2022-Dec-19, Robert Haas wrote: > Here's a modest proposal: let's do nothing about this. There's no > evidence of a real problem here, so we're going to be trying to judge > the performance benefits against the code size savings without any > real data indicating that either one is an issue. I

Fixing typo in 002_pg_dump.pl

Hi, I was going over 002_pg_dump.pl and saw a typo in pgdump_runs. Please see the patch. Thanks pg-dump-comment.patch Description: Binary data

Re: Use get_call_result_type() more widely

On Tue, Dec 13, 2022 at 10:43 AM Tom Lane wrote: > Saving code is nice, but I'd assume the result is slower, because > get_call_result_type has to do a pretty substantial amount of work > to get the data to construct the tupdesc from. Have you tried to > quantify how much overhead this'd add?

Re: meson files copyright

On Mon, Dec 19, 2022 at 1:03 PM Tom Lane wrote: > Vik Fearing writes: > > Perhaps a bit off-topic, but what is the point of the file identifiers? > > IMO, it helps to tell things apart when you've got a bunch of editor > windows open on some mighty samey-looking meson.build files. On the other

Re: Error-safe user functions

On Mon, Dec 19, 2022 at 11:44 AM Tom Lane wrote: > > It also doesn't seem too bad from an implementation point of view to > > try to cover all the caes. > > ... I guess you didn't read my remarks upthread about regtypein. > I do not want to try to make gram.y+scan.l non-error-throwing. Huh, for

Re: meson files copyright

Vik Fearing writes: > Perhaps a bit off-topic, but what is the point of the file identifiers? IMO, it helps to tell things apart when you've got a bunch of editor windows open on some mighty samey-looking meson.build files. regards, tom lane

Re: Add LZ4 compression in pg_dump

On Mon, Dec 19, 2022 at 01:06:00PM +0900, Michael Paquier wrote: > On Sat, Dec 17, 2022 at 05:26:15PM -0600, Justin Pryzby wrote: > > 001: still refers to "gzip", which is correct for -Fp and -Fd but not > > for -Fc, for which it's more correct to say "zlib". > > Or should we begin by changing

Re: Add LZ4 compression in pg_dump

On Mon, Dec 19, 2022 at 05:03:21PM +, gkokola...@pm.me wrote: > > > 001 still doesn't compile on freebsd, and 002 doesn't compile on > > > windows. Have you checked test results from cirrusci on your private > > > github account ? > > There are still known gaps in 0002 and 0003, for example

Re: meson files copyright

On 12/19/22 16:20, Tom Lane wrote: Andrew Dunstan writes: I notice that none of the meson files contain copyright notices. Shall I add them? +1. Their comment density is pretty awful too --- maybe I'm just not used to meson, but they seem just about completely undocumented. And there's

Re: GROUP BY ALL

On 12/19/22 05:19, Andrey Borodin wrote: Hi hackers! I saw a thread in a social network[0] about GROUP BY ALL. The idea seems useful. I always was writing something like select datname, usename, count(*) from pg_stat_activity group by 1,2; and then rewriting to select datname,

Re: Error-safe user functions

Robert Haas writes: > On Fri, Dec 16, 2022 at 1:31 PM Tom Lane wrote: >> The reg* functions probably need a unified plan as to how far >> down we want to push non-error behavior. The rest of these >> I think just require turning the crank along the same lines >> as in functions already dealt

Re: Common function for percent placeholder replacement

On Mon, Dec 19, 2022 at 3:13 AM Peter Eisentraut wrote: > I agree. Here is an updated patch with the error checking included. Nice, but I think something in the error report needs to indicate what caused the problem exactly. As coded, I think the user would have to guess which GUC caused the

Re: Error-safe user functions

On Fri, Dec 16, 2022 at 1:31 PM Tom Lane wrote: > The reg* functions probably need a unified plan as to how far > down we want to push non-error behavior. The rest of these > I think just require turning the crank along the same lines > as in functions already dealt with. I would be in favor of

Add a hook to allow modification of the ldapbindpasswd

This patch, mostly the work of John Naylor, provides a hook whereby a module can modify the ldapbindpasswd before it is handed to the ldap server. This is similar in concept to the ssl_passphrase_callback feature, and allows the user not to have to put the cleartext password in the pg_hba.conf

Add a test to ldapbindpasswd

There is currently no test for the use of ldapbindpasswd in the pg_hba.conf file. This patch, mostly the work of John Naylor, remedies that. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com From 78ca6b405601ce0d884406b94fa356e38e19d2e0 Mon Sep 17 00:00:00 2001 From: Andrew

Re: Avoid generating SSL certs for LDAP tests

On 2022-12-19 Mo 10:25, Tom Lane wrote: > Andrew Dunstan writes: >> We don't generate SSL certificates for running the SSL tests, but >> instead use pregenerated certificates that are part of our source code. >> This patch applies the same policy to the LDAP tests, and in fact simply >> reuses

Re: Patch: Global Unique Index

Hi! Sorry to bother - but is this patch used in IvorySQL? Here: https://www.ivorysql.org/docs/Global%20Unique%20Index/create_global_unique_index According to syntax it definitely looks like this patch. Thank you! On Sat, Dec 3, 2022 at 3:05 AM David Zhang wrote: > On 2022-11-29 6:16 p.m., Tom

Re: Support logical replication of DDLs

On 2022-Oct-31, Peter Smith wrote: > 6. add_policy_clauses > > + else > + { > + append_bool_object(policyStmt, "present", false); > + } > > Something seems strange. Probably I'm wrong but just by code > inspection it looks like there is potential for there to be multiple > param {present:false}

Re: Avoid generating SSL certs for LDAP tests

Andrew Dunstan writes: > We don't generate SSL certificates for running the SSL tests, but > instead use pregenerated certificates that are part of our source code. > This patch applies the same policy to the LDAP tests, and in fact simply > reuses certificates from the SSL test suite by copying

Re: meson files copyright

Andrew Dunstan writes: > I notice that none of the meson files contain copyright notices. Shall I > add them? +1. Their comment density is pretty awful too --- maybe I'm just not used to meson, but they seem just about completely undocumented. And there's certainly been no effort to transfer

Re: appendBinaryStringInfo stuff

David Rowley writes: > I'm currently not sure why the macro trick increases the binary at > all. I understand why the inline function does. In the places where it changes the code at all, you're replacing appendStringInfoString(buf, s); with appendBinaryStringInfo(buf, s, n);

Avoid generating SSL certs for LDAP tests

We don't generate SSL certificates for running the SSL tests, but instead use pregenerated certificates that are part of our source code. This patch applies the same policy to the LDAP tests, and in fact simply reuses certificates from the SSL test suite by copying them. It won't save much but it

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Hi! As a result of discussion in the thread [0], Robert Haas proposed to focus on making SLRU 64 bit, as a first step towards 64 bit XIDs. Here is the patch set. In overall, code of this patch set is based on the existing code from [0] and may be simplified, due to the fact, that

Re: Use get_call_result_type() more widely

On Thu, Dec 15, 2022 at 11:41 AM Michael Paquier wrote: > > On Wed, Dec 14, 2022 at 11:14:59AM +0530, Bharath Rupireddy wrote: > > AFAICS, most of these functions have no direct source code callers, > > they're user-facing functions and not in a hot code path. I measured > > the test times of

meson files copyright

I notice that none of the meson files contain copyright notices. Shall I add them? cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com

Re: GROUP BY ALL

On Sun, 18 Dec 2022 at 23:30, Tom Lane wrote: > Andrey Borodin writes: > > I saw a thread in a social network[0] about GROUP BY ALL. The idea seems > useful. > > Isn't that just a nonstandard spelling of SELECT DISTINCT? > In a pure relational system, yes; but since Postgres allows duplicate

Re: Perform streaming logical transactions by background workers and parallel apply

On Sat, Dec 17, 2022 at 7:34 PM houzj.f...@fujitsu.com wrote: > > Agreed. I have addressed all the comments and did some cosmetic changes. > Attach the new version patch set. > Few comments: 1. + if (fileset_state == FS_SERIALIZE_IN_PROGRESS) + { +

Re: On login trigger: take three

On Mon, Dec 19, 2022 at 1:40 AM Mikhail Gribkov wrote: > Hi Ted, > > > bq. in to the system > > 'in to' -> into > > bq. Any bugs in a trigger procedure > > Any bugs -> Any bug > > Thanks! Fixed typos in the attached v35. > > > + if (event == EVT_Login) > > +

Re: Inconsistency in reporting checkpointer stats

On Fri, Dec 16, 2022 at 2:14 PM Kyotaro Horiguchi wrote: > > In the first place I don't like that we count the same things twice. > Couldn't we count the number only by any one of them? > > If we remove CheckPointerStats.ckpt_bufs_written, CreateCheckPoint can > get the final number as the

Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures

On Mon, Dec 19, 2022 at 5:22 PM Bharath Rupireddy wrote: > > On Mon, Dec 19, 2022 at 1:37 PM Michael Paquier wrote: > > > > On Tue, Dec 13, 2022 at 09:32:19PM +0530, Bharath Rupireddy wrote: > > > Okay, here's the v5 patch that I could come up with. It basically adds > > > functions for

Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures

On Mon, Dec 19, 2022 at 1:37 PM Michael Paquier wrote: > > On Tue, Dec 13, 2022 at 09:32:19PM +0530, Bharath Rupireddy wrote: > > Okay, here's the v5 patch that I could come up with. It basically adds > > functions for dissecting WAL file names and computing offset from lsn. > > Thoughts? > > I

Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths

On 2022-Dec-02, Andres Freund wrote: > Hi, > > On 2022-12-02 14:22:55 +0900, Michael Paquier wrote: > > On Fri, Nov 04, 2022 at 09:52:39AM +0900, Ian Lawrence Barwick wrote: > > > CommitFest 2022-11 is currently underway, so if you are interested > > > in moving this patch forward, now would be

Re: Support logical replication of DDLs

I have presented some comments below: 1. AT_AddColumn > + tmpobj = new_objtree_VA("ADD %{objtype}s %{definition}s", 3, [ IF NOT EXISTS ] is missing here. 2. AT_DropColumn > + tmpobj = new_objtree_VA("DROP %{objtype}s %{column}I", 3, [ IF EXISTS ] is missing here. 3. AT_DropConstraint > +

Re: Common function for percent placeholder replacement

On 2022-Dec-19, Peter Eisentraut wrote: > On 14.12.22 18:05, Justin Pryzby wrote: > > On Wed, Dec 14, 2022 at 08:31:02AM +0100, Peter Eisentraut wrote: > > > + return replace_percent_placeholders(base_command, "df", (const char > > > *[]){target_detail, filename}); > > > > This is a "compound

Re: On login trigger: take three

Hi Ted, > bq. in to the system > 'in to' -> into > bq. Any bugs in a trigger procedure > Any bugs -> Any bug Thanks! Fixed typos in the attached v35. > + if (event == EVT_Login) > + dbgtag = CMDTAG_LOGIN; > + else > +

Re: appendBinaryStringInfo stuff

On Mon, 19 Dec 2022 at 21:12, Andres Freund wrote: > Perhaps we should make appendStringInfoString() a static inline function > - most compilers can compute strlen() of a constant string at compile > time. I had wondered about that, but last time I looked into it there was a small increase in

Re: Common function for percent placeholder replacement

On 14.12.22 18:05, Justin Pryzby wrote: On Wed, Dec 14, 2022 at 08:31:02AM +0100, Peter Eisentraut wrote: + return replace_percent_placeholders(base_command, "df", (const char *[]){target_detail, filename}); This is a "compound literal", which I gather is required by C99. But I don't

Re: Common function for percent placeholder replacement

On 14.12.22 17:09, Robert Haas wrote: Well, OK, I'll tentatively cast a vote in favor of adopting basebackup_to_shell's approach elsewhere. Or to put that in plain English: I think that if the input appears to be malformed, it's better to throw an error than to guess what the user meant. In the

Re: appendBinaryStringInfo stuff

Hi, On 2022-12-19 07:13:40 +0100, Peter Eisentraut wrote: > I found a couple of adjacent weird things: > > There are a bunch of places in the json code that use > appendBinaryStringInfo() where appendStringInfoString() could be used, e.g., > > appendBinaryStringInfo(buf, ".size()", 7); > >

Re: (non) translatable string splicing

On 2022-Dec-16, Justin Pryzby wrote: > I was surprised to see that this has been here for a few years (since > 77517ba59) without complaints or inquiries from translators. See https://postgr.es/m/13948.1501733...@sss.pgh.pa.us -- Álvaro Herrera PostgreSQL Developer —

Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures

On Tue, Dec 13, 2022 at 09:32:19PM +0530, Bharath Rupireddy wrote: > Okay, here's the v5 patch that I could come up with. It basically adds > functions for dissecting WAL file names and computing offset from lsn. > Thoughts? I had a second look at that, and I still have mixed feelings about the