On Fri, Oct 14, 2016 at 11:29 PM, Kevin Grittner <kgri...@gmail.com> wrote:
> On Fri, Oct 14, 2016 at 8:53 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Fri, Oct 14, 2016 at 1:40 PM, Masahiko Sawada <sawada.m...@gmail.com>
>> wrote:
>
>>> For
I expected to get
"snapshot too old" error at #3 where I read test table again after
enough time. But I could never get "snapshot too old" error at #3.
On the other hand, when I set old_snapshot_threshold = 0 I can got the
error at #3.
Is this expected behavior?
Regards,
--
Ma
On Fri, Oct 7, 2016 at 4:25 PM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
> On Thu, Oct 6, 2016 at 2:52 PM, Amit Langote
> <langote_amit...@lab.ntt.co.jp> wrote:
>> On 2016/10/06 17:45, Ashutosh Bapat wrote:
>>> On Thu, Oct 6, 2016 at 1:34 PM, Masah
On Wed, Sep 28, 2016 at 5:14 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Sat, Sep 24, 2016 at 5:37 PM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>> I still vote for changing behaviour of existing syntax 'k (n1, n2)' to
>> quorum commit.
>&
On Thu, Oct 6, 2016 at 12:11 AM, Jeff Janes <jeff.ja...@gmail.com> wrote:
> On Wed, Oct 5, 2016 at 7:28 AM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>>
>> Hi all,
>>
>> I found the kind of strange behaviour of the autovacuum launcher
gt; requiring a certain minimum number of dead index tuples that would be
> required before index vacuuming occurs; prior to that, we'd just
> truncate to dead line pointers and leave those for the next vacuum
> cycle. This might need some refinement - should it be page-based? -
> but the basic
eah, the freeze map would be effective especially for static table.
Since we can skip to vacuum frozen page and the freezing tuples is not
big pain usually, we might want to change autovacuum more aggressive
to freeze the page by reducing default value of vacuum_freeze_min_age.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
parated issue[2].
> 2PC implementation OR guaranteeing that all the legs of a transaction
> commit or roll back, is an essential block of any kind of distributed
> transaction manager. So, we should at least support that one, before
> attacking further problems.
I agree.
[1]https://en.wikipedia.
launcher process after started?
autovacuum.c:L1604
/* wake up the launcher */
if (AutoVacuumShmem->av_launcherpid != 0)
kill(AutoVacuumShmem->av_launcherpid, SIGUSR2);
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source So
phase is completed.
Otherwise the next transaction can see data that is not committed yet
on remote server.
> , which can take
> quite long (or never) if one of the servers has crashed in between.
>
>>
>> Or are you and Sawada-san talking about the case where the user issued
>
trol data. System catalog is out
> of question since a rollback of local transaction would make those
> rows in the system catalog invisible. That's the reason, why I chose
> to write the foreign prepared transactions to files rather than a
> system catalog.
>
We can store the lowest in-dou
On Wed, Sep 28, 2016 at 3:30 PM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
> On Wed, Sep 28, 2016 at 10:43 AM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>> On Tue, Sep 27, 2016 at 9:06 PM, Ashutosh Bapat
>> <ashutosh.ba...@enterprisedb.com
On Fri, Sep 30, 2016 at 2:40 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> On Fri, Sep 30, 2016 at 1:26 PM, Kyotaro HORIGUCHI
> <horiguchi.kyot...@lab.ntt.co.jp> wrote:
>> Hello,
>>
>> At Fri, 30 Sep 2016 13:11:21 +0900, Masahiko Sawada <sawada.m...@gmail.com>
>> wrote in
8_vm") that lead an error, is it
possible that you check if there is '\r\n' [0d 0a] character in that
_vm file or share that _vm file with us?
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Sep 30, 2016 at 1:26 PM, Kyotaro HORIGUCHI
<horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello,
>
> At Fri, 30 Sep 2016 13:11:21 +0900, Masahiko Sawada <sawada.m...@gmail.com>
> wrote in
bytes because
probably _vm file is corrupted?
> if ((src_fd = open(fromfile, O_RDONLY, 0)) < 0)
It could be happen that read() syscall stopped to read at where it
reads bits representing '\n' characters (0x5c6e) because we don't open
file with O_BINARY flag?
Regards,
--
Masahiko Sawad
On Tue, Sep 27, 2016 at 9:06 PM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
> On Tue, Sep 27, 2016 at 2:54 PM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>> On Mon, Sep 26, 2016 at 9:07 PM, Ashutosh Bapat
>> <ashutosh.ba...@enterprisedb.com>
On Mon, Sep 26, 2016 at 9:07 PM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
> On Mon, Sep 26, 2016 at 5:25 PM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>> On Mon, Sep 26, 2016 at 7:28 PM, Ashutosh Bapat
>> <ashutosh.ba...@enterprisedb.com>
to discuss what the best approach is for transaction
involving foreign servers.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
xisting syntax 'k (n1, n2)' to
quorum commit.
That is,
1. 'First k (n1, n2, n3)' means that the master server waits for ACKs
from k standby servers whose name appear earlier in the list.
2. 'Any k (n1, n2, n3)' means that the master server waits for ACKs
from any k listed standby servers.
3. 'n1,
stment.
>
Commit e7010ce seems to forget to change help message of pg_ctl.
Attached patch.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
fix_pg_ctl_help.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-
On Fri, Sep 9, 2016 at 6:23 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 8 September 2016 at 10:26, Masahiko Sawada <sawada.m...@gmail.com> wrote:
>
>> "k (n1, n2, n3)" == "first k (n1, n2, n3)" doesn't break backward
>> compatibility bu
On Thu, Sep 15, 2016 at 11:44 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Sep 15, 2016 at 7:21 AM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>> I'm implementing this patch but I need to resolve the problem
>> regarding lock for extensio
structure.
>
Yeah, the chunking approach Robert suggested seems like a good idea
but considering implementing parallel vacuum, it would be more
complicated IMO.
I think It's better the multiple process simply allocate memory space
for its process than that the single process allocate huge memory
s
> wrote:
>> > On Tue, Aug 23, 2016 at 6:11 PM, Michael Paquier
>> > <michael.paqu...@gmail.com> wrote:
>> >> On Tue, Aug 23, 2016 at 8:02 PM, Masahiko Sawada
>> >> <sawada.m...@gmail.com> wrote:
>> >>> As for PoC, I implemente
On Wed, Sep 14, 2016 at 2:17 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Sep 8, 2016 at 1:32 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
>> Attached patch add --disable-page-skipping option to vacuumed command for
>> 9.6.
>> If by any chance
On Fri, Sep 9, 2016 at 12:33 PM, Pavan Deolasee
<pavan.deola...@gmail.com> wrote:
>
>
> On Thu, Sep 8, 2016 at 11:40 PM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>>
>>
>>
>> Making the vacuum possible to choose between two data representa
erflow region than we provisioned for. There will be some
> challenges in converting representation mid-way, especially in terms of
> memory allocation, but I think those can be sorted out if we think that the
> idea has merit.
>
Making the vacuum possible to choose between two data representations
sounds good.
I implemented the patch that changes dead tuple representation to bitmap before.
I will measure the performance of bitmap representation again and post them.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
In this case, I think that this option for vacuumdb would be convenient.
Please give me feedback.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
disable_page_skipping_option_for_vacuumdb_v1.patch
Description: Binary data
--
Sent via pgsql-hackers
On Thu, Sep 8, 2016 at 11:27 PM, Jim Nasby <jim.na...@bluetreble.com> wrote:
> On 9/8/16 3:03 AM, Masahiko Sawada wrote:
>>
>> Current manual vacuum doesn't output how may all_frozen pages we
>> skipped according to visibility map.
>> That's why I attached 0001 pa
t;
+1.
"k (n1, n2, n3)" == "first k (n1, n2, n3)" doesn't break backward
compatibility but most users would think "k(n1, n2, n3)" as quorum
after introduced quorum.
I wish we can change the s_s_names syntax of 9.6 to "first k(n1, n2,
n3)" style before 9.6 re
On Wed, Sep 7, 2016 at 12:47 AM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> On Tue, Sep 6, 2016 at 11:08 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> On 29 August 2016 at 14:52, Fujii Masao <masao.fu...@gmail.com> wrote:
>>> On Sat, Aug
s you say, but you don't need
> to do qsort() or anything like that. You're just replacing a single
> flat array with a data structure that can be grown incrementally in
> fixed-size chunks.
>
If we replaced dead_tuples with an array-of-array, isn't there
negative performance impact fo
On Wed, Sep 7, 2016 at 4:11 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 7 September 2016 at 04:13, Masahiko Sawada <sawada.m...@gmail.com> wrote:
>
>> Since current HEAD could scan visibility map twice, the execution time
>> of Patched is approximately
On Wed, Sep 7, 2016 at 1:47 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Sep 5, 2016 at 8:57 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
>>> What performance difference does this make, in a realistic use case?
>>
>> I have yet to measure perfo
On Tue, Sep 6, 2016 at 11:08 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 29 August 2016 at 14:52, Fujii Masao <masao.fu...@gmail.com> wrote:
>> On Sat, Aug 6, 2016 at 6:36 PM, Petr Jelinek <p...@2ndquadrant.com> wrote:
>>> On 04/08/16 06:40, Masahiko S
On Mon, Sep 5, 2016 at 6:27 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 4 August 2016 at 05:57, Masahiko Sawada <sawada.m...@gmail.com> wrote:
>
>> While reviewing freeze map code, Andres pointed out[1] that
>> lazy_scan_heap could accesses visibility map t
.
>
+1
>
> IIRC there was an attempt late in the 9.5 cycle, but Bruce
>
(IIRC) ran out of steam. And nobody picked it up again ... :(
>
>
It may be worth to look at
https://www.postgresql.org/message-id/CAMkU%3D1w3osJJ2FneELhhNRLxfZitDgp9FPHee08NT2FQFmz_pQ%40mail.gmail.com
I've updated this patch to apply to current HEAD, can propose it to pg10.
Regards,
--
Masahiko Sawada
--
Regards,
--
Masahiko Sawada
On Fri, Aug 26, 2016 at 3:13 PM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
>
>
> On Fri, Aug 26, 2016 at 11:37 AM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>>
>> On Fri, Aug 26, 2016 at 3:03 PM, Ashutosh Bapat
>> <ashutosh.ba...@e
On Fri, Aug 26, 2016 at 3:03 PM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
>
>
> On Fri, Aug 26, 2016 at 11:22 AM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>>
>> On Fri, Aug 26, 2016 at 1:32 PM, Vinayak Pokale <vinpok...@gmail.com>
ble or all-frozen pages.
For example,
1. Create very large table.
2. Execute VACUUM FREEZE to freeze all pages of table.
3. Measure the execution time of VACUUM FREEZE.
I hope that the second VACUUM FREEZE become fast a little.
I modified the comment, and attached v2 patch.
Regards,
--
M
On Tue, Aug 23, 2016 at 10:50 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Aug 23, 2016 at 7:02 AM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>> I'd like to propose block level parallel VACUUM.
>> This feature makes VACUUM possible to use
ve vacuum of single index by changing data
representation of dead tuple to bitmap.
It can reduce the number of index whole scan during vacuum and make
comparing the index item to the dead tuples faster.
This is a listed on Todo list and I've implemented it.
Regards,
--
Masahiko Sawada
--
S
index vacuum.
Still lots of work to do but attached PoC patch.
Feedback and suggestion are very welcome.
Regards,
--
Masahiko Sawada
From b25d491a05a43fb7adf014b2580c71ec7adb75a2 Mon Sep 17 00:00:00 2001
From: Masahiko Sawada <sawada.m...@gmail.com>
Date: Mon, 8 Aug 2016 16:43:35 -0700
S
or "on". Do
> you have something else in mind?
>
+1 for adding "remote_flush" as a synonym for "on".
It doesn't break backward compatibility.
Regards,
--
Masahiko Sawada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Aug 19, 2016 at 7:06 AM, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> On 7/12/16 9:55 PM, Masahiko Sawada wrote:
>> And what I think is pg_baseback never remove the directory specified
>> by -D option even if execution is failed. initdb command behave
re the information of 32672 heap
pages (255MB), but it would be cost if autovacuum scan whole
visibility map for all tables.
So I think that it's better to provide
autovacuum_vacuum_pagevisible_factor as a relopts.
And the autovacuum scans or samples the visibility map of table that
autovacuum_vacuum_page
On Tue, Aug 9, 2016 at 5:13 PM, Craig Ringer <cr...@2ndquadrant.com> wrote:
> On 9 August 2016 at 15:59, Masahiko Sawada <sawada.m...@gmail.com> wrote:
>
>>
>>
>> The logical replication launcher process and the apply process are
>> implemente
files are old.
And this patch has some whitespace problems.
Please run "git show --check" or "git diff origin/master --check"
Regards,
--
Masahiko Sawada
diff --git a/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c b/src/backend/replication/libpqwalreceiver/libpqwa
this is an optimization,
not bug fix, I'd like to propose it again.
Please give me feedback.
[1]
https://www.postgresql.org/message-id/20160505000840.epatoq6d2e556446%40alap3.anarazel.de
Regards,
--
Masahiko Sawada
diff --git a/src/backend/commands/vacuumlazy.c b/src/backend/commands/vacuumlazy.c
index
On Wed, Aug 3, 2016 at 3:05 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Wed, Aug 3, 2016 at 2:52 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
>> I was thinking that the syntax for quorum method would use '[ ... ]'
>> but it will be confused with '(
'[ ... ]'
but it will be confused with '( ... )' priority method used.
001 patch adds 'Any N ( ... )' style syntax but I know that we still
might need to discuss about better syntax, discussion is very welcome.
Attached draft patch, please give me feedback.
Regards,
--
Masahiko Sawada
diff --git a/src/backend/replication
On Wed, Jul 20, 2016 at 5:08 AM, Alvaro Herrera
<alvhe...@2ndquadrant.com> wrote:
> Masahiko Sawada wrote:
>> Hi all,
>>
>> The file 006_logical_decoding_timelines.pl was removed by the commit c1543a8.
>> But currently 005_***.pl and 007_***.pl exist on source t
Hi all,
The file 006_logical_decoding_timelines.pl was removed by the commit c1543a8.
But currently 005_***.pl and 007_***.pl exist on source tree.
Should we change its file number to 006?
Please find attached patch renames 007_sync_rep.pl to 006_sync_rep.pl.
Regards,
--
Masahiko Sawada
0001
Hi all,
Attached patch fixes small typo in contrib/postgres_fdw/deparse.c
s/whenver/whenever/g
Regards,
--
Masahiko Sawada
fix_small_typo_in_deparse_c.patch
Description: binary/octet-stream
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
iled. initdb command behaves so.
I think it's helpful for backup operation.
Regards,
Masahiko Sawada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jul 8, 2016 at 10:24 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Thu, Jul 7, 2016 at 12:34 PM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>> Than you for reviewing!
>>
>> On Thu, Jul 7, 2016 at 7:06 AM, Andres Freund <and...@anaraze
Than you for reviewing!
On Thu, Jul 7, 2016 at 7:06 AM, Andres Freund <and...@anarazel.de> wrote:
> On 2016-07-05 23:37:59 +0900, Masahiko Sawada wrote:
>> diff --git a/src/backend/access/heap/heapam.c
>> b/src/backend/access/heap/heapam.c
>> index 57da57a..fd66527
Hi all,
Attached patch fixes the typo in jsonb.c
Please find it.
Regards,
--
Masahiko Sawada
diff --git a/src/backend/utils/adt/jsonb.c b/src/backend/utils/adt/jsonb.c
index 256ef80..ab46823 100644
--- a/src/backend/utils/adt/jsonb.c
+++ b/src/backend/utils/adt/jsonb.c
@@ -1849,7 +1849,7
On Mon, Jul 4, 2016 at 5:44 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> On Sat, Jul 2, 2016 at 12:34 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Fri, Jul 1, 2016 at 7:52 PM, Masahiko Sawada <sawada.m...@gmail.com>
>> wrote:
>>> On
On Sat, Jul 2, 2016 at 12:17 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Sat, Jul 2, 2016 at 12:53 AM, Andres Freund <and...@anarazel.de> wrote:
>> On 2016-07-01 15:18:39 -0400, Robert Haas wrote:
>>> On Fri, Jul 1, 2016 at 10:22 AM, Masahiko Sawada <
On Sat, Jul 2, 2016 at 12:34 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Fri, Jul 1, 2016 at 7:52 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
>> On Fri, Jul 1, 2016 at 11:12 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>>
>>> Why
On Sat, Jul 2, 2016 at 6:34 AM, Andres Freund <and...@anarazel.de> wrote:
> Hi,
>
> On 2016-06-23 16:24:12 +0900, Masahiko Sawada wrote:
>> By commit 428b1d6b, function WritebackContextInit is added but the
>> comment of this function seems to be incorrect.
>> *ma
On Fri, Jul 1, 2016 at 11:12 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Thu, Jun 30, 2016 at 8:10 PM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>> On Thu, Jun 30, 2016 at 3:12 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>> On Thu,
crashed after flushed heap
but not vm, after crash recovery the heap is still marked all-visible
on vm.
This case could be happen even on released branched, and could make
IndexOnlyScan returns wrong result?
Regards,
--
Masahiko Sawada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
th cases unfortunately. We could try to
>> add some optimizations (e.g. only release lock & WAL log if the target
>> page, via fsm, is before the current one), but I don't really want to go
>> there in the back branches.
>>
>
> You are right, I think we can try such an optimi
On Tue, Jun 28, 2016 at 8:06 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> On Tue, Jun 21, 2016 at 6:59 AM, Andres Freund <and...@anarazel.de> wrote:
>> On 2016-06-20 17:55:19 -0400, Robert Haas wrote:
>>> On Mon, Jun 20, 2016 at 4:24 PM, Andres Fre
or out - and there's certainly callers
> doing that - we'd "leak" a toasted datum.
Sorry for interrupt you, but I have a question about this case.
Is there case where we back to l2 after we created toasted
datum(called toast_insert_or_update)?
IIUC, after we stored toast datum we just insert heap tuple and log
WAL (or error out for some reasons).
Regards,
--
Masahiko Sawada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
kContextInit(WritebackContext *context, int *max_coalesce);
Regards,
--
Masahiko Sawada
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index a67e518..76ade37 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -4160
On Mon, Jun 20, 2016 at 3:42 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Mon, Jun 20, 2016 at 11:48 AM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>>
>> Hi all,
>>
>> My colleague noticed that the output of EXPLAIN ANALYZE doesn't work
>
(1000 maybe better)
After spent time to investigate this behaviour, ISTM that the problem
is nloops of Parallel Seq Scan.
Parallel Seq Scan is done only once, but nloops is incremented to 3.
So its "actual rows" is calculated 333(1000 / 3) at explain.c:L1223.
Is it a bug?
Re
On Thu, Jun 16, 2016 at 10:03 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Jun 16, 2016 at 2:33 AM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>> Option name DISABLE_PAGE_SKIPPING is good to me.
>> I'm still working on this, but
ew comments.
---
+CREATE FUNCTION pg_truncate_visibility_map(regclass)
+RETURNS void
+AS 'MODULE_PATHNAME', 'pg_truncate_visibility_map'
+LANGUAGE C STRICT
+PARALLEL UNSAFE; -- let's not make this any more dangerous
+
"REVOKE ALL ON FUNCTION pg_truncate_visibility_map(regclass) FROM
PUBLIC;&quo
nd errors out. Backend #2 writes the page to the OS. DBA
> takes a hot backup, tearing the page in the middle of XMAX. Oops.
>
> I'm not sure what to do about this: this part of the heap_update()
> logic has been like this forever, and I assume that if it were easy to
> refactor this away, somebo
ally made the
some situations where database is corrupted and tested it, but ISTM
that this tool works fine.
It doesn't mean proposing as a new feature of course, but please use
it as appropriate.
Regards,
--
Masahiko Sawada
corrupted_test.sql
Description: Binary data
set_spurious_vm_status.patch
On Wed, Jun 8, 2016 at 12:19 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Tue, Jun 7, 2016 at 10:10 PM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>>
>> Thank you for implementing the patch.
>>
>> I've not test it deeply but here are som
le.
That is, it doesn't care in case where the all-frozen page mistakenly
has dead-frozen tuple.
I think this tool should check such case, otherwise the function name
would need to be changed.
+ /* Clean up. */
+ if (vmbuffer != InvalidBuffer)
+ ReleaseBuffer(vmbuffer);
I t
]
hoge_user masahiko pg_signal_backend
After manual input of the 'mapping', 'for' is added by tab completion.
It means that the tab completion for 'mapping' is not working.
Patch attached.
Please review it.
Regards,
--
Masahiko Sawada
fix_tab_completion_for_user_mapping.patch
ing this parameter as a reloption.
We set it true only when the serious bug is discovered and we want to
re-generate the visibility maps of specific tables.
I thought that control by GUC parameter would be convenient rather
than adding the new option.
Regards,
--
Masahiko Sawada
--
Sent via pgsql-
On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> On Sat, Jun 4, 2016 at 12:59 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> On Fri, Jun 3, 2016 at 11:21 AM, Masahiko Sawada <sawada.m...@gmail.com>
>> wrote:
>>>>
On Sat, Jun 4, 2016 at 12:59 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Jun 3, 2016 at 11:21 AM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>>> Can you submit that part as a separate patch?
>>
>> Attached.
>
> Thanks, committed.
>
On Sat, Jun 4, 2016 at 12:41 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Jun 3, 2016 at 10:25 PM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>>>> + charnew_vmbuf[BLCKSZ];
>>>> +
new_cur += BITS_PER_HEAPBLOCK;
>>
>> I'm not sure I'm understanding the point of the BITS_PER_HEAPBLOCK_OLD
>> stuff - as long as it's hardcoded into rewriteVisibilityMap() we'll not
>> be able to have differing ones anyway, should we decide to add a
On Sat, Jun 4, 2016 at 12:08 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Jun 3, 2016 at 10:49 AM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>> That patch also incorporates the following review comment.
>> We can push at least this fix
On Fri, Jun 3, 2016 at 11:03 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Jun 2, 2016 at 11:24 AM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>> Attached patch optimises skipping pages logic so that blkno can jump to
>> next_unskippable_block dire
> Yep, I had the same problem.
>> Hm. This also doubles the number of VM accesses. While I guess that's
>> not noticeable most of the time, it's still not nice; especially when a
>> large relation is entirely frozen, because it'll mean we'll sequentially
>> go through the
;>>> synchronous_standbys (adjust to correct english if necesary)?
>>>
>>>
>>> If the existing values are still going to be accepted, then I would leave
>>> it as is.
>>
>>
>> +1
>
> +1. We've made quite a lot of deal to take a
/*
>> +* If the page is marked as all-visible but not all-frozen,
>> we should
>> +* so mark it. Note that all_frozen is only valid if
>> all_visible is
>> +* true, so we must check both.
>> +
your
> efforts toward speedy resolution. Thanks.
>
> [1]
> http://www.postgresql.org/message-id/20160527025039.ga447...@tornado.leadboat.com
Thank you for notification.
Regarding check tool for visibility map is still under the discussion.
I'm going to address other review comments,
e? I agree that SCAN_ALL doesn't fit. I am not trying to
> pull a left turn but is there a technical reason we don't just make FULL do
> this?
>
FULL option requires AccessExclusiveLock, which could be a problem.
Regards,
--
Masahiko Sawada
--
Sent via pgsql-hackers ma
On Tue, May 17, 2016 at 3:32 PM, Alvaro Herrera
<alvhe...@2ndquadrant.com> wrote:
> Masahiko Sawada wrote:
>> On Mon, May 16, 2016 at 10:49 AM, Robert Haas <robertmh...@gmail.com> wrote:
>
>> > We should support scan_all only with the new-style options syntax
On Mon, May 16, 2016 at 10:49 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, May 10, 2016 at 10:40 PM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>> Or second way I came up with is having tool to remove particular _vm
>> file safely, which is execut
On Tue, May 10, 2016 at 11:30 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, May 9, 2016 at 7:40 PM, Ants Aasma <ants.aa...@eesti.ee> wrote:
>> On Mon, May 9, 2016 at 10:53 PM, Robert Haas <robertmh...@gmail.com> wrote:
>>> On Sun, May 8, 2016 at
es);
The verbose information about skipping frozen page is emitted by only
autovacuum.
But I think that this information is also helpful for manual vacuum.
Please find attached patch which fixes that.
Regards,
--
Masahiko Sawada
diff --git a/src/backend/commands/vacuumlazy.c b/src/backend/command
On Sun, May 8, 2016 at 3:18 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> On Sat, May 7, 2016 at 11:08 PM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>> On Sat, May 7, 2016 at 6:00 AM, Joshua D. Drake <j...@commandprompt.com>
>> wrote:
>>>
On Sat, May 7, 2016 at 11:08 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> On Sat, May 7, 2016 at 6:00 AM, Joshua D. Drake <j...@commandprompt.com>
> wrote:
>> On 05/06/2016 01:58 PM, Stephen Frost wrote:
>>>
>>> * Joshua D. Drake (j...@commandp
As Joshua mentioned, FORCE word might imply doing VACUUM while plowing
through locks.
I guess that it might confuse the users.
IMO, since this option will be a way for emergency, SCANALL word works for me.
Or other ideas are,
VACUUM IGNOREVM
VACUUM RESCURE
Regards,
--
Masahiko Sawada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, I've made no
> attempt to call out which are the most significant changes. I've not
> tried to isolate the non-backwards-compatible items, either.
>
> Please review and comment before Monday, if you can.
>
+Avoid re-vacuuming pages containing only frozen tuples
+(Ma
t; did I miss anything important?
>
That's all.
Regards,
--
Masahiko Sawada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to any commit preceding this one and following the one
>>> mentioned above would result in invalid visibility map contents on the
>>> new cluster, very possibly leading to data corruption. This plugs
>>> that hole.
>>>
>>> Masahiko Sawada, reviewed by Jef
501 - 600 of 730 matches
Mail list logo
