On 2017-10-02 23:24:30，"Alexander Korotkov" wrote:
On Sun, Oct 1, 2017 at 8:27 PM, chenhj wrote:
Now, this patch looks good for me. It applies cleanly, builds cleanly, passes
regression tests, new functionality is covered by regression tests. Code is OK
for me and docs
On 2017-10-01 04:09:19,"Alexander Korotkov" wrote:
On Sat, Sep 30, 2017 at 8:18 PM, chenhj wrote:
On 2017-09-30 02:17:54，"Alexander Korotkov" wrote:
Great. Now code of this patch looks good for me.
However, we forgot about documentation.
The result is equival
On 2017-09-30 02:17:54，"Alexander Korotkov" wrote:
Great. Now code of this patch looks good for me.
However, we forgot about documentation.
The result is equivalent to replacing the target data directory with the
source one. Only changed blocks from relation files are copied;
all
On 2017-09-30 00:53:31，"chenhj" wrote:
On 2017-09-29 19:29:40，"Alexander Korotkov" wrote:
On Fri, Sep 29, 2017 at 10:07 AM, chenhj wrote:
OK. That makes sense. Thank you for the explanation.
I still have some minor comments.
/*
+* Save the WAL filenames o
On 2017-09-29 19:29:40，"Alexander Korotkov" wrote:
On Fri, Sep 29, 2017 at 10:07 AM, chenhj wrote:
OK. That makes sense. Thank you for the explanation.
I still have some minor comments.
/*
+* Save the WAL filenames of the divergence and the current WAL insert
+
On 2017-09-29 05:31:51, "Alexander Korotkov" wrote:
On Thu, Sep 28, 2017 at 10:52 PM, chenhj wrote:
On 2017-09-29 00:43:18，"Alexander Korotkov" wrote:
On Thu, Sep 28, 2017 at 6:44 PM, chenhj wrote:
On 2017-09-28 01:29:29，"Alexander Korotkov" wrote:
It app
On 2017-09-29 00:43:18，"Alexander Korotkov" wrote:
On Thu, Sep 28, 2017 at 6:44 PM, chenhj wrote:
On 2017-09-28 01:29:29，"Alexander Korotkov" wrote:
It appears that your patch conflicts with fc49e24f. Please, rebase it.
Yes, i had rebased it, Please check the new pa
On 2017-09-28 01:29:29，"Alexander Korotkov" wrote:
It appears that your patch conflicts with fc49e24f. Please, rebase it.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Yes, i had rebased it, Please check the new patch.
-
On 2017-09-23 01:59:0, "Alexander Korotkov" wrote:
On Fri, Sep 22, 2017 at 7:16 PM, chenhj wrote:
This is the new pacth with TAP test and use Macro XLOGDIR.
Good. I took a quick look over the patch.
Why do you need master_query(), standby_query() and run_query() in
RewindTest.p
Hi
This is the new pacth with TAP test and use Macro XLOGDIR.
And i had add this patch to the commitfest,
https://commitfest.postgresql.org/15/1302/
--
Best Regards,
Chen Huajun
pg_rewind_wal_copy_reduce_v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hac
At 2017-09-17 08:33:33, "Michael Paquier" wrote:
>On Sun, Sep 17, 2017 at 3:19 AM, Alexander Korotkov
> wrote:
>> Hi!
>>
>> On Sat, Sep 16, 2017 at 5:56 PM, chenhj wrote:
>>>
>>> This patch optimizes the above mentioned issues, as follows:
&g
Hi all,
Currently, pg_rewind copies all WAL files from the source server, whether or
not they are needed.
In some circumstances, will bring a lot of unnecessary network and disk IO
consumption, and also increase the execution time of pg_rewind.
Such as when wal_keep_segments or max_wal_size is
2015-07-03 16:49:44,"David Rowley" wrote：
I'm wondering what the original test setup was. I'm assuming psql and postgres
both running on separate windows machines?
I've tested the patch just connecting to a database running on localhost and
I'm not getting much of a speedup. Perhaps 1%, if th
At 2015-04-10 20:00:35, "Michael Paquier" wrote:
>Interesting. I think that for the time being you should add it to the
>next commit fest to target an integration in 9.6 as these days we are
>busy wrapping up the last commit fest of 9.5:
>https://commitfest.postgresql.org/5/
I had add it to th
ate table and data
createdb db1000
psql -q -v total=1000 -v pnum=1000 -f createsql.sql |psql db1000
psql -c "insert into maintb values(1,'abcde12345')" db1000
2)update the parent table with one connection, 955MB memory has been used.
[chenhj@node2 part]$ pgbench -c 1 -n -T 10
Hi
In my test(PG9.3.4), i found when update a parent table which has a large
number of child tables, the execute plan will consume lots of memory. And
possibly cause OOM.
For example:
create table maintb(id int,name char(10));
create table childtb_1 (CHECK ( id BETWEEN 1 AND 200)) inherits(
16 matches
Mail list logo
