On 2021/04/06 10:57, torikoshia wrote:
I don't have any objections to your improvements.
Thanks for the check! I pushed the patch. Thanks a lot!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
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 nex
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 next CHECK_FOR_INTERRUPTS()
I think the
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/05 12:20, Zhihong Yu wrote:
+ * This is just a warning so a loop-through-resultset will not abort
+ * if one backend logged its memory contexts during the run.
The pid given by arg 0 is not a PostgreSQL server process. Which other backend
could it be ?
This is the
On Sun, Apr 4, 2021 at 7:56 PM torikoshia
wrote:
> 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 mem
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/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 any concrete target.
Or just using
At Wed, 31 Mar 2021 15:02:02 +0900, torikoshia
wrote in
> 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 exam
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 vers
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 version
of the patch. Could you check this
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/29 11:59, torikoshia wrote:
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 alre
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
>
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
> > with limiting with a fixed-numbe
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
with limiting with a fixed-number, and preferablly sorted in
descending order of... totalspace/nblocks?
This
At Fri, 26 Mar 2021 13:17:21 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 26 Mar 2021 12:49:16 +0900, Fujii Masao
> wrote in
> > On 2021/03/26 12:26, Fujii Masao wrote:
> > > On 2021/03/26 12:01, Kyotaro Horiguchi wrote:
> > >> At Thu, 25 Mar 2021 23:45:17 +0900, torikoshia
> > >> wrote
At Fri, 26 Mar 2021 12:49:16 +0900, Fujii Masao
wrote in
> On 2021/03/26 12:26, Fujii Masao wrote:
> > On 2021/03/26 12:01, Kyotaro Horiguchi wrote:
> >> At Thu, 25 Mar 2021 23:45:17 +0900, torikoshia
> >> wrote in
> >>> Attached new one.
> > Regarding the argument max_children, isn't it better
At Fri, 26 Mar 2021 12:26:31 +0900, Fujii Masao
wrote in
>
>
> On 2021/03/26 12:01, Kyotaro Horiguchi wrote:
> > At Thu, 25 Mar 2021 23:45:17 +0900, torikoshia
> > wrote in
> >> Attached new one.
>
> Regarding the argument max_children, isn't it better to set its
> default value,
> e.g., 100
On 2021/03/26 12:26, Fujii Masao wrote:
On 2021/03/26 12:01, Kyotaro Horiguchi wrote:
At Thu, 25 Mar 2021 23:45:17 +0900, torikoshia
wrote in
Attached new one.
Regarding the argument max_children, isn't it better to set its default value,
e.g., 100 like MemoryContextStats() uses?
+
On 2021/03/26 12:01, Kyotaro Horiguchi wrote:
At Thu, 25 Mar 2021 23:45:17 +0900, torikoshia
wrote in
Attached new one.
Regarding the argument max_children, isn't it better to set its default value,
e.g., 100 like MemoryContextStats() uses?
+ ereport(WARNING,
+
At Thu, 25 Mar 2021 23:45:17 +0900, torikoshia
wrote in
> Attached new one.
Thanks!
-SELECT * FROM pg_get_backend_memory_contexts();
+SELECT * FROM pg_get_backend_memory_contexts(0, 0);
However we can freely change the signature since it's new in 14, but I
see the (void) signature as
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's not cont
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?
mcxtfuncs.c:22:10: fatal error: utils/mcxtfuncs.h: No such file or directory
#include "
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 number be passed via sha
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 number be passed via shared memory?
>
> The attached patch uses static shared memory to pass the number.
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 p
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 pg_print_backend_memory_contexts(450855);
** log output **
202
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/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; -- wait
- session1
SELECT * FROM pg
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(); --wa
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
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
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.
Hi,
On Thu, Dec 10, 2020 at 10:48 AM torikoshia wrote:
>
> 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
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 request of
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
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 waiting infinity. Is this a bug?
On 2020/11/16 19:58, torikoshia wrote:
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 ou
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 attached
corre
Hi,
I noticed that this patch fails on the cfbot.
For this, I changed the status to: 'Waiting on Author'.
Cheers,
//Georgios
The new status of this patch is: Waiting on Author
On 2020-10-23 13:46, Kyotaro Horiguchi wrote:
Wait...
Attachments:
0003-Enabled-pg_get_backend_memory_contexts-to-collect.patch
For a moment I thought that the number is patch number but the
predecessors are 0002-Enabled..collect.patch and 0001-(same
name). It's not mandatory but we usually d
Wait...
> Attachments: 0003-Enabled-pg_get_backend_memory_contexts-to-collect.patch
For a moment I thought that the number is patch number but the
predecessors are 0002-Enabled..collect.patch and 0001-(same
name). It's not mandatory but we usually do as the follows and it's
the way of git.
v1-00
On Thu, Oct 1, 2020 at 4:06 PM Kasahara Tatsuhito
wrote:
Hi,
On Fri, Sep 25, 2020 at 4:28 PM torikoshia
wrote:
> Thanks for all your comments, I updated the patch.
Thanks for updating the patch.
I did a brief test and code review.
Thanks for your tests and review!
> I added a shared hash
Hi,
On Fri, Sep 25, 2020 at 4:28 PM torikoshia wrote:
> Thanks for all your comments, I updated the patch.
Thanks for updating the patch.
I did a brief test and code review.
> I added a shared hash table consisted of minimal members
> mainly for managing whether the file is dumped or not.
> Some
Hi,
Thanks for all your comments, I updated the patch.
On Tue, Sep 1, 2020 at 12:03 AM Kasahara Tatsuhito
wrote:
- How about managing the status of signal send/receive and dump
operations on a shared hash or others ?
Sending and receiving signals, dumping memory information, and
referencin
On Thu, Sep 10, 2020 at 09:11:21PM +0900, Kasahara Tatsuhito wrote:
> I think it's fine to have an interface to delete in an emergency, but
> I agree that
> users shouldn't be made aware of the existence or deletion of dump
> files, basically.
Per the CF bot, the number of tests needs to be tweake
Hi,
On Thu, Sep 10, 2020 at 8:53 PM torikoshia wrote:
>
> 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 futu
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 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.
> For example, if you want to read one du
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.
> > For example, if you want to read one dumped file multiple times and analyze
> > it,
> > you will want
Kasahara Tatsuhito writes:
> Yes, but it's not only for future expansion, but also for the
> usability and the stability of this feature.
> For example, if you want to read one dumped file multiple times and analyze
> it,
> you will want the ability to just read the dump.
If we design it to make
Hi,
On Thu, Sep 3, 2020 at 3:38 PM torikoshia wrote:
> >> - Currently, "the signal transmission for dumping memory
> >> information"
> >> and "the read & output of dump information "
> >> are on the same interface, but I think it would be better to
> >> separate them.
> >> How about providing the
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 system
vi
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
process.
+1
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 system
> view.
>
> However, its target is limited to the process attached to
> the current session.
>
> As discussed in the threa
Hi
po 31. 8. 2020 v 17:03 odesílatel Kasahara Tatsuhito <
kasahara.tatsuh...@gmail.com> 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
> > process.
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
> process.
+1
> Attached PoC patch makes pg_get_backend_memory_contexts()
> display meory contexts of the specified PID
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
59 matches
Mail list logo
