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 [email protected] 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
#18 (comment)

[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 [email protected] 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
[email protected]

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#18 (comment)

[AndreMikulec]

.

[davecramer]

Can you actually select from that table in your database ?

Dave Cramer

On 26 March 2016 at 19:16, AndreMikulec [email protected] 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
[email protected]

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#18 (comment)

[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 [email protected] 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
#18 (comment)

[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 [email protected] 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
#18 (comment)

[davecramer]

can you try the file attached to postgres-plr#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
[email protected]

[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.