Re: RES: Priority to a mission critical transaction

Ron Mayer wrote:

Brian Hurt wrote: 

Mark Lewis wrote:   

On Wed, 2006-11-29 at 08:25 -0500, Brian Hurt wrote:      

I have the same question.  I've done some embedded real-time 
programming, so my innate reaction to priority inversions is that 
they're evil.  But, especially given priority inheritance, is there any 
situation where priority inversion provides *worse* performance than 
running everything at the same priority?         

Yes, there are certainly cases where a single high priority
transaction will suffer far worse than it otherwise would have. 

OK.

Although I'm tempted to make the issue more complex by throwing Software Transactional Memory into the mix:
http://citeseer.ist.psu.edu/shavit95software.html
http://citeseer.ist.psu.edu/anderson95realtime.html

That second paper is interesting in that it says that STM solves the priority inversion problem.  Basically the higher priority process forces the lower priority process to abort it's transaction and retry it.

Is it possible to recast Postgres' use of locks to use STM instead?  How would STM interact with Postgres' existing transactions?  I don't know.  This would almost certainly require Postgres to write it's own locking, with all the problems it entails (does the source currently use inline assembly anywhere?  I'd guess not.).

Apparently there are plenty of papers stating that priority inversion
is a major problem in RDBMs's for problems that require that specific
deadlines have to be met (such as in real time systems).  

It's definately a problem in realtime systems, not just realtime DBMS.  In this case,  running everything at the same priority doesn't work and isn't an option.

The question in my mind is whether overall the benefits outweigh
the penalties - in much the same way that qsort's can have O(n^2)
behavior but in practice outweigh the penalties of many alternatives.
 

Also, carefull choice of pivot values, and switching to other sorting methods like heapsort when you detect you're in a pathological case, help.  Make the common case fast and the pathological case not something that causes the database to fall over.

Setting priorities would be a solution to a problem I haven't hit yet, but can see myself needing to deal with.  Which is why I'm interested in this issue.  If it's a case of "setting priorities can make things better, and doesn't make things worse" is great.  If it's a case of "setting priorities can make things better, but occassionally makes things much worse" is a problem.

Of course, this is a little tricky to implement.  I haven't looked at
how difficult it'd be within Postgres.   

ISTM that it would be rather OS-dependent anyway.  Different OS's
have different (or no) hooks - heck, even different 2.6.* linuxes
(pre 2.6.18 vs post) have different hooks for priority
inheritance - so I wouldn't really expect to see cpu scheduling
policy details like that merged with postgresql except maybe from
a patched version from a RTOS vendor.
 

Hmm.  I was thinking of Posix.4's setpriority() call.

Brian