Subject: Re: Starting build-system work (Windows/Mac users please speak up)
To: Kartik Ohri <kartikohri13@gmail.com>
References: <5EC17E17.7070002@anastigmatix.net>
 <CAASLQ4OdOma6h5Mu=hMEPyk0M4-MomYZLnhGH+2wVoL1vt_UEg@mail.gmail.com>
 <5ECED046.3000308@anastigmatix.net>
 <CAASLQ4P11FFgefy_xK0Tcw3vWt1F1MNyVgK5eU=PFGvYrpZcyw@mail.gmail.com>
 <5ED0FCB0.405@anastigmatix.net> <5ED10C6D.2020000@anastigmatix.net>
 <5ED10F36.7060304@anastigmatix.net>
 <CAASLQ4PAQ0PNAxJ5ad9U6o+RT2ip19FXvgoK2y1kGWaJbTZ1WQ@mail.gmail.com>
 <5ED15825.9060504@anastigmatix.net>
 <CAASLQ4OXAb+_J=oK54PH5eYuXjkV9KMsoXEcp-TYaQPqxk1Xbg@mail.gmail.com>
 <5ED270BA.9010001@anastigmatix.net> <5ED3D488.1010401@anastigmatix.net>
 <5ED474CA.3000106@anastigmatix.net>
 <CAASLQ4PfvmgKPp+aFf_r5RsBwigc+EC5Hm2CuzwJSTDCT64i-A@mail.gmail.com>
 <5ED4EA10.4030801@anastigmatix.net>
 <CAASLQ4Px21jyb2vJYSrjF5P0RqhA-G_DDWR9QHG68r+W+AqbxQ@mail.gmail.com>
 <CAASLQ4NYE-TW6hjbkSOuAY2Z4NM2cYzqSQ9ahO2LAUhdP9axeQ@mail.gmail.com>
Cc: pljava-dev@lists.postgresql.org
From: Chapman Flack <chap@anastigmatix.net>
Message-ID: <5ED7E74B.9020800@anastigmatix.net>
Date: Wed, 3 Jun 2020 14:09:15 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: 
 <CAASLQ4NYE-TW6hjbkSOuAY2Z4NM2cYzqSQ9ahO2LAUhdP9axeQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 06/03/20 13:24, Kartik Ohri wrote:
> ERROR: ALTER SYSTEM cannot run inside a
> transaction bloc at psql -c "SET pljava.libjvm_location to '$libjvm'; ALTER
> SYSTEM SET pljava.libjvm_location to '$libjvm'; SELECT pg_reload-conf();"
> -U postgres .

Hmm. psql does have a --single-transaction mode that, if enabled, makes
psql send a BEGIN before your first command and a COMMIT after the last
one, so that if you have multiple commands, they all happen in one
transaction. [1]

If one of your commands is something that's not allowed inside
a transaction block, that of course will be a problem.

What surprises me is that you see this happening on Windows only.
I wonder if psql is built with different option defaults there? Or could
there be a .psqlrc (or whatever it is called in Windows) that is setting
that option? Those are the kind of things I would look for.

That said, there are alternatives to the whole ALTER SYSTEM / pg_reload_conf
business. If you are going to include all of the testing commands within
one psql connection, there isn't any need for the ALTER SYSTEM or reload,
you can just send the SET commands first and then the others in the same
session. Or, if you do want to save the settings for later reconnection,
you could also do that with ALTER DATABASE or ALTER USER, and I think
both of those will work inside transactions.

Another alternative is to simply pass the settings with -c when
starting the PostgreSQL server [2]:

postgres -c pljava.libjvm_location="$libjvm" \
  -c pljava.vmoptions='-ea:org.postgresql.pljava... -Xcheck:jni'

(Note I'm writing Unixy syntax here; I don't use Windows enough to be
sure of the right way to quote that, but it gives you the idea.)

Those settings will apply to all sessions started in that run of the server.
It would be odd to run a production server that way, but one that is just
being started to run some tests, why not?

And still another alternative is just to send the options as part of the
psql connection string [3]:

psql "dbname=postgres options='-c pljava.libjvm_location=$libjvm
  -c pljava.vmoptions=-ea:org.postgresql.pljava...\\\ -Xcheck:jni'"

... where again, I'm showing Unixy syntax. The tricky bit is getting a
space inside a single option setting, which you can see takes three
backslashes in the above. I have no idea what would be correct in Windows
but if you figure it out, it's good practice for the Maven plugin work.

Settings sent with the psql connection of course are in effect just for
that session.

Regards,
-Chap


[1] https://www.postgresql.org/docs/13/app-psql.html#R1-APP-PSQL-3

[2] https://www.postgresql.org/docs/13/app-postgres.html#id-1.9.5.14.6.3

[3] https://www.postgresql.org/docs/13/libpq-connect.html#LIBPQ-CONNSTRING