|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Martijn van Oosterhout <kleptog(at)svana(dot)org>|
|Cc:||"Todd A(dot) Cook" <tcook(at)blackducksoftware(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: WAL logging problem in 9.4.3?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2015-07-21 21:37:41 +0200, Martijn van Oosterhout wrote:
> On Tue, Jul 21, 2015 at 02:24:47PM -0400, Todd A. Cook wrote:
> > Hi,
> > This thread seemed to trail off without a resolution. Was anything done?
> Not that I can tell.
Heikki and I had some in-person conversation about it at a conference,
but we didn't really find anything we both liked...
>I was the original poster of this thread. We've
> worked around the issue by placing a CHECKPOINT command at the end of
> the migration script. For us it's not a performance issue, more a
> correctness one, tables were empty when they shouldn't have been.
If it's just correctness, you could just use wal_level = archive.
> I'm hoping a fix will appear in the 9.5 release, since we're intending
> to release with that version. A forced checkpoint every now and them
> probably won't be a serious problem though.
We're imo going to have to fix this in the back branches.
|Next Message||Etsuro Fujita||2015-07-22 06:45:55||Re: Typo in comment in setrefs.c|
|Previous Message||Etsuro Fujita||2015-07-22 06:45:28||fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it?|