Hi,
On Friday, June 08, 2012 01:42:22 AM Simon Riggs wrote:
> On 7 June 2012 21:08, Andres Freund wrote:
> >> Moved the wakeup to a logical place outside a critical section.
> >
> > Hm. I don't really like the way you implemented that. While it reduces
> > the likelihood quite a bit it will stil
On 7 June 2012 21:08, Andres Freund wrote:
>> Moved the wakeup to a logical place outside a critical section.
> Hm. I don't really like the way you implemented that. While it reduces the
> likelihood quite a bit it will still miss wakeups if an XLogInsert pushes out
> the data because of missing
On Thursday, June 07, 2012 08:41:23 PM Simon Riggs wrote:
> On 6 June 2012 20:11, Andres Freund wrote:
> > On Tuesday, May 29, 2012 08:42:43 PM Andres Freund wrote:
> >> Hi,
> >>
> >> On Monday, May 28, 2012 07:11:53 PM Tom Lane wrote:
> >> > Andres Freund writes:
> >> > > Does anybody have a be
On 6 June 2012 20:11, Andres Freund wrote:
> On Tuesday, May 29, 2012 08:42:43 PM Andres Freund wrote:
>> Hi,
>>
>> On Monday, May 28, 2012 07:11:53 PM Tom Lane wrote:
>> > Andres Freund writes:
>> > > Does anybody have a better idea than to either call WalSndWakeup() at
>> > > essentially the wr
On Tuesday, May 29, 2012 08:42:43 PM Andres Freund wrote:
> Hi,
>
> On Monday, May 28, 2012 07:11:53 PM Tom Lane wrote:
> > Andres Freund writes:
> > > Does anybody have a better idea than to either call WalSndWakeup() at
> > > essentially the wrong places or calling it inside a critical section?
On Thursday, May 31, 2012 01:33:33 AM Fujii Masao wrote:
> On Wed, May 30, 2012 at 9:46 PM, Andres Freund
wrote:
> > On Tuesday, May 29, 2012 08:42:43 PM Andres Freund wrote:
> >> Patch attached.
> >
> > Imo this patch should be backported to 9.1, 9.0 doesn't use latches and
> > does not do expl
On Wed, May 30, 2012 at 9:46 PM, Andres Freund wrote:
> On Tuesday, May 29, 2012 08:42:43 PM Andres Freund wrote:
>> Patch attached.
> Imo this patch should be backported to 9.1, 9.0 doesn't use latches and does
> not do explicit wakeup of the sender so its not applicable there.
>
> I can prepare
On Tuesday, May 29, 2012 08:42:43 PM Andres Freund wrote:
> Patch attached.
Imo this patch should be backported to 9.1, 9.0 doesn't use latches and does
not do explicit wakeup of the sender so its not applicable there.
I can prepare a patch for 9.1 if people agree, there has been some amount of
Hi,
On Monday, May 28, 2012 07:11:53 PM Tom Lane wrote:
> Andres Freund writes:
> > Does anybody have a better idea than to either call WalSndWakeup() at
> > essentially the wrong places or calling it inside a critical section?
> >
> > Tom, what danger do you see from calling it in a critical se
Andres Freund writes:
> Does anybody have a better idea than to either call WalSndWakeup() at
> essentially the wrong places or calling it inside a critical section?
> Tom, what danger do you see from calling it in a critical section?
My concern was basically that it might throw an error. Look
On Tuesday, May 15, 2012 05:30:27 PM Andres Freund wrote:
> On Monday, May 14, 2012 07:55:32 PM Fujii Masao wrote:
> > On Mon, May 14, 2012 at 6:32 PM, Andres Freund
>
> wrote:
> > > On Friday, May 11, 2012 08:45:23 PM Tom Lane wrote:
> > >> Andres Freund writes:
> > >> > Its the only place thou
On Monday, May 14, 2012 07:55:32 PM Fujii Masao wrote:
> On Mon, May 14, 2012 at 6:32 PM, Andres Freund
wrote:
> > On Friday, May 11, 2012 08:45:23 PM Tom Lane wrote:
> >> Andres Freund writes:
> >> > Its the only place though which knows whether its actually sensible to
> >> > wakeup the walsen
On Mon, May 14, 2012 at 6:32 PM, Andres Freund wrote:
> On Friday, May 11, 2012 08:45:23 PM Tom Lane wrote:
>> Andres Freund writes:
>> > Its the only place though which knows whether its actually sensible to
>> > wakeup the walsender. We could make it return whether it wrote anything
>> > and do
On Friday, May 11, 2012 08:45:23 PM Tom Lane wrote:
> Andres Freund writes:
> > Its the only place though which knows whether its actually sensible to
> > wakeup the walsender. We could make it return whether it wrote anything
> > and do the wakeup at the callers. I count 4 different callsites whi
On 11 May 2012 19:45, Tom Lane wrote:
> Andres Freund writes:
>> Its the only place though which knows whether its actually sensible to wakeup
>> the walsender. We could make it return whether it wrote anything and do the
>> wakeup at the callers. I count 4 different callsites which would be an
>
Andres Freund writes:
> Its the only place though which knows whether its actually sensible to wakeup
> the walsender. We could make it return whether it wrote anything and do the
> wakeup at the callers. I count 4 different callsites which would be an
> annoying duplication but I don't really
On Friday, May 11, 2012 08:36:24 PM Tom Lane wrote:
> Robert Haas writes:
> > That definitely doesn't seem ideal - a lot of things can pile up
> > behind WALWriteLock. I'm not sure how big a problem it would be in
> > practice, but we generally make a practice of avoiding sending signals
> > whil
Robert Haas writes:
> That definitely doesn't seem ideal - a lot of things can pile up
> behind WALWriteLock. I'm not sure how big a problem it would be in
> practice, but we generally make a practice of avoiding sending signals
> while holding LWLocks whenever possible...
There's a good reason
On Friday, May 11, 2012 07:20:26 PM Robert Haas wrote:
> On Fri, May 11, 2012 at 1:09 PM, Fujii Masao wrote:
> > Calling WalSndWakeup() while WALWriteLock is being held might cause
> > another performance degradation. No?
>
> That definitely doesn't seem ideal - a lot of things can pile up
> behi
On Fri, May 11, 2012 at 1:09 PM, Fujii Masao wrote:
> Calling WalSndWakeup() while WALWriteLock is being held might cause another
> performance degradation. No?
That definitely doesn't seem ideal - a lot of things can pile up
behind WALWriteLock. I'm not sure how big a problem it would be in
pra
On Fri, May 11, 2012 at 4:51 AM, Andres Freund wrote:
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> index ecb71b6..7a3224b 100644
> --- a/src/backend/access/transam/xlog.c
> +++ b/src/backend/access/transam/xlog.c
> @@ -1906,6 +1906,10 @@ XLogWrite(XLogwr
On 10 May 2012 20:51, Andres Freund wrote:
> I noticed that when synchronous_commit=off were not waking up the wal sender
> latch in xact.c:RecordTransactionCommit which leads to ugly delays of approx 7
> seconds (1 + replication_timeout/10) with default settings.
> Given that were flushing the w
Hi all,
I noticed that when synchronous_commit=off were not waking up the wal sender
latch in xact.c:RecordTransactionCommit which leads to ugly delays of approx 7
seconds (1 + replication_timeout/10) with default settings.
Given that were flushing the wal to disk much sooner this appears to be
23 matches
Mail list logo
