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. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
