Обсуждение: more concurrency information in the documentation
I was looking for some good documentation resources on dealing with database concurrency issues online and I stumbled across this gem from Microsoft: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/h tml/concurev4M.asp In it is a kind of 'best practices' in dealing with various concurrency issues in the 'real world' i.e. a business environment. Would a similarly structured document covering concurrency issues be acceptable in the PostgreSQL documentation? Merlin
Merlin Moncure wrote: > I was looking for some good documentation resources on dealing with > database concurrency issues online and I stumbled across this gem from > Microsoft: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/h > tml/concurev4M.asp > > In it is a kind of 'best practices' in dealing with various concurrency > issues in the 'real world' i.e. a business environment. Would a > similarly structured document covering concurrency issues be acceptable > in the PostgreSQL documentation? I read the headings on the page and read the first line of each section, and had very little idea what they were talking about. What exactly would you like to cover? It seems more like concurrency basics rather than something we would have in our docs. Perhaps we should like to more outside documentation, but the URL you provided is so content-light that I would not recommend it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> Merlin Moncure wrote: > > I was looking for some good documentation resources on dealing with > > database concurrency issues online and I stumbled across this gem from > > Microsoft: > > > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/h > > tml/concurev4M.asp > > > > In it is a kind of 'best practices' in dealing with various concurrency > > issues in the 'real world' i.e. a business environment. Would a > > similarly structured document covering concurrency issues be acceptable > > in the PostgreSQL documentation? > > I read the headings on the page and read the first line of each section, ok, I admit there is a fair amount of gook in there. It's fairly laden with meaningless or obvious terminology ('service model', etc). However there is some good stuff in there as well. > and had very little idea what they were talking about. What exactly > would you like to cover? It seems more like concurrency basics rather 1. Relative merits of various locking strategies. 2. Data conflict resolution. 3. When and why to use the different transaction isolation models. 4. How to deal with time differential between client and server. 5. How to organize your transactions such that they will not a. deadlock b. not inadvertently invalidate one another. The above all focused within the capabilities of the database, of course. > than something we would have in our docs. Perhaps we should like to > more outside documentation, but the URL you provided is so content-light > that I would not recommend it. hm, I'm not so sure I would agree with that sentiment. Good information on how to deal with database concurrency issues seems to me to be pretty hard to find. Let me ask you this, do you think the current documentation on database concurrency could be improved, and if so, how? Right now, it is fairly abstract and technical, and that may be a good thing. Merlin
Merlin Moncure wrote: > > > than something we would have in our docs. Perhaps we should like to > > more outside documentation, but the URL you provided is so > content-light > > that I would not recommend it. > > hm, I'm not so sure I would agree with that sentiment. Good information > on how to deal with database concurrency issues seems to me to be pretty > hard to find. Let me ask you this, do you think the current > documentation on database concurrency could be improved, and if so, how? > Right now, it is fairly abstract and technical, and that may be a good > thing. Yea, I guess we could improve it, but looking at cost/benefit, I am not sure how much sense it makes to add stuff that is not PostgreSQL-specific. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073