Hi Tom,
I had replication enabled and it was working fine but I hadn't turned archive mode on yet (it was on the todo list but needed a log location).
I had WAL settings:
wal_level = hot_standby
max_wal_senders = 5
wal_keep_segments = 32
wal_buffers = 32MB
And checkpoint settings:
checkpoint_segments = 64
checkpoint_completion_target = 0.7
But pg_bulkload only puts the index updates into WAL if you also have
archive_mode = on
I guess it needs to test wal_level rather than archive mode now? It looks like changes to the project have been minimal for some time, which is a shame because it's a very useful tool.
Cheers,
James
From: Tom Lane <tgl@sss.pgh.pa.us>
To: James Cowell <jcowell@btinternet.com>
Cc: "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>; Jeff Janes <jeff.janes@gmail.com>; "wd@wdicc.com" <wd@wdicc.com>
Sent: Tuesday, 8 January 2013, 18:02
Subject: Re: [GENERAL] [Solved] Corrupt indexes on slave when using pg_bulkload on master
James Cowell <
jcowell@btinternet.com> writes:
> I enabled archive mode (which I didn't care about before as the database only holds 36 hours of data) and the indexes seem to replicate over fine. I suppose the problem here is lack of documentation, but at least the code is well commented :)
> It looks like pg_bulkload works just fine with replication so long as it's set up right.
Hm. I had thought we had interlocks in there to prevent turning on
replication unless the WAL level was sufficiently high. It sounds like
you managed to dodge that sanity check. Could you be more specific about
what your replication configuration looks like?
regards, tom lane
--
Sent via pgsql-general mailing list (
pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
