Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding
Jan Wieck wrote: On 1/25/2007 7:33 PM, Tom Lane wrote: 1 fires always 0 fires never N fires in Normal mode R fires in Replica mode other letters available for other future mode values? If you consistently think of origin and replica modes then the original proposal is better (using both 0 and O would be Real Bad), but your use of normal and replica in the followup makes me wonder which terminology is more common. Yeah, I tried for a long time to stay away from terms like master and slave ... but in the end people don't understand you if you talk about origin and subscriber or replica. That's how this inconsistent terminology slipped into my vocabulary. I personally don't care about the particular values. I could live with A, B, C, D. If people find 1, 0, N, R more explanatory, fine. Hi, Regardless of the actual namiing, we at the GORDA project strongly support this feature. In fact, our current prototype does this, although we do not allow fine grained configuration of which triggers get deactivated by the replica mode. It is hardcoded. (Sorry for being so late to the party, but the subject hasn't initially caught our attention.) Regards, -- Jose Orlando Pereira ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Priorities for users or queries?
Benjamin Arai wrote: Is there a way to give priorities to queries or users? Something similar to NICE in Linux. My goal is to give the updating (backend) application a very low priority and give the web application a high priority to avoid disturbing the user experience. Thanks in advance! You might want to look at the following, as they mention a PostgreSQL prototype: http://www.cs.cmu.edu/~natassa/aapubs/conference/priority mechanisms.pdf Regards, -- Jose Orlando Pereira ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Proposal: Commit timestamp
On Friday 09 February 2007, Jan Wieck wrote: I am not sure, I would have to look at what exactly that hook provides. The key to a Lamport timestamp is that it is advancing it commit order (plus some other things ... of course). If the hook can guarantee that the calls are made always in commit order, serialized without any race condition possible, it would probably be suitable. Actually what we do is a bit stronger. We use the commit hook to enforce an externally defined commit order. In our case, this is defined by a group communication protocol, which is even allowed to reorder a pair of transactions originating from the same replica. Therefore, achieving a commit order that is consistent with a local clock should be straightforward. Regards, -- Jose Orlando Pereira ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Proposal: Commit timestamp
On Saturday 03 February 2007, Bruce Momjian wrote: Jan Wieck wrote: I don't have any such paper and the proof of concept will be the implementation of the system. I do however see enough resistance against this proposal to withdraw the commit timestamp at this time. The new replication system will therefore require the installation of a patched, non-standard PostgreSQL version, compiled from sources cluster wide in order to be used. I am aware that this will dramatically reduce it's popularity but it is impossible to develop this essential feature as an external module. I thank everyone for their attention. Going and working on it on your own doesn't seem like the proper solution. I don't see people objecting to adding it, but they want it work, which I am sure you want too. You have to show how it will work and convince others of that, and then you have a higher chance it will work, and be in the PostgreSQL codebase. Hi, Would it be possible to solve the problem using the GORDA on-commit hook? Jan would be able reliably obtain a commit timestamp with the desired semantics and store it in a regular table within transaction boundaries. PostgreSQL would not have to commit to a specific timestamp semantics and the patch is quite small. Regards, -- Jose Orlando Pereira ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Replication hooks discussion
On Friday 29 September 2006 20:02, Andrew Sullivan wrote: At the beginning of the month, in http://archives.postgresql.org/pgsql-hackers/2006-09/msg00453.php, I said that I'd be willing to try to do any sort of co-ordination, document writing, c. for a project that might define common back-end resources necessary for the various kinds of replication systems people seem to want. There seems to be a widespread agreement that there is more than one sort of replication facilities that are desired, and that none of the systems on offer satisfies all of those desires. There also seems to be a hope that we could come to some sort of agreement on what the necessary conditions for any of these facilties are. If we could, then we could build the necessary framework to provide those conditions, and it could be made available in the back end without every replication project having to be shipped with the main PostgreSQL code. We at the GORDA project strongly agree with this approach. I'll try to summarize our proposals on the new list. Regards, -- Jose Orlando Pereira ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] standard interfaces for replication providers
On Wednesday 09 August 2006 20:57, Hannu Krosing wrote: Why reinvent the wheel for everything if there was an interface that offered some of the needed functionality? Maybe PostgreSQL-R is simply too deep in the database for any of this to be useful, but I'm 99% certain that Slony could make use of some of this stuff, such as a hook on tuples being written out. Slonys problems ar *not* in getting access to tuples written out. Why fix something that aint broken ? The current implementation of GAPI on PostgreSQL uses the same approach as Slony-I to extract the write-set. The difference is that it can push them out immediatly on commit, as required for eager update. -- Jose Orlando Pereira ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] standard interfaces for replication providers
On Friday 04 August 2006 16:46, Tom Lane wrote: We haven't been able to build production-grade multi-master replication without the barrier of a standard database-agnostic API, so I kinda doubt that it will work all that much better with one. See Slony-II. I would argue that people haven't been able to build production-grade multi-master replication, in part, due to the barrier of not having a standard database-agnostic API. :-) In fact, the problem is not the lack of a standard API but the lack of an API at all. Having to learn the intrincacies of a database server (or build a full fledged server wrapper) to experiment with simple prototypes is a serious hurdle for RD in database replication. This has been the case for replication based on group communication. In short the burden of proof is to show why this should go in, not why not. Please don't confuse two proposals included in the distributed package: (1) A PostgreSQL specific patch, which implements a minimal set of required features with a PostgreSQL-specific interface (e.g. triggers, new statements, configuration variables). This is by no means a standard interface. The included technical report discusses why these are required for a variety of replication scenarios. (2) A DBMS independent standard Java interface, which is easily built on the modified PostgreSQL server using both existing features (e.g. normal triggers) and those introduced by (1). Included toy applications show how this would be useful for replication, but we are not (yet) pushing for its adoption. (Suitable proof would be a usable replication system built atop it...) I agree. ;) -- Jose Orlando Pereira ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two-phase commit issues
On Saturday 21 May 2005 03:37, Josh Berkus wrote: 2PC is a key to supporting 3rd-party replication tools, like C-JDBC. I don't think C-JDBC requires 2PC for replication. Mixed up acronyms maybe? :) -- Jose Orlando Pereira ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Two-phase commit issues
On Friday 20 May 2005 18:14, Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: As I remember, you said two-phase wasn't 100% reliable and we just needed a way to report failures. [ Shrug... ] I remain of the opinion that 2PC is a solution in search of a problem, because it does not solve the single point of failure issue (just moves same from the database to the 2PC controller). You're right. 2PC to coordinate replicas of the same data is not that interesting. It is however most interesting when coordination updates to different objects such as (i) a central database server and a local staging area or (ii) a database server and transactional queues in a workflow-style app. But some people want it anyway, and they aren't going to be satisfied that we are an enterprise grade database until we can check off this particular bullet point. As long as the implementation doesn't impose any significant costs when not being used (which AFAICS Heikki's method doesn't), I think we gotta hold our noses and do it. It is a definitly in the check list if you're shopping for a database to go with your buzzword compliant J2EE app server. :-) -- Jose Orlando Pereira ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
