[Info-vax] Integrated Databases

[Dave Froble]

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.

The first problem I see with the SSIO is that it appears to be 
implemented in the CRTL.  That is about as disgusting an approach as I 
can imagine.  If it is to be a VMS capability, (and disk I/O seems to 
fit into that catagory), then it should be implemented as part of VMS.

Regardless, from what I read, it appears that there is still a need for 
locking a range of bytes, which may span block boundaries, and may not 
include whole blocks.  Now, as I see it, locking should be done by the DLM.

At this time, the DLM has one type of lock, a lock on a resource name. 
My idea was to allow multiple types of locks.  A second type might lock 
a numeric range, x to y.  Some part of the lock would be two 8 byte 
integers, and for that type additional code to determine if any part of 
that range is already locked.

Once there are DLM types of locks, while I have no idea at this time 
what a third type of lock might be, there is the option for additional 
types of locks.  Sort of flexible, huh?

As for the I/O.  There are several concerns.

First, we're looking at soon having memory for storage, beyond SSDs 
which mimic disks.  With such, there is no longer a concept of disk 
blocks.  There would be no temporary data in buffers, all work would be 
direct to memory.

If Postgre is indeed a worthy database product for VMS, and I know 
absolutely nothing about the product, perhaps it can be modified to 
conform to disk I/O capabilities of VMS.  This would immediately give it 
all the current VMS capabilities, clusters, mirrored storage, etc.

Perhaps as the SSIO appears to attempt, additional I/O capabilities 
should be implemented on VMS.  Not sure this is a good approach, as long 
as disks are still in use.  Seems to me to be chasing the past, not the 
future.

Note, most of the above comes from the perspective of software 
architecture, more so that engineering.