Re: Adding the extension name to EData / log_line_prefix

2024-05-16 Thread Peter Eisentraut
On 15.05.24 17:50, Tom Lane wrote: We kind of already have something like this, for NLS. If you look for pg_bindtextdomain(TEXTDOMAIN) and ereport_domain(), this information already trickles into the vicinity of the error data. Maybe the same thing could just be used for this, by wiring up the

Re: Adding the extension name to EData / log_line_prefix

2024-05-15 Thread Tom Lane
Andres Freund writes: > What portability issues do you forsee? We already look up the same symbol in > all the shared libraries ("Pg_magic_func"), so we know that we can deal with > duplicate function names. Are you thinking that somehow we'd end up with > symbol interposition or something? No, i

Re: Adding the extension name to EData / log_line_prefix

2024-05-15 Thread Andres Freund
Hi, On 2024-05-15 13:45:30 -0400, Tom Lane wrote: > There is one advantage over my suggestion of changing PG_MODULE_MAGIC: > if we tell people to write > >PG_MODULE_MAGIC; >#undef TEXTDOMAIN >#define TEXTDOMAIN PG_TEXTDOMAIN("hstore") > > then that's 100% backwards compatible and the

Re: Adding the extension name to EData / log_line_prefix

2024-05-15 Thread Chapman Flack
On 05/15/24 13:45, Tom Lane wrote: > if we tell people to write > >PG_MODULE_MAGIC; >#undef TEXTDOMAIN >#define TEXTDOMAIN PG_TEXTDOMAIN("hstore") > > then that's 100% backwards compatible and they don't need any > version-testing ifdef's. OT for this thread, but related: supposing o

Re: Adding the extension name to EData / log_line_prefix

2024-05-15 Thread Tom Lane
Andres Freund writes: > On 2024-05-15 12:54:45 -0400, Chapman Flack wrote: >> But I'd bet, within the fraction of the population that does use it, >> it is already a short string that looks a whole lot like the name >> of the extension. So maybe enhancing the documentation and making it >> easy to

Re: Adding the extension name to EData / log_line_prefix

2024-05-15 Thread Andres Freund
Hi, On 2024-05-15 12:54:45 -0400, Chapman Flack wrote: > On 05/15/24 11:50, Tom Lane wrote: > > Hmm, cute idea, but it'd only help for extensions that are > > NLS-enabled. Which I bet is a tiny fraction of the population. > > So far as I can find, we don't even document how to set up > > TEXTDOMA

Re: Adding the extension name to EData / log_line_prefix

2024-05-15 Thread Chapman Flack
On 05/15/24 11:50, Tom Lane wrote: > Hmm, cute idea, but it'd only help for extensions that are > NLS-enabled. Which I bet is a tiny fraction of the population. > So far as I can find, we don't even document how to set up > TEXTDOMAIN for an extension --- you have to cargo-cult the But I'd bet, w

Re: Adding the extension name to EData / log_line_prefix

2024-05-15 Thread Tom Lane
Peter Eisentraut writes: > On 14.05.24 01:11, Tom Lane wrote: >> The mechanism that Andres describes for sourcing the name seems a bit >> overcomplex though. Why not just allow/require each extension to >> specify its name as a constant string? We could force the matter by >> redefining PG_MODUL

Re: Adding the extension name to EData / log_line_prefix

2024-05-15 Thread Peter Eisentraut
On 14.05.24 01:11, Tom Lane wrote: The mechanism that Andres describes for sourcing the name seems a bit overcomplex though. Why not just allow/require each extension to specify its name as a constant string? We could force the matter by redefining PG_MODULE_MAGIC as taking an argument:

Re: Adding the extension name to EData / log_line_prefix

2024-05-13 Thread Julien Rouhaud
On Mon, May 13, 2024 at 07:11:53PM GMT, Tom Lane wrote: > Andres Freund writes: > > On 2024-05-13 19:25:11 -0300, Fabrízio de Royes Mello wrote: > >> Hmmm, depending on the extension it can extensively call/use postgres code > >> so would be nice if we can differentiate if the code is called from

Re: Adding the extension name to EData / log_line_prefix

2024-05-13 Thread Andres Freund
Hi, On 2024-05-13 19:11:53 -0400, Tom Lane wrote: > The mechanism that Andres describes for sourcing the name seems a bit > overcomplex though. Why not just allow/require each extension to > specify its name as a constant string? We could force the matter by > redefining PG_MODULE_MAGIC as takin

Re: Adding the extension name to EData / log_line_prefix

2024-05-13 Thread Tom Lane
Andres Freund writes: > On 2024-05-13 19:25:11 -0300, Fabrízio de Royes Mello wrote: >> Hmmm, depending on the extension it can extensively call/use postgres code >> so would be nice if we can differentiate if the code is called from >> Postgres itself or from an extension. > I think that's not r

Re: Adding the extension name to EData / log_line_prefix

2024-05-13 Thread Andres Freund
Hi, On 2024-05-13 19:25:11 -0300, Fabrízio de Royes Mello wrote: > On Mon, May 13, 2024 at 5:51 PM Andres Freund wrote: > > It's not entirely trivial to provide errfinish() with a parameter > indicating > > the extension, but it's doable: > > > > 1) Have PG_MODULE_MAGIC also define a new variable

Re: Adding the extension name to EData / log_line_prefix

2024-05-13 Thread Fabrízio de Royes Mello
On Mon, May 13, 2024 at 5:51 PM Andres Freund wrote: > > Hi, > > It can be very useful to look at the log messages emitted by a larger number > of postgres instances to see if anything unusual is happening. E.g. checking > whether there are an increased number of internal, IO, corruption errors (a