On Fri, 20 Jul 2018 10:48:15 -0400
Tom Lane wrote:
> Yugo Nagata writes:
> > Recently, one of our clients reported a problem that Windows 10 sometime
> > (approximately once in 300 tries) hung up at OS starting up while PostgreSQL
> > 9.3.x service is starting up.
On Fri, 20 Jul 2018 19:13:21 +0900
Michael Paquier wrote:
> On Fri, Jul 20, 2018 at 05:58:13PM +0900, Yugo Nagata wrote:
> > He reported this problem to pgsql-general list as below. Also, he created a
> > patch
> > to add a build-time option for adding 0.5 or 3.0 sec
--
Yugo Nagata
diff --git a/src/backend/postmaster/postmaster.c
b/src/backend/postmaster/postmaster.c
index d6fc2ed..ff03ebd 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -398,6 +398,30 @@ extern int optreset; /* might
On Thu, 12 Jul 2018 16:44:45 +0900
Michael Paquier wrote:
> On Thu, Jul 12, 2018 at 03:35:53PM +0900, Yugo Nagata wrote:
> > I think it makes sense to remove unnecessary temporary WAL files although
> > I'm not sure how high the risk of ENOSPC is.
>
> It depends on how c
e((i+1),(i+1));
In the past, I proposed a patch to forbid this, but this is rejected
since there is harmless and no need to restrict this.
Attached is a patch to get rid of "appears more than once" restriction.
Regards,
--
Yugo Nagata
diff --git a/src/backend/commands/tablecmds.c
On Thu, 12 Jul 2018 12:59:15 +0200
Tomas Vondra wrote:
>
>
> On 07/12/2018 03:44 AM, Yugo Nagata wrote:
> > On Wed, 11 Jul 2018 14:37:46 +0200
> > Tomas Vondra wrote:
> >
> >>
> >> On 07/11/2018 01:28 PM, Ashutosh Bapat wrote:
> >
> >
roach is appropriate?
Regards,
[1]
https://www.postgresql.org/message-id/flat/20180712155808.49e712d8.nagata%40sraoss.co.jp#00bbfb5054c0a57f9a2fe48fae77b848
--
Yugo Nagata
On Thu, 12 Jul 2018 15:58:08 +0900
Yugo Nagata wrote:
> Yes, more simplly, the following query also works;
>
> CREATE INDEX ON test((i)) INCLUDE (i);
>
> However, a problem is that when we use pg_dump for the database, this
> generate the following query
>
> CR
rting
postgres that was shutdown immediately.
One little thing I noticed is the function name "RemoveXLogTempFiles".
Other similar functions are named as RemoveOldXlogFiles or RemoveXlogFile
(using Xlog not XLog), so it seem to me more consistent to rename this
"RemoveXlogTempFiles" or "RemoveTempXlogFiles" and so on.
Regards
--
Yugo Nagata
ible etc which is crucial for
> estimating index-only scans. I'd bet that's why the cost estimates for
> index scans and index-only scans are the same here.
You are right. When the table have rows and this is vacuumed, index only
scan's cost is cheaper and chosen properly. Sorry, I have jumped to the
conclusion before confirming this.
Thanks,
--
Yugo Nagata
On Wed, 11 Jul 2018 14:26:03 +0300
Alexander Korotkov wrote:
> On Wed, Jul 11, 2018 at 12:04 PM Yugo Nagata wrote:
> > When we specify column names for ANALYZE, only the statistics for those
> > columns
> > are collected. Similarly, is it useful if we have a option to
; is large and/or whose expression takes time to compute, for example.
Attached is the WIP patch to allow to specify a index name as ANALYZE parameter.
Any documatation is not yet included. I would appreciate any feedback!
Regards,
--
Yugo Nagata
diff --git a/src/backend/commands/analyze.c b/s
-scan when the cost is equal to other
index
path. Honestly, I'm not sure this is the best way. Any comments and advices
would
be appriciated.
Regards,
--
Yugo Nagata
diff --git a/src/backend/optimizer/util/pathnode.c b/src/backend/optimizer/util/pathnode.c
index dbf9adc..61f0609 100644
/projects/pgtranslation
[2] https://wiki.postgresql.org/wiki/NLS
Regards,
>
> Please find attached.
>
>
> Sincerely,
>
> --
> Taiki Kondo
> NEC Solution Innovators, Ltd.
--
Yugo Nagata
es, this is what I intend in my patch, but I don't persist in this if there
is a reason to leave the code as it is, since the current code is alomot
harmless.
Thanks,
--
Yugo Nagata
understand the usefulness of the statistics
on non-key expression attributions and that "CREATE INDEX ... INCLUDE" migth be
a means to collect the statistics on "non-key" expressions in future.
>
> regards, tom lane
>
--
Yugo Nagata
this thread.
Thank you for fixing this.
>
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
--
Yugo Nagata
On Mon, 2 Jul 2018 14:23:09 -0400
Robert Haas wrote:
> On Thu, Jun 28, 2018 at 5:28 AM, Yugo Nagata wrote:
> > According to the error message, it is not allowed to alter statistics on
> > included column because this is "non-expression column".
> >
> > p
On Fri, 29 Jun 2018 11:36:19 +0200
Daniel Gustafsson wrote:
> > On 29 Jun 2018, at 09:14, Yugo Nagata wrote:
>
> > Thanks a lot.
> >
> > I updated the patch.
>
> This version looks good to me. You might want to add it to the CF to make
> sure
> i
On Thu, 28 Jun 2018 19:18:36 -0400
Tom Lane wrote:
> Yugo Nagata writes:
> > I found that both key columns and included columns are checked when analyze
> > is run on indexes. This is almost harmless because non-expression columns
> > are not processed. However, th
On Thu, 28 Jun 2018 10:26:13 -0400
Robert Haas wrote:
> On Wed, Jun 27, 2018 at 9:22 AM, Yugo Nagata wrote:
> > According to the syntax in ALTER INDEX doc, a column should be specified by
> > column number as discussed in [1]. However, the current code still allows to
> > u
On Fri, 29 Jun 2018 08:39:01 +0200
Daniel Gustafsson wrote:
> > On 29 Jun 2018, at 07:56, Yugo Nagata wrote:
> > On Thu, 28 Jun 2018 16:22:15 -0700
> > "David G. Johnston" wrote:
>
> >> Maybe try something like:
> >>
> >> I
On Thu, 28 Jun 2018 16:22:15 -0700
"David G. Johnston" wrote:
> On Thu, Jun 28, 2018 at 3:57 PM, Daniel Gustafsson wrote:
Thank you for your reviewing!
I attached the updated patch.
>
> > > On 27 Jun 2018, at 18:02, Yugo Nagata wrote:
> >
> > > I
expressions
in included columns in future, this must be fixed eventually.
Attached is a patch to fix this.
Regards,
--
Yugo Nagata
diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 25194e8..d2b2c39 100644
--- a/src/backend/commands/analyze.c
+++ b/src/backend
elow;
postgres=# alter index idx alter column 2 set statistics 10;
ERROR: cannot alter statistics on included column "d" of index "idx"
Regards,
--
Yugo Nagata
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 7c0cf0d..4beb160 10064
On Wed, 27 Jun 2018 18:36:46 +0900
Michael Paquier wrote:
> On Wed, Jun 27, 2018 at 05:42:07PM +0900, Yugo Nagata wrote:
> > On Wed, 27 Jun 2018 00:58:18 +0900
> > Fujii Masao wrote:
> >>> In addition, the current pg_standby still can handle a backup history
>
Hi,
I found that there isn't explanation about EXCLUDING in CREATE TABLE doc.
Attached is a patch to add this. I would appreciate it if a native English
speaker comments on this.
Regards,
--
Yugo Nagata
diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml
index
d
unuseful behavior. The attached patch does it.
[1]
https://www.postgresql.org/message-id/CAPpHfdsSYo6xpt0F%3DngAdqMPFJJhC7zApde9h1qwkdpHpwFisA%40mail.gmail.com
--
Yugo Nagata
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 7c0cf0d..1b6f278 100644
--- a/s
On Tue, 26 Jun 2018 20:19:42 +0900 (Tokyo Standard Time)
Kyotaro HORIGUCHI wrote:
> Hello.
>
> Good catch!
>
> At Tue, 26 Jun 2018 17:47:52 +0900, Yugo Nagata wrote
> in <20180626174752.0ce505e3.nag...@sraoss.co.jp>
> > Hi,
> >
> > While looking
On Wed, 27 Jun 2018 00:58:18 +0900
Fujii Masao wrote:
> On Tue, Jun 26, 2018 at 5:47 PM, Yugo Nagata wrote:
> > Hi,
> >
> > While looking into the backup and recovery code, I found small
> > documentation bugs.
> > The documatation says that the back
this part of code.
Regards,
--
Yugo Nagata
diff --git a/contrib/pg_standby/pg_standby.c b/contrib/pg_standby/pg_standby.c
index cb78597..d957f44 100644
--- a/contrib/pg_standby/pg_standby.c
+++ b/contrib/pg_standby/pg_standby.c
@@ -211,15 +211,9 @@ CustomizableNextWALFileReady(void
recursion.
> >>
> >> create view v3 as select * from v1;
> >> begin;
> >> lock v3;
> >> abort;
>
> Shouldn't they be in the regression test?
Added tests for the infinite recursion detection.
Regards,
>
> It's shame that create_view test does
On Mon, 2 Apr 2018 18:32:53 +0900
Yugo Nagata <nag...@sraoss.co.jp> wrote:
> On Thu, 29 Mar 2018 17:26:36 -0700
> Andres Freund <and...@anarazel.de> wrote:
>
> Thank you for your comments. I attach a patch to fix issues
> you've pointed out.
I found a typo in t
On Thu, 29 Mar 2018 17:26:36 -0700
Andres Freund <and...@anarazel.de> wrote:
Thank you for your comments. I attach a patch to fix issues
you've pointed out.
> Hi,
>
> On 2018-03-28 20:26:48 +0900, Yugo Nagata wrote:
> > diff --git a/doc/src/sgml/ref/lock.sgml b/doc/s
an lock a table with inheritance children.
> --- 118,125
>
>lock_tbl1
>lock_view6
> ! mvtest_tm
> ! (3 rows)
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese
On Tue, 27 Mar 2018 23:28:04 +0900
Yugo Nagata <nag...@sraoss.co.jp> wrote:
I found the previous patch was broken and this can't handle
views that has subqueries as bellow;
CREATE VIEW lock_view6 AS SELECT * from (select * from lock_tbl1) sub;
I fixed this and attached the updated v
> pessimistic concurrency control, (2) finer-grained locking, and (3)
> not needing to issue explicit LOCK commands.
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
--
Yugo Nagata <nag...@sraoss.co.jp>
diff --git a/doc/s
not imposing a performance
> cost on unrelated queries.
I would like to elaborate my patch if needed and possible. Any suggestion
would be appriciated.
Thanks,
>
> regards, tom lane
--
Yugo Nagata <nag...@sraoss.co.jp>
On Thu, 1 Mar 2018 14:29:58 -0800
Andres Freund <and...@anarazel.de> wrote:
> Hi,
>
> On 2018-01-11 11:03:26 +0900, Yugo Nagata wrote:
> > However, I don't inisist on this patch, so If anyone other don't need this
> > feature, I'll withdraw this.
>
> Given this
On Wed, 31 Jan 2018 21:12:51 -0500
Tom Lane <t...@sss.pgh.pa.us> wrote:
> Yugo Nagata <nag...@sraoss.co.jp> writes:
> > I'm sorry the patch attached in the previous mail is broken and
> > not raises a compile error. I attached the fixed patch.
>
> This patch is
ll mark this as "ready for committer".
> >
> > No objection from me.
>
> I marked this as "Ready for Committer".
Thank you for reviewing the patch!
Regards,
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo Nagata <nag...@sraoss.co.jp>
On Thu, 1 Feb 2018 01:33:49 +0900
Yugo Nagata <nag...@sraoss.co.jp> wrote:
I'm sorry the patch attached in the previous mail is broken and
not raises a compile error. I attached the fixed patch.
Regards,
> Hi,
>
> I found that updating a cursor by using CURRENT OF causes the
&g
= 1;
DECLARE CURSOR
postgres=# fetch from c;
i
---
1
(1 row)
postgres=# update test set i=i+1 where current of c;
ERROR: cannot extract system attribute from virtual tuple
===
The patch fixes the error and allows this update successfully.
Regards,
--
Yugo Nagata <nag...@sraoss.co.jp>
d
urrently, only auto-updatable views can be locked, that is,
> + * views whose definition are simple and that doesn't have
> + * instead of rules or triggers are lockable.
>
> s/definition are simple and that doesn't/definition is simple and that don't/
> s/instead of/INSTEAD OF/ ?
Thank y
g the patch.
I fixed this and attached a updated patch v6.
Regards,
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo Nagata <nag...@sraoss.co.jp>
diff --git a/doc/src
On Fri, 26 Jan 2018 21:30:49 +0900
Yugo Nagata <nag...@sraoss.co.jp> wrote:
> On Thu, 25 Jan 2018 20:51:41 +1300
> Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
>
> > On Sun, Dec 31, 2017 at 11:57 PM, Yugo Nagata <nag...@sraoss.co.jp> wrote:
> > &g
On Thu, 25 Jan 2018 20:51:41 +1300
Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
> On Sun, Dec 31, 2017 at 11:57 PM, Yugo Nagata <nag...@sraoss.co.jp> wrote:
> > On Fri, 29 Dec 2017 23:39:39 +0900 (JST)
> > Tatsuo Ishii <is...@sraoss.co.jp> wro
On Sun, 31 Dec 2017 11:57:02 -0500
Tom Lane <t...@sss.pgh.pa.us> wrote:
> Yugo Nagata <nag...@sraoss.co.jp> writes:
> > Attached is a patch to implement a feature to get the current function
> > name by GET DIAGNOSTICS in PL/pgSQL function.
>
> While this is
gt; English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo Nagata <nag...@sraoss.co.jp>
diff --git a/doc/src/sgml/ref/lock.sgml b/doc/src/sgml/ref/lock.sgml
index b2c7203..c2ed481 100644
--- a/doc/src/sgml/ref/lock.sgml
+++ b/doc/src/sgml/ref/lock.sgml
@@ -46,6
CF 2018-01.
Thank you.
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo Nagata <nag...@sraoss.co.jp>
CF, I have not seen it there? Maybe the
> > deadline is tonight...
>
> I have added this to the next CF.
Thank you.
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo Nagata <nag...@sraoss.co.jp>
, but the sample code returns zero. This patch fixes this.
Regards,
--
Yugo Nagata <nag...@sraoss.co.jp>
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index 7d23ed4..5a67c38 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -5676,6 +5676,10 @@ D
postgres=# select test();
INFO: function name: test()
test
--
(1 row)
Regards,
--
Yugo Nagata <nag...@sraoss.co.jp>
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index 7d23ed4..c0daa14 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -
the subquery do not hold locks.
Attached is the update patch, v3. I add some regression test and
the documentation.
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo Nagata
Lock all tables including in a subquery
> >
> > 3) Check subquery in the view
> > So it seem #1 is the most reasonable way to deal with the problem
> > assuming that it's user's responsibility to take appropriate locks on
> > the tables in the subquery.
I adopte
On Tue, 26 Dec 2017 22:22:33 +0900
Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Tue, Dec 26, 2017 at 06:37:06PM +0900, Yugo Nagata wrote:
> > I have created a new entry in CF-2017-1 and registered this thread again.
>
> Fine for me. Thanks for the update.
On Sat, 23 Dec 2017 09:44:30 +0900
Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Fri, Dec 22, 2017 at 04:19:46PM +0900, Yugo Nagata wrote:
> > I was busy for and I could not work on this patch. After reading the
> > previous discussion, I still think the behavio
On Wed, 29 Nov 2017 11:29:36 +0900
Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Fri, Oct 27, 2017 at 2:11 PM, Robert Haas <robertmh...@gmail.com> wrote:
> > On Wed, Oct 11, 2017 at 11:36 AM, Yugo Nagata <nag...@sraoss.co.jp> wrote:
> >> In th
On Fri, 27 Oct 2017 07:11:14 +0200
Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Oct 11, 2017 at 11:36 AM, Yugo Nagata <nag...@sraoss.co.jp> wrote:
> > In the attached patch, only automatically-updatable views that do not have
> > INSTEAD OF rules or INSTE
401 - 459 of 459 matches
Mail list logo
