ce should start with "This ... ".
> >
> > + while(size)
> > + {
> >
> > I wonder inserting a space after "while" is the standard style.
>
> Thanks, fixed.
Should we fix the comment on byteaGetByte in passing, too?
Regards,
Yugo Nagata
--
Yugo Nagata
er ad d the same comment in dropdb(). I attached a trivial
patch for it.
Regards,
Yugo Nagata
--
Yugo Nagata
diff --git a/src/backend/commands/dbcommands.c b/src/backend/commands/dbcommands.c
index 7a7e2c6e3e..d00ae40e19 100644
--- a/src/backend/commands/dbcommands.c
+++ b/src/backend/com
ly
due to a bug.
Best Regards,
Takuma Hoshiai
--
Yugo NAGATA
IVM_patches_v15.tar.gz
Description: application/gzip
On Fri, 10 Apr 2020 23:26:58 +0900
Yugo NAGATA wrote:
> Hi,
>
> Attached is the latest patch (v15) to add support for Incremental Materialized
> View Maintenance (IVM). It is possible to apply to current latest master
> branch.
I found a mistake of splitting patch, so I att
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
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
note to the document (rules.sgml).
Thank you for your suggestion! We'll add some description
about this to the documentation.
Regards,
Yugo Nagata
>
> execute log.
>
> ```
> [ec2-user@ip-10-0-1-10 rls]$ psql testdb -e -f rls.sql
> CREATE USER user_a;
> CREATE ROLE
>
including
UNION is concurrently unsupported, although this is not checked at
definition time and not documented either. Now we are thoroughly
investigating unsupported queries, and will add checks and
documentations for them.
Regards,
Yugo Nagata
>
> (commit id = 23151be7be8d8f8f
Yugo Nagata
On Fri, 20 Dec 2019 14:02:32 +0900
Yugo Nagata wrote:
> IVM is a way to make materialized views up-to-date in which only
> incremental changes are computed and applied on views rather than
> recomputing the contents from scratch as REFRESH MATERIALIZED VIEW
> doe
.. SET {WITH | WITHOUT} INCREMENTAL REFRESH
although this is just a idea and we will need discussion on it.
Regards,
Yugo Nagata
--
Yugo NAGATA
le_x' AS name, * FROM table_x
> > UNION
> > SELECT 'table_y' AS name, * FROM table_y
> > ;
> > CREATE VIEW
> > TABLE xy_union_v;
> > name | id |data
> > -++
> > table_y | 2 | 0.0528458947672874
>
auto_explain.log_min_duration
unless this is set -1 to disable logging. If log_before_query is
enabled, only duration time is logged after query execution as in
the case of when both log_statement and log_min_duration_statement
are enabled.
Regards,
Yugo Nagata
--
Yugo NAGATA
>F
On Wed, 26 Feb 2020 18:51:21 +0100
Julien Rouhaud wrote:
> On Thu, Feb 27, 2020 at 02:35:18AM +0900, Yugo NAGATA wrote:
> > Hi,
> >
> > Attached is a patch for allowing auto_explain to log plans before
> > queries are executed.
> >
> > Currently, a
On Thu, 27 Feb 2020 14:14:41 +0900 (JST)
Kyotaro Horiguchi wrote:
> Hello.
>
> At Thu, 27 Feb 2020 10:18:16 +0900, Yugo NAGATA wrote
> in
> > On Wed, 26 Feb 2020 18:51:21 +0100
> > Julien Rouhaud wrote:
> >
> > > On Thu, Feb 27, 2020 at 02:35:18
On Thu, 27 Feb 2020 06:27:24 +0100
Pavel Stehule wrote:
> čt 27. 2. 2020 v 6:16 odesílatel Kyotaro Horiguchi
> napsal:
>
> > Hello.
> >
> > At Thu, 27 Feb 2020 10:18:16 +0900, Yugo NAGATA
> > wrote in
> > > On Wed, 26 Feb 2020 18:51:21 +0100
> &g
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
;
SELECT * FROM mv_ivm_group ORDER BY 1;
sum
-
150
(1 row)
INSERT INTO mv_base_a VALUES(6,20);
SELECT * FROM mv_ivm_group ORDER BY 1;
sum
-
170
(1 row)
===
On Thu, 20 Jun 2019 16:44:10 +0900
Yugo Nagata wrote:
> Hi h
Hi Greg,
On Wed, 3 Apr 2019 17:41:36 -0400
Greg Stark wrote:
> On Sun, 31 Mar 2019 at 23:22, Yugo Nagata wrote:
> >
> > Firstly, this will handle simple definition views which includes only
> > selection, projection, and join. Standard aggregations (count, sum, avg,
Hi Thomas,
Thank you for your review and discussion on this patch!
> > 2019年7月8日(月) 15:32 Thomas Munro :
> >
> > > On Fri, Jun 28, 2019 at 10:56 PM Yugo Nagata wrote:
> > > > Attached is a WIP patch of IVM which supports some aggregate functions.
> >
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;
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
RIALIZED
> VIEW
>
> Typo: lager should be larger ?
>
> +postgres=# SELECt * FROM m; -- automatically updated
>
> Typo: SELECt should be SELECT ?
>
> Regards,
>
> --
> Fujii Masao
> Advanced Computing Technology Center
> Research and Development Headquarters
> NTT DATA CORPORATION
--
Yugo NAGATA
* FROM mv;
r | x
+-
20 | 200
(1 row)
cte=# INSERT INTO r VALUES (3,30);
INSERT 0 1
cte=# INSERT INTO s VALUES (1,100);
INSERT 0 1
cte=# SELECT * FROM mv;
r | x
+-
20 | 200
30 | 300
10 | 100
(3 rows)
==
Regards,
Yugo Nagata
--
Yugo NAGATA
IVM_patches_v1
suggestions would be greatly appreciated.
[1] https://wiki.postgresql.org/wiki/Incremental_View_Maintenance
[2]
https://www.postgresql.org/message-id/20191129173328.e5a0e9f81e369a3769c4fd0c%40sraoss.co.jp
[3]
https://www.postgresql.org/message-id/flat/CAEepm%3D3ZHh%3Dp0nEEnVbs1Dig_UShPzHUcMNAqvDQUgYgcDo-pA%40mail.gmail.com
Regard,
Yugo Nagata
--
Yugo NAGATA
u could tell us what your use cases of materialized
view is and whether our implementation suits your needs or not.
Regards,
Yugo Nagata
--
Yugo NAGATA
provides the exact this feature and I think this will meet
your needs.
> As soon as my coworker gets that example built up I'll send a followup with
> it attached.
Great! We are looking forward to it.
Regards,
Yugo Nagata
--
Yugo NAGATA
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
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
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
the details in the script.
>
> Do you think?
I am not sure if it is good to include psql's meta-command in pg_dump/pg_dumpall
results. Can we assume users will always use psql to restore the pg_dump
results?
Regards,
Yugo Nagata
--
Yugo Nagata
example, when
applying WAL
record is delayed due to conflict with recovery or recovery_min_apply_delay.
It might be better if if could notice that there is not requested record in the
primary's
timeline before requesting the streaming, but I don't have a good solution for
now.
Regards,
Yugo Nagata
401 - 500 of 590 matches
Mail list logo
