d a blank line between the input
and output parameter comments in table_tuple_delete() and
table_tuple_update().
Regards,
--
Fujii Masao
ction doesn’t take tid. How about fixing both issues in
the same patch,
since there’s no need to commit them separately?
Regards,
--
Fujii Masao
arer to list them separately.
Also, there's no explanation of what happens if the query with \gset returns
zero or multiple rows, so I'd like to add that too. Thought?
I've attached an updated version of the patch with these changes applied.
Regards,
--
Fujii Masao
v3-0001
he 0001 patch for now.
Regards,
--
Fujii Masao
ch
to hang. From my analysis, it enters an infinite loop in discardUntilSync().
That loop waits for PGRES_PIPELINE_SYNC, but since the connection has already
been closed, it never arrives, leaving pgbench stuck.
Could this also happen without the continue-on-error patch, or is it a new bug
introduced by it? Either way, it seems pgbench needs to exit the loop when
the result status is PGRES_FATAL_ERROR.
Regards,
--
Fujii Masao
alid character
[io worker] HINT: Replication slot names may only contain lower case
letters, numbers, and the underscore character.
--------
Regards,
[1]
http://postgr.es/m/CANhcyEUUWJ7XBycqFuqQg=eZ_==kt6s7e+rdmy-ge23ola8...@mail.gmail.com
--
Fujii Masao
On Fri, Sep 19, 2025 at 11:43 AM Fujii Masao wrote:
>
> On Thu, Sep 18, 2025 at 4:20 PM Yugo Nagata wrote:
> >
> > On Thu, 18 Sep 2025 14:37:29 +0900
> > Fujii Masao wrote:
> >
> > > On Thu, Sep 18, 2025 at 10:22 AM Yugo Nagata wrote:
> > > &
On Fri, Sep 19, 2025 at 8:21 AM Chao Li wrote:
>
>
>
> On Sep 19, 2025, at 00:48, Fujii Masao wrote:
>
> Fujii Masao
>
>
>
> ```
> +error:
> + if (elevel == 0)
> + {
> + GUC_check_errdetail("%s", err_msg);
> + if (err_hint != NULL
On Thu, Sep 18, 2025 at 4:20 PM Yugo Nagata wrote:
>
> On Thu, 18 Sep 2025 14:37:29 +0900
> Fujii Masao wrote:
>
> > On Thu, Sep 18, 2025 at 10:22 AM Yugo Nagata wrote:
> > > That makes sense. How about rewriting this like:
> > >
> > > However, i
On Thu, Sep 18, 2025 at 10:54 PM Fujii Masao wrote:
>
> On Fri, Sep 12, 2025 at 9:12 PM Fujii Masao wrote:
> >
> > Hi,
> >
> > While reviewing the patch at [1], I noticed that if primary_slot_name is
> > set to an invalid slot name in postgresql.conf and th
On Fri, Sep 12, 2025 at 9:12 PM Fujii Masao wrote:
>
> Hi,
>
> While reviewing the patch at [1], I noticed that if primary_slot_name is
> set to an invalid slot name in postgresql.conf and the configuration file
> is reloaded, all running postgres processes emit the WARNING me
n a meta-command,
however, the client still aborts even when this option is specified.
Regards,
--
Fujii Masao
On Tue, Sep 16, 2025 at 5:04 PM Fujii Masao wrote:
>
> On Tue, Sep 9, 2025 at 4:56 PM Fujii Masao wrote:
> > Thanks for the review! Unless there are any objections,
> > I’ll run the tests again and then push the patches.
>
> I've pushed patches 0001, 0002, and 0003
On Wed, Sep 17, 2025 at 10:31 PM Fujii Masao wrote:
>
> On Wed, Sep 17, 2025 at 5:25 PM Steven Niu wrote:
> > I've attached a patch that removes an unused argument from
> > create_sql_command() in pgbench.c.
>
> LGTM. Barring any objection, I will commit the patch.
On Tue, Sep 9, 2025 at 2:50 PM jian he wrote:
>
> On Tue, Sep 9, 2025 at 12:00 PM Fujii Masao wrote:
> >
> > On Thu, Sep 4, 2025 at 6:00 PM jian he wrote:
> > > in _tocEntryRestorePass
> > > if we do
> > >
> > > if ((strcmp(te-&g
- qr{processed: 0/10\b},
- qr{other failures: 10\b}
+ qr{processed: 1/10\b},
+ qr{other failures: 9\b}
-
Regards,
--
Fujii Masao
On Wed, Sep 17, 2025 at 5:25 PM Steven Niu wrote:
> I've attached a patch that removes an unused argument from
> create_sql_command() in pgbench.c.
LGTM. Barring any objection, I will commit the patch.
Regards,
--
Fujii Masao
pts/t/100_vacuumdb.pl:
> $node->issues_sql_unlike(
> [ 'vacuumdb', '--analyze-only', 'postgres' ],
> qr/statement: VACUUM.*;/,
> 'vacuumdb --analyze-only skips vacuum');
+1. I've added that test to the patch.
Attached is the upda
On Tue, Sep 9, 2025 at 4:56 PM Fujii Masao wrote:
> Thanks for the review! Unless there are any objections,
> I’ll run the tests again and then push the patches.
I've pushed patches 0001, 0002, and 0003. I'll push 0004 later.
Buildfarm member petalura reported a failure at [1
ll processes check
for slot existence via the GUC check hook, which wastes cycles. The proposed
change would eliminate that overhead.
Regards,
--
Fujii Masao
long time, since it needs to remove a large number of
WAL files. This could delay subsequent checkpoints beyond checkpoint_timeout.
If so, perhaps we'd need to limit how many WAL files a single checkpoint
can remove.
Regards,
--
Fujii Masao
duced in commit d9572c4e3b4,
which added core support for extensions. Since security labels on
extensions are not supported, I agree that the code should be
removed in master.
Regards,
--
Fujii Masao
he slot doesn't exist (since it has no MyProc).
As a result, synchronized_standby_slots in the postmaster is set to
that slot. New backends then inherit this setting from the postmaster,
while already running backends correctly detect that the slot doesn't
exist and fail to apply it.
This leads to an inconsistent state: the reload succeeds with no error,
but some backends apply the new setting while others do not.
That inconsistency seems like an issue.
To fix this, ISTM that the GUC check hook for synchronized_standby_slots
should be revised so it doesn't rely on MyProc or perform slot existence
checks there
Regards,
--
Fujii Masao
"". So the proposed change seems reasonable. However,
the current behavior has existed for a long time, and I haven’t seen
any complaints about it. Some users may rely on the existing behavior
(I think that’s unlikely, though). So I'm not completely sure yet if this change
should be applied.
Regards,
--
Fujii Masao
add regression tests.
Regards,
--
Fujii Masao
ed, I found that pg_recvlogical
could previously exit without flushing written data, risking data loss.
The attached patch fixes this issue by also ensuring that all data is flushed
to disk before exiting with --no-loop.
Thought?
Regards,
--
Fujii Masao
v1-0001-pg_recvlogical-Prevent-flushed
!(val[0] == '\0' &&
list_length(args) == 1))
appendStringInfoString(&buf, quote_identifier(val));
else
appendStringInfoString(&buf, val);
Regards,
--
Fujii Masao
handle those as well.
> > > 03: make pg_restore not restore security labels if the associated
> > > object is excluded.
This patch looks good. I only applied minor cosmetic changes and
attached it as v4-0004.
Regards,
--
Fujii Masao
From 6d85d536c37cbce55fa07fe9300c153
ng back at past discussions, there seem similar patches and
conversations [1][2].
These might be useful references when considering this issue.
Regards,
[1]
https://postgr.es/m/20200228.160100.2210969269596489579.horikyota@gmail.com
[2] https://postgr.es/m/674af9dc.050a0220.268e1c.4...@mx.google.com
--
Fujii Masao
On Mon, Sep 1, 2025 at 7:12 PM Jim Jones wrote:
>
>
>
> On 01.09.25 11:09, Fujii Masao wrote:
> > The patch looks good to me. Barring any objections, I'm thinking to
> > commit the patch.
>
> LGTM.
I've pushed the patch. Thanks!
Regards,
--
Fujii Masao
with the HINT from COPY TO from views
> >
> > postgres=# COPY v1 TO STDOUT;
> > ERROR: cannot copy from view "v1"
> > HINT: Try the COPY (SELECT ...) TO variant.
>
> Thanks for your review!
>
> Updated the patch to pass regression tests.
The patch looks good to me. Barring any objections, I'm thinking to
commit the patch.
Regards,
--
Fujii Masao
mentation update in the next 24-48
> hours, provided no additional feedback materializes.
The patch looks good to me. Thanks!
Regards,
--
Fujii Masao
On Thu, Jul 3, 2025 at 11:32 PM jian he wrote:
>
> On Wed, Jul 2, 2025 at 5:18 PM Fujii Masao
> wrote:
> >
> > > hi.
> > >
> > > I’ve tested the pg_restore options --no-policies, --no-publications, and
> > > --no-subscriptions locally.
> &g
On Sat, Aug 23, 2025 at 12:00 PM Nathan Bossart
wrote:
>
> On Sat, Aug 23, 2025 at 10:59:43AM +0900, Fujii Masao wrote:
> > I tested by creating many tables with make installcheck and running
> > vacuumdb --missing-stats-only on the regression database.
> > Without the
about 60 ms,
but with the patch it took 18 seconds. That seems too slow,
so probably we'll need to tune the query?
Regards,
--
Fujii Masao
red whether vacuumdb --missing-stats-only would work
on older servers, since the patch adds access to the attgenerated column,
which might not exist there. But that's not an issue, because
--missing-stats-only is supported only on servers version 15 or later,
where attgenerated is available.
Regards,
--
Fujii Masao
ding, 2-1.snap would come before 10-1.snap, which is incorrect.
I understand this situation can occur. Does this actually cause any real issues?
If not, and if no other programs depend on file name ordering, then the current
naming should be fine?
Regards,
--
Fujii Masao
gards,
[1] https://postgr.es/m/20250820104226.8ba51e43164cd590b863c...@sraoss.co.jp
--
Fujii Masao
uumdb_test when it is first created so that we can just rely
> on the existing test cases. In fact, by doing so, you'll see that we need
> a similar change to the "inheritance and regular stats" part of the query.
+1
Regards,
--
Fujii Masao
On Wed, Aug 20, 2025 at 12:16 AM Laurenz Albe wrote:
>
> On Tue, 2025-08-19 at 23:40 +0900, Fujii Masao wrote:
> > > > --- a/doc/src/sgml/ref/vacuumdb.sgml
> > > > +++ b/doc/src/sgml/ref/vacuumdb.sgml
> > > > @@ -397,6 +397,15 @@ PostgreSQL documentatio
egression test for --missing-stats-only
with generated columns, to prevent this issue from happening again?
Regards,
--
Fujii Masao
h zero-padding? Is it just for consistency, or is it to make
file names more sortable?
Regards,
--
Fujii Masao
On Mon, Aug 18, 2025 at 3:40 PM Laurenz Albe wrote:
>
> On Mon, 2025-08-18 at 11:38 +0900, Fujii Masao wrote:
> > Thanks! So I've updated the patch based on my earlier comments.
> > Unless there are objections, I'll commit the attached version to master
> > o
On Tue, Aug 19, 2025 at 7:57 PM Jelte Fennema-Nio wrote:
>
> On Tue, 19 Aug 2025 at 12:08, Fujii Masao wrote:
> > I pushed the patch registered in PG19-2 and tried to change its status
> > to Committed by clicking [Change Status] -> [Committed] in its
> > commitfest
ase?
Regards,
[1] https://commitfest.postgresql.org/patch/5945/
--
Fujii Masao
On Mon, Aug 18, 2025 at 11:55 AM Fujii Masao wrote:
>
> On Fri, Aug 15, 2025 at 1:46 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Dear Fujii-san,
> >
> > Thanks for updating the patch. Your patches look good to me.
>
> Thanks for the review! Unless there
On Fri, Aug 15, 2025 at 1:46 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Fujii-san,
>
> Thanks for updating the patch. Your patches look good to me.
Thanks for the review! Unless there are objections, I'll commit these
two patches.
Regards,
--
Fujii Masao
ion.
Thanks! So I've updated the patch based on my earlier comments.
Unless there are objections, I'll commit the attached version to master only.
Regards,
--
Fujii Masao
v3-0001-vacuumdb-Make-vacuumdb-analyze-only-process-parti.patch
Description: Binary data
+1
> Furthermore, auto-analyze doesn't process partitioned tables, either, so
> this introduces a bit of divergence. (I'd love to see that project picked
> up again someday. Perhaps I will take a gander...)
Sounds good!
Regards,
--
Fujii Masao
associated with
> + the replication slot specified in the command.
> + See for options
> + that are accepted by the standard (pgoutput) plugin.
>
> nit: The START_REPLICATION command can pass options to the logical decoding
> output plugin associated with the specified replic
On Wed, Aug 13, 2025 at 1:00 PM Amit Kapila wrote:
>
> On Tue, Aug 12, 2025 at 4:28 PM Fujii Masao wrote:
> >
> > I'm not sure these messages are useful for end users, and LOG might not be
> > the right level. They seem more like debug information, so should we
>
On Wed, Aug 13, 2025 at 11:54 AM Amit Kapila wrote:
>
> On Tue, Aug 12, 2025 at 6:32 PM Fujii Masao wrote:
> >
> > Should we also update LOGICAL_REWRITE_FORMAT to use %08X?
> >
> > That said, the number of places to change is growing, and we're drifting
> &
On Tue, Aug 12, 2025 at 7:36 PM Fujii Masao wrote:
>
> On Tue, Aug 12, 2025 at 4:45 PM Japin Li wrote:
> >
> > Hi, all
> >
> > Commit 2633dae2e487 standardized LSN formatting with zero-padding. However,
> > a mistake was made (by me) in the example within a co
On Tue, Aug 12, 2025 at 8:06 PM Japin Li wrote:
>
> On Tue, Aug 12, 2025 at 07:14:38PM +0900, Fujii Masao wrote:
> > On Tue, Aug 12, 2025 at 6:25 PM Japin Li wrote:
> > > I believe that the format %X-%X also works with sscanf(). However, to
> > > maintain
>
On Tue, Aug 12, 2025 at 7:14 PM Fujii Masao wrote:
>
> On Tue, Aug 12, 2025 at 6:25 PM Japin Li wrote:
> > I believe that the format %X-%X also works with sscanf(). However, to
> > maintain
> > consistency, the format for sscanf() has been updated as well.
>
> Yes.
onal format, e.g.,
> *
> - * printf("%X/08X", LSN_FORMAT_ARGS(lsn));
> + * printf("%X/%08X", LSN_FORMAT_ARGS(lsn));
> *
> * To avoid breaking translatable messages, we're directly applying the
> * LSN format instead of using a macro.
LGTM.
Barring any objections, I'll commit the patch.
Regards,
--
Fujii Masao
snapshot_meta('0-40796E18.foo.snap');
contrib/pg_logicalinspect/sql/pg_logicalinspect.sql:SELECT
pg_get_logical_snapshot_meta('0/40796E18.snap');
...
Regards,
--
Fujii Masao
/logical/snapbuild.c:sprintf(tmppath,
"%s/%X-%X.snap.%d.tmp",
src/backend/replication/logical/snapbuild.c:sprintf(path, "%s/%X-%X.snap",
src/backend/replication/logical/snapbuild.c:if
(sscanf(snap_de->d_name, "%X-%X.snap", &hi, &lo) != 2)
Regards,
--
Fujii Masao
Hi,
While testing the replication slot synchronization feature, I set up
three instances on the same machine:
- Physical replication primary (also Logical replication publisher)
- Physical replication standby
- Logical replication subscriber
initdb -D pri
Regards,
--
Fujii Masao
v1-0001-vacuumdb-Skip-VACUUM-ONLY_DATABASE_STATS-with-ana.patch
Description: Binary data
On Thu, Aug 7, 2025 at 9:17 PM Daniel Gustafsson wrote:
>
> > On 6 Aug 2025, at 06:49, Fujii Masao wrote:
>
> > I've added Assert(*line != NULL) at the start of filter_get_keyword().
> > Updated patch attached.
>
> LGTM.
I've pushed the patch. Thanks!
Regards,
--
Fujii Masao
On Wed, Aug 6, 2025 at 1:17 PM Chao Li wrote:
>
> I am fine with that, and thanks for the v2 patch.
I've pushed the patch. Thanks!
Regards,
--
Fujii Masao
nds. If analyze_only is true, process
regular tables, materialized views, and partitioned tables, just like
ANALYZE (with no specific target tables) does. Otherwise, process
only regular tables and materialized views, since VACUUM skips
partitioned tables when no target tables are specified.
Regards,
--
Fujii Masao
On Wed, Aug 6, 2025 at 3:44 PM Yugo Nagata wrote:
> Yes. I believe the back-patching would be better to both v17 and v18.
> I've attached a patch for v17.
Thanks for the patch for v17! I've pushed the patches.
Regards,
--
Fujii Masao
On Tue, Aug 5, 2025 at 4:52 PM Daniel Gustafsson wrote:
>
> > On 4 Aug 2025, at 17:18, Fujii Masao wrote:
>
> I missed this thread while being on vacation, thanks for finding and fixing
> this!
>
> > This also got me thinking, if we simply define keywords as st
should go into v18,
since that's when they were added?
Regards,
--
Fujii Masao
The comment doesn't follow our usual style. How about adjusting it to
match our typical format while fixing the typo? I've attached
the updated version of the patch.
Regards,
--
Fujii Masao
v2-0001-Fix-typo-in-comment.patch
Description: Binary data
is also got me thinking, if we simply define keywords as strings of
non-whitespace characters, maybe we don't need to change the term "keyword"
to "token" at all. I've updated the patch with that in mind. Thoughts?
Regards,
--
Fujii Masao
v2-0001-pg_dump-Fix-incorrect-parsing-of-object-types-in-.patch
Description: Binary data
stics
are removed, so running ANALYZE
on the table afterwards is recommended.
For a virtual generated column, ANALYZE
is not necessary because such columns never have statistics.
--
Regards,
--
Fujii Masao
On Fri, Aug 1, 2025 at 8:55 PM Fujii Masao wrote:
> Unless there are any objections, I plan to commit this and
> back-patch to v15.
I've pushed the patch. Thanks!
Regards,
--
Fujii Masao
break;
-
case 19:
no_data = true;
break;
---
We could apply the same pattern to others like no_data, no_schema,
no_statistics, and with_statistics to make the code cleaner and more
consistent across tools.
Regards,
--
Fujii Masao
r: invalid format in filter read from file "filter.txt"
on line 1: unsupported filter object type: "table-data"
Regards,
--
Fujii Masao
v1-0001-pg_dump-Fix-incorrect-parsing-of-object-types-in-.patch
Description: Binary data
pen while using pipeline mode. Since
this issue exists from v15 onward, the fix should be back-patched
to v15. I’ve also attached a version of the patch that applies
cleanly to v15 and v16, as the master patch doesn’t apply cleanly
to those branches.
Unless there are any objections, I plan to commit
#x27;s also a logical
replication target, I saw the following log messages. Is this expected?
=# REPACK (CONCURRENTLY) t;
LOG: logical decoding found consistent point at 1/00021F20
DETAIL: There are no running transactions.
STATEMENT: REPACK (CONCURRENTLY) t;
Regards,
--
Fujii Masao
able to reproduce
the issue (i.e., assertion failure by immediate shutdown)
since my earlier post. Sorry for the noise.
Regards,
--
Fujii Masao
y you think repeatedly calling PQgetResult
until it returns NULL isn't the right fix?
Regards,
--
Fujii Masao
v1-0001-Fix-assertion-failure-in-pgbench-when-handling-mu.patch
Description: Binary data
ode assumes that PGRES_PIPELINE_SYNC
is always followed by a NULL. However, it seems that another
PGRES_PIPELINE_SYNC can appear consecutively, which violates that assumption
and causes the assertion to fail. Thought?
Regards.
--
Fujii Masao
.parent_table/s,
+ '--analyze_only updates statistics for partitioned tables');
A plain space might be sufficient instead of \s+.
Also, I don't think the backslash before ".parent_table" is necessary.
Regards,
--
Fujii Masao
On Sun, Jul 27, 2025 at 3:13 PM cca5507 wrote:
>
> > I've attached an updated patch with that change.
>
> LGTM!
I've pushed the patch. Thanks!
Regards,
--
Fujii Masao
On Wed, Jul 9, 2025 at 7:46 PM Fujii Masao wrote:
>
>
>
> On 2025/07/09 3:50, Dagfinn Ilmari Mannsåker wrote:
> > Hi hackers,
> >
> > I noticed that psql's tab completion suggested TO immediately after
> > GRANT ... ON LARGE OBJECT, and not after ON
ER_COMMAND_CLUSTER))
|
^
1 error generated.
-
Regards,
--
Fujii Masao
l_query_until()
instead of safe_psql() to handle this properly.
I've attached an updated patch with that change.
Regards,
--
Fujii Masao
v2-0001-Add-regression-test-for-background-worker-restart.patch
Description: Binary data
#x27;t set any parameters that would
prevent the logical replication launcher from starting, I think
we don't need to worry about that. No??
Regards,
--
Fujii Masao
v1-0001-Add-regression-test-for-background-worker-restart.patch
Description: Binary data
On Fri, Jul 25, 2025 at 5:25 PM shveta malik wrote:
>
> On Fri, Jul 25, 2025 at 7:17 AM Fujii Masao wrote:
> >
> > On Thu, Jul 24, 2025 at 6:46 PM shveta malik wrote:
> > > Sounds reasonable.
> > > Thinking out loud, when cleaning up after a back
e test separately.
Andrey Rudometov proposed a test patch in thread [1],
which we might use as a starting point.
Regards,
[1]
https://postgr.es/m/CAF6JsWiO=i24qyitwe6ns1sxqcl86ryxdyu+pnyk-wuekps...@mail.gmail.com
--
Fujii Masao
v2-0001-Fix-background-worker-not-restarting-after-crash-.patch
Description: Binary data
address it.
Regards,
[1] https://postgr.es/m/tencent_e00a056b3953ee6440f0f40f80ec30427...@qq.com
--
Fujii Masao
we need may be
resetting rw_pid to 0.
Instead of modifying CleanupBackend() to do this, another option
could be to reset rw_pid during restart-after-crash code, for example,
inside ResetBackgroundWorkerCrashTimes(). Thought?
Regards,
--
Fujii Masao
respective directories.
Meanwhile, the standby’s restore_command might be set up to fetch WAL files
from the primary’s archive directory. This kind of setup can be used
when there’s
no shared archive directory between the primary and standby. In such cases,
even WAL files restored on the standby might need to be archived again.
Regards,
--
Fujii Masao
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 a
On Tue, Jul 22, 2025 at 9:30 PM Andrei Lepikhov wrote:
>
> On 22/7/2025 07:22, Fujii Masao wrote:
> > Log remote NOTICE, WARNING, and similar messages using ereport().
> >
> > Previously, NOTICE, WARNING, and similar messages received from remote
> > servers over
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
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 recen
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
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
used earlier in
libpq-be-fe-helpers.h,
but that's not the case here, so I don't think it's necessary.
Unless there are objections, I'll remove that prototype and commit the patch.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
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/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
ssed to the notice receiver" should be changed to
"message text returned by PQresultErrorMessage()"?
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
al replication, not necessarily a logical publisher.
Maybe something like "received message via replication" would be clearer?
I'd like to hear others' thoughts on a better wording.
Modified the message to "received message via replication." Will
update it further if we get any better wording.
+1
Regards,
[1] https://www.postgresql.org/docs/devel/libpq-notice-processing.html
--
Fujii Masao
NTT DATA Japan Corporation
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
1 - 100 of 1473 matches
Mail list logo
