On Fri, Aug 14, 2015 at 9:54 AM, Jeff Janes wrote:
> On Fri, Aug 14, 2015 at 9:34 AM, Josh Berkus wrote:
>
>>
>> On 08/13/2015 01:59 PM, Jeff Janes wrote: execute on the
>>
>> > Once the commit of the whole-table update has replayed, the problem
>> > should go way instantly because at that point
On Fri, Aug 14, 2015 at 9:34 AM, Josh Berkus wrote:
>
> On 08/13/2015 01:59 PM, Jeff Janes wrote: execute on the
>
> > Once the commit of the whole-table update has replayed, the problem
> > should go way instantly because at that point each backend doing the
> > seqscan will find the the transac
On 08/13/2015 01:24 PM, Kevin Grittner wrote:
>> Thing is, the update all rows only takes 2.5 seconds to execute on the
>> master. So even if the update is blocking the seq scans on the replica
>> (and I can't see why it would), it should only block them for < 3 seconds.
>
> Visibility hinting and
On Thu, Aug 13, 2015 at 10:09 AM, Josh Berkus wrote:
> Setup:
>
> * PostgreSQL 9.3.9
> * 1 master, 1 replica
> * Tiny database, under 0.5GB, completely cached in shared_buffers
> * 90% read query traffic, which is handled by replica
> * Traffic in the 1000's QPS.
>
> The wierdness:
>
> Periodical
Josh Berkus wrote:
> Periodically the master runs an "update all rows" query on the main
> table in the database. When this update hits the replica via
> replication stream, *some* (about 5%) of the queries which do seq scans
> will stall for 22 to 32 seconds (these queries normally take about
>
