<div>Thanks, I'll check it out.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 11 Jul 2022 at 13:18 Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">> Hi,<br>
> <br>
> I am trying to check how the real write split working with caching, and I<br>
> think I found an issue which return stale data.<br>
><br>
> The scenario is the following:<br>
> 1. I have a primary for write operation and read replica for reads.<br>
> <br>
> 2. I am using streaming replication mode.<br>
> <br>
> 3. When I am doing a write which cause an invalidation on the primary, how<br>
> can I be sure that in case I am trying to read from the same table and the<br>
> read replica not synced yet that I will not cached a stale data. Because in<br>
> case the read replica not synced yet what will happened is pgpool will<br>
> cache what he got from the read replica and the user will get stale data<br>
> until the next invalidation.<br>
<br>
Currently there's no way to completely avoid that. Probably you could<br>
specify memqcache_expire so that the stale cache does not remain for<br>
long time.<br>
<br>
> Any thoughts on this? Do you encounter with this issue before?<br>
<br>
The fundamental problem is, PostgreSQL's asynchronous replication does<br>
not guarantee that any committed transaction data is also committed at<br>
the same time on standby servers. The only way to guarantee it is,<br>
using synchronous replication with "synchronous_commit = remote_apply"<br>
<br>
Or you could use backend_clustering_mode = 'snapshot_isolation' in<br>
pgpool. This is superior than streaming replication in that it allows<br>
to have cross server consistent visibility. See manual for more<br>
details to know why you need that.<br>
<a href="https://www.pgpool.net/docs/latest/en/html/runtime-config-running-mode.html#GUC-SNAPSHOT-ISOLATION-MODE" rel="noreferrer" target="_blank">https://www.pgpool.net/docs/latest/en/html/runtime-config-running-mode.html#GUC-SNAPSHOT-ISOLATION-MODE</a><br>
<br>
However there are some down side in the mode including the only<br>
allowed transaction isolation mode is REPEATABLE READ.  Also the mode<br>
inherits same limitaions from native replication mode.<br>
<a href="https://www.pgpool.net/docs/latest/en/html/runtime-config-running-mode.html#GUC-REPLICATION-MODE" rel="noreferrer" target="_blank">https://www.pgpool.net/docs/latest/en/html/runtime-config-running-mode.html#GUC-REPLICATION-MODE</a><br>
<br>
Best reagards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
</blockquote></div></div>