git.postgresql.org is down/unreachable
( git://git.postgresql.org/git/postgresql.git )
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
In the 'ftp' listing, v10 appears at the bottom:
https://www.postgresql.org/ftp/source/
With all the other v10* directories at the top, we could get a lot of
people installing wrong binaries...
Maybe it can be fixed so that it appears at the top.
Thanks,
Erik Rijkers
--
Sent via
comments improvements--- src/backend/optimizer/prep/prepunion.c.orig 2017-09-24 17:40:34.888790877 +0200
+++ src/backend/optimizer/prep/prepunion.c 2017-09-24 17:41:39.796748743 +0200
@@ -2413,7 +2413,7 @@
* Find AppendRelInfo structures for all relations specified by relids.
*
* The
should come out of the commitfest app.
For me, such a list would be even more useful than any subsequently
processed results.
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
-formatting.
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
st-app. I would think it would be best to make it so that when
the thread gets set to state 'committed', the actual commit/hash is
added somewhere at the same time.
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
The feature matrix table in high-availability.sgml had a column added so
also increase the column-count (patch attached).
thanks,
Erik Rijkers--- doc/src/sgml/high-availability.sgml.orig 2017-08-17 15:04:32.535819637 +0200
+++ doc/src/sgml/high-availability.sgml 2017-08-17 15:04:46.528122345
On 2017-08-01 20:43, Robert Haas wrote:
In commit 054637d2e08cda6a096f48cc99696136a06f4ef5, I updated the
parallel query documentation to reflect recently-committed parallel
Barring objections, I'd like to commit this in the next couple of days
I think that in this bit:
occurrence is
On 2017-07-27 21:08, Mark Rofail wrote:
On Thu, Jul 27, 2017 at 7:15 PM, Erik Rijkers <e...@xs4all.nl> wrote:
It would help (me at least) if you could be more explicit about what
exactly each instance is.
I apologize, I thought it was clear through the context.
Thanks a lot. It'
posted earlier?
I guess it could be distilled from the earlier posts but when I looked
those over yesterday evening I still didn't get it.
A link to the post where the 'original patch' is would be ideal...
thanks!
Erik Rijkers
With two tables a PK table with 5 rows and an FK table with growing
On 2017-07-24 23:31, Mark Rofail wrote:
On Mon, Jul 24, 2017 at 11:25 PM, Erik Rijkers <e...@xs4all.nl> wrote:
This patch doesn't apply to HEAD at the moment ( e2c8100e6072936 ).
My bad, I should have mentioned that the patch is dependant on the
original
patch.
Here is a *unified*
a 41.68% slow down, while the
new
patch with the index has a 95.18% speed up!
[elemOperatorV4.patch]
This patch doesn't apply to HEAD at the moment ( e2c8100e6072936 ).
Can you have a look?
thanks,
Erik Rijkers
patching file doc/src/sgml/ref/create_table.sgml
Hunk #1 succeeded at 816
.
(By the way (unrelated), I also noticed only today that the new process
now wraps many of the too-long-lines; lines that were previously
unceremoniously cut off in 'mid-sentence'. That wrapping, although not
always pretty, is a really useful improvement.)
thanks,
Erik Rijkers
--
Sent via
On 2017-06-18 00:27, Peter Eisentraut wrote:
On 6/17/17 06:48, Erik Rijkers wrote:
On 2017-05-28 12:44, Erik Rijkers wrote:
re: srsubstate in pg_subscription_rel:
No idea what it means. At the very least this value 'w' is missing
from the documentation, which only mentions:
i = initalize
On 2017-05-28 12:44, Erik Rijkers wrote:
re: srsubstate in pg_subscription_rel:
No idea what it means. At the very least this value 'w' is missing
from the documentation, which only mentions:
i = initalize
d = data copy
s = synchronized
r = (normal replication)
Shouldn't we add
tablesync.c - comment improvements--- src/backend/replication/logical/tablesync.c.orig 2017-06-10 10:20:07.617662465 +0200
+++ src/backend/replication/logical/tablesync.c 2017-06-10 10:45:52.620514397 +0200
@@ -12,18 +12,18 @@
* logical replication.
*
* The initial data synchronization
On 2017-06-07 23:18, Alvaro Herrera wrote:
Erik Rijkers wrote:
Now, looking at the script again I am thinking that it would be
reasonable
to expect that after issuing
delete from pg_subscription;
the other 2 tables are /also/ cleaned, automatically, as a
consequence
On 2017-06-07 20:31, Robert Haas wrote:
[...]
[ Side note: Erik's report on this thread initially seemed to suggest
that we needed this patch to make logical decoding stable. But my
impression is that this is belied by subsequent developments on other
threads, so my theory is that this patch
ly vague and I am only posting
in the hope that Petr (or someone else) perhaps immediately understands
what goes wrong, with even his limited amount of info.
In the meantime I will try to dig up more detailed info...
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
don't know if it worked but I'm glad that it is solved ;)
Thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-05-31 16:20, Erik Rijkers wrote:
On 2017-05-31 11:16, Petr Jelinek wrote:
[...]
Thanks to Mark's offer I was able to study the issue as it happened
and
found the cause of this.
[0001-Improve-handover-logic-between-sync-and-apply-worker.patch]
This looks good:
-- out_20170531_1141
to longer (1-hour) runs (no errors so
far), and I'd like to keep track of what the most 'vulnerable'
parameters are.
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
does look as if you fixed it.
Thanks!
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-05-26 08:10, Erik Rijkers wrote:
If you run a pgbench session of 1 minute over a logical replication
connection and repeat that 100x this is what you get:
At clients 90, 64, 8, scale 25:
-- out_20170525_0944.txt
100 -- pgbench -c 90 -j 8 -T 60 -P 12 -n -- scale 25
7
ld you give the params for the successful runs?
(ideally, a grep | sort | uniq -c of the ran pgbench lines )
Can you say anything about hardware?
Thanks for repeating my lengthy tests.
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
that there seems
to be a bug, and an elusive one at that)
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
initalize
d = data copy
s = synchronized
r = (normal replication)
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-05-28 01:15, Mark Kirkwood wrote:
Also, any idea which rows are different? If you want something out of
the box that will do that for you see DBIx::Compare.
I used to save the content-diffs too but in the end decided they were
useless (to me, anyway).
--
Sent via pgsql-hackers
On 2017-05-28 01:21, Mark Kirkwood wrote:
Sorry - I see you have done this already.
On 28/05/17 11:15, Mark Kirkwood wrote:
Interesting - might be good to see your test script too (so we can
better understand how you are deciding if the runs are successful or
not).
Yes, in
On 2017-05-27 17:11, Andres Freund wrote:
On May 27, 2017 6:13:19 AM EDT, Simon Riggs <si...@2ndquadrant.com>
wrote:
On 27 May 2017 at 09:44, Erik Rijkers <e...@xs4all.nl> wrote:
I am very curious at your results.
We take your bug report on good faith, but we still haven't
On 2017-05-27 10:30, Erik Rijkers wrote:
On 2017-05-27 01:35, Mark Kirkwood wrote:
Here is what I have:
instances.sh:
testset.sh
pgbench_derail2.sh
pubsub.sh
To be clear:
( Apart from that standalone call like
./pgbench_derail2.sh $scale $clients $duration $date_str
)
I normally run
On 2017-05-27 01:35, Mark Kirkwood wrote:
On 26/05/17 20:09, Erik Rijkers wrote:
The idea is simple enough:
startup instance1
startup instance2 (on same machine)
primary: init pgbench tables
primary: add primary key to pgbench_history
copy empty tables to replica by dump/restore
primary
On 2017-05-27 01:35, Mark Kirkwood wrote:
On 26/05/17 20:09, Erik Rijkers wrote:
this whole thing 100x
Some questions that might help me get it right:
- do you think we need to stop and start the instances every time?
- do we need to init pgbench each time?
- could we just drop
version exactly because of the earlier problems with
snapbuild: I wanted a test that does a lot of starting and stopping of
publication and subscription.
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 2017-05-26 10:29, Mark Kirkwood wrote:
On 26/05/17 20:09, Erik Rijkers wrote:
On 2017-05-26 09:40, Simon Riggs wrote:
If we can find out what the bug is with a repeatable test case we can
fix it.
Could you provide more details? Thanks
I will, just need some time to clean things up
On 2017-05-26 09:40, Simon Riggs wrote:
If we can find out what the bug is with a repeatable test case we can
fix it.
Could you provide more details? Thanks
I will, just need some time to clean things up a bit.
But what I would like is for someone else to repeat my 100x1-minute
tests,
On 2017-05-26 08:58, Simon Riggs wrote:
On 26 May 2017 at 07:10, Erik Rijkers <e...@xs4all.nl> wrote:
- Do you agree this number of failures is far too high?
- Am I the only one finding so many failures?
What type of failure are you getting?
The failure is that in the result
concentrate results and
method somewhere?
Thanks,
Erik Rijkers
PS
The core of the 'pgbench_derail' test (bash) is simply:
echo "drop table if exists pgbench_accounts;
drop table if exists pgbench_branches;
drop table if exists pgbench_tellers;
drop table if exists pgbench_history;" |
On 2017-05-21 06:37, Erik Rijkers wrote:
On 2017-05-20 14:40, Michael Paquier wrote:
On Fri, May 19, 2017 at 3:01 PM, Masahiko Sawada
<sawada.m...@gmail.com> wrote:
Also, as Horiguchi-san pointed out earlier, walreceiver seems need
the
similar fix.
Actually, now that
Pity it didn't make the beta.
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-05-09 21:00, Petr Jelinek wrote:
On 09/05/17 19:54, Erik Rijkers wrote:
On 2017-05-09 11:50, Petr Jelinek wrote:
Ah okay, so this is same issue that's reported by both Masahiko Sawada
[1] and Jeff Janes [2].
[1]
https://www.postgresql.org/message-id/CAD21AoBYpyqTSw%2B%3DES
349 107145 0 17:12 ?Ss 0:27 \_ postgres: wal
sender process rijkers [local] idle
rijkers 108351 107145 0 17:12 ?Ss 0:26 \_ postgres: wal
sender process rijkers [local] idle
I have had no time to add (or view) any CPUinfo.
Erik Rijkers
out_20170509_1635.txt
Descript
On 2017-05-09 11:50, Petr Jelinek wrote:
On 09/05/17 10:59, Erik Rijkers wrote:
On 2017-05-09 10:50, Petr Jelinek wrote:
On 09/05/17 00:03, Erik Rijkers wrote:
On 2017-05-05 02:00, Andres Freund wrote:
Could you have a look?
[...]
I rebased the above mentioned patch to apply
On 2017-05-09 10:50, Petr Jelinek wrote:
On 09/05/17 00:03, Erik Rijkers wrote:
On 2017-05-05 02:00, Andres Freund wrote:
Could you have a look?
Running tests with these three patches:
0001-WIP-Fix-off-by-one-around-GetLastImportantRecPtr.patch+
0002-WIP-Possibly-more-robust-snapbuild
the much more rare stuck-DROP-SUBSCRIPTION which is mentioned in another
thread).
Sorry, I have not been able to get any thing more clear or definitive...
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 2017-05-08 13:13, Masahiko Sawada wrote:
On Mon, May 8, 2017 at 7:14 PM, Erik Rijkers <e...@xs4all.nl> wrote:
On 2017-05-08 11:27, Masahiko Sawada wrote:
FWIW, running
0001-WIP-Fix-off-by-one-around-GetLastImportantRecPtr.patch+
0002-WIP-Possibly-more-robust-snapbuild-approach
of 44c528810)
I have encountered the same condition as well in the last few days, a
few times (I think 2 or 3 times).
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ere is any other configuration of patches worth testing please let
me know)
thanks
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-04-17 15:59, Stas Kelvich wrote:
On 17 Apr 2017, at 10:30, Erik Rijkers <e...@xs4all.nl> wrote:
On 2017-04-16 20:41, Andres Freund wrote:
On 2017-04-16 10:46:21 +0200, Erik Rijkers wrote:
On 2017-04-15 04:47, Erik Rijkers wrote:
>
> 0001-Reserve-global-xmin-for-create-s
On 2017-04-16 20:41, Andres Freund wrote:
On 2017-04-16 10:46:21 +0200, Erik Rijkers wrote:
On 2017-04-15 04:47, Erik Rijkers wrote:
>
> 0001-Reserve-global-xmin-for-create-slot-snasphot-export.patch +
> 0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch+
> 0003-Prev
On 2017-04-15 04:47, Erik Rijkers wrote:
0001-Reserve-global-xmin-for-create-slot-snasphot-export.patch +
0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch+
0003-Prevent-snapshot-builder-xmin-from-going-backwards.patch +
0004-Fix-xl_running_xacts-usage-in-snapshot-builder.patch
)", File:
"pgstat.c", Line: 828)
reliably (often within a minute).
The test itself does not fail, at least not that I saw (but I only ran a
few).
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
message by a computer. I
dislike it strongly.
I would prefer the line to be more terse:
DETAIL: 90 transactions to finish.
Am I the only one who is annoyed by this phrase?
Thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
es - I
don't know which ones are essential and which may not be).
If it's at all useful I can repeat tests to show how often current
master still fails (easily 50% or so failure-rate).
This would be the pgbench-over-logical-replication test that I did so
often earlier on.
thanks,
Erik R
On 2017-04-07 22:50, Andres Freund wrote:
On 2017-04-07 22:47:55 +0200, Erik Rijkers wrote:
monitoring.sgml has one tag missing
Is that actually an issue? SGML allows skipping certain close tags, and
IIRC row is one them. We'll probably move to xml at some point not too
far away, but I
monitoring.sgml has one tag missing--- doc/src/sgml/monitoring.sgml.orig 2017-04-07 22:37:55.388708334 +0200
+++ doc/src/sgml/monitoring.sgml 2017-04-07 22:38:16.582047695 +0200
@@ -1275,6 +1275,7 @@
ProcArrayGroupUpdate
Waiting for group leader to clear transaction
fine now; I hope the above patches can all be committed soon.
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-03-09 11:06, Erik Rijkers wrote:
I use three different machines (2 desktop, 1 server) to test logical
replication, and all three have now at least once failed to correctly
synchronise a pgbench session (amidst many succesful runs, of course)
(At the moment using tese patches
Small fry gathered wile reading walsender.c ...
(to be applied to master)
Thanks,
Erik Rijkers
--- src/backend/replication/walsender.c.orig 2017-03-28 08:34:56.787217522 +0200
+++ src/backend/replication/walsender.c 2017-03-28 08:44:56.486327700 +0200
@@ -14,11 +14,11 @@
* replication-mode
On 2017-03-24 10:45, Mark Kirkwood wrote:
However one minor observation - as Michael Banck noted - the elapsed
time for slave to catch up after running:
$ pgbench -c8 -T600 bench
on the master was (subjectively) much longer than for physical
streaming replication. Is this expected?
I think
On 2017-03-23 03:28, Michael Paquier wrote:
On Thu, Mar 23, 2017 at 12:51 AM, Erik Rijkers <e...@xs4all.nl> wrote:
While trying to test pgbench's stderr (looking for 'creating tables'
in
output of the initialisation step) I ran into these two bugs (or
perhaps
better 'over
seems to make sense, but in this case not possible: pgbench
returns 0 on init with output on stderr).
make check-world passes without error
Thanks,
Erik Rijkers
--- src/test/perl/TestLib.pm.orig 2017-03-22 11:34:36.948857255 +0100
+++ src/test/perl/TestLib.pm 2017-03-22 14:36:56.793267113 +0100
On 2017-03-18 06:37, Erik Rijkers wrote:
Studying logrep yielded some more improvements to the comments in
snapbuild.c
(to be applied to master)
Attached the actual file
thanks,
Erik Rijekrs
--- src/backend/replication/logical/snapbuild.c.orig 2017-03-18 05:02:28.627077888 +0100
+++ src
Studying logrep yielded some more improvements to the comments in
snapbuild.c
(to be applied to master)
thanks,
Erik Rijekrs
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ing is done yet", but I can't
tell from your email so I thought I'd report ir anyway. Ignore as
appropriate...
Thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Improvements (grammar/typos) in the comments in snapbuild.c
To be applied to master.
thanks,
Erik Rijkers
--- src/backend/replication/logical/snapbuild.c.orig 2017-03-14 21:53:42.590196415 +0100
+++ src/backend/replication/logical/snapbuild.c 2017-03-14 21:57:57.906539208 +0100
@@ -34,7 +34,7
On 2017-03-09 11:06, Erik Rijkers wrote:
On 2017-03-08 10:36, Petr Jelinek wrote:
On 07/03/17 23:30, Erik Rijkers wrote:
On 2017-03-06 11:27, Petr Jelinek wrote:
0001-Reserve-global-xmin-for-create-slot-snasphot-export.patch +
0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch
On 2017-03-09 11:06, Erik Rijkers wrote:
file Name:
logrep.20170309_1021.1.1043.scale_25.clients_64.NOK.log
20170309_1021 is the start-time of the script
1 is master (2 is replica)
1043 is the time, 10:43, just before the pg_waldump call
Sorry, that might be confusing. That 10:43
.
thanks,
Erik Rijkers
20170307_1613.tar.bz2
Description: BZip2 compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-03-06 16:10, Erik Rijkers wrote:
On 2017-03-06 11:27, Petr Jelinek wrote:
Hi,
updated and rebased version of the patch attached.
I compiled with /only/ this one latest patch:
0001-Logical-replication-support-for-initial-data-copy-v6.patch
Is that correct, or are other patches
?
Anyway, with that one patch, and even after
alter role ... set synchronous_commit = off;
the process is very slow. (sufficiently slow that I haven't
had the patience to see it to completion yet)
What am I doing wrong?
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 2017-03-03 01:30, Petr Jelinek wrote:
With these patches:
0001-Use-asynchronous-connect-API-in-libpqwalreceiver.patch
0002-Fix-after-trigger-execution-in-logical-replication.patch
0003-Add-RENAME-support-for-PUBLICATIONs-and-SUBSCRIPTION.patch
On 2017-02-28 07:38, Erik Rijkers wrote:
On 2017-02-27 15:08, Petr Jelinek wrote:
0001-Use-asynchronous-connect-API-in-libpqwalreceiver.patch
+
0002-Fix-after-trigger-execution-in-logical-replication.patch
+
0003-Add-RENAME-support-for-PUBLICATIONs
but that's a really spectacular difference.
It's the difference between keeping up or getting lost.
Would you remind me why synchronous_commit = on was deemed a better
default? This thread isn't very clear about it (not the 'logical
replication WIP' thread).
thanks,
Erik Rijkers
--
Sent
max_sync_workers_per_subscription to 6 (from
default 2) but it doesn't help much (at all).
To be continued...
Thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-02-26 10:53, Erik Rijkers wrote:
Not yet perfect, but we're getting there...
Sorry, I made a mistake: I was running the newest patches on master but
the older versions on replica (or more precise: I didn't properly
shutdown the replica so the older version remained up and running
On 2017-02-26 01:45, Petr Jelinek wrote:
Again, much better... :
-- out_20170226_0724.txt
25 -- pgbench -c 1 -j 8 -T 10 -P 5 -n
25 -- All is well.
-- out_20170226_0751.txt
25 -- pgbench -c 4 -j 8 -T 10 -P 5 -n
25 -- All is well.
-- out_20170226_0819.txt
25 -- pgbench -c
.
(By the way, no hanged sessions so far, so that's good)
thanks
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-02-25 00:08, Petr Jelinek wrote:
There is now a lot of fixes for existing code that this patch depends
on. Hopefully some of the fixes get committed soonish.
Indeed - could you look over the below list of 8 patches; is it correct
and in the right (apply) order?
On 2017-02-24 22:58, Petr Jelinek wrote:
On 23/02/17 01:41, Petr Jelinek wrote:
On 23/02/17 01:02, Erik Rijkers wrote:
On 2017-02-22 18:13, Erik Rijkers wrote:
On 2017-02-22 14:48, Erik Rijkers wrote:
On 2017-02-22 13:03, Petr Jelinek wrote:
0001-Skip-unnecessary-snapshot-builds.patch
0002
On 2017-02-22 18:13, Erik Rijkers wrote:
On 2017-02-22 14:48, Erik Rijkers wrote:
On 2017-02-22 13:03, Petr Jelinek wrote:
0001-Skip-unnecessary-snapshot-builds.patch
0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch
0003-Fix-xl_running_xacts-usage-in-snapshot-builder.patch
0001
-execution-in-logical-replication.patch
0003-Add-RENAME-support-for-PUBLICATIONs-and-SUBSCRIPTION.patch
0001-Logical-replication-support-for-initial-data-copy-v5.patch
It works well now, or at least my particular test case seems now solved.
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list
table
(an ordered select *)
I repeated this a few times: of course, the number of rows in
pgbench_history varies a bit but otherwise it is always the same: 3
empty replica tables, pgbench_history replicated correctly.
Something is not right.
thanks,
Erik Rijkers
--
Sent via pgsql-hackers
On 2017-02-19 23:24, Erik Rijkers wrote:
0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch
0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch
0003-Fix-after-trigger-execution-in-logical-replication-v2.patch
0004-Add-RENAME-support-for-PUBLICATIONs-and-SUBSCRIPTION-v2
0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch
0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch
0003-Fix-after-trigger-execution-in-logical-replication-v2.patch
0004-Add-RENAME-support-for-PUBLICATIONs-and-SUBSCRIPTION-v2.patch
On 2017-02-19 17:21, Erik Rijkers wrote:
0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch
0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch
0003-Fix-after-trigger-execution-in-logical-replication-v2.patch
0004-Add-RENAME-support-for-PUBLICATIONs-and-SUBSCRIPTION-v2
-for-initial-data-copy-v4.patch
Improve readability of comment blocks
in src/backend/replication/logical/origin.c
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-02-11 11:16, Erik Rijkers wrote:
On 2017-02-08 23:25, Petr Jelinek wrote:
0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch
0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch
0003-Fix-after-trigger-execution-in-logical-replication-v2.patch
0004-Add-RENAME
Maybe add this to the 10 Open Items list?
https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items
It may garner a bit more attention.
Ah sorry, it's there already.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 2017-02-16 00:43, Petr Jelinek wrote:
On 13/02/17 14:51, Erik Rijkers wrote:
On 2017-02-11 11:16, Erik Rijkers wrote:
On 2017-02-08 23:25, Petr Jelinek wrote:
0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch
0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch
On 2017-02-16 00:43, Petr Jelinek wrote:
On 13/02/17 14:51, Erik Rijkers wrote:
On 2017-02-11 11:16, Erik Rijkers wrote:
On 2017-02-08 23:25, Petr Jelinek wrote:
0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch
0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch
On 2017-02-11 11:16, Erik Rijkers wrote:
On 2017-02-08 23:25, Petr Jelinek wrote:
0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch
0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch
0003-Fix-after-trigger-execution-in-logical-replication-v2.patch
0004-Add-RENAME
On 2017-02-09 02:25, Erik Rijkers wrote:
On 2017-02-08 23:25, Petr Jelinek wrote:
0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch
0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch
0003-Fix-after-trigger-execution-in-logical-replication-v2.patch
0004-Add-RENAME
than
1 client yet.
Can you have a look whether this is reproducible elsewhere?
thanks,
Erik Rijkers
#!/bin/sh
# assumes both instances are running, on port 6972 and 6973
logfile1=$HOME/pg_stuff/pg_installations/pgsql.logical_replication/logfile.logical_replication
logfile2=$HOME/pg_stuff
would prefer to just remove /all/ the interactive
output.
I would vote to just make it remain silent if there is no error. (and
if there is an error, issue a message and exit)
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
.patch
0001-Logical-replication-support-for-initial-data-copy-v4.patch
test 'object_address' fails, see atachment.
That's all I found in a quick first trial.
thanks,
Erik Rijkers
*** /home/aardvark/pg_stuff/pg_sandbox/pgsql.logical_replication/src/test/regress/expected/object_address.out 2017
-uninitialized]
rel->rd_amcache = cache;
^~~
which hopefully can be prevented...
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ndented 1 place
too much.
The help text has a few typos (some multiple times):
queires -> queries
exectue -> execute
subsequennt -> subsequent
Thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
On 2017-02-02 22:44, Tom Lane wrote:
Erik Rijkers <e...@xs4all.nl> writes:
Something is broken in HEAD:
Fixed, thanks for the report!
Indeed, the complicated version of the script runs again as before.
Thank you very much,
Erik Rijkers
--
Sent via pgsql-hackers mailing list
regexp* functions aren't doing anything particularly
useful anymore here; they did in the more complicated original (which I
had used for years).
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1 - 100 of 353 matches
Mail list logo
