On Sun, Feb 24, 2019 at 11:53 PM Kyotaro HORIGUCHI
wrote:
> The two aboves are fixed in the attached v17.
Andres just drew my attention to patch 0004 in this series, which is
definitely not OK. That patch allows the postmaster to use dynamic
shared memory, claiming: "Shared memory baesd stats co
Hi,
> From 88740269660d00d548910c2f3aa631878c7cf0d4 Mon Sep 17 00:00:00 2001
> From: Kyotaro Horiguchi
> Date: Thu, 21 Feb 2019 12:42:07 +0900
> Subject: [PATCH 4/6] Allow dsm to use on postmaster.
>
> DSM is inhibited to be used on postmaster. Shared memory baesd stats
> collector needs it to w
Ping? Unless there's a new version pretty soon, we're going to have to
move this to the next CF, I think.
Hi,
Unfortunately I don't think it's realistic to target this to v12. I
think it was unlikely to make at the beginning of the CF, but since then
development just wasn't quick enough to warrant aiming for it. It's a
large and somewhat complex patch, and has some significant risks
associated. There
Hello.
At Wed, 3 Apr 2019 12:56:59 -0700, Andres Freund wrote in
<20190403195659.fcmk2i7ruxhty...@alap3.anarazel.de>
> Unfortunately I don't think it's realistic to target this to v12. I
> think it was unlikely to make at the beginning of the CF, but since then
> development just wasn't quick en
Hi,
The patch needs rebasing, as it got broken by 285d8e1205, and there's
some other minor bitrot.
On 11/27/18 4:40 PM, Tomas Vondra wrote:
> On 11/27/18 9:59 AM, Kyotaro HORIGUCHI wrote:
>>>
>>> ...>>
>>> For the main workload there's pretty much no difference, but for
>>> selects from the sta
On Tue, Jan 22, 2019 at 03:48:02PM +0900, Kyotaro HORIGUCHI wrote:
> Fixed doubious memory context usage.
That's quite something that we have here for 0005:
84 files changed, 6588 insertions(+), 7501 deletions(-)
Moved to next CF for now.
--
Michael
signature.asc
Description: PGP signature
Hi,
On 2018-11-12 20:10:42 +0900, Kyotaro HORIGUCHI wrote:
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> index 7eed5866d2..e52ae54821 100644
> --- a/src/backend/access/transam/xlog.c
> +++ b/src/backend/access/transam/xlog.c
> @@ -8587,9 +8587,9 @@ LogCh
Hi Kyatoro,
On 2019-02-07 13:10:08 -0800, Andres Freund wrote:
> I don't think this is all that close to being committable :(
Are you planning to update this soon? I think this needs to be improved
pretty quickly to have any shot at getting into v12. I'm willing to put
in some resources towards t
Hi,
On 2019-02-15 17:29:00 +0900, Kyotaro HORIGUCHI wrote:
> At Thu, 7 Feb 2019 13:10:08 -0800, Andres Freund wrote
> in <20190207211008.nc3axviivmcoa...@alap3.anarazel.de>
> > Hi,
> >
> > On 2018-11-12 20:10:42 +0900, Kyotaro HORIGUCHI wrote:
> > > diff --git a/src/backend/access/transam/xlog.
On 2019-Feb-15, Andres Freund wrote:
> It's fine to do such renames, just do them as separate patches. It's
> hard enough to review changes this big...
Talk about moving the whole file to another subdir ...
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24
At Fri, 15 Feb 2019 15:53:28 -0300, Alvaro Herrera
wrote in <20190215185328.GA29663@alvherre.pgsql>
> On 2019-Feb-15, Andres Freund wrote:
>
> > It's fine to do such renames, just do them as separate patches. It's
> > hard enough to review changes this big...
>
> Talk about moving the whole fil
Hello,
On 21.02.2019 10:05, Kyotaro HORIGUCHI wrote:
Done. This verison 16 looks as if the moving and splitting were
not happen. Major changes are:
- Restored old pgstats_* names. This largily shrinks the patch
size to less than a half lines of v15. More than that, it
gets easier to
Hello, Arthur.
At Thu, 21 Feb 2019 17:30:50 +0300, Arthur Zakirov
wrote in
> Hello,
>
> On 21.02.2019 10:05, Kyotaro HORIGUCHI wrote:
> > Done. This verison 16 looks as if the moving and splitting were
> > not happen. Major changes are:
> > - Restored old pgstats_* names. This largily shrink
On 25.02.2019 07:52, Kyotaro HORIGUCHI wrote:
It is fixed by moving StartTransactionCommand to before the first
pgstat_f_s_dbentry(), which looks better not having this problem.
Thank you. Still there are couple TAP-test which don't pass:
002_archiving.pl and 010_pg_basebackup.pl. I think the
On Fri, Jun 29, 2018 at 4:34 AM, Kyotaro HORIGUCHI
wrote:
> Nowadays PostgreSQL has dynamic shared hash (dshash) so we can
> use this as the main storage of statistics. We can share data
> without a stress using this.
>
> A PoC previously posted tried to use "locally copied" dshash but
> it doesn'
Hello. Thanks for the comment.
At Mon, 2 Jul 2018 14:25:58 -0400, Robert Haas wrote in
> On Fri, Jun 29, 2018 at 4:34 AM, Kyotaro HORIGUCHI
> wrote:
> > Nowadays PostgreSQL has dynamic shared hash (dshash) so we can
> > use this as the main storage of statistics. We can share data
> > without
Hello. This is new version fixed windows build.
At Tue, 03 Jul 2018 19:01:44 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180703.190144.222427588.horiguchi.kyot...@lab.ntt.co.jp>
> Hello. Thanks for the comment.
>
> At Mon, 2 Jul 2018 14:25:58 -0400, Robert Haas wrote
> in
> >
Kyotaro HORIGUCHI writes:
> At Mon, 2 Jul 2018 14:25:58 -0400, Robert Haas wrote
> in
>> Copying the whole hash table kinds of sucks, partly because of the
>> time it will take to copy it, but also because it means that memory
>> usage is still O(nbackends * ntables). Without looking at the pa
Hello.
At Wed, 04 Jul 2018 17:23:51 -0400, Tom Lane wrote in
<67470.1530739...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > At Mon, 2 Jul 2018 14:25:58 -0400, Robert Haas
> > wrote in
> >
> >> Copying the whole hash table kinds of sucks, partly because of the
> >> time it will take to cop
Hello.
At Thu, 05 Jul 2018 12:04:23 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180705.120423.49626073.horiguchi.kyot...@lab.ntt.co.jp>
> UNDO logs seems a bit promising. If we looking stats in a long
> transaction, the required memory for UNDO information easily
> reaches to the
On Wed, Jul 4, 2018 at 11:23 PM, Tom Lane wrote:
> Kyotaro HORIGUCHI writes:
> > At Mon, 2 Jul 2018 14:25:58 -0400, Robert Haas
> wrote in gmail.com>
> >> Copying the whole hash table kinds of sucks, partly because of the
> >> time it will take to copy it, but also because it means that memory
On Fri, Jul 6, 2018 at 10:29 AM, Magnus Hagander wrote:
> I agree that this is definitely something that needs to be considered. I
> took a look some time ago at the same thing, and ran up against exactly that
> one (and at the time did not have time to fix it).
>
> I have not yet had time to look
On 2018-07-06 14:49:53 -0400, Robert Haas wrote:
> I think we also have to ask ourselves in general whether snapshots of
> this data are worth what they cost. I don't think anyone would doubt
> that a consistent snapshot of the data is better than an inconsistent
> view of the data if the costs we
On 07/06/2018 11:57 AM, Andres Freund wrote:
On 2018-07-06 14:49:53 -0400, Robert Haas wrote:
I think we also have to ask ourselves in general whether snapshots of
this data are worth what they cost. I don't think anyone would doubt
that a consistent snapshot of the data is better than an incon
On Fri, Jul 6, 2018 at 3:02 PM, Joshua D. Drake wrote:
> Will stats, if we move toward the suggested changes be "less" accurate than
> they are now? We already know that stats are generally not accurate but they
> are close enough. If we move toward this change will it still be close
> enough?
Th
On 2018-07-06 12:02:39 -0700, Joshua D. Drake wrote:
> On 07/06/2018 11:57 AM, Andres Freund wrote:
> > On 2018-07-06 14:49:53 -0400, Robert Haas wrote:
> > > I think we also have to ask ourselves in general whether snapshots of
> > > this data are worth what they cost. I don't think anyone would
On 07/06/2018 12:34 PM, Robert Haas wrote:
On Fri, Jul 6, 2018 at 3:02 PM, Joshua D. Drake wrote:
Will stats, if we move toward the suggested changes be "less" accurate than
they are now? We already know that stats are generally not accurate but they
are close enough. If we move toward this cha
On Fri, Jul 6, 2018 at 8:57 PM, Andres Freund wrote:
> On 2018-07-06 14:49:53 -0400, Robert Haas wrote:
> > I think we also have to ask ourselves in general whether snapshots of
> > this data are worth what they cost. I don't think anyone would doubt
> > that a consistent snapshot of the data is
Hi,
On 2018-07-06 22:03:12 +0200, Magnus Hagander wrote:
> *If* we can provide the snapshots view of them without too much overhead I
> think it's worth looking into that while *also* proviiding a lower overhead
> interface for those that don't care about it.
I don't see how that's possible witho
Hello. Thanks for the opinions.
At Fri, 6 Jul 2018 13:10:36 -0700, Andres Freund wrote in
<20180706201036.awheoi6tk556x...@alap3.anarazel.de>
> Hi,
>
> On 2018-07-06 22:03:12 +0200, Magnus Hagander wrote:
> > *If* we can provide the snapshots view of them without too much overhead I
> > think i
On 07/10/2018 02:07 PM, Kyotaro HORIGUCHI wrote:
Hello. Thanks for the opinions.
At Fri, 6 Jul 2018 13:10:36 -0700, Andres Freund wrote in
<20180706201036.awheoi6tk556x...@alap3.anarazel.de>
Hi,
On 2018-07-06 22:03:12 +0200, Magnus Hagander wrote:
*If* we can provide the snapshots view of t
On 2018-07-10 14:52:13 +0200, Tomas Vondra wrote:
> There's one more reason why attempts to keep stats snapshots "perfectly"
> consistent are likely doomed to fail - the messages are sent over UDP, which
> does not guarantee delivery etc. So there's always some level of possible
> inconsistency eve
Hi,
Unfortunately, the patch does not apply anymore - it seems it got broken
by the changes to signal handling and/or removal of magic OIDs :-(
I've done a review and testing when applied on top of 10074651e335.
Firstly, the testing - I was wondering if the patch has some performance
impact, so
On 11/27/18 9:59 AM, Kyotaro HORIGUCHI wrote:
>>
>> ...>>
For the main workload there's pretty much no difference, but for selects
from the stats catalogs there's ~20% drop in throughput. In absolute
numbers this means drop from ~670tps to ~550tps. I haven't investigated
this, but I suppose this
On 11/27/18 9:59 AM, Kyotaro HORIGUCHI wrote:
> ...
>
> v10-0001-sequential-scan-for-dshash.patch
> v10-0002-Add-conditional-lock-feature-to-dshash.patch
> fixed.
> v10-0003-Make-archiver-process-an-auxiliary-process.patch
> fixed.
> v10-0004-Shared-memory-based-stats-collector.patch
> updat
On 2018-Nov-28, Tomas Vondra wrote:
> > v10-0004-Shared-memory-based-stats-collector.patch
> > updated not to touch guc.
> > v10-0005-Remove-the-GUC-stats_temp_directory.patch
> > collected all guc-related changes.
> > updated not to break other programs.
> > v10-0006-Split-out-backend-statu
On 11/29/18 1:18 PM, Alvaro Herrera wrote:
> On 2018-Nov-28, Tomas Vondra wrote:
>
>>> v10-0004-Shared-memory-based-stats-collector.patch
>>> updated not to touch guc.
>>> v10-0005-Remove-the-GUC-stats_temp_directory.patch
>>> collected all guc-related changes.
>>> updated not to break other
Hi,
On 2019-01-01 18:39:12 +0100, Tomas Vondra wrote:
> On 11/29/18 1:18 PM, Alvaro Herrera wrote:
> > On 2018-Nov-28, Tomas Vondra wrote:
> >
> >>> v10-0004-Shared-memory-based-stats-collector.patch
> >>> updated not to touch guc.
> >>> v10-0005-Remove-the-GUC-stats_temp_directory.patch
> >>>
On 1/1/19 7:03 PM, Andres Freund wrote:
> Hi,
>
> On 2019-01-01 18:39:12 +0100, Tomas Vondra wrote:
>> On 11/29/18 1:18 PM, Alvaro Herrera wrote:
>>> On 2018-Nov-28, Tomas Vondra wrote:
>>>
> v10-0004-Shared-memory-based-stats-collector.patch
> updated not to touch guc.
> v10-0005
On 2019-Jan-01, Tomas Vondra wrote:
> I agree it's a sensitive part of the code, so additional reviews would
> be welcome of course. I've done as much review and testing as possible,
> and overall it seems in a fairly good shape. Do you have any particular
> concerns / ideas what to look for?
I h
On Thu, Apr 04, 2019 at 09:25:12AM +0900, Kyotaro HORIGUCHI wrote:
Hello.
At Wed, 3 Apr 2019 12:56:59 -0700, Andres Freund wrote in
<20190403195659.fcmk2i7ruxhty...@alap3.anarazel.de>
Unfortunately I don't think it's realistic to target this to v12. I
think it was unlikely to make at the begi
At Tue, 9 Apr 2019 17:03:33 +0200, Tomas Vondra
wrote in <20190409150333.5iashyjxm5jmraml@development>
> Unfortunately, now that we're past code freeze it's clear this is a
> PG12
> matter now :-(
>
> I personally consider this to be very worthwhile & beneficial
> improvement,
> but I agree with
On Wed, Apr 10, 2019 at 09:39:29AM +0900, Kyotaro HORIGUCHI wrote:
At Tue, 9 Apr 2019 17:03:33 +0200, Tomas Vondra wrote
in <20190409150333.5iashyjxm5jmraml@development>
Unfortunately, now that we're past code freeze it's clear this is a
PG12
matter now :-(
I personally consider this to be ve
Hi.
At Fri, 17 May 2019 14:27:22 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190517.142722.139901807.horiguchi.kyot...@lab.ntt.co.jp>
> The attached files are:
It's broken perhaps by recent core change?
I'll fix it.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Cent
Hi,
On 2018-09-20 09:55:27 +0200, Antonin Houska wrote:
> I've spent some time reviewing this version.
>
> Design
> --
>
> 1. Even with your patch the stats collector still uses an UDP socket to
>receive data. Now that the shared memory API is there, shouldn't the
>messages be sent v
Hello. Thank you for the comments.
At Thu, 20 Sep 2018 10:37:24 -0700, Andres Freund wrote in
<20180920173724.5w2n2nwkxtyi4...@alap3.anarazel.de>
> Hi,
>
> On 2018-09-20 09:55:27 +0200, Antonin Houska wrote:
> > I've spent some time reviewing this version.
> >
> > Design
> > --
> >
> > 1.
The previous patch doesn't work...
At Thu, 27 Sep 2018 22:00:49 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180927.220049.168546206.horiguchi.kyot...@lab.ntt.co.jp>
> - 0001 to 0006 is rebased version of v4.
> - 0007 adds conditional locking to dshash
>
> - 0008 is the no-UDP st
Kyotaro HORIGUCHI wrote:
> This is more saner version of previous v5-0008, which didn't pass
> regression test. v6-0008 to v6-0010 are attached and they are
> applied on top of v5-0001-0007.
>
> - stats collector has been removed.
>
> - modified dshash further so that deletion is allowed during
Hi,
I've started looking at the patch over the past few days. I don't have
any deep insights at this point, but there seems to be some sort of
issue in pgstat_update_stat. When building using gcc, I do get this warning:
pgstat.c: In function ‘pgstat_update_stat’:
pgstat.c:648:18: warning: ‘no
On 10/05/2018 10:30 AM, Kyotaro HORIGUCHI wrote:
> Hello.
>
> At Tue, 02 Oct 2018 16:06:51 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20181002.160651.117284090.horiguchi.kyot...@lab.ntt.co.jp>
>> It doesn't work nor even compile since I failed to include some
>> changes. Th
Thank you for the comments, Antonin, Tomas.
At Tue, 30 Oct 2018 13:35:23 +0100, Tomas Vondra
wrote in
>
>
> On 10/05/2018 10:30 AM, Kyotaro HORIGUCHI wrote:
> > Hello.
> >
> > At Tue, 02 Oct 2018 16:06:51 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> > wrote in
> > <20181002.160651.117
Thank you for the comments.
This message contains the whole refactored patch set.
At Mon, 29 Oct 2018 15:10:10 +0100, Antonin Houska wrote in
<28855.1540822210@localhost>
> Kyotaro HORIGUCHI wrote:
>
> > This is more saner version of previous v5-0008, which didn't pass
> > regression test. v6
On 11/8/18 12:46 PM, Kyotaro HORIGUCHI wrote:
Hello. Thank you for looking this.
At Tue, 30 Oct 2018 01:49:59 +0100, Tomas Vondra wrote
in <5253d750-890b-069b-031f-2a9b73e47...@2ndquadrant.com>
Hi,
I've started looking at the patch over the past few days. I don't have
any deep insights at
On 2018-Nov-08, Tomas Vondra wrote:
> I'm not sure splitting the headers like this is needed, actually. It's true
> we're replacing pgstat.c with something else, but it's still related to
> stats, backing pg_stat_* system views etc. So I'd keep as much of the
> definitions in pgstat.h, so that it'
On 11/9/18 9:33 AM, Kyotaro HORIGUCHI wrote:
Hello. This is rebased version.
At Thu, 8 Nov 2018 16:06:49 +0100, Tomas Vondra wrote
in
However a quite a few extensions in contrib seem are broken now. It
seems fixing it is as simple as including the new bestatus.h next to
pgstat.h.
The ad
On Mon, 2018-11-12 at 20:10 +0900, Kyotaro HORIGUCHI wrote:
> At Fri, 9 Nov 2018 14:16:31 +0100, Tomas Vondra <
> tomas.von...@2ndquadrant.com> wrote in <
> 803f2d96-3b4b-f357-9a2e-45443212f...@2ndquadrant.com>
> >
> >
> > On 11/9/18 9:33 AM, Kyotaro HORIGUCHI wrote:
> > > Hello. This is rebased
I've spent some time reviewing this version.
Design
--
1. Even with your patch the stats collector still uses an UDP socket to
receive data. Now that the shared memory API is there, shouldn't the
messages be sent via shared memory queue? [1] That would increase the
reliability of mes
On Fri, May 17, 2019 at 6:48 PM Kyotaro HORIGUCHI
wrote:
> Fixed. Version 20.
Hello Horiguchi-san,
A new Commitfest is here. This doesn't apply (maybe just because of
the new improved pgindent). Could we please have a fresh rebase?
Thanks,
--
Thomas Munro
https://enterprisedb.com
At Thu, 04 Jul 2019 19:27:54 +0900 (Tokyo Standard Time), Kyotaro Horiguchi
wrote in
<20190704.192754.27063464.horikyota@gmail.com>
> #db #tbl #clients #iter #xactlen #referers
> A1: 1 1 1 2100
> A2: 1 1 1 2101
> B
On 2019-Jul-11, Kyotaro Horiguchi wrote:
> Hello. This is v21 of the patch.
>
> > CF-bot warned that it doesn't work on Windows. I'm experiencing
> > an very painful time to wait for tortoise git is walking slowly
> > as its name suggests. It would be fixed in the next version.
>
> Found a bug i
Hello, Arthur.
At Thu, 21 Feb 2019 17:30:50 +0300, Arthur Zakirov
wrote in
> Hello,
>
> On 21.02.2019 10:05, Kyotaro HORIGUCHI wrote:
> > Done. This verison 16 looks as if the moving and splitting were
> > not happen. Major changes are:
> > - Restored old pgstats_* names. This largily shrink
On 25.02.2019 07:52, Kyotaro HORIGUCHI wrote:
It is fixed by moving StartTransactionCommand to before the first
pgstat_f_s_dbentry(), which looks better not having this problem.
Thank you. Still there are couple TAP-test which don't pass:
002_archiving.pl and 010_pg_basebackup.pl. I think the
On Sun, Feb 24, 2019 at 11:53 PM Kyotaro HORIGUCHI
wrote:
> The two aboves are fixed in the attached v17.
Andres just drew my attention to patch 0004 in this series, which is
definitely not OK. That patch allows the postmaster to use dynamic
shared memory, claiming: "Shared memory baesd stats co
Hi,
> From 88740269660d00d548910c2f3aa631878c7cf0d4 Mon Sep 17 00:00:00 2001
> From: Kyotaro Horiguchi
> Date: Thu, 21 Feb 2019 12:42:07 +0900
> Subject: [PATCH 4/6] Allow dsm to use on postmaster.
>
> DSM is inhibited to be used on postmaster. Shared memory baesd stats
> collector needs it to w
Ping? Unless there's a new version pretty soon, we're going to have to
move this to the next CF, I think.
On 2021/03/05 17:18, Kyotaro Horiguchi wrote:
At Thu, 21 Jan 2021 12:03:48 +0900 (JST), Kyotaro Horiguchi
wrote in
Commit 960869da08 (database statistics) conflicted with this. Rebased.
I'm concerned about the behavior that pgstat_update_connstats calls
GetCurrentTimestamp() every time sta
On Fri, Mar 5, 2021 at 8:32 PM Fujii Masao
wrote:
>
>
> On 2021/03/05 17:18, Kyotaro Horiguchi wrote:
> > At Thu, 21 Jan 2021 12:03:48 +0900 (JST), Kyotaro Horiguchi <
> horikyota@gmail.com> wrote in
> >> Commit 960869da08 (database statistics) conflicted with this. Rebased.
> >>
> >> I'm con
At Sat, 6 Mar 2021 00:32:07 +0900, Fujii Masao
wrote in
>
>
> On 2021/03/05 17:18, Kyotaro Horiguchi wrote:
> > At Thu, 21 Jan 2021 12:03:48 +0900 (JST), Kyotaro Horiguchi
> > wrote in
> >> Commit 960869da08 (database statistics) conflicted with this. Rebased.
> >>
> >> I'm concerned about th
At Tue, 09 Mar 2021 16:53:11 +0900 (JST), Kyotaro Horiguchi
wrote in
> The attached is a new version of this patchset.
Hmm. That's too bad. A just commited change killed this. Will do a
further rebase.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
On 2021/03/09 16:51, Kyotaro Horiguchi wrote:
At Sat, 6 Mar 2021 00:32:07 +0900, Fujii Masao
wrote in
On 2021/03/05 17:18, Kyotaro Horiguchi wrote:
At Thu, 21 Jan 2021 12:03:48 +0900 (JST), Kyotaro Horiguchi
wrote in
Commit 960869da08 (database statistics) conflicted with this. Rebased
On 2021/03/10 12:10, Kyotaro Horiguchi wrote:
At Tue, 9 Mar 2021 23:24:10 +0900, Fujii Masao
wrote in
On 2021/03/09 16:51, Kyotaro Horiguchi wrote:
At Sat, 6 Mar 2021 00:32:07 +0900, Fujii Masao
wrote in
I don't think that we should treat non-zero exit condition as a crash,
as before.
On 2021/03/10 17:51, Kyotaro Horiguchi wrote:
At Wed, 10 Mar 2021 15:20:43 +0900, Fujii Masao
wrote in
On 2021/03/10 12:10, Kyotaro Horiguchi wrote:
Agreed. The code moved to the original place and added the crash
handling code. And I added a phrase to the comment.
+* Was it
At Wed, 10 Mar 2021 21:47:51 +0900, Fujii Masao
wrote in
> Attached is the updated version of the 0003 patch. Barring any
> objection,
> I will commit this patch.
>
>
> -#include "storage/latch.h"
> -#include "storage/proc.h"
>
> I removed these because they are no longer necessary.
Mmm. Sor
Hi,
Two minor nits:
On 2021-03-10 21:47:51 +0900, Fujii Masao wrote:
> +/* Shared memory area for archiver process */
> +typedef struct PgArchData
> +{
> + Latch *latch; /* latch to wake the archiver
> up */
> + slock_t mutex; /* locks t
Hi,
On 2021-03-10 17:51:37 +0900, Kyotaro Horiguchi wrote:
> From ed2fb2fca47fccbf9af1538688aab8334cf6470c Mon Sep 17 00:00:00 2001
> From: Kyotaro Horiguchi
> Date: Fri, 13 Mar 2020 16:58:03 +0900
> Subject: [PATCH v52 1/7] sequential scan for dshash
>
> Dshash did not allow scan the all entrie
At Wed, 10 Mar 2021 19:21:00 -0800, Andres Freund wrote in
> Hi,
>
> Two minor nits:
Thanks for the comments!
> On 2021-03-10 21:47:51 +0900, Fujii Masao wrote:
> > +/* Shared memory area for archiver process */
> > +typedef struct PgArchData
> > +{
> > + Latch *latch;
On 2021/03/11 13:42, Kyotaro Horiguchi wrote:
At Wed, 10 Mar 2021 19:21:00 -0800, Andres Freund wrote in
Hi,
Two minor nits:
Thanks for the comments!
On 2021-03-10 21:47:51 +0900, Fujii Masao wrote:
+/* Shared memory area for archiver process */
+typedef struct PgArchData
+{
+ La
At Thu, 11 Mar 2021 15:33:52 +0900, Fujii Masao
wrote in
>
>
> On 2021/03/11 13:42, Kyotaro Horiguchi wrote:
> > At Wed, 10 Mar 2021 19:21:00 -0800, Andres Freund
> > wrote in
> >> Hi,
> >>
> >> Two minor nits:
> > Thanks for the comments!
> >
> >> On 2021-03-10 21:47:51 +0900, Fujii Masao w
On 2021/03/12 9:23, Kyotaro Horiguchi wrote:
At Thu, 11 Mar 2021 15:33:52 +0900, Fujii Masao
wrote in
On 2021/03/11 13:42, Kyotaro Horiguchi wrote:
At Wed, 10 Mar 2021 19:21:00 -0800, Andres Freund
wrote in
Hi,
Two minor nits:
Thanks for the comments!
On 2021-03-10 21:47:51 +0900,
At Fri, 12 Mar 2021 09:23:12 +0900 (JST), Kyotaro Horiguchi
wrote in
> The attached the only 0003 of the new version based on the last one
> from Fujii-san.
Please wait a moment. Something might be wrong.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Fri, 12 Mar 2021 10:07:10 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 12 Mar 2021 09:23:12 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > The attached the only 0003 of the new version based on the last one
> > from Fujii-san.
>
> Please wait a moment. Something might be wrong.
It wa
At Fri, 12 Mar 2021 10:03:31 +0900, Fujii Masao
wrote in
> > I moved archiver from the current location to next to "walsenders"
> > that is to be terminated along with archiver.
> > The attached the only 0003 of the new version based on the last one
> > from Fujii-san.
>
> Thanks for updating t
Hi,
On 2021-03-10 20:26:56 -0800, Andres Freund wrote:
> > +static void
> > +attach_shared_stats(void)
> > +{
> > + MemoryContext oldcontext;
>
> > + /*
> > +* The first attacher backend may still reading the stats file, or the
> > +* last detacher may writing it. Wait for the work to
At Fri, 12 Mar 2021 10:38:00 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 12 Mar 2021 10:03:31 +0900, Fujii Masao
> wrote in
> > > I moved archiver from the current location to next to "walsenders"
> > > that is to be terminated along with archiver.
> > > The attached the only 0003 of th
At Thu, 11 Mar 2021 19:22:57 -0800, Andres Freund wrote in
> Hi,
>
> On 2021-03-10 20:26:56 -0800, Andres Freund wrote:
> > > +static void
> > > +attach_shared_stats(void)
> > > +{
> > > + MemoryContext oldcontext;
> >
> > > + /*
> > > + * The first attacher backend may still reading the stats
On 2021/03/12 13:49, Kyotaro Horiguchi wrote:
At Fri, 12 Mar 2021 10:38:00 +0900 (JST), Kyotaro Horiguchi
wrote in
At Fri, 12 Mar 2021 10:03:31 +0900, Fujii Masao
wrote in
I moved archiver from the current location to next to "walsenders"
that is to be terminated along with archiver.
The
At Fri, 12 Mar 2021 15:13:15 +0900, Fujii Masao
wrote in
> On 2021/03/12 13:49, Kyotaro Horiguchi wrote:
> > I noticed that I accidentally removed the launch-suppression feature
> > that is to avoid frequent relaunching. That mechanism is needed on
> > the postmaster side. I added PgArchIsSuppr
On 2021/03/12 17:24, Kyotaro Horiguchi wrote:
At Fri, 12 Mar 2021 15:13:15 +0900, Fujii Masao
wrote in
On 2021/03/12 13:49, Kyotaro Horiguchi wrote:
I noticed that I accidentally removed the launch-suppression feature
that is to avoid frequent relaunching. That mechanism is needed on
the p
Hi,
On 2021-03-11 19:22:57 -0800, Andres Freund wrote:
> I started changing the patch to address my complaints. I'll try to do
> it as an incremental patch ontop of your 0004, but it might become too
> unwieldy. Not planning to touch other patches for now (and would be
> happy if the first few wer
On Sat, Mar 13, 2021 at 7:20 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-03-11 19:22:57 -0800, Andres Freund wrote:
> > I started changing the patch to address my complaints. I'll try to do
> > it as an incremental patch ontop of your 0004, but it might become too
> > unwieldy. Not planning to tou
Hi,
On 2021-03-13 12:53:30 +0100, Magnus Hagander wrote:
> On Sat, Mar 13, 2021 at 7:20 AM Andres Freund wrote:
> >I think before making things differently complicated with this patch,
> >we need to clean this up, unfortunately. I think we should initially have
> >- src/backend/postma
At Sat, 13 Mar 2021 10:05:21 -0800, Andres Freund wrote in
> Hi,
>
> On 2021-03-13 12:53:30 +0100, Magnus Hagander wrote:
> > On Sat, Mar 13, 2021 at 7:20 AM Andres Freund wrote:
> > >I think before making things differently complicated with this patch,
> > >we need to clean this up, un
At Fri, 12 Mar 2021 23:33:05 +0900, Fujii Masao
wrote in
>
>
> On 2021/03/12 17:24, Kyotaro Horiguchi wrote:
> > At Fri, 12 Mar 2021 15:13:15 +0900, Fujii Masao
> > wrote in
> >> On 2021/03/12 13:49, Kyotaro Horiguchi wrote:
> >>> I noticed that I accidentally removed the launch-suppression f
At Fri, 12 Mar 2021 22:20:40 -0800, Andres Freund wrote in
> Horiguchi-san, is there a chance you could add a few tests (on master)
> that test/document the way stats are kept across "normal" restarts, and
> thrown away after crash restarts/immediate restarts and also thrown away
> graceful strea
Hi,
On 2021-03-13 10:05:21 -0800, Andres Freund wrote:
> Cool. I'll give it a try.
I have a few questions about the patch:
- Why was collect_oids() changed to a different hashtable as part of
this change? Seems fairly independent?
- What's the point of all those cached_* stuff? There's not a
At Mon, 15 Mar 2021 19:04:29 -0700, Andres Freund wrote in
> I have a few questions about the patch:
>
> - Why was collect_oids() changed to a different hashtable as part of
> this change? Seems fairly independent?
Right. It is changed at the time I used simplehash for some other
stuff.
> -
At Tue, 16 Mar 2021 16:44:38 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Mon, 15 Mar 2021 19:04:29 -0700, Andres Freund wrote
> in
> > Do you have some benchmarks that you used to verify performance?
>
> https://www.postgresql.org/message-id/20201008.160326.2246946707652981235.horikyota.ntt
On Mon, Mar 15, 2021 at 10:56 PM Andres Freund wrote:
> I did roughly the first steps of the split as I had outlined. I moved:
>
> 1) wait event related functions into utils/activity/wait_event.c /
>wait_event.h
>
> 2) "backend status" functionality (PgBackendStatus stuff) into
>utils/acti
Hi,
On 2021-03-16 15:08:39 -0400, Robert Haas wrote:
> On Mon, Mar 15, 2021 at 10:56 PM Andres Freund wrote:
> > I did roughly the first steps of the split as I had outlined. I moved:
> >
> > 1) wait event related functions into utils/activity/wait_event.c /
> >wait_event.h
> >
> > 2) "backen
1 - 100 of 325 matches
Mail list logo
