On Thu, 2010-05-13 at 20:13 +0900, Fujii Masao wrote:
> On Thu, May 13, 2010 at 8:05 PM, Simon Riggs wrote:
> > On Thu, 2010-05-13 at 19:32 +0900, Fujii Masao wrote:
> >> On Thu, May 13, 2010 at 7:22 PM, Simon Riggs wrote:
> >> > On Thu, 2010-05-13 at 19:08 +0900, Fujii Masao wrote:
> >> >
> >> >
On Thu, 2010-05-13 at 20:13 +0900, Fujii Masao wrote:
> On Thu, May 13, 2010 at 8:05 PM, Simon Riggs wrote:
> > On Thu, 2010-05-13 at 19:32 +0900, Fujii Masao wrote:
> >> On Thu, May 13, 2010 at 7:22 PM, Simon Riggs wrote:
> >> > On Thu, 2010-05-13 at 19:08 +0900, Fujii Masao wrote:
> >> >
> >> >
On Thu, May 13, 2010 at 8:05 PM, Simon Riggs wrote:
> On Thu, 2010-05-13 at 19:32 +0900, Fujii Masao wrote:
>> On Thu, May 13, 2010 at 7:22 PM, Simon Riggs wrote:
>> > On Thu, 2010-05-13 at 19:08 +0900, Fujii Masao wrote:
>> >
>> >> I was able to reproduce such a hang by not executing another
>>
On Thu, 2010-05-13 at 19:32 +0900, Fujii Masao wrote:
> On Thu, May 13, 2010 at 7:22 PM, Simon Riggs wrote:
> > On Thu, 2010-05-13 at 19:08 +0900, Fujii Masao wrote:
> >
> >> I was able to reproduce such a hang by not executing another
> >> transaction after rollback. In this case, walsender canno
On Thu, May 13, 2010 at 7:22 PM, Simon Riggs wrote:
> On Thu, 2010-05-13 at 19:08 +0900, Fujii Masao wrote:
>
>> I was able to reproduce such a hang by not executing another
>> transaction after rollback. In this case, walsender cannot replicate
>> the rollback since it's not in the disk.
>
> WALW
On Thu, 2010-05-13 at 19:08 +0900, Fujii Masao wrote:
> I was able to reproduce such a hang by not executing another
> transaction after rollback. In this case, walsender cannot replicate
> the rollback since it's not in the disk.
WALWriter is not active?
--
Simon Riggs www.2ndQuadra
On Thu, May 13, 2010 at 6:47 PM, Simon Riggs wrote:
> Rollbacks are always flushed to disk, so this explanation doesn't work.
> Even if it were it would take no longer than ~1 sec if everything were
> working correctly on the test system.
Yeah, rollbacks are always flushed sooner or later, but no
On Thu, 2010-05-13 at 10:49 +0900, Fujii Masao wrote:
> On Thu, May 13, 2010 at 3:50 AM, Robert Haas wrote:
> > rhaas=# rollback;
> > ROLLBACK
> >
> > So at this point, one would think that there are no locks hanging
> > around anywhere. Back to the standby:
> >
> > rhaas=# select * from pgbench_
On Thu, May 13, 2010 at 3:50 AM, Robert Haas wrote:
> rhaas=# rollback;
> ROLLBACK
>
> So at this point, one would think that there are no locks hanging
> around anywhere. Back to the standby:
>
> rhaas=# select * from pgbench_accounts;
>
I think that this problem happens because the WAL record
While fooling around with Hot Standby today, I did this on the master:
rhaas=# begin work;
BEGIN
rhaas=# lock table pgbench_accounts;
LOCK TABLE
Then on slave I did this:
rhaas=# select * from pgbench_accounts;
ERROR: canceling statement due to conflict with recovery
DETAIL: User query might h
10 matches
Mail list logo