Hi
I've recently resumed work on this proposal.
I was revising tests that use the injection point, but given that there
was a recent talk at PGConf.EU about further features based on this
proposal [1], I thought it might be of interest to some. Therefore, I'll
share a patch that removes the i
On 2024-11-12 01:49, Fujii Masao wrote:
On 2024/11/11 21:45, torikoshia wrote:
Thanks for adding the comment. It clearly states that REJECT_LIMIT
can be
a single-quoted string. However, it might also be helpful to mention
that
it can be provided as an int64 in the COPY command option. How
On 2024-11-09 21:55, Kirill Reshke wrote:
Thanks for working on this!
On Thu, 7 Nov 2024 at 23:00, Fujii Masao
wrote:
On 2024/10/26 6:03, Kirill Reshke wrote:
> when the REJECT LIMIT is set to some non-zero number and the number of
> row NULL replacements exceeds the limit, is it OK to fai
On 2024-11-08 01:44, Fujii Masao wrote:
Thanks for your review!
On 2024/11/05 22:30, torikoshia wrote:
Thanks for the patch! Could you add it to the next CommitFest?
Added an entry for this patch:
https://commitfest.postgresql.org/50/5331/
Thanks!
+ALTER FOREIGN TABLE agg_bad OPTIONS
On 2024-11-12 14:17, Yugo Nagata wrote:
On Tue, 12 Nov 2024 14:03:50 +0900
Yugo Nagata wrote:
On Tue, 12 Nov 2024 01:27:53 +0500
Kirill Reshke wrote:
> On Mon, 11 Nov 2024 at 16:11, torikoshia wrote:
> >
> > On 2024-11-09 21:55, Kirill Reshke wrote:
> >
> >
On 2024-11-12 15:23, Kirill Reshke wrote:
Thanks for your review!
On Tue, 12 Nov 2024 at 06:17, torikoshia
wrote:
On 2024-11-12 01:49, Fujii Masao wrote:
> On 2024/11/11 21:45, torikoshia wrote:
>>> Thanks for adding the comment. It clearly states that REJECT_LIMIT
>>>
On 2024-11-12 14:51, Yugo Nagata wrote:
Thanks for your review!
On Tue, 12 Nov 2024 10:16:50 +0900
torikoshia wrote:
On 2024-11-12 01:49, Fujii Masao wrote:
> On 2024/11/11 21:45, torikoshia wrote:
>>> Thanks for adding the comment. It clearly states that REJECT_LIMIT
>
On 2024-09-20 11:27, Fujii Masao wrote:
Thanks for your comments!
On 2024/09/19 23:16, torikoshia wrote:
- COPY_LOG_VERBOSITY_DEFAULT = 0, /* logs no additional
messages, default */
- COPY_LOG_VERBOSITY_VERBOSE, /* logs additional messages */
+ COPY_LOG_VERBOSITY_SILENT
On 2024-09-25 00:46, Fujii Masao wrote:
Thanks for the comments!
On 2024/09/24 20:08, torikoshia wrote:
Thanks for the explanation and suggestion.
Since there is almost the same code in copyfrom.c, attached 0003 patch
for refactoring both.
Thanks for updating the patches!
Regarding 0002
On 2024-09-25 02:22, Fujii Masao wrote:
Thanks for your review!
Attached v5 patch.
On 2024/09/24 14:25, torikoshia wrote:
Updated the patch.
Thanks for updating the patch!
+REJECT_LIMIT { class="parameter">integer }
The curly braces {} seem unnecessary here.
+ Wh
On 2024-09-28 10:48, Jian he wrote:
Thanks for your comments!
+/*
+ * Extract REJECT_LIMIT value from a DefElem.
+ */
+static int64
+defGetCopyRejectLimitOptions(DefElem *def)
+{
+ int64 reject_limit;
+
+ if (def->arg == NULL)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("REJECT_
On 2024-09-11 23:50, Fujii Masao wrote:
Thanks for your comments!
Here are the review comments for 0001 patch.
+ silent excludes verbose messages.
This should clarify that in silent mode, not only verbose messages but
also
default ones are suppressed?
Agreed.
+ cstate-
Updated the patch.
On 2024-07-23 23:06, torikoshia wrote:
On Tue, Jul 23, 2024 at 1:35 PM Fujii Masao
wrote:
Thanks for your review.
On 2024/07/22 21:37, torikoshia wrote:
On Fri, Jul 19, 2024 at 11:48 PM Junwang Zhao
wrote:
Thanks for the comment.
In patch 0002, the ratio is
On 2024-10-03 18:03, Fujii Masao wrote:
On 2024/10/03 13:23, Masahiko Sawada wrote:
On Tue, Oct 1, 2024 at 11:34 PM Fujii Masao
wrote:
On 2024/10/02 9:27, Masahiko Sawada wrote:
Sorry for being late in joining the review of this patch. Both 0001
and 0003 look good to me. I have two comments
On 2024-11-13 23:17, Yugo NAGATA wrote:
On Wed, 13 Nov 2024 21:48:10 +0900
torikoshia wrote:
On 2024-11-12 14:51, Yugo Nagata wrote:
Thanks for your review!
> On Tue, 12 Nov 2024 10:16:50 +0900
> torikoshia wrote:
>
>> On 2024-11-12 01:49, Fujii Masao wrote:
>>
On 2024-11-13 22:02, Yugo NAGATA wrote:
On Tue, 12 Nov 2024 17:38:25 +0900
torikoshia wrote:
On 2024-11-12 14:17, Yugo Nagata wrote:
> On Tue, 12 Nov 2024 14:03:50 +0900
> Yugo Nagata wrote:
>
>> On Tue, 12 Nov 2024 01:27:53 +0500
>> Kirill Reshke wrote:
>>
>&g
On 2024-11-21 00:43, Fujii Masao wrote:
On 2024/11/19 21:40, torikoshia wrote:
These messages may be unexpected for some users because the
documentation of
fild_fdw does not explicitly describe that file_fdw uses COPY
internally.
(I can find several wordings like "as COPY", though
On 2024-12-25 00:52, Tom Lane wrote:
torikoshia writes:
I have attached a PoC patch that modifies EXPLAIN to include page
fault
information during both the planning and execution phases of a query.
Surely these numbers would be too unstable to be worth anything.
Thanks for your comment
On Tue, Dec 31, 2024 at 1:39 AM Tom Lane wrote:
Bruce Momjian writes:
I certainly would love to see storage I/O numbers as distinct from
kernel read I/O numbers.
Me too, but I think it is 100% wishful thinking to imagine that
page fault counts match up with that. Maybe there are filesyste
Hi,
When reading the output of EXPLAIN (ANALYZE) to diagnose slow queries
for our customers, I often want to know how many page faults occurred,
especially major page faults, which involve disk access.
Currently, the BUFFERS option in EXPLAIN provides information on whether
a page was found
Hi,
Rebased the patch since it couldn't be applied anymore.
--
Regards,
--
Atsushi Torikoshi
Seconded from NTT DATA GROUP CORPORATION to SRA OSS K.K.From 3f580c17214595eb8d6013674f5f054ec352ab7a Mon Sep 17 00:00:00 2001
From: Atsushi Torikoshi
Date: Mon, 3 Feb 2025 21:22:40 +0900
Subject: [PAT
Hi,
When a hot standby is restarted in a state where subtransactions have
overflowed, it may become inaccessible:
$ psql: error: connection to server at "localhost" (::1), port 5433
failed: FATAL: the database system is not yet accepting connections
DETAIL: Consistent recovery
On 2025-02-03 21:47, Rahila Syed wrote:
Hi,
Just idea; as an another option, how about blocking new
requests to
the target process (e.g., causing them to fail with an error
or
returning NULL with a warning) if a previous request is still
pending?
Users can simply retry the request if it
On 2025-02-10 05:06, Jelte Fennema-Nio wrote:
Thanks for reviewing the patch and comments!
Fixed issues you pointed out and attached v2 patch.
On Sun, 9 Feb 2025 at 19:05, Tom Lane wrote:
Andres Freund writes:
> I'm somewhat against this patch, as it's fairly fundamentally incompatible
> wi
Hi,
Thanks for updating the patch and here are some comments:
'path' column of pg_get_process_memory_contexts() begins with 0, but
that column of pg_backend_memory_contexts view begins with 1:
=# select path FROM pg_get_process_memory_contexts('20271', false);
path
---
{0}
{0,
Hi,
On Tue, Jan 7, 2025 at 5:09 AM Jelte Fennema-Nio
wrote:
The core functionality works well in my opinion. I think it makes sense
to spend the effort to move this from PoC quality to something
committable. Below some of the things that are necessary to do that
after an initial pass over the
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 been yet
reached.")));
+
Hi,
Rebased it again.
On 2025-03-10 14:10, torikoshia wrote:
BTW the patch adds about 400 lines to explain.c and it may be better
to split the file as well as 9173e8b6046, but I leave it as it is for
now.
This part remains unchanged.
--
Regards,
--
Atsushi Torikoshi
Seconded from NTT DATA
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 people may not understand what needs to be done to
On 2025-03-22 20:23, Jelte Fennema-Nio wrote:
On Wed, 19 Mar 2025 at 14:15, torikoshia
wrote:
BTW based on your discussion, I thought this patch could not be merged
anytime soon. Does that align with your understanding?
Yeah, that aligns with my understanding. I don't think it's
On 2025-04-02 03:52, Robert Haas wrote:
Thank you for review!
On Fri, Mar 21, 2025 at 8:40 AM torikoshia
wrote:
Rebased it again.
On 2025-03-10 14:10, torikoshia wrote:
> BTW the patch adds about 400 lines to explain.c and it may be better
> to split the file as well as 9173e8b6046,
On 2025-03-31 12:51, Fujii Masao wrote:
I had the same thought during our off-list discussion. However,
after reviewing the recovery code - such as recoveryStopsBefore(),
which checks whether a consistent state is reached - I now believe
the manual’s definition of a consistent state may be incorr
On 2025-04-01 01:12, Fujii Masao wrote:
On 2025/03/31 22:45, Yugo Nagata wrote:
I prefer this approach clarifying that consistency and subtransaction
overflow
are separate concepts in the documentation.
Here are minor comments on the patch:
Thanks for the review!
- case CAC_NOTC
Hi,
I had another off-list discussion with Fujii-san, and according to the
following manual[1], it seems that a transaction with an overflowed
subtransaction is already considered inconsistent:
Reaching a consistent state can also be delayed in the presence of
both of these conditions:
On 2025-03-27 11:06, torikoshia wrote:
Hi,
I had another off-list discussion with Fujii-san, and according to the
following manual[1], it seems that a transaction with an overflowed
subtransaction is already considered inconsistent:
Reaching a consistent state can also be delayed in the
On 2025-04-01 21:32, Robert Haas wrote:
Thanks for your comment.
On Mon, Mar 31, 2025 at 9:43 PM torikoshia
wrote:
Previously, Rafael proposed a patch in this thread that added
execution
progress tracking. However, I felt that expanding the scope could make
it harder to get the patch
On 2025-04-01 04:24, Robert Haas wrote:
On Fri, Mar 21, 2025 at 8:40 AM torikoshia
wrote:
Rebased it again.
Hi,
I apologize for not having noticed this thread sooner.
Thank you for your checking! No worries.
I just became
aware of it as a result of a discussion in the hacking Discord
On 2025-04-01 15:23, Rafael Thofehrn Castro wrote:
Hello again,
ERROR: could not attach to dynamic shared area
In addition to that refactoring issue, the current patch had a race
condition in pg_stat_progress_explain to access the DSA of a process
running a query that gets aborted.
While di
On 2025-03-25 10:27, torikoshia wrote:
On 2025-03-22 20:23, Jelte Fennema-Nio wrote:
On Wed, 19 Mar 2025 at 14:15, torikoshia
wrote:
BTW based on your discussion, I thought this patch could not be
merged
anytime soon. Does that align with your understanding?
Yeah, that aligns with my
Hi,
With commit 32d3ed81, pg_backend_memory_contexts view will start
numbering memory context levels from 1 instead of 0 in PostgreSQL 18.
For example:
=# select name, level from pg_backend_memory_contexts;
name | level
+---
TopM
Thanks for your review, Melih and Rahila.
On 2025-04-17 21:25, Rahila Syed wrote:
Hi,
The attached patch is how I think we should do it.
Thank you for the patch.
I tested this patch and it works fine. I agree with the changes made
in it.
Regarding v2 patch,
- int
Hi,
Attached a rebased version of the patch.
--
Regards,
--
Atsushi Torikoshi
Seconded from NTT DATA GROUP CORPORATION to SRA OSS K.K.From 112467238f585bb3398d86ac6e1a71caa6549fb4 Mon Sep 17 00:00:00 2001
From: Atsushi Torikoshi
Date: Thu, 24 Apr 2025 20:50:41 +0900
Subject: [PATCH v44] Add fu
Hi,
On 2025-04-28 08:55, Hannu Krosing wrote:
Have you also checked out
https://github.com/postgrespro/pg_query_state which logs running query
plan AND collected counts and timings as a response to a signal?
Yes. For example, see the discussion:
https://www.postgresql.org/message-id/d68c3ae316
On 2025-04-16 06:18, Daniel Gustafsson wrote:
On 15 Apr 2025, at 23:03, David Rowley wrote:
My vote is to make the levels 1-based in all locations where we output
the context information.
I agree with this, pg_get_process_memory_contexts() also use 1-based
levels
fwiw.
+1.
I believe the
On 2025-04-17 07:31, David Rowley wrote:
On Thu, 17 Apr 2025 at 02:20, torikoshia
wrote:
Regarding the implementation:
In the initial patch attached, I naïvely incremented the level just
before emitting the log line.
However, it might be cleaner to simply initialize the level variable
to
1
On 2025-05-02 09:02, Fujii Masao wrote:
On 2025/05/02 2:27, Fujii Masao wrote:
On 2025/05/01 21:42, Robert Haas wrote:
On Thu, May 1, 2025 at 3:53 AM Fujii Masao
wrote:
Just idea, what do you think about adding a flag to indicate whether
ProcessLogMemoryContextInterrupt() is currently runni
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 to server at "localhost" (::1),
On 2025-03-04 03:17, Fujii Masao wrote:
Agreed and I feel that a message suggesting something like "check if
there are any overflowing transactions on the primary side" would make
it useful.
I’m wondering if this message might still be confusing for users.
Would they immediately understand wh
On 2025-03-09 00:42, Akshat Jaimini wrote:
Hi,
I think there is still some problem with the patch. I am not able to
apply it to the master branch.
Can you please take another look at it?
Thanks for pointing it out!
Modified it.
BTW the patch adds about 400 lines to explain.c and it may be bet
Hi,
After an off-list discussion with Fujii-san, I'm now trying to modify
the following message that is output when a client attempts to connect
instead of changing the log level as the original proposal:
$ psql: error: connection to server at "localhost" (::1), port 5433
failed: FATAL: t
On 2025-04-03 01:22, Sami Imseih wrote:
> FWIW, I have been thinking about auto_explain for another task,
> remote plans for fdw [0], and perhaps there are now other good
> reasons, some that you mention, that can be simplified if "auto_explain"
> becomes a core feature. This could be a proposal
On 2025-04-01 03:51, Sadeq Dousti wrote:
Hi,
Sergey and I reviewed this patch and have a few comments, listed
below.
Thanks for your review!
BTW the patch adds about 400 lines to explain.c and it may be better
to split the file as well as 9173e8b6046, but I leave it as it is
for
now.
1. A
On Fri, Mar 7, 2025 at 6:43 AM Rafael Thofehrn Castro
wrote:
The wrapper code was implemented by torikoshia
(torikoshia(at)oss(dot)nttdata(dot)com),
so adding the credits here.
On Thu, Mar 20, 2025 at 5:35 AM Robert Haas
wrote:
Without having the prior discussion near to hand, I *think
Hi,
On 2025-03-18 08:52, Jelte Fennema-Nio wrote:
On Mon, 10 Feb 2025 at 14:23, torikoshia
wrote:
Thanks for reviewing the patch and comments!
Fixed issues you pointed out and attached v2 patch.
This patch needs a rebase, because it's failing to compile currently.
So I marked th
On 2025-04-02 15:21, Fujii Masao wrote:
On 2025/04/01 20:54, torikoshia wrote:
Thank you for updating the patch!
LGTM.
I've pushed the patch. Thanks!
Thanks a lot!
I feel like changing the status to 'Ready for Committer', but since
Nagata-san may have additional comments,
Thanks for your comments!
On 2025-05-08 08:53, Yugo Nagata wrote:
On Wed, 7 May 2025 14:36:35 -0700
Masahiko Sawada wrote:
On Wed, May 7, 2025 at 6:23 AM Yugo Nagata
wrote:
>
> On Wed, 7 May 2025 15:39:26 +0900
> torikoshia wrote:
>
> > Hi,
> >
> > I notice
On 2025-04-11 22:18, torikoshia wrote:
On 2025-03-25 10:27, torikoshia wrote:
On 2025-03-22 20:23, Jelte Fennema-Nio wrote:
On Wed, 19 Mar 2025 at 14:15, torikoshia
wrote:
BTW based on your discussion, I thought this patch could not be
merged
anytime soon. Does that align with your
Hi,
I noticed that REJECT_LIMIT, an option available for COPY FROM, is not
currently supported in psql's tab completion.
Additionally, some options are only valid for COPY FROM or COPY TO, i.e.
FREEZE, ON_ERROR, FORCE_QUOTE, but psql currently suggests them for both
COPY FROM and COPY TO.
As
On Sat, Apr 5, 2025 at 3:14 PM Atsushi Torikoshi
wrote:
On Thu, Apr 3, 2025 at 11:10 PM Robert Haas
wrote:
Do we really need ExecProcNodeOriginal? Can we find some way to reuse
ExecProcNodeReal instead of making the structure bigger?
I also wanted to implement this without adding elements to
Hi,
I've noticed a minor inconsistency in the output of pg_aios.
According to the documentation, the values for 'operation' are described
as:
readv, a vectored read
...
writev, a vectored write
However, in actual output, they appear as read and write -- without the
trailing v:
=#
On 2025-06-03 17:58, Yugo Nagata wrote:
Thank you for updating the patch.
It looks good and I confirmed that this works as expected.
Thanks for your review!
BTW this is a small patch, but it does two things:
(1) adds tab completion support for the REJECT_LIMIT option, which was
introduced in
On 2025-06-05 09:45, jian he wrote:
hi.
In the V10 patch, there will be some regression if the partition column
ordering is different from the root partitioned table.
because in V10 CopyThisRelTo
+ while (table_scan_getnextslot(scandesc, ForwardScanDirection, slot))
+ {
+ if (map != NULL)
+ {
+
On 2025-04-30 09:00, jian he wrote:
hi.
Currently, (on_error ignore) only handles data type incompatibility
errors.
However, we can extend its functionality to also handle errors caused
by extra
data (additional columns) or missing data (fewer columns), I think.
on_error is only applicable t
On 2025-05-23 17:50, Atsushi Torikoshi wrote:
Thanks for the idea and the sample patch!
Agreed. I’ll go ahead and implement a new patch based on this approach.
Updated the patch.
Here are some notes:
As with the previous patches, this one wraps not only the currently
executing plan node but
On 2025-07-02 13:10, jian he wrote:
Thanks for updating the patch.
now it is:
/*
* Scan a single table (which may be a partition) and export its rows
to the
* COPY destination.
Based on the explanations in the glossary, should 'parition' be
partitioned table/relation?
| -- https://www.
On 2025-07-03 11:37, Masahiko Sawada wrote:
On Wed, Jul 2, 2025 at 2:46 PM torikoshia
wrote:
On 2025-07-01 14:20, Masahiko Sawada wrote:
> On Thu, Jun 12, 2025 at 3:47 AM Masahiko Sawada
> wrote:
>>
>> On Tue, Jun 10, 2025 at 1:33 PM Nathan Bossart
>> wrote:
>&g
On 2025-06-27 16:14, jian he wrote:
Thanks for updating the patch!
On Thu, Jun 26, 2025 at 9:43 AM torikoshia
wrote:
After applying the patch, blank lines exist between these statements
as
below. Do we really need these blank lines?
```
scan_rel = table_open
Hi,
Thanks for updating the patch and I've read
v17-0001-COPY-on_error-set_null.patch and here are some comments.
+COPY x from stdin (on_error set_null, reject_limit 2);
+ERROR: COPY REJECT_LIMIT requires ON_ERROR to be set to IGNORE
I understand that REJECT_LIMIT is out of scope for this
On 2025-07-01 14:20, Masahiko Sawada wrote:
On Thu, Jun 12, 2025 at 3:47 AM Masahiko Sawada
wrote:
On Tue, Jun 10, 2025 at 1:33 PM Nathan Bossart
wrote:
>
> On Tue, Jun 10, 2025 at 12:37:48PM -0700, Masahiko Sawada wrote:
> >> > (1) adds tab completion support for the REJECT_LIMIT option, w
On 2025-07-15 12:31, jian he wrote:
On Mon, Jul 14, 2025 at 10:02 PM Álvaro Herrera
wrote:
On 2025-Jul-02, jian he wrote:
> @@ -673,11 +680,34 @@ BeginCopyTo(ParseState *pstate,
>errmsg("cannot copy from sequence
\"%s\"",
>
On 2025-07-26 00:26, Hironobu SUZUKI wrote:
Thanks for the proposal!
Hi,
Even when using EXPLAIN ANALYZE with TIMING=FALSE, the functions
InstrStopNode(), InstrEndLoop(), and InstrAggNode() in Instrument.c
still execute code related to the "starttime", "counter",
"firsttuple", "startup", and "
301 - 371 of 371 matches
Mail list logo
