nts. Since logicalrep_worker_launch()
isn't a performance-critical path, this might not be a high-priority change.
But if my understanding is correct, I'm a bit tempted to apply it as a
refactoring.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development H
include \d+ output listing partitions with bound info but
-- output could vary depending on the order in which partition oids are
@@ -906,7 +889,7 @@
a | text| | |
b | integer | | not null | 0
Partition key: LIST (a)
-Number of partitions: 3 (Use \d+ to list them.)
+N
On 2025/04/18 18:45, Fujii Masao wrote:
On 2025/04/18 18:23, David Rowley wrote:
On Fri, 18 Apr 2025 at 20:54, Fujii Masao wrote:
Shouldn't the example output of pg_log_backend_memory_contexts() in
the documentation also be updated to use 1-based numbering for consistency?
Patch att
On 2025/04/18 18:23, David Rowley wrote:
On Fri, 18 Apr 2025 at 20:54, Fujii Masao wrote:
Shouldn't the example output of pg_log_backend_memory_contexts() in
the documentation also be updated to use 1-based numbering for consistency?
Patch attached.
Yeah. I failed to notice we h
On 2025/04/17 13:12, Fujii Masao wrote:
I've updated the patch to reflect this comment.
Barring any objections, I'm thinking to commit this patch.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
I've now pushed the latest patch. Thanks for the reviews.
Shouldn't the example output of pg_log_backend_memory_contexts() in
the documentation also be updated to use 1-based numbering for consistency?
Patch attached.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Rese
On 2025/04/16 13:30, Fujii Masao wrote:
On 2025/04/15 23:37, Tom Lane wrote:
Fujii Masao writes:
Thanks for the report and patch! It looks good to me.
Agreed.
Since this issue exists in the back branches,
the patch needs be back-patched to all supported versions.
I doubt it's
On 2025/04/07 16:26, Fujii Masao wrote:
On 2025/04/07 15:55, Kyotaro Horiguchi wrote:
Hello,
The recent commit 173c97812ff made the following change:
- prep_status("Adding \".old\" suffix to old global/pg_control");
+ prep_status("Adding \".old\"
On 2025/04/15 23:37, Tom Lane wrote:
Fujii Masao writes:
Thanks for the report and patch! It looks good to me.
Agreed.
Since this issue exists in the back branches,
the patch needs be back-patched to all supported versions.
I doubt it's worth the trouble and buildfarm cycles to
On 2025/04/15 17:02, Fujii Masao wrote:
On 2025/04/15 7:21, Mahendra Singh Thalor wrote:
Hi hackers,
In _allocAH function(pg_backup_archiver.c), we were using the *fmt* variable in
switch case for *default case*, but correct variable is AH->format.
Here, I am attaching a patch for
It looks good to me.
Since this issue exists in the back branches,
the patch needs be back-patched to all supported versions.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
/patch/5282/
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2025/04/11 18:27, Dave Cramer wrote:
On Fri, 11 Apr 2025 at 05:05, Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
On 2025/04/11 5:17, Dave Cramer wrote:
> No, you are correct.
>
> See new patch
Thanks for updating the patch!
-
ests a newer protocol version than the server supports.
The protocol version requested by the client, otherwise.
-
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
FROM case?
If we aim to support tab-completion for all valid targets of both COPY TO
and COPY FROM, shouldn't foreign tables also be included? And what about
views with INSTEAD OF INSERT triggers - though maybe that's overkill?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
On 2025/04/11 0:49, Dave Cramer wrote:
On Thu, 10 Apr 2025 at 11:17, Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
On 2025/04/10 23:40, Dave Cramer wrote:
>
> On Thu, 10 Apr 2025 at 09:54, Fujii Masao mailto:masao.fu...@oss.nttdata.com> &
On 2025/04/10 23:40, Dave Cramer wrote:
On Thu, 10 Apr 2025 at 09:54, Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
On 2025/04/10 18:52, Dave Cramer wrote:
> Greetings,
>
> The current docs say that if a client asks for a protocol that the
On 2025/04/09 19:24, Kirill Reshke wrote:
On Wed, 9 Apr 2025 at 14:45, Fujii Masao wrote:
On 2025/04/09 18:25, Kirill Reshke wrote:
On Wed, 9 Apr 2025 at 13:23, jian he wrote:
hi.
we allow the "COPY table TO" command to copy rows from materialized
views in [1].
The attache
or is in the upper 16 bits and the lower in the low 16 bits.
To match the style of similar descriptions, how about rephrasing it as:
"The most significant 16 bits are the major version number, and the least
significant 16 bits are the minor version number”?
Regards,
--
Fujii Masao
Advan
On 2025/04/09 6:27, Daniel Gustafsson wrote:
On 8 Apr 2025, at 18:41, Fujii Masao wrote:
I noticed that the third argument of pg_get_process_memory_contexts() is named
"retries" in pg_proc.dat, while the documentation refers to it as "timeout".
I've commi
minated with:
ERROR: ResourceOwnerEnlarge called after release started
FATAL: terminating connection because protocol synchronization was lost
Shouldn't this be addressed?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORA
laced the hardcoded "global/pg_control" with %s using XLOG_CONTROL_FILE.
Maybe we should also add a translator: comment and wrap %s/%s.old in
double quotes there?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2025/04/06 4:10, Anton A. Melnikov wrote:
Hi!
On 05.04.2025 06:11, Fujii Masao wrote:
Thanks for checking! Barring any objections, I'll go ahead and commit the patch.
As for me all is ok. Thanks!
I've pushed the patch. Thanks!
Regards,
--
Fujii Masao
Advanced Computing
y SQLSTATE filtering may not be good idea,
while supporting all possible cases in the core wouldn't be practical either.
Given that, I think implementing this as an extension using emit_log_hook
would be a better approach. Anyway, I'd like to hear more opinions from
other hackers on this.
On 2025/04/01 12:12, jian he wrote:
On Mon, Mar 31, 2025 at 11:27 PM Fujii Masao
wrote:
Regarding the patch, here are some review comments:
+ errmsg("cannot copy from
materialized view when the materialized view is not populated"),
On 2025/04/05 8:27, Anton A. Melnikov wrote:
Hi!
On 04.04.2025 19:32, Fujii Masao wrote:
I'm not sure there's clear consensus yet on the changes in the 0001 and
0002 patches, and it might not be worth rushing them in right before
the feature freeze. So for now, I reviewed and up
On 2025/04/04 23:47, Nathan Bossart wrote:
On Fri, Apr 04, 2025 at 07:18:11PM +0900, Fujii Masao wrote:
I've pushed the patch. Thanks!
Just a heads up, I fixed a pgindent issue in this commit (see commits
e1a8b1ad58 and 742317a80f). I'd ordinarily just report it, but since we&
ng the attached patch first? We can consider applying
the others later if consensus is reached.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
From 3c2891e042fec2d8251907782b02f5acdbd31ae6 Mon Sep 17 00:00:00 2001
From: Fujii M
On 2025/04/03 20:46, Fujii Masao wrote:
Thanks for updating the patch! I made some minor cosmetic changes
and updated the commit log. The revised patch is attached.
Unless there are any objections, I'll proceed with committing it.
I've pushed the patch. Thanks!
As a follow-up, i
On 2025/04/04 0:21, Fujii Masao wrote:
Thanks for updating the patch!
If there are no objections, I'll proceed with committing it using the following
commit log.
I've pushed the patch. Thanks!
While testing the feature, I noticed that psql doesn't complete
"ALTER DEFA
he patches. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2025/04/03 23:04, Yugo NAGATA wrote:
On Wed, 2 Apr 2025 02:35:35 +0900
Fujii Masao wrote:
On 2025/01/23 19:22, Yugo NAGATA wrote:
On Wed, 22 Jan 2025 13:30:17 +0100
Laurenz Albe wrote:
On Fri, 2024-09-13 at 16:18 +0900, Yugo Nagata wrote:
I've attached a updated patch. The
rect behavior.
This commit fixes the issue by checking the "plugin" field in the result
of slot() instead, ensuring the tests properly verify slot existence.
Back-patch to all supported versions.
Author: Hayato Kuroda
Reviewed-by: Fuj
On 2025/04/03 17:53, jian he wrote:
On Wed, Apr 2, 2025 at 11:20 PM Fujii Masao wrote:
if (!RelationIsPopulated(rel))
ereport(ERROR,
errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot copy
;)->{'plugin'},
+ '', 'logical slot was actually dropped on standby');
This seems like a separate issue from what your patch is addressing,
but since this test is meant to confirm that the slot was dropped
on the standby, shouldn't node_primary be node_replica instead?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
e it's not a perfect solution since it may return NULL
in standby mode until the WAL receiver starts, but it should work in most cases.
Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
.
If any issues arise, let's continue to address them.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ctions, and types (including domains) can be
altered.
In alter_default_privileges.sgml, this part should also mention large objects?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
them. I'm not sure we can identify and address all of
them before the feature freeze.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
reached", it seems better to use
"yet"
I may have unintentionally modified the error message.
I fixed the patch as suggested. Please check the latest patch
I posted earlier in response to Torikoshi-san.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
is better here, but I've updated
the patch as suggested. Attached is the revised version.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
From 2c83ae035c8093498b78243095180fa906a39c4a Mon Sep 17 00:00:00 2001
From: Fujii
documentation should clarify that COPY TO can
be used with a materialized view only if it is populated.
Wouldn't it be beneficial to add a regression test to check
whether COPY matview TO works as expected?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ver, in the attached patch, I have left them unchanged for now.
On 2025-03-25 00:55, Fujii Masao wrote:
- case CAC_NOTCONSISTENT:
+ case CAC_NOTCONSISTENT_OR_OVERFLOWED:
This new name seems a bit too long. I'm OK to leave the name as it is.
Or, something lik
design
work,
which isn't feasible within this CommitFest. So, I'm withdrawing the patch for
now.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
the commit messages for both patches and also revised
the code comments in the 0002 patch. The updated patches are attached.
Unless there are any objections, I'm thinking to commit them.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT D
r updating the patch. LGTM.
I've pushed the patches. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2025/03/24 23:18, torikoshia wrote:
On 2025-03-24 00:08, Fujii Masao wrote:
Do you also think the errhint message is unnecessary?
I agree with your idea to add a description of the overflowed subtransaction in
the manual, but I'm not sure all users will be able to find it.
Some p
on
test?
Just my idea to stabilize the test with "RETURNING *" is to use WITH, like this:
WITH tmp AS (UPDATE ... RETURNING *) SELECT * FROM tmp ORDER BY ...
Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
with that message. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2025/03/21 21:29, torikoshia wrote:
Hi,
On 2025-03-21 02:15, Fujii Masao wrote:
Thanks for your review!
Personally, I feel 1st patch may be sufficient, but I would appreciate any
feedback.
Agreed.
- errdetail("Consistent recovery state has not bee
covery has brought the system to a consistent state." - should be updated
to reflect this condition.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
apply
the change only to the master branch. What do you think should we
back-patch it as a bug fix or apply it only to master?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
it removes that incorrect statement. A similar mistake was
also present in the documentation for the DROP_REPLICATION_SLOT
command, which has now been corrected as well.
Back-patch to all supported versions.
Author: Hayato Kuroda
Reviewed-by: Fujii Masao
Discussion:
http
be updated to include
the new category, with vacuum_truncate placed under it. Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
5 or later.
So, I think the proper fix is to avoid raising a fatal error even when not
connected to
a specific database in --drop-slot action.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
n removed? If there was a past discussion about it,
could you share the details?
Since it's generally expected that a session in one database shouldn't
be able to drop objects in another, I'm wondering if removing this
restriction was intentional or possibly a bug.
Regards,
_recvlogical: error: could not establish database-specific replication
connection
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
From 8dcc53a6bebeaa1c4d0ddaacd35a3c450327bfef Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date:
On 2025/03/06 21:55, Robins Tharakan wrote:
Hi,
Thanks for taking a look at the patch, and for your feedback.
On Wed, 5 Mar 2025 at 03:22, Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
On 2025/02/16 16:05, Robins Tharakan wrote:
> This patch introduces a new
e for parameter.
It was explicitly documented that the TRUNCATE option in the VACUUM
command overrides the vacuum_truncate reloption, but this information
has been removed in the patch. Shouldn't we keep it to clarify
the priority of these settings?
Regards,
--
Fujii Masao
Advanced Computing
On 2025/03/11 22:24, Fujii Masao wrote:
On 2025/03/11 16:50, Yuki Seino wrote:
Instead, wouldn't it be simpler to update LockAcquireExtended() to
take a new argument, like logLockFailure, to control whether
a lock failure should be logged directly? I’ve adjusted the patch
accordingl
think this patch is good to be committed.
Thanks for reviewing the patch and confirming! I've pushed the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
me. I think it's a good improvement.
Thanks for reviewing the patch!
On Tue, Nov 19, 2024 at 10:14 PM Fujii Masao
wrote:
The latest version of the patch is attached.
@@ -2773,6 +2773,10 @@ FastPathTransferRelationLocks(LockMethod
lockMethodTable, const LOCKTAG *locktag
LWLock *par
Unless there are any objections, I'll proceed with committing it.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
From b6ad757e99456d379c1a1ec90cac73cd034d8926 Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date: Tue, 11
ly and attached it. Please let me know what you think!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
From 2f47436931848e63b1ca26658441cafe891bfb0e Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date: Tue, 11 Mar 2025 02:53:5
On 2025/03/09 20:38, vignesh C wrote:
I've updated the status to "withdrawn." Feel free to add it again
anytime if you change your mind.
Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
he authentication timeout begins. But shouldn't these
be the same?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
eshooting WAL replay. It would be
helpful to distinguish the startup process from a regular backend,
so we can set its log level independently.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
eloption is set.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2025/03/05 9:32, Fujii Masao wrote:
On 2025/03/05 7:26, Jacob Champion wrote:
On Mon, Mar 3, 2025 at 10:02 PM Fujii Masao wrote:
I've pushed the patch. Thanks!
Hi all,
+tests += {
+ 'name': 'ecpg',
+ 'sd': meson.current_source_dir(),
+ '
On 2024/11/30 15:23, Kirill Reshke wrote:
On Fri, 11 Oct 2024 at 06:53, Fujii Masao wrote:
However, this issue already exists without the proposed patch.
Since file_fdw already reports progress partially, querying multiple
file_fdw tables can lead to inaccurate or confusing progress reports
On 2025/03/05 7:26, Jacob Champion wrote:
On Mon, Mar 3, 2025 at 10:02 PM Fujii Masao wrote:
I've pushed the patch. Thanks!
Hi all,
+tests += {
+ 'name': 'ecpg',
+ 'sd': meson.current_source_dir(),
+ 'bd': meson.current_build
lumns — one for when the postmaster
starts accepting read-only connections and another for normal
connections?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2025/03/04 17:57, jian he wrote:
On Mon, Mar 3, 2025 at 5:05 PM Fujii Masao wrote:
Thanks for the patch!
The patch basically looks good to me.
I’ve made some minor cosmetic adjustments — the updated patch is attached.
Unless there are any objections, I'm thinking to commit it.
On 2025/03/03 14:09, Ryo Kanbayashi wrote:
On Mon, Mar 3, 2025 at 12:23 PM Fujii Masao wrote:
On 2025/03/01 19:45, Ryo Kanbayashi wrote:
+program_help_ok('ecpg');
+program_version_ok('ecpg');
+program_options_handling_ok('ecpg');
+command_fails(['ec
essage.
You can see the total duration in this message is unexpected.
It looks like this happens because creation_time wasn’t collected,
as log_connections was empty before the fork.
LOG: connection establishment times (ms): total: 1148052469, fork: 0,
authentication: 0
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2025/03/04 0:20, torikoshia wrote:
On 2025-03-03 13:10, Fujii Masao wrote:
Thanks for your comments!
On 2025/02/03 22:35, torikoshia wrote:
Hi,
When a hot standby is restarted in a state where subtransactions have
overflowed, it may become inaccessible:
$ psql: error: connection
?
+#log_connections = ''
It would also be helpful to include all valid values in a comment
within postgresql.conf.sample, making it easier for users to configure.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
kward, couldn't it affect
not only the standby but also the primary? I’m wondering
because TimestampDifferenceExceeds() seems to be used
in several places in addition to hot standby feedback.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
e made some minor cosmetic adjustments — the updated patch is attached.
Unless there are any objections, I'm thinking to commit it.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
From e136b8e656a29995ec64b3fefcb07b08c0b
7;t this log message too difficult for most users? It seems to
describe PostgreSQL's internal mechanisms, making it hard
for users to understand the issue and what actions to take.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
hey're already covered in 001.
I reflected above.
Thanks for updating the patch!
I've made some minor fixes and cosmetic adjustments.
The updated patch is attached.
Unless there are any objections, I'll commit it.
Regards,
--
Fujii Masao
Advanced Computing Technology Cente
On 2025/02/28 21:23, Sagar Shedge wrote:
Hi Fujii,
Thanks for updates.
Looks good to me. We can proceed with latest potch.
Thanks for the review! I've pushed the patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
this decision...
+program_help_ok('ecpg');
+program_version_ok('ecpg');
+program_options_handling_ok('ecpg');
+command_fails(['ecpg'], 'ecpg without arguments fails');
These checks seem unnecessary in 002 since they're already covered in 001.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ttps://cirrus-ci.com/task/5070779370438656
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
et in postgres_fdw.
Make sense. I have created a patch according to the above suggestions.
Please review.
Thanks for updating the patch!
I made a few cosmetic adjustments and attached the revised version.
Unless there are any objections, I plan to commit this.
Regards,
--
Fujii Masao
Advanced Comp
that future case, does it?
For now, I think it makes sense to keep postgres_fdw_get_connections()
aligned with the current implementation. Otherwise, explaining what
remote_backend_pid = NULL means could be confusing, especially since
pipeline mode isn't supported yet in postgres_fdw.
Thou
t->sock,
Why expose the socket's file descriptor? I'm not sure how users would use that
information.
Including the PID seems unnecessary since it's already available via
log_line_prefix with %p?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
en PQbackendPID() returns 0, would it
make sense for postgres_fdw_get_connections() to just return the result
of PQbackendPID() as-is?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
/sgml/postgres-fdw.sgml,
which contains the explanation of postgres_fdw_get_connections().
Could you update that?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ELSE 'true' END
AS remote_conn_closed,
+CASE WHEN remote_backend_pid IS NOT NULL then 'available' ELSE 'not available'
END AS remote_backend_pid
Similarly, instead of checking if remote_backend_pid is NOT NULL,
how about verifying it against pg_stat_activity?
On 2025/02/20 15:27, Yuki Seino wrote:
On 2025/02/19 1:08, Fujii Masao wrote:
Just an idea, but how about updating ConditionalXactLockTableWait() to do the
followings?
- Use LockAcquireExtended() instead of LockAcquire() to retrieve the LOCALLOCK
value.
- Generate a log message about the
On 2025/02/19 2:06, Sagar Shedge wrote:
Hi Fujii,
On Tue, Feb 18, 2025 at 10:25 PM Fujii Masao
wrote:
I assume you're planning to extend postgres_fdw_get_connections() to
also return the result of PQbackendPID(entry->conn).
However, the patch you attached doesn't seem to
>conn).
However, the patch you attached doesn't seem to include that change.
Did you attach the wrong patch?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2025/02/18 18:33, Yuki Seino wrote:
On 2025/02/13 2:31, Jelte Fennema-Nio wrote:
On Wed, 12 Feb 2025 at 12:32, Fujii Masao wrote:
What do you think if we simply don't log anything for SKIP LOCKED?
Implementing both NOWAIT and SKIP LOCKED could take time and make the patch
more co
so there would be many places that need further implementation and refinement.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/src/interfaces/ecpg/preproc/Makefile
b/src/interfaces/ecpg/preproc/Makefile
i
or?
Should we revise the comment? or change the code so it can write that record?
If my analysis is correct, ISTM that the code should be updated to write
an FPW CHANGE record at the end of recovery.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
plementing both NOWAIT and SKIP LOCKED could take time and make the patch
more complex. I'm fine with focusing on the NOWAIT case first as an initial
patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
each backend can use for WAL compression?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ils. IMO failing quickly
seems preferable to getting stuck for a while in cases with concurrent
requests.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
lockmode);
The partition lock is unnecessary for DescribeLockTag() and GetLockmodeName().
It should only be acquired right before calling CollectLockHoldersAndWaiters()
and released immediately afterward.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
1 - 100 of 1274 matches
Mail list logo
