[Info-vax] Integrated Databases

[Craig A. Berry]

On 5/30/18 12:17 PM, Stephen Hoffman wrote:
> On 2018-05-30 02:50:09 +0000, Dave Froble said:
> 
>> On 5/29/2018 11:48 AM, Stephen Hoffman wrote:
>>> On 2018-05-29 14:51:26 +0000, Dave Froble said:
>>>
>>>> On 5/29/2018 9:34 AM, Stephen Hoffman wrote:
>>>>
>>>>>> PostgreSQL would be a phenom bundle for businesses looking for an 
>>>>>> enterprise class database.
>>>>>
>>>>> Ayup.   https://www.postgresql.org/docs/10/static/index.html
>>>>>
>>>>> But that port has unfortunately been blocked by flaws in the 
>>>>> OpenVMS SSIO implementation.
>>>>
>>>> Which should be fixable by a rather simple enhancement to the DLM.  
>>>> I suggested such an enhancement to VSI, namely numeric range 
>>>> locking, and hope that work on the port has pushed any consideration 
>>>> of the suggestion until after the port is completed.  Or, perhaps, 
>>>> NIH is the problem.  We'll see.
>>>
>>> SSIO and the issues around atomicity are not particularly related to 
>>> byte-range locking.
>>> http://de.openvms.org/TUD2012/opensource_and_unix_portability.pdf
>>
>> Ok, that was a bit interesting.  Apparently I didn't understand the 
>> entire problem.
>>
>> I do seem to recall someone, perhaps Robert, stating that a partial 
>> block read can be done.  He didn't mention partial block writes.  Nor 
>> am I all that sure that such would be a good idea.
> 
> Though I don't think it's the intended reference, neither HDDs nor SSDs 
> support fractional-sector writes.  On any platform.  The issue here is 
> that there are I/O caches around all over the place in OpenVMS and in 
> the underlying hardware, and the contents of those OpenVMS caches are 
> here uncoordinated.  That's a pretty nasty data corruption problem 
> lurking here for folks using stream access, unfortunately.

The link Hoff cited above, and which Dave seems not to have read very
carefully, says the following on p. 19 about the problems SSIO addresses:

• Lost update problem:
   – XFC provides the new API
   – Programs pass byte-offset via new API
   – New code in XFC to update only part of a block
• Mixed data problem:
   – XFC will lock all affected buffers during block I/O
   – Atomic up to SSIO_MAX_ATOMIC_IO bytes

In other words, it appears to be an attempt to coordinate the
"uncoordinated" caches. Given the complexities, I guess it's not
surprising version 1.0 wasn't ready for prime time, but I hope they
eventually sort it out.