On 2022-02-08 01:13, Fujii Masao wrote:
AbortSubTransaction() should reset ActiveQueryDesc to
save_ActiveQueryDesc that ExecutorRun() set, instead of NULL?
Otherwise ActiveQueryDesc of top-level statement will be unavailable
after subtransaction is aborted in the nested statements.
I once agree
On 2020-12-04 14:29, Fujii Masao wrote:
On 2020/11/30 15:24, Tatsuro Yamada wrote:
Hi Torikoshi-san,
In this patch, exposing new columns is mandatory, but I think
it's better to make it optional by adding a GUC something
like 'pgss.track_general_custom_plans.
I also feel it makes the number
On 2020-12-03 10:36, Tom Lane wrote:
Fujii Masao writes:
I'm starting to study how this feature behaves. At first, when I
executed
the following query, the function never returned. ISTM that since
the autovacuum launcher cannot respond to the request of memory
contexts dump, the function keeps
On 2020-12-04 19:16, torikoshia wrote:
On 2020-12-03 10:36, Tom Lane wrote:
Fujii Masao writes:
I'm starting to study how this feature behaves. At first, when I
executed
the following query, the function never returned. ISTM that since
the autovacuum launcher cannot respond to the reque
Hi,
When examining the duration of locks, we often do join on pg_locks
and pg_stat_activity and use columns such as query_start or
state_change.
However, since these columns are the moment when queries have
started or their state has changed, we cannot get the exact lock
duration in this way.
S
On Fri, Dec 25, 2020 at 6:08 PM Kasahara Tatsuhito
wrote:
Thanks for reviewing and kind suggestion!
Attached a rewritten patch.
Thanks for updating patch.
But when I had applyed the patch to the current HEAD and did make, I
got an error due to duplicate OIDs.
You need to rebase the patch.
On 2021-01-02 06:49, Justin Pryzby wrote:
On Tue, Dec 15, 2020 at 11:47:23AM +0900, torikoshia wrote:
So I'm now thinking about adding a new column in pg_locks which
keeps the time at which locks started waiting.
Attached a patch.
This is failing make check-world, would you send an up
On 2021-02-16 16:59, Fujii Masao wrote:
On 2021/02/15 15:17, Fujii Masao wrote:
On 2021/02/10 10:43, Fujii Masao wrote:
On 2021/02/09 23:31, torikoshia wrote:
On 2021-02-09 22:54, Fujii Masao wrote:
On 2021/02/09 19:11, Fujii Masao wrote:
On 2021/02/09 18:13, Fujii Masao wrote:
On
Hi,
I also think this feature would be useful when supporting
environments that lack debugger or debug symbols.
I think such environments are not rare.
+ for more information.
This
+will help in identifying where exactly the backend process is
currently
+executing.
W
On 2021-01-14 19:11, torikoshia wrote:
Since pg_get_target_backend_memory_contexts() waits to dump memory and
it could lead dead lock as below.
- session1
BEGIN; TRUNCATE t;
- session2
BEGIN; TRUNCATE t; -- wait
- session1
SELECT * FROM pg_get_target_backend_memory_contexts
On 2021-03-04 21:55, Bharath Rupireddy wrote:
On Mon, Mar 1, 2021 at 10:43 AM torikoshia
wrote:
Since the current patch use BackendPidGetProc(), it does not
support this feature not only postmaster, logging, and
statistics but also checkpointer, background writer, and
walwriter.
And when I
On 2021-03-07 19:16, Bharath Rupireddy wrote:
On Fri, Feb 5, 2021 at 5:15 PM Bharath Rupireddy
wrote:
pg_terminate_backend and pg_cancel_backend with postmaster PID produce
"PID is not a PostgresSQL server process" warning [1], which
basically implies that the postmaster is not a PostgreS
ually do as the follows and it's
the way of git.
v1-0001-Enabled...collect.patch
v2-0001-Enabled...collect.patch
The vn is added by -v option for git-format-patch.
Sorry for the confusion. I'll follow that way next time.
At Thu, 22 Oct 2020 21:32:00 +0900, torikoshia
wrote in
>
On 2020-09-29 02:39, legrand legrand wrote:
Hi Atsushi,
+1: Your proposal is a good answer for time based performance analysis
(even if parsing durationor blks are not differentiated) .
As it makes pgss number of columns wilder, may be an other solution
would be to create a pg_stat_statements_x
On 2020-10-28 15:32, torikoshia wrote:
On 2020-10-23 13:46, Kyotaro Horiguchi wrote:
I think we might need to step-back to basic design of this feature
since this patch seems to have unhandled corner cases that are
difficult to find.
I've written out the basic design below and att
On 2020-11-12 14:23, Pavel Stehule wrote:
yes, the plan self is very interesting information - and information
if plan was generic or not is interesting too. It is other dimension
of query - maybe there can be rule - for any query store max 100 most
slows plans with all attributes. The next issu
Hi,
Currently, EXPLAIN is the only way to know whether the plan is generic
or custom according to the manual of PREPARE.
https://www.postgresql.org/docs/devel/sql-prepare.html
After commit d05b172, we can also use pg_prepared_statements view to
examine the plan types.
How about adding t
Hi,
AFAIU, when the planner statistics are updated, generic plans are
invalidated and PostgreSQL recreates. However, the manual doesn't seem
to explain it explicitly.
https://www.postgresql.org/docs/devel/sql-prepare.html
I guess this case is included in 'whenever database objects used in
On 2020-11-18 11:35, Fujii Masao wrote:
Thanks for your comment!
On 2020/11/18 11:04, torikoshia wrote:
Hi,
AFAIU, when the planner statistics are updated, generic plans are
invalidated and PostgreSQL recreates. However, the manual doesn't seem
to explain it explicitly.
On 2020-11-18 11:04, torikoshia wrote:
Hi,
Currently, EXPLAIN is the only way to know whether the plan is generic
or custom according to the manual of PREPARE.
https://www.postgresql.org/docs/devel/sql-prepare.html
After commit d05b172, we can also use pg_prepared_statements view to
On 2020-11-25 14:13, Fujii Masao wrote:
On 2020/11/24 23:14, Fujii Masao wrote:
On 2020/11/19 14:33, torikoshia wrote:
On 2020-11-18 11:35, Fujii Masao wrote:
Thanks for your comment!
On 2020/11/18 11:04, torikoshia wrote:
Hi,
AFAIU, when the planner statistics are updated, generic
wrote in
ISTM now that creating pg_stat_statements_xxx views
both for generic andcustom plans is better than my PoC patch.
On my second thought, it also makes pg_stat_statements too complicated
compared to what it makes possible..
I'm also worrying that whether taking generic and custom pla
v7 that fixes recent conflicts.
It also changed the behavior of requestor when another requestor is
already working for simplicity.
In this case, v6 patch makes the requestor wait. v7 patch makes the
requestor quit.
Regards,
--
Atsushi TorikoshiFrom f20e48d99f2770bfec275805185aa5ce08661fce Mon
Since pg_get_target_backend_memory_contexts() waits to dump memory and
it could lead dead lock as below.
- session1
BEGIN; TRUNCATE t;
- session2
BEGIN; TRUNCATE t; -- wait
- session1
SELECT * FROM pg_get_target_backend_memory_contexts(2>); --wait
Thanks for notifying me, Fujii-s
Thanks for your reviewing and comments!
On 2021-01-14 12:39, Ian Lawrence Barwick wrote:
Looking at the code, this happens as the wait start time is being
recorded in
the lock record itself, so always contains the value reported by the
latest lock
acquisition attempt.
I think you are right a
On 2021-01-15 15:23, torikoshia wrote:
Thanks for your reviewing and comments!
On 2021-01-14 12:39, Ian Lawrence Barwick wrote:
Looking at the code, this happens as the wait start time is being
recorded in
the lock record itself, so always contains the value reported by the
latest lock
Hi,
When I created a table consisting of 400 VARCHAR columns and tried
to INSERT a record which rows were all the same size, there were
cases where I got an error due to exceeding the size limit per
row.
=# -- create a table consisting of 400 VARCHAR columns
=# CREATE TABLE t1 (c1 VARCHAR(10
On 2021-01-19 19:32, Amit Kapila wrote:
On Mon, Jan 18, 2021 at 7:53 PM torikoshia
Because no benefit is to be expected by compressing it. The size will
be mostly the same. Also, even if we somehow try to fit this data via
toast, I think reading speed will be slower because for all such
columns
On 2021-01-21 12:48, Fujii Masao wrote:
Thanks for updating the patch! I think that this is really useful
feature!!
Thanks for reviewing!
I have two minor comments.
+ role="column_definition">
+ wait_start timestamptz
The column name "wait_start" should be "waitstart" for the s
On 2021-01-25 23:44, Fujii Masao wrote:
Another comment is; Doesn't the change of MyProc->waitStart need the
lock table's partition lock? If yes, we can do that by moving
LWLockRelease(partitionLock) just after the change of
MyProc->waitStart, but which causes the time that lwlock is being held
t
Chengxi Sun, Yamada-san, Horiguchi-san,
Thanks for all your comments.
Adding only the number of generic plan execution seems acceptable.
On Mon, Jan 25, 2021 at 2:10 PM Kyotaro Horiguchi
wrote:
Note that ActivePortal is the closest nested portal. So it gives the
wrong result for nested portal
On 2021-02-03 11:23, Fujii Masao wrote:
64-bit fetches are not atomic on some platforms. So spinlock is
necessary when updating "waitStart" without holding the partition
lock? Also GetLockStatusData() needs spinlock when reading
"waitStart"?
Also it might be worth thinking to use 64-bit atomi
On 2021-02-04 11:19, Kyotaro Horiguchi wrote:
At Thu, 04 Feb 2021 10:16:47 +0900, torikoshia
wrote in
Chengxi Sun, Yamada-san, Horiguchi-san,
Thanks for all your comments.
Adding only the number of generic plan execution seems acceptable.
On Mon, Jan 25, 2021 at 2:10 PM Kyotaro Horiguchi
On 2021-02-05 18:49, Fujii Masao wrote:
On 2021/02/05 0:03, torikoshia wrote:
On 2021-02-03 11:23, Fujii Masao wrote:
64-bit fetches are not atomic on some platforms. So spinlock is
necessary when updating "waitStart" without holding the partition
lock? Also GetLockStatusData() need
On 2021-02-09 22:54, Fujii Masao wrote:
On 2021/02/09 19:11, Fujii Masao wrote:
On 2021/02/09 18:13, Fujii Masao wrote:
On 2021/02/09 17:48, torikoshia wrote:
On 2021-02-05 18:49, Fujii Masao wrote:
On 2021/02/05 0:03, torikoshia wrote:
On 2021-02-03 11:23, Fujii Masao wrote:
64-bit
On 2021-11-26 12:39, torikoshia wrote:
Since the patch could not be applied to the HEAD anymore, I also
updated it.
Updated the patch for fixing compiler warning about the format on
windows.
--
Regards,
--
Atsushi Torikoshi
NTT DATA CORPORATIONFrom b8367e22d7a9898e4b85627ba8c203be273fc22f
On 2022-01-07 14:30, torikoshia wrote:
Updated the patch for fixing compiler warning about the format on
windows.
I got another compiler warning, updated the patch again.
--
Regards,
--
Atsushi Torikoshi
NTT DATA CORPORATIONFrom b8367e22d7a9898e4b85627ba8c203be273fc22f Mon Sep 17 00:00:00
On 2021-03-16 20:51, Bharath Rupireddy wrote:
On Mon, Mar 15, 2021 at 11:23 AM torikoshia
wrote:
On 2021-03-07 19:16, Bharath Rupireddy wrote:
> On Fri, Feb 5, 2021 at 5:15 PM Bharath Rupireddy
> wrote:
>>
>> pg_terminate_backend and pg_cancel_backend with postmaster PID pr
On 2021-03-05 14:22, Fujii Masao wrote:
On 2021/03/04 18:32, torikoshia wrote:
On 2021-01-14 19:11, torikoshia wrote:
Since pg_get_target_backend_memory_contexts() waits to dump memory
and
it could lead dead lock as below.
- session1
BEGIN; TRUNCATE t;
- session2
BEGIN; TRUNCATE t
On 2021-03-18 15:09, Fujii Masao wrote:
Thanks for your comments!
On 2021/03/17 22:24, torikoshia wrote:
I remade the patch and introduced a function
pg_print_backend_memory_contexts(PID) which prints the memory contexts
of
the specified PID to elog.
Thanks for the patch!
=# SELECT
On 2021-03-05 17:47, Fujii Masao wrote:
Thanks for your comments!
I just tried this feature. When I set plan_cache_mode to
force_generic_plan
and executed the following queries, I found that
pg_stat_statements.generic_calls
and pg_prepared_statements.generic_plans were not the same.
Is this be
On 2021-03-23 17:24, Kyotaro Horiguchi wrote:
Thanks for reviewing and suggestions!
At Mon, 22 Mar 2021 15:09:58 +0900, torikoshia
wrote in
>> If MemoryContextStatsPrint(), i.e. showing 100 children at most is
>> enough, this hard limit may be acceptable.
> Can't this
On 2021-03-25 22:02, Fujii Masao wrote:
On 2021/03/25 0:17, torikoshia wrote:
On 2021-03-23 17:24, Kyotaro Horiguchi wrote:
Thanks for reviewing and suggestions!
The patched version failed to be compiled as follows. Could you fix
this issue?
Sorry, it included a header file that'
On 2021-03-25 22:14, Fujii Masao wrote:
On 2021/03/23 16:32, torikoshia wrote:
On 2021-03-05 17:47, Fujii Masao wrote:
Thanks for your comments!
Thanks for updating the patch!
PostgreSQL Patch Tester reported that the patched version failed to be
compiled
at Windows. Could you fix this
On 2021-03-26 14:08, Kyotaro Horiguchi wrote:
At Fri, 26 Mar 2021 14:02:49 +0900, Fujii Masao
wrote in
On 2021/03/26 13:28, Kyotaro Horiguchi wrote:
>> "some contexts are omitted"
>> "n child contexts: total_bytes = ..."
> Sorry I missed that is already implemented. So my opnion is I agree
>
On 2021-03-30 02:28, Fujii Masao wrote:
Thanks for reviewing and kind suggestions!
It adds pg_log_backend_memory_contexts(pid) which logs memory contexts
of the specified backend process.
The number of child contexts to be logged per parent is limited to 100
as with MemoryContextStats().
As w
On 2021-03-31 04:36, Fujii Masao wrote:
On 2021/03/30 22:06, torikoshia wrote:
Modified the patch according to the suggestions.
Thanks for updating the patch!
I applied the cosmetic changes to the patch and added the example of
the function call into the document. Attached is the updated
On 2021-04-01 19:13, Fujii Masao wrote:
On 2021/03/31 15:16, Kyotaro Horiguchi wrote:
+ The memory contexts will be logged based on the log configuration
set. For example:
How do you think?
How about "The memory contexts will be logged in the server log" ?
I think "server log" doesn't suggest
On 2021-03-26 17:46, Fujii Masao wrote:
On 2021/03/26 0:33, torikoshia wrote:
On 2021-03-25 22:14, Fujii Masao wrote:
On 2021/03/23 16:32, torikoshia wrote:
On 2021-03-05 17:47, Fujii Masao wrote:
Thanks for your comments!
Thanks for updating the patch!
PostgreSQL Patch Tester reported
On 2021-04-05 12:59, Fujii Masao wrote:
On 2021/04/05 12:20, Zhihong Yu wrote:
Thanks for reviewing!
+ * On receipt of this signal, a backend sets the flag in the signal
+ * handler, and then which causes the next CHECK_FOR_INTERRUPTS()
I think the 'and then' is not needed:
Although I wo
On 2021-04-06 00:08, Fujii Masao wrote:
On 2021/04/05 21:03, torikoshia wrote:
On 2021-04-05 12:59, Fujii Masao wrote:
On 2021/04/05 12:20, Zhihong Yu wrote:
Thanks for reviewing!
+ * On receipt of this signal, a backend sets the flag in the signal
+ * handler, and then which causes the
On 2020-07-20 13:57, torikoshia wrote:
As I proposed earlier in this thread, I'm now trying to add information
about generic/cudstom plan to pg_stat_statements.
I'll share the idea and the poc patch soon.
Attached a poc patch.
Main purpose is to decide (1) the user interface and (
On 2020-07-14 20:24, Julien Rouhaud wrote:
On Tue, Jul 14, 2020 at 07:11:02PM +0900, Atsushi Torikoshi wrote:
Hi,
v9 patch fails to apply to HEAD, could you check and rebase it?
Thanks for the notice, v10 attached!
And here are minor typos.
79 +* utility statements. Note that we
On 2020-07-30 15:13, Kasahara Tatsuhito wrote:
Hi,
On Fri, Jul 10, 2020 at 5:32 PM torikoshia
wrote:
- whether information for identifying parent-child relation is
necessary
or it's an overkill
I think it's important to understand the parent-child relationship of
the context.
Per
On 2020-07-30 14:31, Fujii Masao wrote:
On 2020/07/22 16:49, torikoshia wrote:
On 2020-07-20 13:57, torikoshia wrote:
As I proposed earlier in this thread, I'm now trying to add
information
about generic/cudstom plan to pg_stat_statements.
I'll share the idea and the poc
On 2020-08-08 10:44, Michael Paquier wrote:
On Fri, Jul 31, 2020 at 03:23:52PM -0400, Robert Haas wrote:
On Fri, Jul 31, 2020 at 4:25 AM torikoshia
wrote:
And as Fujii-san told me in person, exposing memory address seems
not preferable considering there are security techniques like
address
On 2020-08-17 21:19, Fujii Masao wrote:
On 2020/08/17 21:14, Fujii Masao wrote:
On 2020-08-07 16:38, Kasahara Tatsuhito wrote:
The following review has been posted through the commitfest
application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec complia
On 2020-08-18 22:54, Fujii Masao wrote:
On 2020/08/18 18:41, torikoshia wrote:
On 2020-08-17 21:19, Fujii Masao wrote:
On 2020/08/17 21:14, Fujii Masao wrote:
On 2020-08-07 16:38, Kasahara Tatsuhito wrote:
The following review has been posted through the commitfest
application:
make
On 2020-08-19 15:48, Fujii Masao wrote:
On 2020/08/19 9:43, torikoshia wrote:
On 2020-08-18 22:54, Fujii Masao wrote:
On 2020/08/18 18:41, torikoshia wrote:
On 2020-08-17 21:19, Fujii Masao wrote:
On 2020/08/17 21:14, Fujii Masao wrote:
On 2020-08-07 16:38, Kasahara Tatsuhito wrote:
The
Thanks for all your comments!
Thankfully it seems that this feature is regarded as not
meaningless one, I'm going to do some improvements.
On Wed, Aug 19, 2020 at 10:56 PM Michael Paquier
wrote:
On Wed, Aug 19, 2020 at 06:12:02PM +0900, Fujii Masao wrote:
On 2020/08/19 17:40, torik
On 2020-08-22 21:18, Michael Paquier wrote:
Thanks for reviewing!
On Fri, Aug 21, 2020 at 11:27:06PM +0900, torikoshia wrote:
OK. Added a regression test on sysviews.sql.
(0001-Added-a-regression-test-for-pg_backend_memory_contex.patch)
Fujii-san gave us an example, but I added more simple
On 2020-08-24 13:13, Fujii Masao wrote:
On 2020/08/24 13:01, torikoshia wrote:
On 2020-08-22 21:18, Michael Paquier wrote:
Thanks for reviewing!
On Fri, Aug 21, 2020 at 11:27:06PM +0900, torikoshia wrote:
OK. Added a regression test on sysviews.sql.
(0001-Added-a-regression-test-for
Hi,
After commit 3e98c0bafb28de, we can display the usage of the
memory contexts using pg_backend_memory_contexts system
view.
However, its target is limited to the process attached to
the current session.
As discussed in the thread[1], it'll be useful to make it
possible to get the memory con
On 2020-09-01 03:29, Pavel Stehule wrote:
Hi
po 31. 8. 2020 v 17:03 odesílatel Kasahara Tatsuhito
napsal:
Hi,
On Mon, Aug 31, 2020 at 8:22 PM torikoshia
wrote:
As discussed in the thread[1], it'll be useful to make it
possible to get the memory contexts of an arbitrary backend
pr
Thanks for reviewing!
I'm going to modify the patch according to your comments.
On 2020-09-01 10:54, Andres Freund wrote:
Hi,
On 2020-08-31 20:22:18 +0900, torikoshia wrote:
After commit 3e98c0bafb28de, we can display the usage of the
memory contexts using pg_backend_memory_contexts s
On 2020-09-04 21:46, Tomas Vondra wrote:
On Fri, Sep 04, 2020 at 11:47:30AM +0900, Kasahara Tatsuhito wrote:
On Fri, Sep 4, 2020 at 2:40 AM Tom Lane wrote:
Kasahara Tatsuhito writes:
> Yes, but it's not only for future expansion, but also for the
> usability and the stability of this feature.
On 2021-10-13 23:28, Ekaterina Sokolova wrote:
Hi, hackers!
• The last version of patch is correct applied. It changes 8 files
from /src/backend, and 9 other files.
• I have 1 error and 1 warning during compilation on Mac.
explain.c:4985:25: error: implicit declaration of function
'GetLockMeth
On 2021-10-15 15:17, torikoshia wrote:
I only took a quick look at pg_query_state, I have some questions.
pg_query_state seems using shm_mq to expose the plan information, but
there was a discussion that this kind of architecture would be tricky
to do properly [1].
Does pg_query_state handle
On 2021-11-02 20:32, Ekaterina Sokolova wrote:
Thanks for your response!
Hi!
I'm here to answer your questions about contrib/pg_query_state.
I only took a quick look at pg_query_state, I have some questions.
pg_query_state seems using shm_mq to expose the plan information, but
there was a d
On 2021-11-13 22:29, Bharath Rupireddy wrote:
Thanks for your review!
On Wed, Oct 13, 2021 at 7:58 PM Ekaterina Sokolova
wrote:
Thank you for working on this issue. I would be glad to continue to
follow the development of this issue.
Thanks for the patch. I'm not sure if v11 is the latest pa
On 2021-11-13 03:37, Justin Pryzby wrote:
I reviewed this version of the patch - I have some language fixes.
Thanks for your review!
Attached patch that reflects your comments.
Regards,
--
Atsushi Torikoshi
NTT DATA CORPORATIONFrom b8367e22d7a9898e4b85627ba8c203be273fc22f Mon Sep 17 00:00:0
On 2021-11-15 23:15, Bharath Rupireddy wrote:
I have another comment: isn't it a good idea that an overloaded
version of the new function pg_log_query_plan can take the available
explain command options as a text argument? I'm not sure if it is
possible to get the stats like buffers, costs etc o
On 2021-11-17 22:44, Ekaterina Sokolova wrote:
Hi!
You forgot my last fix to build correctly on Mac. I have added it.
Thanks for the notification!
Since the patch could not be applied to the HEAD anymore, I also updated
it.
About our discussion of pg_query_state:
torikoshia писал 2021
rror tables" feature.
+1.
I'm also going to make patch for "logging errors", since this
functionality is isolated from v7 patch.
Seems promising. I'll look at the patch.
Thanks a lot!
Sorry to attach v2 if you already reviewed v1..
On 2024-01-11 12:13, jian he wrote:
Hi,
RETURNING is usually tagged with appropriate tags, such as ,
but not in the 'query' section of COPY.
https://www.postgresql.org/docs/devel/sql-copy.html
Would it be better to put here as well?
--
Regards,
--
Atsushi Torikoshi
NTT DATA Group CorporationFrom 3c9efe404310bf01d79b2f0f00654
On 2024-01-12 20:56, Alvaro Herrera wrote:
On 2024-Jan-12, Ashutosh Bapat wrote:
On Fri, Jan 12, 2024 at 11:27 AM torikoshia
wrote:
>
> RETURNING is usually tagged with appropriate tags, such as ,
> but not in the 'query' section of COPY.
The patch looks good.
Good
On 2024-01-16 00:17, Alexander Korotkov wrote:
On Mon, Jan 15, 2024 at 8:44 AM Masahiko Sawada
wrote:
On Mon, Jan 15, 2024 at 8:21 AM Alexander Korotkov
wrote:
>
> On Sun, Jan 14, 2024 at 10:35 PM Masahiko Sawada
wrote:
> > Thank you for updating the patch. Here are two comments:
> >
> >
Hi,
132de9968840c introduced SAVE_ERROR_TO option to COPY and enabled to
skip malformed data, but there is no way to watch the number of skipped
rows during COPY.
Attached patch adds tuples_skipped to pg_stat_progress_copy, which
counts the number of skipped tuples because source data is mal
Hi,
Thanks for applying!
+ errmsg_plural("%zd row were skipped due
to data type incompatibility",
Sorry, I just noticed it, but 'were' should be 'was' here?
BTW I'm thinking we should add a column to pg_stat_progress_copy that
counts soft errors. I'll suggest t
On 2024-01-18 10:10, jian he wrote:
On Thu, Jan 18, 2024 at 8:57 AM Masahiko Sawada
wrote:
On Thu, Jan 18, 2024 at 6:38 AM Tom Lane wrote:
>
> Alexander Korotkov writes:
> > On Wed, Jan 17, 2024 at 9:49 AM Kyotaro Horiguchi
> > wrote:
> >> On the other hand, SAVE_ERROR_TO takes 'error' or '
On 2024-01-18 16:59, Alexander Korotkov wrote:
On Thu, Jan 18, 2024 at 4:16 AM torikoshia
wrote:
On 2024-01-18 10:10, jian he wrote:
> On Thu, Jan 18, 2024 at 8:57 AM Masahiko Sawada
> wrote:
>> On Thu, Jan 18, 2024 at 6:38 AM Tom Lane wrote:
>> > Kyotaro-san's sugg
On 2024-01-16 18:41, Melih Mutlu wrote:
Hi,
Thanks for reviewing.
torikoshia , 10 Oca 2024 Çar, 09:37
tarihinde şunu yazdı:
+
+
+ context_id int4
+
+
+ Current context id. Note that the context id is a
temporary id
and may
+ change in each
On 2024-01-18 23:59, jian he wrote:
Hi.
patch refactored based on "on_error {stop|ignore}"
doc changes:
--- a/doc/src/sgml/ref/copy.sgml
+++ b/doc/src/sgml/ref/copy.sgml
@@ -43,7 +43,7 @@ COPY { table_name [ ( column_name [, ...] ) | * }
FORCE_NOT_NULL { ( column_name [, ...] ) | * }
F
On 2024-01-19 22:27, Alexander Korotkov wrote:
Hi!
On Fri, Jan 19, 2024 at 2:37 PM torikoshia
wrote:
Thanks for making the patch!
The patch is pushed! The proposed changes are incorporated excluding
this.
> - /* If SAVE_ERROR_TO is specified, skip rows
>
On 2024-01-17 14:47, Masahiko Sawada wrote:
On Wed, Jan 17, 2024 at 2:22 PM torikoshia
wrote:
Hi,
132de9968840c introduced SAVE_ERROR_TO option to COPY and enabled to
skip malformed data, but there is no way to watch the number of
skipped
rows during COPY.
Attached patch adds
On 2024-01-24 17:05, Masahiko Sawada wrote:
On Tue, Jan 23, 2024 at 1:02 AM torikoshia
wrote:
On 2024-01-17 14:47, Masahiko Sawada wrote:
> On Wed, Jan 17, 2024 at 2:22 PM torikoshia
> wrote:
>>
>> Hi,
>>
>> 132de9968840c introduced SAVE_ERROR_TO option
Hi,
As described in 9e2d870119, COPY ON_EEOR is expected to have more
"error_action".
(Note that option name was changed by b725b7eec)
I'd like to have a new option "log", which skips soft errors and logs
information that should have resulted in errors to PostgreSQL log.
I think this option
Hi,
9e2d870 enabled the COPY command to skip soft error, and I think we can
add another option which specifies the maximum tolerable number of soft
errors.
I remember this was discussed in [1], and feel it would be useful when
loading 'dirty' data but there is a limit to how dirty it can be.
On 2024-01-27 00:04, David G. Johnston wrote:
On Fri, Jan 26, 2024 at 2:30 AM Yugo NAGATA
wrote:
On Fri, 26 Jan 2024 00:00:57 -0700
"David G. Johnston" wrote:
I will need to make this tweak and probably a couple others to my
own
suggestions in 12 hours or so.
And here is my v2.
Notabl
ified them to NOTICE in accordance with the following summary
message:
NOTICE: x row was skipped due to data type incompatibility
On 2024-01-27 00:43, David G. Johnston wrote:
On Thu, Jan 25, 2024 at 9:42 AM torikoshia
wrote:
Hi,
As described in 9e2d870119, COPY ON_EEOR is expected to
Hi,
Updated the patch to fix typos and move
ProcessLogQueryPlanInterruptActive from errfinish() to AbortTransaction.
BTW since the thread is getting long, I list the some points of the
discussion so far:
# Safety concern
## Catalog access inside CFI
- it seems safe if the CFI call is insid
On 2024-02-01 15:16, Yugo NAGATA wrote:
On Mon, 29 Jan 2024 15:47:25 +0900
Yugo NAGATA wrote:
On Sun, 28 Jan 2024 19:14:58 -0700
"David G. Johnston" wrote:
> > Also, I think "invalid input syntax" is a bit ambiguous. For example,
> > COPY FROM raises an error when the number of input column
On 2024-01-27 00:20, David G. Johnston wrote:
Thanks for your comments!
On Fri, Jan 26, 2024 at 2:49 AM torikoshia
wrote:
Hi,
9e2d870 enabled the COPY command to skip soft error, and I think we
can
add another option which specifies the maximum tolerable number of
soft
errors.
I remember
Hi,
On 2024-02-03 15:22, jian he wrote:
The idea of on_error is to tolerate errors, I think.
if a column has a not null constraint, let it cannot be used with
(on_error 'null')
+ /*
+* we can specify on_error 'null', but it can only apply to
columns
+* don't have not n
Hi Ashutosh,
On 2024-02-06 19:51, Ashutosh Bapat wrote:
Thanks for the summary. It is helpful. I think patch is also getting
better.
I have a few questions and suggestions
Thanks for your comments.
1. Prologue of GetLockMethodLocalHash() mentions
* NOTE: When there are many entries in Lo
On 2024-02-07 13:58, Ashutosh Bapat wrote:
On Wed, Feb 7, 2024 at 9:38 AM torikoshia
wrote:
Hi Ashutosh,
On 2024-02-06 19:51, Ashutosh Bapat wrote:
> Thanks for the summary. It is helpful. I think patch is also getting
> better.
>
> I have a few questions and suggestions
Tha
On 2023-02-06 15:00, Tom Lane wrote:
Andres Freund writes:
On February 5, 2023 9:12:17 PM PST, Tom Lane
wrote:
Damir Belyalov writes:
InputFunctionCallSafe() is good for detecting errors from
input-functions
but there are such errors from NextCopyFrom () that can not be
detected
with Input
On 2023-03-06 23:03, Daniel Gustafsson wrote:
On 28 Feb 2023, at 15:28, Damir Belyalov wrote:
Tested patch on all cases: CIM_SINGLE, CIM_MULTI, CIM_MULTI_CONDITION.
As expected it works.
Also added a description to copy.sgml and made a review on patch.
Thanks for your tests and improvements
On 2023-03-07 08:50, Imseih (AWS), Sami wrote:
I am wondering if this patch should be backpatched?
The reason being is in auto_explain documentation [1],
there is a claim of equivalence of the auto_explain.log_verbose
option and EXPLAIN(verbose)
". it's equivalent to the VERBOSE option of E
On 2023-03-07 18:09, Daniel Gustafsson wrote:
On 7 Mar 2023, at 09:35, Damir Belyalov wrote:
I felt just logging "Error: %ld" would make people wonder the meaning
of
the %ld. Logging something like ""Error: %ld data type errors were
found" might be clearer.
Thanks. For more clearance change
1 - 100 of 337 matches
Mail list logo
