ntfs for windows port rc5-2

On Fri, Jan 14, 2005 at 08:39:28AM -0800, J. Greenlees wrote:

why?
since an app that I'm working on would be useless for 60% of potential
clients, using posgresql with the requirement for ms' corrupted ntfs
means postgresql isn't going to work for it.

I think what you are referring to is the installer refusing to install
on a NTFS partition. From the FAQ:

http://pginstaller.projects.postgresql.org/FAQ_windows.html

2.4) Can I install PostgreSQL on a FAT partition?

PostgreSQL's number one priority is the integrity of your data. FAT and
FAT32 filesystems simply do not offer the reliabilty required to allow
this. In addition, the lack of security features offered by FAT make it
impossible to secure the raw data files from unauthorised modification.
Finally, PostgreSQL utilises a feature called 'reparse points' to
implement tablespaces. This feature is not available on FAT partitions.

<snip>

It is recognised however, that on some systems such as developer's PCs,
FAT partitions may be the only choice. In such cases, you can simply
install PostgreSQL as normal, but without initialising the database
cluster. When the installation has finished, manually run the
'initdb.exe' program on the FAT partition. Security and reliability
will be compromised however, and any attempts to create tablespaces
will fail.

since ms does not include a compiler, and the source for 8.0 won't cross
compile from linux. ( gcc 3.3.0 )

To compile the native port on Windows you need MinGW. And there's
always the Cygwin port still. See:

http://www.postgresql.org/files/documentation/faqs/text/FAQ_MINGW

Hope this helps,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Hi,
Does anyone know if there is a way to get the backends IP address from
the PID?
I am using the view pg_stat_activity and it would be nice if it would
also display the IP address along with the PID.

I can see the IP address when I do a ps -ef but it would be nice to be
able to get it via a sql command.

Thanks,

Tony Caduto
http://www.amsoftwaredesign.com

Martijn van Oosterhout wrote:

On Fri, Jan 14, 2005 at 08:39:28AM -0800, J. Greenlees wrote:

why?
since an app that I'm working on would be useless for 60% of potential
clients, using posgresql with the requirement for ms' corrupted ntfs
means postgresql isn't going to work for it.

I think what you are referring to is the installer refusing to install
on a NTFS partition. From the FAQ:

http://pginstaller.projects.postgresql.org/FAQ_windows.html

2.4) Can I install PostgreSQL on a FAT partition?

PostgreSQL's number one priority is the integrity of your data. FAT and
FAT32 filesystems simply do not offer the reliabilty required to allow
this. In addition, the lack of security features offered by FAT make it
impossible to secure the raw data files from unauthorised modification.
Finally, PostgreSQL utilises a feature called 'reparse points' to
implement tablespaces. This feature is not available on FAT partitions.

<snip>

It is recognised however, that on some systems such as developer's PCs,
FAT partitions may be the only choice. In such cases, you can simply
install PostgreSQL as normal, but without initialising the database
cluster. When the installation has finished, manually run the
'initdb.exe' program on the FAT partition. Security and reliability
will be compromised however, and any attempts to create tablespaces
will fail.

since ms does not include a compiler, and the source for 8.0 won't cross
compile from linux. ( gcc 3.3.0 )

To compile the native port on Windows you need MinGW. And there's
always the Cygwin port still. See:

http://www.postgresql.org/files/documentation/faqs/text/FAQ_MINGW

Hope this helps,

rc5-2 msi will not install at all on a fat32 filesystem
even without initialising the database.
sorry but whole purpose of putting it on a windows box was to make db
app for a 250,000 person client base.
with some still using win95, some win 98, some winme.
all of which do not have ntfs support.

since the app will not be world accessable, only through localhost, the
lack of security isn't a major concern.

--
========================================

only plain text format email accepted.

smaller file size, no virus transfer
no proprietary file formats.

========================================

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You may wish to consider a different database for your project. SQLite
may be a better choice, for example, depending on the project's
specific needs (www.sqlite.org).

Win95/98/ME is poor technology, no matter how many users it still has.
It's probably about time for them to upgrade or switch to another OS
(of course, I think Windows in general is a poor technology, but that's
for another list...).

OTOH, does anyone know if the cygwin version of postgresql enforces the
NTFS requirement? That may be another option...

On Jan 14, 2005, at 4:39 PM, J. Greenlees wrote:

Martijn van Oosterhout wrote:

On Fri, Jan 14, 2005 at 08:39:28AM -0800, J. Greenlees wrote:

why?
since an app that I'm working on would be useless for 60% of
potential clients, using posgresql with the requirement for ms'
corrupted ntfs means postgresql isn't going to work for it.

I think what you are referring to is the installer refusing to install
on a NTFS partition. From the FAQ:
http://pginstaller.projects.postgresql.org/FAQ_windows.html
2.4) Can I install PostgreSQL on a FAT partition?
PostgreSQL's number one priority is the integrity of your data. FAT
and
FAT32 filesystems simply do not offer the reliabilty required to allow
this. In addition, the lack of security features offered by FAT make
it
impossible to secure the raw data files from unauthorised
modification.
Finally, PostgreSQL utilises a feature called 'reparse points' to
implement tablespaces. This feature is not available on FAT
partitions.
<snip>
It is recognised however, that on some systems such as developer's
PCs,
FAT partitions may be the only choice. In such cases, you can simply
install PostgreSQL as normal, but without initialising the database
cluster. When the installation has finished, manually run the
'initdb.exe' program on the FAT partition. Security and reliability
will be compromised however, and any attempts to create tablespaces
will fail.

since ms does not include a compiler, and the source for 8.0 won't
cross compile from linux. ( gcc 3.3.0 )

To compile the native port on Windows you need MinGW. And there's
always the Cygwin port still. See:
http://www.postgresql.org/files/documentation/faqs/text/FAQ_MINGW
Hope this helps,

rc5-2 msi will not install at all on a fat32 filesystem
even without initialising the database.
sorry but whole purpose of putting it on a windows box was to make db
app for a 250,000 person client base.
with some still using win95, some win 98, some winme.
all of which do not have ntfs support.

since the app will not be world accessable, only through localhost,
the lack of security isn't a major concern.

--
========================================

only plain text format email accepted.

smaller file size, no virus transfer
no proprietary file formats.

========================================

- -----------------------------------------------------------
Frank D. Engel, Jr. <fde101@fjrhome.net>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten
Son, that whosoever believeth in him should not perish, but have
everlasting life.
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB6EOs7aqtWrR9cZoRAtGcAKCDdfxAWPzNw23+hJ/t9xObxoP+kACfTz1T
eD6NOkOnIcok1U3iSGnjxyo=
=P26l
-----END PGP SIGNATURE-----

___________________________________________________________
$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com

Frank D. Engel, Jr. wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You may wish to consider a different database for your project. SQLite
may be a better choice, for example, depending on the project's specific
needs (www.sqlite.org).

Win95/98/ME is poor technology, no matter how many users it still has.
It's probably about time for them to upgrade or switch to another OS (of
course, I think Windows in general is a poor technology, but that's for
another list...).

OTOH, does anyone know if the cygwin version of postgresql enforces the
NTFS requirement? That may be another option...

I'll check sqllite out, thanks for the tip on it.

not sure about the cygwin, but don't really want to cause clients to
have to install and run extra services that shouldn't be needed.

I agree about windows, not worth using at all.
--
========================================

only plain text format email accepted.

smaller file size, no virus transfer
no proprietary file formats.

========================================

I don't think that Windows isn't worth using some versions such as XP are quite
stable for most purposes. By no means am I saying go put a production database
server like Postgres or Oracle on it. SMB's (Small - to - Medium Businesses) may
benefit from Windows 2000 if there aren't able to get somebody who can manage
Linux/Unix in their environment and don't have a heavy load.

Cheers,

Aly.

I agree about windows, not worth using at all.

--
Aly Dharshi
aly.dharshi@telus.net

"A good speech is like a good dress
that's short enough to be interesting
and long enough to cover the subject"

On Fri, Jan 14, 2005 at 02:29:47PM -0600, Tony Caduto wrote:

Does anyone know if there is a way to get the backends IP address from
the PID?

Do you mean the IP address of the backend (the server) or the address
of the client that's using that backend?

PostgreSQL 8.0 will have inet_client_addr() and inet_server_addr()
functions to get the client and backend IP addresses for the current
session, but I'm not aware of a way to get another session's IP
addresses via an SQL query.

I am using the view pg_stat_activity and it would be nice if it would
also display the IP address along with the PID.

That probably wouldn't be hard to add -- consider submitting a patch
or suggesting it to the developers.

I can see the IP address when I do a ps -ef but it would be nice to be
able to get it via a sql command.

A workaround would be to write a function that runs ps, netstat,
lsof, etc., and extracts the IP address from the command's output.
Here's a set-returning plperlu example that works with PostgreSQL
8.0.0rc5 on FreeBSD 4.11:

CREATE TYPE pid_ip AS (
pid integer,
ipaddr inet
);

CREATE FUNCTION backend_client_ips() RETURNS SETOF pid_ip AS $$
my $psprog = "/bin/ps";
my $rows;

if (open(my $ps, "-|", $psprog, $pid)) {
while (<$ps>) {
if (/^\s*(\d+).*postmaster: \S+ \S+ (\d+\.\d+\.\d+\.\d+)/) {
push @$rows, {pid => $1, ipaddr => $2};
}
}
close $ps;
} else {
elog ERROR, "$psprog: $!";
}

return $rows;
$$ LANGUAGE plperlu VOLATILE;

SELECT * FROM backend_client_ips();
pid | ipaddr
-------+-----------
78563 | 10.1.0.1
78566 | 127.0.0.1
78573 | 10.1.0.2
(3 rows)

SELECT i.ipaddr, a.*
FROM pg_stat_activity AS a
LEFT OUTER JOIN backend_client_ips() AS i ON i.pid = a.procpid;
ipaddr | datid | datname | procpid | usesysid | usename | current_query | query_start
-----------+-------+---------+---------+----------+---------+---------------+-------------------------------
| 26492 | test | 78575 | 100 | mfuhr | <IDLE> | 2005-01-15 08:23:51.816278-07
10.1.0.2 | 26492 | test | 78573 | 100 | mfuhr | <IDLE> | 2005-01-15 08:23:34.224116-07
10.1.0.1 | 26492 | test | 78563 | 100 | mfuhr | <IDLE> | 2005-01-15 08:23:39.294674-07
127.0.0.1 | 26492 | test | 78566 | 100 | mfuhr | <IDLE> | 2005-01-15 08:23:14.276227-07
(4 rows)

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

rc5-2 msi will not install at all on a fat32 filesystem
even without initialising the database.

Really? The code for checking the filesystem type is only executed if
you chose to initdb, so I really don't see this happening. Exactly what
message do you get?

sorry but whole purpose of putting it on a windows box was to make db
app for a 250,000 person client base.
with some still using win95, some win 98, some winme.
all of which do not have ntfs support.

This is a different thing. We don't support 9x for a *lot* of reasons.
The lack of NTFS is a very minor one. There are a *lot* of other things
that are just not inmplemented, or so badly implemented it's unusable,
in these systems.

Your only option in this case is the Cygwin version, where a huge amount
of work has gone into re-implementing these things in teh Cygwin
framework. AFAIK it works on 9x - as well as anything can ;-)

since the app will not be world accessable, only through
localhost, the
lack of security isn't a major concern.

If you're even considering Win9x, security is clearly not a concern :-)

//Magnus

Magnus Hagander wrote:

rc5-2 msi will not install at all on a fat32 filesystem
even without initialising the database.

Really? The code for checking the filesystem type is only executed if
you chose to initdb, so I really don't see this happening. Exactly what
message do you get?

Log in the temp install dir:
The Cacls command can be run only on disk drives that use the NTFS file
system

I'll have to rip half or more of the full log as it seems to be to large
for the list to accept

--
========================================

only plain text format email accepted.

smaller file size, no virus transfer
no proprietary file formats.

========================================

rc5-2 msi will not install at all on a fat32 filesystem
even without initialising the database.

Really? The code for checking the filesystem type is only executed if
you chose to initdb, so I really don't see this happening.

Exactly what

message do you get?

Log in the temp install dir:
The Cacls command can be run only on disk drives that use the
NTFS file
system

I'll have to rip half or more of the full log as it seems to
be to large
for the list to accept

I assume you are talking about the initdb.log file? That file is created
by initdb.bat, which should only be called when you choose to run
initdb. Exactly which options did you specify during the installation?

//Magnus

Magnus Hagander wrote:

rc5-2 msi will not install at all on a fat32 filesystem
even without initialising the database.

Really? The code for checking the filesystem type is only executed if
you chose to initdb, so I really don't see this happening.

Exactly what

message do you get?

Log in the temp install dir:
The Cacls command can be run only on disk drives that use the
NTFS file
system

I'll have to rip half or more of the full log as it seems to
be to large
for the list to accept

I assume you are talking about the initdb.log file? That file is created
by initdb.bat, which should only be called when you choose to run
initdb. Exactly which options did you specify during the installation?

//Magnus

with msi installer, options are only for where to install, until initdb
stage. chose no at that point, and it installs, then errors and
completely un-installs.
leaving a dir struct under program files with a single file: pgperm.log
under the directory with the msi files in it there is a full install
log, which the list has twice refused to accept as being to large.

Log in the temp install dir:
The Cacls command can be run only on disk drives that use the NTFS
file system

I'll have to rip half or more of the full log as it seems to be to
large for the list to accept

I assume you are talking about the initdb.log file? That

file is created

by initdb.bat, which should only be called when you choose to run
initdb. Exactly which options did you specify during the

installation?

//Magnus

with msi installer, options are only for where to install,
until initdb
stage.

(I assume you entered a service username and password as well, because
there is no way to get past that dialog without it)

chose no at that point, and it installs, then errors and
completely un-installs.
leaving a dir struct under program files with a single file:
pgperm.log
under the directory with the msi files in it there is a full install
log, which the list has twice refused to accept as being to large.

Ok. There is indeed a bug here. Seems this codepath is not exercised a
lot - most people follow the advice not to store their data on FAT ;-)
And the other tests just exercised the case when you didn't do a service
install at all.

The pgperm.bat file incorrectly tries to do cacls on the DATA directory
even if it's installed on FAT. It correctly skips the bin, lib, share
etc paths, but not DATA.

Dave has committed a fix for this and it will be in the release.

//Magnus

chose no at that point, and it installs, then errors and completely
un-installs.
leaving a dir struct under program files with a single file:
pgperm.log
under the directory with the msi files in it there is a

full install

log, which the list has twice refused to accept as being to large.

Ok. There is indeed a bug here. Seems this codepath is not
exercised a lot - most people follow the advice not to store
their data on FAT ;-) And the other tests just exercised the
case when you didn't do a service install at all.

The pgperm.bat file incorrectly tries to do cacls on the DATA
directory even if it's installed on FAT. It correctly skips
the bin, lib, share etc paths, but not DATA.

Dave has committed a fix for this and it will be in the release.

Actually, we just uploaded RC5-3 to the pgFoundry site with this fix in
it if you need it faster.

//Magnus

Tony Caduto wrote:

Hi,
Does anyone know if there is a way to get the backends IP address from
the PID?
I am using the view pg_stat_activity and it would be nice if it would
also display the IP address along with the PID.

I can see the IP address when I do a ps -ef but it would be nice to be
able to get it via a sql command.

Added to TODO:

* Add IP address to pg_stat_activity

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tony Caduto wrote:

Hi,
Does anyone know if there is a way to get the backends IP address from
the PID?
I am using the view pg_stat_activity and it would be nice if it would
also display the IP address along with the PID.

I can see the IP address when I do a ps -ef but it would be nice to be
able to get it via a sql command.

Added to TODO:

* Add IP address to pg_stat_activity

While this does not involve the POD, but doesn't this give the IP address of
the host:

select inet_server_addr()

Or is he talking about something else?

--BMT

Berend Tober wrote:

Tony Caduto wrote:

Hi,
Does anyone know if there is a way to get the backends IP address from
the PID?
I am using the view pg_stat_activity and it would be nice if it would
also display the IP address along with the PID.

I can see the IP address when I do a ps -ef but it would be nice to be
able to get it via a sql command.

Added to TODO:

* Add IP address to pg_stat_activity

While this does not involve the POD, but doesn't this give the IP address of
the host:

select inet_server_addr()

Or is he talking about something else?

Yes, I updated the TODO:

* Add the client IP address to pg_stat_activity

and while there is a client version that does your connection, it
doesn't work for other connections.

I think we should display all the info we show in ps -ef in
pg_stat_activity and the one piece we don't give currently is the client
address.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce,
On another note, is there plans to improve the type checking of stored
functions during the save/compile?
Currently I can pretty much make tons of mistakes (on purpose of course
:-) and they are not flagged as errors until runtime.
The biggest complaint I see from other DBAs (MS SQL, Oracle) is that
Postgres does little to no pre-runtime type checking.

Thanks,

Tony Caduto

Bruce Momjian wrote:

On Saturday 12 February 2005 4:09 pm, Bruce Momjian wrote:

Added to TODO:

* Add IP address to pg_stat_activity

I like it. How about IP and port to differentiate multiple connections
from the same host? Will this support IPV6?

Cheers,
Steve

Tony Caduto wrote:

Bruce,
On another note, is there plans to improve the type checking of stored
functions during the save/compile?
Currently I can pretty much make tons of mistakes (on purpose of course
:-) and they are not flagged as errors until runtime.
The biggest complaint I see from other DBAs (MS SQL, Oracle) is that
Postgres does little to no pre-runtime type checking.

We have no plans to improve that. We do have 'check_function_bodies'
which defaults to true and does some checking. Would you give us a
particular example you would like improved?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073