On Wed, May 28, 2014 at 5:30 PM, Gurjeet Singh <gurj...@singh.im> wrote: > On Wed, May 28, 2014 at 2:15 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > How about the cases when shared buffers already contain some > > data: > > a. Before Readers start filling shared buffers, if this cluster wishes > > to join replication as a slave and receive the data from master, then > > this utility might need to evict some buffers filled during startup > > phase. > > A cluster that wishes to be a replication standby, it would do so > while it's in startup phase. The BlockReaders are launched immediately > on cluster reaching consistent state, at which point, I presume, in > most of the cases, most of the buffers would be unoccupied.
Even to reach consistent state, it might need to get the records from master (example to get to STANDBY_SNAPSHOT_READY state). > Hence > BlockReaders might evict the occupied buffers, which may be a small > fraction of total shared_buffers. Yes, but I think still it depends on how much redo replay happens on different pages. > > b. As soon as the server completes startup (reached consistent > > point), it allows new connections which can also use some shared > > buffers before Reader process could use shared buffers or are you > > planing to change the time when users can connect to database. > > The BlockReaders are launched immediately after the cluster reaches > consistent state, that is, just about when it is ready to accept > connections. So yes, there is a possibility that the I/O caused by the > BlockReaders may affect the performance of queries executed right at > cluster startup. But given that the performance of those queries was > anyway going to be low (because of empty shared buffers), and that > BlockReaders tend to cause sequential reads, and that by default > there's only one BlockReader active at a time, I think this won't be a > concern in most of the cases. By the time the shared buffers start > getting filled up, the buffer replacement strategy will evict any > buffers populated by BlockReaders if they are not used by the normal > queries. Even Block Readers might need to evict buffers filled by user queries or by itself in which case there is chance of contention, but again all these are quite rare scenario's. > > I am not sure if replacing shared buffer contents in such cases can > > always be considered useful. > > IMHO, all of these caveats, would affect a very small fraction of > use-cases and are eclipsed by the benefits this extension provides in > normal cases. I agree with you that there are only few corner cases where evicting shared buffers by this utility would harm, but was wondering if we could even save those, say if it would only use available free buffers. I think currently there is no such interface and inventing a new interface for this case doesn't seem to reasonable unless we see any other use case of such a interface. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
