On 6/7/2004 2:33 PM, Jeff Davis wrote:
> On Mon, 2004-06-07 at 06:20, Jan Wieck wrote:
>> I tend to agree with you that spurious SYNC's aren't the end of the
>> world. The idea of using notify to tell the syncThread somthing happened
>> is probably the right way to do it, but at this time a little invasive.
>> We need more time to investigate how to avoid notice storms during high
>> update activity on the master.
>>
>
> There was discussion a while back about improving notify, and one
> suggestion was to make it use shared memory so no disk writes are
> involved (I believe the current implementation uses a table somehow). If
> that was implemented, than we would have no problem with a notice storm,
> right? It wouldn't use much shared memory since the slon daemon can
> retrieve the notices just as fast as the backend can send them, right?
Keep in mind that for the time being, one of the important features of
Slony-I is the ability to replicate from a 7.3.x to anything >7.3.x. You
sure don't want to cripple that functionality by heavily depending on
features fixed or significantly improved for 7.5.
>
> Backtracking a little, I'm still wondering how exactly a replicated
> sequence is supposed to behave, do you have some comments about that? I
> don't understand exactly why it's useful.
At the moment the origin of a set discovers that there has been update
activity, it generates the SYNC event and records all sequences
last_values. At that time, a sequence can possibly be incremented again
by a not yet committed transaction, so it might be recorded with a
higher number than a max() query over the tables would show. When a
subscriber applies the SYNC event, it also calls setval() with those
recorded values. So on the replica the sequence number is adjusted up
just before the SYNC event occupying those numbers commits.
This means, that in the case of a failover, the sequences might show a
gap. This is absolutely in accordance to PostgreSQL's sequence handling
which cannot guarantee gap free sequences in the case of server crashes
or other transaction rollback reasons.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #