nnect psql meta-commands to
test
the user privilege to a namespace, but I think we can make this more simpler
by using SET SESSION AUTHORIZATION and RESET AUTHORIZATION.
Regards,
--
Yugo Nagata
cache. You have
to install libmemcached.
, but maybe libmemcached-devel is correct instead of libmemcached?
Regards,
--
Yugo Nagata
--
Yugo Nagata
Hi,
I apologize that I accidentally sent the following email to this list.
Please disregard this.
I am sorry for making a lot of noise.
Regard,
On Tue, 26 Mar 2019 20:38:31 +0900
Yugo Nagata wrote:
> Hi,
>
> One of our clients suggested that the installation document[1] lacks
>
bmemcached-devel is correct instead of libmemcached?
>
> I don't think so. "libmemcached-devel" is just a package name in a
> cetain Linux distribution. "libmemcached" is a more geneal and non
> distribution dependent term.
Thanks for your explaination. I understood it.
> 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
On Thu, 27 Dec 2018 21:57:26 +0900
Yugo Nagata wrote:
> Hi,
>
> I would like to implement Incremental View Maintenance (IVM) on PostgreSQL.
I am now working on an initial patch for implementing IVM on PostgreSQL.
This enables materialized views to be updated incrementally after one
n [1], that is,
if concurrent transactions update different two tables in the join
view definition, is MV updated sucessfully?
[1]
https://www.postgresql.org/message-id/flat/1368561126.64093.YahooMailNeo%40web162904.mail.bf1.yahoo.com
Regards,
--
Yugo Nagata
ated to "bar" and we
> compute an update for the materialized view again. If we have not
> applied any of those updates (because we are "lazy") now the
> previously computed update can be discarded. We could still apply
> both, but it would not be efficient.
In our PoC implementation, I handled this situation by removing
old contents from NEW delata table. In your example, when the base
table is updated from "foo" to "bar", the "foo" tuple is removed
from and the "bar" tuple is inserted in NEW delta and the delta
of MV is computed using the final NEW delta.
Regards,
--
Yugo Nagata
On Thu, 1 Mar 2018 14:29:58 -0800
Andres Freund 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 is where
osing 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
; 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
diff --git a/doc/src/sgml/ref/lock.sgml b/doc
On Tue, 27 Mar 2018 23:28:04 +0900
Yugo Nagata 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 version including addit
eritance 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:http://www.sraoss.co.j
On Thu, 29 Mar 2018 17:26:36 -0700
Andres Freund 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/src/sgml/ref/lock.sgml
> &
On Mon, 2 Apr 2018 18:32:53 +0900
Yugo Nagata wrote:
> On Thu, 29 Mar 2018 17:26:36 -0700
> Andres Freund wrote:
>
> Thank you for your comments. I attach a patch to fix issues
> you've pointed out.
I found a typo in the documentation and attach the updated patch.
;
> >> 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 no
moves 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
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 backup h
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
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
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
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
>
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
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
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
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 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 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 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 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
cussed in this thread.
Thank you for fixing this.
>
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
--
Yugo Nagata
on. I 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
ded columns.
Yes, 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
/projects/pgtranslation
[2] https://wiki.postgresql.org/wiki/NLS
Regards,
>
> Please find attached.
>
>
> Sincerely,
>
> --
> Taiki Kondo
> NEC Solution Innovators, Ltd.
--
Yugo Nagata
index-only-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..61f06
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
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
x27;t have relallvisible 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
when restarting
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
enerate
the following query
CREATE INDEX test_i_i1_idx ON public.test USING btree (i) INCLUDE (i);
Of cause, this causes the "must not intersect" error, and we cannot restore
this dump.
To fix this, we agree with Tom about getting rid of "must not intersect"
restriction.
A
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
>
> CREAT
h approach 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 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:
> >
> >
t) partition by range((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/
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
akatsuka Haruka
--
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;
tgresql.org/message-id/flat/1368561126.64093.YahooMailNeo%40web162904.mail.bf1.yahoo.com
[5] https://dl.acm.org/citation.cfm?id=170066
Regards,
--
Yugo Nagata
On Mon, 1 Apr 2019 12:11:22 +0900
Yugo Nagata wrote:
> On Thu, 27 Dec 2018 21:57:26 +0900
> Yugo Nagata wrote:
>
> > Hi,
> >
> > I would like to implement Incremental View Maintenance (IVM) on PostgreSQL.
> >
>
> I am now working on an initial p
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
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. My co
parameter to
control the behavior of the function.
Any comments would be appriciated.
Regards,
--
Yugo Nagata
diff --git a/src/backend/utils/adt/acl.c b/src/backend/utils/adt/acl.c
index a45e093de7..6628385277 100644
--- a/src/backend/utils/adt/acl.c
+++ b/src/backend/utils/adt/acl.c
On Thu, 16 Aug 2018 19:37:42 -0400
Tom Lane wrote:
> Yugo Nagata writes:
> > I found that has_table_privilege returns an error when a table is specified
> > by schema-qualified name and the user doen't have privilege for its schema.
>
> > postgres=> select h
s not allowed to change it to keep back-compatibility, I would like to
propose
to add a parameter to the function to consider the privilege of the schema, for
example as bellow. Assuming false as the default values will keep the
back-compatibility.
has_table_privilege(user, table, privilege[, co
an be rewritten using the latter code as the attached patch.
Is this reasonable fix?
Regards,
--
Yugo Nagata
diff --git a/src/backend/utils/adt/varlena.c b/src/backend/utils/adt/varlena.c
index a5e812d026..2ef1a1e330 100644
--- a/src/backend/utils/adt/varlena.c
+++ b/src/backend/utils/adt/varlena.c
@@
ere. And I don't
> think there's all that much to the backwards-compatibility argument,
> considering that the current behavior is to fail.
With regarding to keeping the backwards-compatibility, to add a new paramater
to has_*_privilege functions is a solution as proposed previously.
has_table_privilege(user, table, privilege[, consider_schema=false])
How do you think this proposal?
Regards,
--
Yugo Nagata
On Fri, 24 Aug 2018 20:44:12 +0900
Yugo Nagata wrote:
> Hi,
>
> When working on other patch[1], I found there are almost same
> functions, texttoQualifiedNameList() and stringToQualifiedNameList().
> The only difference is the argument type, text or char*. I don't know
>
nk
it makes senses to allow to specify a relfilenode instead of a file name.
I think it is reasonable to add a option to specify a database, although
I don't know which character is good because both -d and -D are already used
Regards,
--
Yugo Nagata
On Mon, 27 Aug 2018 13:34:12 +0200
Michael Banck wrote:
> Hi,
>
> On Mon, Aug 27, 2018 at 07:53:36PM +0900, Yugo Nagata wrote:
> > On Fri, 24 Aug 2018 18:01:09 +0200
> > Peter Eisentraut wrote:
> > > I'm curious about this option:
> > >
> > &
To collect the log, set the connection string or environment variable.
> - logdir or PGLOGDIR : directory where log file written
> - logsize or PGLOGSIZE : maximum log size
How we can specify the log file name? What should happen if a file size
exceeds to PGLOGSIZE?
Regards,
--
Yugo Nagata
On Tue, 28 Aug 2018 11:49:26 +0900 (Tokyo Standard Time)
Kyotaro HORIGUCHI wrote:
> At Fri, 24 Aug 2018 20:44:12 +0900, Yugo Nagata wrote
> in <20180824204412.150979ae6b283ddb639f9...@sraoss.co.jp>
> > When working on other patch[1], I found there are almost
pagesize | version |
prune_xid
---+--+---+---+---+-+--+-+---
0/939FE48 |0 | 0 |24 | 8176 |8176 | 8192 | 4 |
0
(1 row)
Looking at the code to check the checksum, each page is checked if this is a
new page by using PageIsNew(), and if so its checksum is not checked because
new pages are assumed to have no checksum. PageIsNew() determines if a
page is new or not from pd_upper. For some reason, the last page has pd_upper
but no checksum, so the checksum verification fails.
It is not clear for me why the last page has a head information, but, after
some code investigation, I think it happend in _hash_alloc_buckets(). When
expanding a hash table, smgrextend() add some blocks to a file. At that time,
it seems that a page that has a header infomation is written to the end of
the file (in mdextend()).
I'm not sure how to fix this for now, but it might be worth to share my
analysis for this issue.
Regards,
--
Yugo Nagata
s also by clearing the header information of
the last
page instead of setting a checksum to the unused page although I am not sure
which way
is better.
Regards,
--
Yugo Nagata
ke the
codes complicated, so I think the way you posted is better.
Regards,
--
Yugo Nagata
On Wed, 29 Aug 2018 10:28:33 +0200
Daniel Gustafsson wrote:
> > On 27 Aug 2018, at 14:05, Yugo Nagata wrote:
> >
> > On Mon, 27 Aug 2018 13:34:12 +0200
> > Michael Banck wrote:
> >
> >> Hi,
> >>
> >> On Mon, Aug 27, 2018 at 07:53:36
On Wed, 29 Aug 2018 13:46:38 +0200
Magnus Hagander wrote:
> On Wed, Aug 29, 2018 at 1:37 PM, Michael Banck
> wrote:
>
> > Hi,
> >
> > On Wed, Aug 29, 2018 at 08:33:43PM +0900, Yugo Nagata wrote:
> > > On Wed, 29 Aug 2018 10:28:33 +0200
> > > Danie
On Wed, 29 Aug 2018 21:09:03 +0900
Yugo Nagata wrote:
> On Wed, 29 Aug 2018 13:46:38 +0200
> Magnus Hagander wrote:
>
> > On Wed, Aug 29, 2018 at 1:37 PM, Michael Banck
> > wrote:
> >
> > > Hi,
> > >
> > > On Wed, Aug 29, 2018 at 08:33
Hi,
Attached is a patch to fix comments of IndexInfo. ii_KeyAttrNumbers was
renamed to ii_IndexAttrNumbers and ii_Am was added but these are
not reflected to the comment.
Regards,
--
Yugo Nagata
diff --git a/src/include/nodes/execnodes.h b/src/include/nodes/execnodes.h
index 41fa2052a2
On Thu, 30 Aug 2018 09:14:26 +0300
Heikki Linnakangas wrote:
> On 30/08/18 07:48, Yugo Nagata wrote:
> > Attached is a patch to fix comments of IndexInfo. ii_KeyAttrNumbers was
> > renamed to ii_IndexAttrNumbers and ii_Am was added but these are
> > not reflected to the
On Thu, 30 Aug 2018 15:01:24 +0900 (Tokyo Standard Time)
Kyotaro HORIGUCHI wrote:
> At Wed, 29 Aug 2018 20:10:15 +0900, Yugo Nagata wrote
> in <20180829201015.d9d4fde2748910e86a13c...@sraoss.co.jp>
> > On Wed, 29 Aug 2018 16:01:53 +0530
> > Amit Kapila wrote:
> >
On Thu, 30 Aug 2018 10:13:31 +0200
Michael Banck wrote:
> Hi,
>
> thanks for fixing this up!
>
> On Wed, Aug 29, 2018 at 11:25:28PM +0900, Yugo Nagata wrote:
> > diff --git a/doc/src/sgml/ref/pg_verify_checksums.sgml
> > b/doc/src/sgml/ref/pg_verify_checksum
On Thu, 30 Aug 2018 10:34:06 +0200
Michael Banck wrote:
> Hi,
>
> On Thu, Aug 30, 2018 at 05:35:09PM +0900, Yugo Nagata wrote:
> > --- a/doc/src/sgml/ref/pg_verify_checksums.sgml
> > +++ b/doc/src/sgml/ref/pg_verify_checksums.sgml
> > @@ -61,11 +61,11
On Thu, 30 Aug 2018 10:54:08 +0200
Michael Banck wrote:
> Hi,
>
> On Thu, Aug 30, 2018 at 05:48:24PM +0900, Yugo Nagata wrote:
> > Oops, It's my mistake. I updated the patch.
>
> Looks good to me now.
>
> One could argue that the message could be 'check
ease, so
> that they get fixed (or at least considered) before we release.
>
> https://wiki.postgresql.org/wiki/Open_Items
I don't have the editor privilege now, so I'll add this discussion to the
wiki (Fixed issues or Resolve issues?) after I get the privilege.
Regards,
--
Yugo Nagata
On Thu, 30 Aug 2018 07:18:13 -0300
Alvaro Herrera wrote:
> On 2018-Aug-30, Yugo Nagata wrote:
>
> > On Thu, 30 Aug 2018 06:52:58 -0300
> > Alvaro Herrera wrote:
>
> > > This should have been listed in the pg11 open items. Please list there
> > > everyth
On Mon, 27 Aug 2018 21:05:33 +0900
Yugo Nagata wrote:
> On Mon, 27 Aug 2018 13:34:12 +0200
> Michael Banck wrote:
>
> > Hi,
> >
> > On Mon, Aug 27, 2018 at 07:53:36PM +0900, Yugo Nagata wrote:
> > > On Fri, 24 Aug 2018 18:01:09 +0200
> > > Peter
a database by OID using -d or
> > --dboid option.
> > Also, when -g or --global-only is used only shared relations are scaned.
>
> It seems that the patch does not apply anymore. Could you rebase it?
I attached the rebased patch.
Regards,
--
Yugo Nagata
>From f2141a28d1c1
Hi,
I found that a argument "filename" is not used in execute_sql_string()
although the comment says "filename is used only to report errors.",
so I think we can remove this argument as done in the patch I attached.
Regards,
--
Yugo Nagata
diff --git a/src/backend/comman
e the unused argument.
>
> Same opinion and arguments here, so I have committed the patch.
Thanks!
--
Yugo Nagata
On Sun, 31 Dec 2017 11:57:02 -0500
Tom Lane wrote:
> Yugo Nagata 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 certainly not a very large patch, it's still code th
On Thu, 25 Jan 2018 20:51:41 +1300
Thomas Munro wrote:
> On Sun, Dec 31, 2017 at 11:57 PM, Yugo Nagata wrote:
> > On Fri, 29 Dec 2017 23:39:39 +0900 (JST)
> > Tatsuo Ishii wrote:
> >> Your addition to the doc:
> >> + Automatically updatable views (see )
>
On Fri, 26 Jan 2018 21:30:49 +0900
Yugo Nagata wrote:
> On Thu, 25 Jan 2018 20:51:41 +1300
> Thomas Munro wrote:
>
> > On Sun, Dec 31, 2017 at 11:57 PM, Yugo Nagata wrote:
> > > On Fri, 29 Dec 2017 23:39:39 +0900 (JST)
> > > Tatsuo Ishii wrote
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
diff --git a/doc/src/sgml/ref/lock.sgml b/doc/src/sgml/ref/lock.sgml
index b
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 you for pointi
re i = 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
diff --git a/src/backend/
On Thu, 1 Feb 2018 01:33:49 +0900
Yugo Nagata 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
> following error
> > 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
On Wed, 31 Jan 2018 21:12:51 -0500
Tom Lane wrote:
> Yugo Nagata 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 almost certainly wrong: you can't ass
should do something like:
>
> insert into v7(i) values...
>
> In short, you don't need to care about a subquery appearing in the TLE
> as far as the view locking concerns.
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hack...@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Yugo Nagata
On Fri, 27 Oct 2017 07:11:14 +0200
Robert Haas wrote:
> On Wed, Oct 11, 2017 at 11:36 AM, Yugo Nagata wrote:
> > In the attached patch, only automatically-updatable views that do not have
> > INSTEAD OF rules or INSTEAD OF triggers are lockable. It is assumed that
> > t
On Wed, 29 Nov 2017 11:29:36 +0900
Michael Paquier wrote:
> On Fri, Oct 27, 2017 at 2:11 PM, Robert Haas wrote:
> > On Wed, Oct 11, 2017 at 11:36 AM, Yugo Nagata wrote:
> >> In the attached patch, only automatically-updatable views that do not have
> >> INSTEAD OF r
On Sat, 23 Dec 2017 09:44:30 +0900
Michael Paquier 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 behavior of this patch would
> > be ri
On Tue, 26 Dec 2017 22:22:33 +0900
Michael Paquier 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. And I guess that you are planning
> > 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 adopted #1 and I didn't change anything about
d 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
diff --git a/doc/src/sgml/ref/lock.sgml
E FUNCTION
postgres=# select test();
INFO: function name: test()
test
--
(1 row)
Regards,
--
Yugo Nagata
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
@@ -1506,6 +1506
t the sample code returns zero. This patch fixes this.
Regards,
--
Yugo Nagata
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 @@ DECLARE
length in
be 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
1.
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
.
>
> does not mention about the point:
>
> >> >> > 1) Leave as it is (ignore tables appearing in a subquery)
I added this point to the documentation.
Regards,
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss
Hi hackers,
Thank you for your many questions and feedbacks at PGCon 2019.
Attached is the patch rebased for the current master branch.
Regards,
Yugo Nagata
On Tue, 14 May 2019 15:46:48 +0900
Yugo Nagata wrote:
> On Mon, 1 Apr 2019 12:11:22 +0900
> Yugo Nagata wrote:
>
> >
www.postgresql.eu/events/pgconfeu2018/schedule/session/2195-implementing-incremental-view-maintenance-on-postgresql/
I agree that capturing the deltas using logical decoding will be faster than
using a trigger although we haven't yet consider this well.
Best regadrds,
Yugo Nagata
--
Yugo Nagata
1 - 100 of 600 matches
Mail list logo
