pl/r runs fine on Windows 7 64 bit

[AndreMikulec]

I am running Windows 7 64 bit.

I tried this and this works fine.

64 bit Windows DLL posted, compiled against postgres 9.4.1 and R-3.1.2. 

[Plr-general] new release
http://lists.pgfoundry.org/pipermail/plr-general/2015-February/000902.html

I have not tried this.

64 bit Win7 DLL compiled against postgres 9.3.0 and R-3.0.2:
http://www.joeconway.com/plr/plr-8.3.0.15-pg9.3-win64.zip

Plr-general] To compile PL/R on Windows 
http://lists.pgfoundry.org/pipermail/plr-general/2013-October/000810.html

[AndreMikulec]

.

[davecramer]

Is there a plr_modules table ?

Dave Cramer

On 26 March 2016 at 06:19, AndreMikulec notifications@github.com wrote:

Using 64 bit PostgreSQL 9.4/64 bit plr/64 bit R version 3.2.2/64 bit Windows 7,

I did manage to get the following to maybe seamingly work. ( I have not re-tried 32bit yet )

CREATE EXTENSION plr; postgres=# CREATE EXTENSION plr;CREATE EXTENSION

postgres=# select plr_version(); plr_version------------- 08.03.00.16 (1 row)

Then, I try to create a simple function.

CREATE OR REPLACE FUNCTION my_function() RETURNS text AS$$ return("done")$$language 'plr';

Then I try to run it.

postgres=# select my_function();

I get back the following error.

ERROR: could not open file "base/12135/11896": No such file or directoryCONTEXT: SQL statement "SELECT NULL FROM pg_catalog.pg_class WHERE relname = 'plr_modules' AND relnamespace = 2200"

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/jconway/plr/issues/18#issuecomment-201751788

[AndreMikulec]

.

[davecramer]

Andre,

CREATE TABLE plr_modules ( modseq int4 primary key, modsrc text );

Should do it

Dave Cramer

On 26 March 2016 at 15:34, AndreMikulec notifications@github.com wrote:

Dave Cramer,

After browsing in pgAdmin III, I am not finding

plr_modules

anywhere.

If you know of a specific, SQL, that I can run, that can query the meta-data, then send it to me. I will run it.

Thank you, Andre Mikulec Andre_Mikulec@Hotmail.com

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/jconway/plr/issues/18#issuecomment-201916052

[AndreMikulec]

.

[davecramer]

Can you actually select from that table in your database ?

Dave Cramer

On 26 March 2016 at 19:16, AndreMikulec notifications@github.com wrote:

I worked on this problem. yesterday and most of today ( 12+ hours ).

As Dave Cramer recommeds, I did do this.

CREATE TABLE plr_modules ( modseq int4 primary key, modsrc text );

The actual problem seems to be the following. It took me may hours to figure out this pattern.

This statement here is the result of a session crash.

ERROR: could not open file "base/12135/11896": No such file or directory CONTEXT: SQL statement "SELECT NULL FROM pg_catalog.pg_class WHERE relname = 'plr_modules' AND relnamespace = 2200"

Once the session crashes, no statement will work in it anymore. I have to close the session and start a new session.

At first it seemed like a performance problem. It seem that I needed to run a long running SQL statement before running a pl/r statement.

At one time, if I started a session like

select null from pg_class where relfilenode = 11896; select my_function();

then a typical response would be I working my_function

relname

(0 rows)

my_function

done (1 row)

So the 'plr' function my_functon works.

But then after I followed Dave Cramer's advice, I am getting a different message. Also, my 'SQL before PLR' trick above, no longer works.

CREATE TABLE plr_modules ( modseq int4 primary key, modsrc text );

postgres=# select null from pg_class where relfilenode = 11896; select my_function(); ?column?---------- (0 rows)

ERROR: could not open file "base/12135/16649": No such file or directory CONTEXT: SQL statement "SELECT modseq, modsrc FROM public.plr_modules ORDER BYmodseq" postgres=#

Am I missing some tables somewhere? Is there anything that I may do to solve this problem?

Note, my PostgreSQL works fine. I only get these base/xxx/yyy messages after I do

CREATE EXTENSION plr;

If I drop the plr extension, the problems go away ( but also plr goes away too).

Thanks, Andre Mikulec Andre_Mikulec@Hotmail.com

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/jconway/plr/issues/18#issuecomment-201949132

[AndreMikulec]

.

[davecramer]

could you tell me what select * from pg_class where oid = 16649 returns ?

[AndreMikulec]

.

[davecramer]

did you forget a semicolon ?

Dave Cramer

On 26 March 2016 at 20:25, AndreMikulec notifications@github.com wrote:

Dave, It returns nothing ( zero rows )

postgres=# select * from pg_class where oid = 16649 postgres-#

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/jconway/plr/issues/18#issuecomment-201959467

[AndreMikulec]

.

[davecramer]

Well that is strange... are there any server logs? Try increasing the server logs considerably

Dave Cramer

On 26 March 2016 at 20:59, AndreMikulec notifications@github.com wrote:

With the semicolon . . .

postgres=# select * from pg_class where oid = 16649;

relname | relnamespace | reltype | reloftype | relowner | relam | relfileno de | reltablespace | relpages | reltuples | relallvisible | reltoastrelid | relh asindex | relisshared | relpersistence | relkind | relnatts | relchecks | relhas oids | relhaspkey | relhasrules | relhastriggers | relhassubclass | relispopulat ed | relreplident | relfrozenxid | relminmxid | relacl | reloptions -------------+--------------+---------+-----------+----------+-------+---------- ---+---------------+----------+-----------+---------------+---------------+----- --------+-------------+----------------+---------+----------+-----------+------- -----+------------+-------------+----------------+----------------+------------- ---+--------------+--------------+------------+--------+------------ plr_modules | 2200 | 16651 | 0 | 10 | 0 | 166 49 | 0 | 0 | 0 | 0 | 16652 | t | f | p | r | 2 | 0 | f | t | f | f | f | t | d | 713 | 1 | | (1 row)

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/jconway/plr/issues/18#issuecomment-201965022

[davecramer]

can you try the file attached to https://github.com/postgres-plr/plr/issues/1 and move the discussion over there ?

[AndreMikulec]

Following this.

Testing out PL/R PLR Part 1: Up and Running with PL/R (PLR) in PostgreSQL: An almost Idiot's Guide http://www.bostongis.com/PrinterFriendly.aspx?content_name=postgresql_plr_tut01

I tested this one on computer A (PostgreSQL 9.5.2 and R 3.3.0 ) PostgreSQL 9.5.2, compiled by Visual C++ build 1800, 64-bit

The OS is Windows 7 64bit. The computer is 10 years old.

The dll is Win64 plr.dll for Postgres 9.5.x, R-3.3.0 (plr-8.3.0.16) : May 11, 2016 build http://www.joeconway.com/plr/plr-8.3.0.16-pg9.5-R3.3.0-win64.zip

I tried on NTFS.

I pre-checked the disk by: NTFS filesystem: Tools -> Error Checking -> Check now ... no errors

I am getting the following error.

postgres=# select version();
                           version
-------------------------------------------------------------
 PostgreSQL 9.5.3, compiled by Visual C++ build 1800, 64-bit
(1 row)

postgres=# select plr_version();
 plr_version
-------------
 08.03.00.16
(1 row)

postgres=# SELECT load_r_typenames();
ERROR:  could not open file "base/12373/2663": No such file or directory
LINE 1: SELECT NULL FROM pg_catalog.pg_class WHERE relname = 'plr_mo...
                         ^
QUERY:  SELECT NULL FROM pg_catalog.pg_class WHERE relname = 'plr_modules' AND relnamespace = 2200
postgres=#

I tried on FAT32

I pre-checked the disk by: FAT32 filesystem: Tools -> Error Checking -> Check now ... no errors

I am getting the following error.

postgres=# select version();
                           version
-------------------------------------------------------------
 PostgreSQL 9.5.3, compiled by Visual C++ build 1800, 64-bit
(1 row)

postgres=# select plr_version();
 plr_version
-------------
 08.03.00.16

(1 row)
postgres=# SELECT load_r_typenames();
ERROR:  could not open file "base/12373/2663": No such file or directory
LINE 1: SELECT NULL FROM pg_catalog.pg_class WHERE relname = 'plr_mo...
                         ^
QUERY:  SELECT NULL FROM pg_catalog.pg_class WHERE relname = 'plr_modules' AND relnamespace = 2200
postgres=#

However,

I tested these on Computer B (PostgreSQL 9.5.2 and R 3.3.0 ) PostgreSQL 9.5.2, compiled by Visual C++ build 1800, 64-bit

The OS is Windows 7 64bit. The computer is 1 year old.

I tried on NTFS.

and these work fine.

Win32 plr.dll for Postgres 9.5.x, R-3.3.0 (plr-8.3.0.16): May 11, 2016 build http://www.joeconway.com/plr/plr-8.3.0.16-pg9.5-R3.3.0-win32.zip

Win64 plr.dll for Postgres 9.5.x, R-3.3.0 (plr-8.3.0.16): May 11, 2016 build http://www.joeconway.com/plr/plr-8.3.0.16-pg9.5-R3.3.0-win64.zip

postgres=# select version();
                           version
-------------------------------------------------------------
 PostgreSQL 9.5.3, compiled by Visual C++ build 1800, 64-bit
(1 row)

postgres=# select plr_version();
 plr_version
-------------
 08.03.00.16
(1 row)

postgres=# SELECT load_r_typenames();
 load_r_typenames
------------------
 OK
(1 row)

Therefore, computer A, is a mystery.

On Computer A, 2 monts ago I tested (PostgreSQL 9.4.1 and R 3.1.2 ) PostgreSQL 9.4.1, compiled by Visual C++ build 1800, 64-bit

and this work fine.

Win64 plr.dll for Postgres 9.4.x (plr-8.3.0.16) http://www.joeconway.com/plr/plr-8.3.0.16-pg9.4-win64.zip

And I retried now.

postgres=# select version();
                           version
-------------------------------------------------------------
 PostgreSQL 9.4.1, compiled by Visual C++ build 1800, 64-bit
(1 row)

postgres=# SELECT load_r_typenames();
 load_r_typenames
------------------
 OK
(1 row)

postgres=# select plr_version();
 plr_version
-------------
 08.03.00.16
(1 row)

And this works fine.

So,I am not sure what happened between between

old computers ( 10 years old ) AND new computers ( 1 year old )

AND

PostgreSQL 9.4.1, compiled by Visual C++ build 1800, 64-bit AND PostgreSQL 9.5.2, compiled by Visual C++ build 1800, 64-bit

Andre Mikulec Andre_Mikulec@Hotmail.com

[jconway]

So it seems to be a isolated/strange issue related to the old hardware? In that case, I would like to close this issue, as I doubt it is worth the effort to troubleshoot further.