On Tue, 22 Jul 2025 at 18:43, Fujii Masao wrote:
>
> On Tue, Jul 22, 2025 at 9:49 PM Álvaro Herrera wrote:
> >
> > On 2025-Jul-22, Fujii Masao wrote:
> >
> > > On Tue, Jul 22, 2025 at 8:47 PM Álvaro Herrera
> > > wrote:
> >
> > > > Oh yeah, I should have remembered this -- see commit 213c959a29
On Tue, Jul 22, 2025 at 9:49 PM Álvaro Herrera wrote:
>
> On 2025-Jul-22, Fujii Masao wrote:
>
> > On Tue, Jul 22, 2025 at 8:47 PM Álvaro Herrera wrote:
>
> > > Oh yeah, I should have remembered this -- see commit 213c959a294d. Feel
> > > free to do away with the whole translation thing ... does
On 22/7/2025 14:49, Álvaro Herrera wrote:
On 2025-Jul-22, Fujii Masao wrote:
We should still remove all gettext_noop() markers in contrib :-)
You mean to remove gettext_noop() also from basic_archive.c?
Yes, it's useless and misleading. Feel free to do it in the same commit ...
Just for t
On 2025-Jul-22, Fujii Masao wrote:
> On Tue, Jul 22, 2025 at 8:47 PM Álvaro Herrera wrote:
> > Oh yeah, I should have remembered this -- see commit 213c959a294d. Feel
> > free to do away with the whole translation thing ... doesn't seem worth
> > spending more time on it.
>
> Yes! The attached
On Tue, Jul 22, 2025 at 8:47 PM Álvaro Herrera wrote:
>
> On 2025-Jul-22, Fujii Masao wrote:
>
> > Is the issue caused by the use of _() in libpq-be-fe-helpers.h,
> > instead of using gettext_noop() in dblink.c? At least in my test
> > environment, the build error disappeared after applying
> > th
On 2025-Jul-22, Fujii Masao wrote:
> Is the issue caused by the use of _() in libpq-be-fe-helpers.h,
> instead of using gettext_noop() in dblink.c? At least in my test
> environment, the build error disappeared after applying
> the following change:
>
> - errmsg_internal("%s: %.*s", _(prefix), le
On Tue, Jul 22, 2025 at 6:24 PM Álvaro Herrera wrote:
>
> On 2025-Jul-22, Álvaro Herrera wrote:
>
> > On 2025-07-22, Fujii Masao wrote:
> >
> > > The buildfarm member indri reported the following error, which seems
> > > related to
> > > the recent changes in dblink. I'll investigate this later.
On 2025-Jul-22, Álvaro Herrera wrote:
> On 2025-07-22, Fujii Masao wrote:
>
> > The buildfarm member indri reported the following error, which seems
> > related to
> > the recent changes in dblink. I'll investigate this later.
>
> Ah yes — contrib doesn't have gettext support and macOS doesn't
On 2025-07-22, Fujii Masao wrote:
> The buildfarm member indri reported the following error, which seems related
> to
> the recent changes in dblink. I'll investigate this later.
Ah yes — contrib doesn't have gettext support and macOS doesn't like that.
Maybe removing the gettext_noop calls in
On 2025/07/22 14:29, Fujii Masao wrote:
On Mon, Jul 21, 2025 at 5:51 PM Álvaro Herrera wrote:
On 2025-Jul-21, Fujii Masao wrote:
Thanks for updating the patch! It looks good to me, except for one minor point:
static inline PGresult *libpqsrv_get_result(PGconn *conn, uint32
wait_event_
On Mon, Jul 21, 2025 at 5:51 PM Álvaro Herrera wrote:
>
> On 2025-Jul-21, Fujii Masao wrote:
>
> > Thanks for updating the patch! It looks good to me, except for one minor
> > point:
> >
> > static inline PGresult *libpqsrv_get_result(PGconn *conn, uint32
> > wait_event_info);
> > +static inlin
On 2025-Jul-21, Fujii Masao wrote:
> Thanks for updating the patch! It looks good to me, except for one minor
> point:
>
> static inline PGresult *libpqsrv_get_result(PGconn *conn, uint32
> wait_event_info);
> +static inline void libpqsrv_notice_receiver(void *arg, const PGresult *res);
>
> T
On 2025/07/19 15:45, vignesh C wrote:
Also, I don't see why there are three patches here instead of just one.
Earlier we thought to commit replication changes function firstlly and
then commit dblink and fdw changes, but now that we are using a common
notice receiver function. I feel it can
On Sat, 19 Jul 2025 at 01:39, Álvaro Herrera wrote:
>
> On 2025-Jul-18, vignesh C wrote:
>
> > diff --git a/contrib/postgres_fdw/connection.c
> > b/contrib/postgres_fdw/connection.c
> > index 304f3c20f83..c1ce6f33436 100644
> > --- a/contrib/postgres_fdw/connection.c
> > +++ b/contrib/postgres_fd
On 2025-Jul-18, vignesh C wrote:
> diff --git a/contrib/postgres_fdw/connection.c
> b/contrib/postgres_fdw/connection.c
> index 304f3c20f83..c1ce6f33436 100644
> --- a/contrib/postgres_fdw/connection.c
> +++ b/contrib/postgres_fdw/connection.c
> @@ -625,6 +625,9 @@ connect_pg_server(ForeignServer
On Fri, 18 Jul 2025 at 04:46, Fujii Masao wrote:
>
>
>
> On 2025/07/18 1:15, Álvaro Herrera wrote:
> > On 2025-Jul-18, Fujii Masao wrote:
> >
> >> The current patches add nearly identical notice_receiver functions
> >> in multiple places such as libpqwalreceiver.c and elsewhere. To avoid
> >> dupl
On 2025/07/18 1:15, Álvaro Herrera wrote:
On 2025-Jul-18, Fujii Masao wrote:
The current patches add nearly identical notice_receiver functions
in multiple places such as libpqwalreceiver.c and elsewhere. To avoid
duplicating the same logic, could we define a shared notice receiver
function
On 2025-Jul-18, Fujii Masao wrote:
> The current patches add nearly identical notice_receiver functions
> in multiple places such as libpqwalreceiver.c and elsewhere. To avoid
> duplicating the same logic, could we define a shared notice receiver
> function in a common file, like libpq-be-fe-helpe
On 2025/07/17 23:34, Fujii Masao wrote:
The attached v5 version patch
has the changes for the same.
Thanks for updating the patches!
The current patches add nearly identical notice_receiver functions
in multiple places such as libpqwalreceiver.c and elsewhere. To avoid
duplicating the same
On 2025/07/17 17:05, vignesh C wrote:
On Thu, 17 Jul 2025 at 11:18, Álvaro Herrera wrote:
Hi,
Shouldn't we be using a notice receiver rather than a notice processor?
I saw the following comment in code regarding PQsetNoticeProcessor
should be deprecated:
/*
* The default notice message
On Thu, 17 Jul 2025 at 11:18, Álvaro Herrera wrote:
>
> Hi,
>
> Shouldn't we be using a notice receiver rather than a notice processor?
I saw the following comment in code regarding PQsetNoticeProcessor
should be deprecated:
/*
* The default notice message receiver just gets the standard notice
Hi,
Shouldn't we be using a notice receiver rather than a notice processor?
--
Álvaro Herrera
On Wed, 16 Jul 2025 at 21:30, Fujii Masao wrote:
>
>
>
> On 2025/07/16 19:45, vignesh C wrote:
> > If we don't trim the trailing newline, an extra blank line will appear
> > after the message is printed, like this:
> > 2025-07-16 12:44:20.076 IST [534376] LOG: logical replication table
> > synchr
On 2025/07/16 19:45, vignesh C wrote:
If we don't trim the trailing newline, an extra blank line will appear
after the message is printed, like this:
2025-07-16 12:44:20.076 IST [534376] LOG: logical replication table
synchronization worker for subscription "sub1", table "t2" has started
2025
On Wed, 16 Jul 2025 at 09:09, Fujii Masao wrote:
>
> >
> > Included it for dblink and fdw
>
> Thanks! It's better to submit each change for dblink and postgres_fdw
> as separate patches, and first focus on the patch that sets the notice
> processor for replication connections.
Modified
> > > +no
On Wed, Jul 16, 2025 at 2:24 AM vignesh C wrote:
>
> On Mon, 14 Jul 2025 at 21:36, Fujii Masao wrote:
> >
> >
> >
> > On 2025/04/15 13:37, vignesh C wrote:
> > > Hi,
> > >
> > > Currently, when a warning is emitted by the publisher, the
> > > corresponding log message does not include the log pre
On Mon, 14 Jul 2025 at 21:36, Fujii Masao wrote:
>
>
>
> On 2025/04/15 13:37, vignesh C wrote:
> > Hi,
> >
> > Currently, when a warning is emitted by the publisher, the
> > corresponding log message does not include the log prefix. This makes
> > it harder to correlate such messages with other lo
On 2025/04/15 13:37, vignesh C wrote:
Hi,
Currently, when a warning is emitted by the publisher, the
corresponding log message does not include the log prefix. This makes
it harder to correlate such messages with other log entries. For
example, in a simulated error scenario where directory re
28 matches
Mail list logo
