Jan Wieck JanWieck at Yahoo.com
Wed Jan 30 10:14:11 PST 2013
Is anyone else getting these?


Jan


-------- Original Message --------
Subject: Failure Notice
Date: Wed, 30 Jan 2013 18:12:15 -0000
From: MAILER-DAEMON at yahoo.com
To: JanWieck at yahoo.com

Sorry, we were unable to deliver your message to the following address.

<bugzilla-daemon at main.slony.info>:
Remote host said: 550 5.1.1 <bugzilla-daemon at main.slony.info>: Recipient 
address rejected: User unknown in local recipient table [RCPT_TO]

--- Below this line is a copy of the message.

Received: from [98.138.90.48] by nm7.bullet.mail.ne1.yahoo.com with 
NNFMP; 30 Jan 2013 18:12:14 -0000
Received: from [98.138.226.128] by tm1.bullet.mail.ne1.yahoo.com with 
NNFMP; 30 Jan 2013 18:12:14 -0000
Received: from [127.0.0.1] by smtp215.mail.ne1.yahoo.com with NNFMP; 30 
Jan 2013 18:12:14 -0000
X-Yahoo-Newman-Id: 152795.8992.bm at smtp215.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: UrRB4BQVM1kkM9oBhhXERLbqOpczvlbkDUvPa9tNLTxIByk
  EijY6YfSwc_CsOoiGBFZnwB8rqvI_3go_H5sVga2mlQn082rgWc_OT.W_gg7
  T6hrowA9nbM6WgTRpRjjYLhWgW3eo0UGjgWYwpffVhGZxyLyHpwbWcsNHPyh
  vnIf0H4wfwUvzjq1N7Lct4IRkBieHpJulm74w5cHOhQEI1BJy2m0VhNkEtwN
  n.9f6jScbgnfOYYcEKL.iJrcCna9Yb19VIQpvakUlO8du7R930KkskyfrZV8
  X3dFTZP40KOjGDw7ulHK8UboBDd3jMTmr5l6YTZbJeRkqJV1pjAAxNYN7y6.
  FyfugsouD2pFCwYLwuJb35P9Pc0zymk1YiLAPy3dJ.xX6DefYTqcynhasnWk
  MA4oVtV4F2RiMOi2AGp8lYgj7CaZOLDBjeL37P3xsA8fgdckzwnbflBJ6UVE
  fFqK.HowBG4ygXZz6TLqslXdwOrroD7hHW9DaaaSwKZtUi1sMVKWyh.dQ
X-Yahoo-SMTP: auMih2KswBAUyVy7YHrIeglmGa00
Received: from [172.21.8.21] (JanWieck at 173.49.215.95 with plain)
         by smtp215.mail.ne1.yahoo.com with SMTP; 30 Jan 2013 10:12:14 
-0800 PST
Message-ID: <51096282.8080102 at Yahoo.com>
Date: Wed, 30 Jan 2013 13:12:18 -0500
From: Jan Wieck <JanWieck at Yahoo.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 
Thunderbird/17.0.2
MIME-Version: 1.0
To: Steve Singer <ssinger at ca.afilias.info>
CC: slony1-bugs at lists.slony.info, bugzilla-daemon at main.slony.info
Subject: Re: [Slony1-bugs] [Bug 285] move set issues
References: <bug-285-4 at http.www.slony.info/bugzilla/> 
<20130130145538.E06A0290EF7 at main.slony.info> 
<51093E78.6070903 at Yahoo.com> <510949D0.8000603 at ca.afilias.info>
In-Reply-To: <510949D0.8000603 at ca.afilias.info>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 1/30/2013 11:26 AM, Steve Singer wrote:
> On 13-01-30 10:38 AM, Jan Wieck wrote:
>> On 1/30/2013 9:55 AM, bugzilla-daemon at main.slony.info wrote:
>>
>>> The UPDATE to sl_setsync does not have ssy_origin as part of the where clause,
>>> because we are running in READ COMMITTED mode the DELETE+INSERT of the row on
>>> sl_setsync becomes visible to the UPDATE part of sync_event() even though the
>>> sync_event() started before the ACCEPT_SET was processed.
>>
>> This sounds very plausible.
>>
>> I wonder if Slony in general is using too many concurrent threads.
>> Unfortunately changing that won't be easy.
>>
>>
>> Jan
>>
>
> I suspect the solution is to at ssy_origin as part of the where clause
> on that update so we only change sl_setsync rows for the current remote
> worker.
>
> I am testing
> *************** sync_event(SlonNode *node, SlonConn *loc
> *** 4693,4701 ****
>                           "update %s.sl_setsync set "
>                           "    ssy_seqno = '%s', ssy_snapshot = '%s', "
>                           "    ssy_action_list = '' "
> !                       "where ssy_setid in (",
>                           rtcfg_namespace,
> !                       seqbuf, event->ev_snapshot_c);
>       i = 0;
>       for (provider = wd->provider_head; provider; provider = provider->next)
>       {
> --- 4692,4700 ----
>                           "update %s.sl_setsync set "
>                           "    ssy_seqno = '%s', ssy_snapshot = '%s', "
>                           "    ssy_action_list = '' "
> !                       "where ssy_origin=%d and  ssy_setid in (",
>                           rtcfg_namespace,
> !                       seqbuf, event->ev_snapshot_c,node->no_id);
>       i = 0;
>       for (provider = wd->provider_head; provider; provider = provider->next)
>       {
>
>
> To see if that makes the problem go away.  Because the race condition is
> somewhat rare it will be a few days before I can have an idea if that helps

Makes sense. Although it is a little frightening that this sort of
concurrency on the database can result in the wrong rows being updated
in the first place.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin


-------------- next part --------------



More information about the Slony1-bugs mailing list