Possible problem with C++ based CREATE FUNCTION

3 Sep 2019

      I am trying to create a function that works around concurrency issues that are documented, and that we are seeing, when doing simultaneous "create table" statements and bulk insert statements (or selects) off of other tables.

To do this, I am implementing a function that uses a boost::shared_mutex that we call around transactions.

We are using a custom version of the boost library, so it is installed in a non-standard place: /usr/local/boost-1.54.0 for development, and /opt/xxx/ for production.
...
From the documentation, it appears that I can use #pragma LDFLAGS and CFLAGS to point to the non-standard directories.  It appears to honor the CFLAGS option, but not the LDFLAGS option.  If I use the standard /usr/lib64 libraries, calling my function works (but with the wrong library).  Adding the #pragma in, I get the following link error:
Failed to open shared library: libboost_thread.so.1.54.0: cannot open shared object file: No such file or directory.

If I modify LD_LIBRARY_PATH before starting MonetDB, the problem goes away.  Ideally, we don't want to have to add all of our relevant directories into the environment, but would expect the #pragma to work.

Here is the function definition:
CREATE FUNCTION rwlocker(input INT)
RETURNS INT
LANGUAGE CPP {
#pragma LDFLAGS -L/usr/local/boost-1.54.0/lib -lboost_thread
#pragma CFLAGS -I/opt/tc3/include -I/usr/local/boost-1.54.0/include

#include 

    // use lock() for schema changes, lock_shared() for inserts and queries
    static boost::shared_mutex readerWriterMutex;

    result->initialize(result, 1);
    int val = input.data[0];
    switch(val) {
        case 1: // shared lock
            readerWriterMutex.lock_shared();
            break;
       case 2: // shared unlock
            readerWriterMutex.unlock_shared();
            break;
        case 3: // unique lock
            readerWriterMutex.lock();
            break;
        case 4: // unique unlock
            readerWriterMutex.unlock();
            break;
        default: // Error
            break;
    }

    result->data[0] = val;
};

Invocation is easiest with: select rwlocker(12); which will just output a 12, bypassing the reader/writer locking.

Any thoughts on why #pragma LDFLAGS doesn't appear to work right?

We are using 11.33.3 on CentOS 7.3.1611

Thanks,

Dave

Gotwisner, Dave

Ying Zhang

Gotwisner, Dave

tags

participants (2)