On Wed, Jun 09, 2004 at 09:13:05PM +0530, Shridhar Daithankar wrote:
>
> Well that is easy. In the service file just say
>
> [Cluster1]
> datapath=/data/foo
>
> [Cluster2]
> datapath=/data/foo1
>
> and postgresql.conf could still reside inside each cluster to provide
> specific configuration
On Wed, 9 Jun 2004, Stephan Szabo wrote:
> On Wed, 9 Jun 2004, Alvaro Herrera wrote:
>
> > On Sun, May 30, 2004 at 04:07:27AM -0700, Stephan Szabo wrote:
> > > On Sat, 29 May 2004, Alvaro Herrera wrote:
> >
> > > > Ah, this seems to work. I'll implement it and I'll let you know how it
> > > > go
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Looks good to me. The only issue I saw was that the default file name
mentioned in postgresql.conf doesn't match the actual default.
I'm really not happy with the concept that the postmaster overrides
its stderr direction.
Me ei
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
> be supplied by the connection string in libpq on platforms that want
> threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)?
AFAICS that was not what Jan was suggesting at
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Looks good to me. The only issue I saw was that the default file name
> mentioned in postgresql.conf doesn't match the actual default.
I'm really not happy with the concept that the postmaster overrides
its stderr direction.
reg
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> [blink] This seems to miss out on the actual point of the thread (hash
>> bucket size shouldn't be a disk page) in favor of an entirely
>> unsupported sub-suggestion.
> Yes, I was unsure of the text myself. I have changed it to:
>
Oh, it would need doc additions. I can do that when I apply, or you can
resubmit.
---
Andreas Pflug wrote:
> Magnus Hagander wrote:
>
> >Specifically about the logs, I still think there is a lot of value to
> >being able t
Are people OK with requiring PGUSER, $USER, $LOGNAME, or the username to
be supplied by the connection string in libpq on platforms that want
threads and don't have getpwuid_r() (Solaris, FreeBSD, etc.)?
If so, I can easily create a patch and apply it.
---
Looks good to me. The only issue I saw was that the default file name
mentioned in postgresql.conf doesn't match the actual default.
Is this ready to be added to the patch queue?
---
Andreas Pflug wrote:
> Magnus Hagander
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Added to TODO:
> > * Order heap pointers on hash index pages by hash value and ctid
>
> [blink] This seems to miss out on the actual point of the thread (hash
> bucket size shouldn't be a disk page) in favor of an entirely
> unsu
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Added to TODO:
> * Order heap pointers on hash index pages by hash value and ctid
[blink] This seems to miss out on the actual point of the thread (hash
bucket size shouldn't be a disk page) in favor of an entirely
unsupported sub-suggestion.
Added to TODO:
* Order heap pointers on hash index pages by hash value and ctid
---
Zeugswetter Andreas SB SD wrote:
>
> > We could safely sort on the hash value, but I'm not sure how effective
> > that would be, c
In a recent discussion on IRC, some anomalies concerning CHECK
constraints were brought to light, in that in some cases they do not
guarantee that the data within the table satisfies them. For example
(against 7.4.1),
test=# create table foo (
test(# foo_stamp timestamptz not null,
test(# foo_i
On Fri, Feb 27, 2004 at 10:48:57AM -0800, Josh Berkus wrote:
>
> RT: I've been using RT for OSCON, and am not wowed by it.Of course, I
> can say the same of BZ and GForge-Tracker. From my perspective, it's
> neither better nor worse than the other solutions, although the interaction
> w
A new BETA tarball for the Slony-I replication system is now available
for download form the project homepage:
http://gborg.postgresql.org/project/slony1/projdisplay.php
Regards, the Slony-I project team
---(end of broadcast)---
TIP 7: don't fo
On Wed, 9 Jun 2004, Alvaro Herrera wrote:
> On Sun, May 30, 2004 at 04:07:27AM -0700, Stephan Szabo wrote:
> > On Sat, 29 May 2004, Alvaro Herrera wrote:
>
> > > Ah, this seems to work. I'll implement it and I'll let you know how it
> > > goes.
> >
> > Ugh... There's one further wrinkle I hadn't
Is there a TODO here?
---
Tom Lane wrote:
> "Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> > ... Introducing a new query execution step sounds
> > like a better/easier idea than was I was going to do, which was to
> > rewo
Alvaro Herrera wrote:
> > One interesting idea would be for COMMIT to affect the outer
> > transaction, and END not affect the outer transaction. Of course that
> > kills the logic that COMMIT and END are the same, but it is an
> > interesting idea, and doesn't affect backward compatibility becaus
> On Wed, Jun 09, 2004 at 13:41:27 -0400,
> [EMAIL PROTECTED] wrote:
>>
>> Sigh, because vacuums take away from performance. Imagine a table that
>> has
>> to be updated on the order of a few thousand times a minute. Think about
>> the drop in performance during the vacuum.
>>
>> On a one row tab
On Tue, Jun 08, 2004 at 07:16:45PM -0400, [EMAIL PROTECTED] wrote:
> >
> >
> > [EMAIL PROTECTED] wrote:
> >
> >>I've been down several roads about how to handle data that has to change
> >>on a very frequent and rapid manner.
> >>
> >>Think about summary tables, WEB session tables, etc. As great as
In the last exciting episode, [EMAIL PROTECTED] wrote:
>> [EMAIL PROTECTED] writes:
>>> Anyway, I'm not quite getting the idea of caching sequence values. I
>>> understand the performance benefits, but it seems problematic across
>>> multiple backends, almost ensuring "holes" in the sequence of num
Dear Tom,
Thanks for your reply.
Thinking about it, yes; there are triggers that (may) do updates on this
table, and there is a master table "pakolas" ("pakolas_cikktetel" is a
detail of it) that I touch, and yes, it has a NOTIFY in AFTER trigger. (that
is one of the causes I touch that table ;) )
On Fri, May 28, 2004 at 04:05:40PM -0400, Bruce Momjian wrote:
Bruce,
> One interesting idea would be for COMMIT to affect the outer
> transaction, and END not affect the outer transaction. Of course that
> kills the logic that COMMIT and END are the same, but it is an
> interesting idea, and do
I've appended a quote from Ch 41 on the SPI; I'd like
to make sure I understand the implications of this. If
I've allocated resources inside my procedure (file
handles or what-not), how would I clean those up in
the case of a transaction abort? Could I Notify my
application that the transaction abo
On Sun, May 30, 2004 at 04:07:27AM -0700, Stephan Szabo wrote:
> On Sat, 29 May 2004, Alvaro Herrera wrote:
> > Ah, this seems to work. I'll implement it and I'll let you know how it
> > goes.
>
> Ugh... There's one further wrinkle I hadn't thought about, imagine the
> following:
Ok Stephan, th
> On 6/8/2004 11:46 AM, [EMAIL PROTECTED] wrote:
>
>>>
>>> This strikes me as a complete nonstarter.
>>
>> Tom, I have to chuckle here. You HATE every suggestion I ever make. I
>> can't think of one thing I've suggested over the years that was ever met
>> with enthusiasm. Never change. :-)
>
> I ha
Greg Stark <[EMAIL PROTECTED]> writes:
> What I'm curious about is where the original behaviour came from. Is
> it just because insert with subscripts was never implemented? Or was
> there a rationale for ignoring the subscripts?
It's been awhile, but I think that "ignore the subscripts" may have
On Wed, Jun 09, 2004 at 01:41:27PM -0400, [EMAIL PROTECTED] wrote:
> > On Wed, Jun 09, 2004 at 10:49:20PM +0800, Christopher Kings-Lynne wrote:
> > Also he said that the problem was solved with enough lazy VACUUM
> > scheduling. I don't understand why he doesn't want to use that
> > solution.
>
Jan Wieck wrote:
> On 6/9/2004 1:44 PM, Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> On 6/9/2004 1:04 PM, Bruce Momjian wrote:
> >>
> >> > What we really need is a way to do the uid->username mapping in a
> >> > thread-safe way. Could we check the environment for $USER or $LOGNAME?
> >> > Co
On Wed, 2004-06-09 at 11:41, [EMAIL PROTECTED] wrote:
> > On Wed, Jun 09, 2004 at 10:49:20PM +0800, Christopher Kings-Lynne wrote:
> >> >I love PG, I've been using it since version 6x, and it has gotten
> >> >fantastic over the years, and in many cases, I would choose it over
> >> >Oracle, but for
Sigh, because vacuums take away from performance.
This is a known issue that has been pretty much resolved for 7.5. Vacuum
in 7.5 does not take even close to as much IO resources.
Imagine a table that has
to be updated on the order of a few thousand times a minute. Think about
the drop in perfo
On 6/9/2004 1:44 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 6/9/2004 1:04 PM, Bruce Momjian wrote:
> What we really need is a way to do the uid->username mapping in a
> thread-safe way. Could we check the environment for $USER or $LOGNAME?
> Could we require them to be set for thread builds on O
Also he said that the problem was solved with enough lazy VACUUM
scheduling. I don't understand why he doesn't want to use that
solution.
Because even lazy VACUUM is horrendous to performance but as I said in
a further post this has been pretty much fixed by (Jan I believe) in 7.5.
Sincerely,
Jos
On Wed, Jun 09, 2004 at 13:41:27 -0400,
[EMAIL PROTECTED] wrote:
>
> Sigh, because vacuums take away from performance. Imagine a table that has
> to be updated on the order of a few thousand times a minute. Think about
> the drop in performance during the vacuum.
>
> On a one row table, vacuum
Jan Wieck wrote:
> On 6/9/2004 1:04 PM, Bruce Momjian wrote:
>
> > What we really need is a way to do the uid->username mapping in a
> > thread-safe way. Could we check the environment for $USER or $LOGNAME?
> > Could we require them to be set for thread builds on OS's without
> > getpwuid_r and
On 6/9/2004 1:04 PM, Bruce Momjian wrote:
What we really need is a way to do the uid->username mapping in a
thread-safe way. Could we check the environment for $USER or $LOGNAME?
Could we require them to be set for thread builds on OS's without
getpwuid_r and in cases where the username is not spe
> On Wed, Jun 09, 2004 at 10:49:20PM +0800, Christopher Kings-Lynne wrote:
>> >I love PG, I've been using it since version 6x, and it has gotten
>> >fantastic over the years, and in many cases, I would choose it over
>> >Oracle, but for systems that need frequent updates, I have a lot of
>> >concer
On 6/8/2004 11:46 AM, [EMAIL PROTECTED] wrote:
This strikes me as a complete nonstarter.
Tom, I have to chuckle here. You HATE every suggestion I ever make. I
can't think of one thing I've suggested over the years that was ever met
with enthusiasm. Never change. :-)
I happen to agree with Tom on th
Well, looks like you are missing getpwuid_r():
Your system uses getpwuid() which is not thread-safe. **
and we don't have any workaround for this.
---
Jan Wieck wrote:
> On 6/9/2004 11:16 AM, Bruce Momjian wrote:
>
Jan Wieck wrote:
> On 6/9/2004 11:45 AM, Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> The problem is that if your thread-safety tests fail, there is no way to
> >> build libpq with -pthread and -DREENTRANT or whatever is required on
> >> that platform. On Solaris this results in errno being
Added time.h to pg_dumpall.c. Thanks.
---
Alvaro Herrera wrote:
> I got:
>
> gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations
> -I/home/alvherre/CVS/pgsql/source/13commitOpt/src/interfaces
On Wed, Jun 09, 2004 at 10:49:20PM +0800, Christopher Kings-Lynne wrote:
> >I love PG, I've been using it since version 6x, and it has gotten
> >fantastic over the years, and in many cases, I would choose it over
> >Oracle, but for systems that need frequent updates, I have a lot of
> >concerns.
>
"=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?=" <[EMAIL PROTECTED]> writes:
> Q1. So is this everything that can be said -- NOTIFY calls
> simple_heap_update that is concurrently updated by a different transaction?
If that's what it is, then there's still a question: why? The notify
code has enough locking t
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Thu, 26 Feb 2004, Gavin Sherry wrote:
>
> > Comments? Questions? Suggestions?
>
> Is that plan that in the future one can split a single table into
> different table spaces? Like storing all rows with year < 1999 in one
> tablespace and the re
Honza Pazdziora wrote:
On Wed, Jun 09, 2004 at 07:53:19PM +0530, Shridhar Daithankar wrote:
Well, the statement 'postgresql.conf outside data directory' isn't going to
win I think.
One day there won't be any data directory because the data will be
on raw partitions. Then you will _have_ to have th
Jan Wieck wrote:
> On 6/9/2004 9:36 AM, Bruce Momjian wrote:
> >
> >> Also, I would suggest that we allow to build the libpq with thread
> >> specific compiler options, even if it is not entirely thread safe. It
> >> would require that a really multithreaded application has to have
> >> mutexes
On 6/9/2004 11:16 AM, Bruce Momjian wrote:
Jan Wieck wrote:
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
> Jan Wieck wrote:
>> I am wondering why thread_test.c is checking for mktemp()? That function
>> is nowhere used in the libpq.
>
> Uh, it isn't checking for mktemp, it is using it, and it is usi
Tom Lane <[EMAIL PROTECTED]> writes:
> What I would like to do about this is define INSERT to a subscripted
> column name as working the same way that an assignment to a element or
> slice of a zero-dimension array presently does --- that is, you get an
> actual array back and not a NULL. It wou
On 6/9/2004 11:45 AM, Bruce Momjian wrote:
Jan Wieck wrote:
The problem is that if your thread-safety tests fail, there is no way to
build libpq with -pthread and -DREENTRANT or whatever is required on
that platform. On Solaris this results in errno being defined as
extern int errno;
as sup
I got:
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations
-I/home/alvherre/CVS/pgsql/source/13commitOpt/src/interfaces/libpq
-I../../../src/include -I/home/alvherre/CVS/pgsql/source/13commitOpt/src/include
-D_GNU_SOURCE -DFRONTEND -c -o pg_dumpall.o
/home/alvhe
I love PG, I've been using it since version 6x, and it has gotten
fantastic over the years, and in many cases, I would choose it over
Oracle, but for systems that need frequent updates, I have a lot of
concerns.
...that's the price you pay for concurrency man...
Chris
---(en
>> I love PG, I've been using it since version 6x, and it has gotten
>> fantastic over the years, and in many cases, I would choose it over
>> Oracle, but for systems that need frequent updates, I have a lot of
>> concerns.
>
> ...that's the price you pay for concurrency man...
I think that's a co
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Jan Wieck wrote:
I am wondering why thread_test.c is checking for mktemp()? That function
is nowhere used in the libpq.
Uh, it isn't checking for mktemp, it is using it, and it is using it
because someone didn't like hard-coded paths I was using in the pas
Greg Sabino Mullane wrote:
(warning: rehashing of issues ahead)
[snipped: suggestion to have much more documentation in sample postgresql.conf]
Wasn't RedHat working on a configuration utility for Postgres? That
seems to me like a much more productive way to go.
cheers
andrew
-
Jan Wieck wrote:
> On 6/9/2004 9:36 AM, Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> I am wondering why thread_test.c is checking for mktemp()? That function
> >> is nowhere used in the libpq.
> >
> > Uh, it isn't checking for mktemp, it is using it, and it is using it
> > because someone di
On 6/9/2004 9:36 AM, Bruce Momjian wrote:
Also, I would suggest that we allow to build the libpq with thread
specific compiler options, even if it is not entirely thread safe. It
would require that a really multithreaded application has to have
mutexes around certain operations, but being entir
"=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?=" <[EMAIL PROTECTED]> writes:
> ERROR: simple_heap_update: tuple concurrently updatedog.
> LOG: statement: INSERT INTO pakolas_cikktetel
> (cikk, minoseg, helyrol, mennyi, pakolas, sorszam, helyre) VALUES
> (102165, 1, 1488, '25', 68615, 1, 1338)
Hmm
On Wed, Jun 09, 2004 at 07:53:19PM +0530, Shridhar Daithankar wrote:
>
> Well, the statement 'postgresql.conf outside data directory' isn't going to
> win I think.
One day there won't be any data directory because the data will be
on raw partitions. Then you will _have_ to have the configuration
[EMAIL PROTECTED] writes:
> This is *NOT* a perfect or elegant solution. There is, however, an
> important problem. How do you maintain a value that is visable to the
> database, but does not incure the cost of a huge number of updates or a
> full table scan? I'm talking about systems that need t
Darko Prenosil <[EMAIL PROTECTED]> writes:
> CREATE RULE child_ins AS ON INSERT TO test.child
> DO INSTEAD SELECT test.testfi(NEW);
> INSERT INTO test.child(id,id_data,opis,podaci) VALUES (1,1,'Opis','podaci');
> (-403)ERROR: cannot handle whole-row reference
It works in CVS tip ;-). No
Bruce Momjian <[EMAIL PROTECTED]> writes:
> One idea that has been floated around is to pull the docs automatically
> from SGML and put them in postgresql.conf.
In theory, postgresql.conf.sample could be a generated file: pull the
docs from SGML and the default values from the GUC tables. However
[EMAIL PROTECTED] wrote:
I have a LOT of opinions about postgresql.conf, and frankly, I think more
comments are not where the problems lie.
If you *really* want to make configuring postgresql easier,
postgresql.conf HAS to live outside the data directory and specify where
everything is. postgresql.
On Wed, Jun 09, 2004 at 12:33:03PM +0200, Grega Bremec wrote:
>
> Collate order for those databases, however, needs to be different. Obviously,
[...]
> Is it possible to do either of these things that could solve this problem
> adequately:
>
> - somehow manage to make one postmaster run on
I agree. I wasn't aware of that restriction.
regards,
Thomas Hallgren
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Thomas Hallgren" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, June 09, 2004 15:56
Subject: Re: [HACKERS] Question regarding dynamic_librar
Dear Gurus,
I tried to shuffle through the archives but was lost in the technical
details. Please feel free to tell me a search keyword suitable for my case
if there's any.
QUESTION1: is this error _always_ harmless (other than transaction
rollback)?
QUESTION2: is this reported exactly like other
Hello, List,
I recently stumbled across a problem that I can't really get across.
We have a database cluster (PG 7.4.2) that was initialized as follows:
$ pg_controldata /data/dir
pg_control version number:72
Catalog version number: 200310211
Database cl
"Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> And only the super user can use directory components in a module name?
Only superusers can create C functions in the first place, so quibbling
about what paths they can use doesn't seem that useful ...
regards, tom lane
Grega Bremec <[EMAIL PROTECTED]> writes:
> Collate order for those databases, however, needs to be different.
If you need multiple LC_COLLATE settings then you have to run multiple
postmasters. There is no other solution today, nor likely to be one in
the near future.
> Also, running several pos
I have a LOT of opinions about postgresql.conf, and frankly, I think more
comments are not where the problems lie.
If you *really* want to make configuring postgresql easier,
postgresql.conf HAS to live outside the data directory and specify where
everything is. postgresql.conf should do exactly a
Jan Wieck wrote:
> I am wondering why thread_test.c is checking for mktemp()? That function
> is nowhere used in the libpq.
Uh, it isn't checking for mktemp, it is using it, and it is using it
because someone didn't like hard-coded paths I was using in the past.
Is there something wrong with usi
We discussed this and thought that it would end up duplicating stuff
already in the docs, and removing the comments means that you have no
way to know which are being set to non-default values. Both seem to be
a loss.
Are people saying the Apache config files are easier to use? I actually
find
I am wondering why thread_test.c is checking for mktemp()? That function
is nowhere used in the libpq.
Also, I would suggest that we allow to build the libpq with thread
specific compiler options, even if it is not entirely thread safe. It
would require that a really multithreaded application h
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > Yep, Tom fixed it good.
>
> Was this another of those darn regurgitated-from-February messages?
> I'm about ready to go out and acquire missile targeting coordinates
> for pcbuddy.com ...
No, it was me cleaning out my old e
And only the super user can use directory components in a module name?
regards,
Thomas Hallgren
"Andrew Dunstan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
>
> Thomas Hallgren wrote:
>
> >Isn't the fact that "dynamic_library_path" can
> >be changed at any time by a user a seri
>
> [EMAIL PROTECTED] wrote:
>
>>The best phrasing would be "the accumulating overhead of deletes and
>>updates."
>>
>>Yes.
>>
>>
>
> Are you using 7.3?
>
> I am asking because in 7.3 high update / delete tables could suffer
> (index and toast) bloat that was untamable via (lazy) VACUUM and FSM.
>
Why is this wrong ?:
DROP SCHEMA test CASCADE ;
CREATE SCHEMA test;
CREATE TABLE test.parent (
id serial PRIMARY KEY,
opis text
);
CREATE TABLE test.child_data (
id serial PRIMARY KEY,
id_parent int ,
podaci text,
FOREIGN KEY (id_parent) REFERENCE
Thomas Hallgren wrote:
Isn't the fact that "dynamic_library_path" can
be changed at any time by a user a serious security flaw?
It's not "a user". Only the superuser can change it.
cheers
andrew
---(end of broadcast)---
TIP 2: you can get off all
"Tommi Maekitalo" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> in linux you can change LD_LIBRARY_PATH in a running process, but it does
not
> help. The library-loader initializes himself at process-startup and
changing
> LD_LIBRARY_PATH do not change the actual path, the process is using for
> dlopen.
>
T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(warning: rehashing of issues ahead)
Sometimes when I talk to technical people about using PostgreSQL,
I get a strong reaction along the lines of "it's ugly, complex, and
hard to set up." While we have gotten better than we used to be,
some of th
Per a brief conversation with Tom, I've created a patch for adding support for
'week' within the date_trunc function.
Within the patch I added a couple of test cases and associated target output,
and changed the documentation to add 'week' appropriately.
Comments? Should I of bypassed this list
When grilled further on (29 Feb 2004 08:46:36 -0800),
[EMAIL PROTECTED] (Hammer) confessed:
> Quick one:
> Anyone know how to use Putty to open a connection up under SSH which
> will allow pgAdmin III to connect to a postgresql database ie. Only
> access to server postgresql is on is via ssh.
>
Hi,
in linux you can change LD_LIBRARY_PATH in a running process, but it does not
help. The library-loader initializes himself at process-startup and changing
LD_LIBRARY_PATH do not change the actual path, the process is using for
dlopen.
Tommi Mäkitalo
Am Dienstag, 8. Juni 2004 19:14 schrieb
Gavin,
#1: I really think that we should have a way to set a "default tablespace"
for any database in a cluster. This property would be vitally important
for anyone wishing to use tablespaces to impose quotas. First, the
superuser would:
ALTER DATABASE db1 ALTER DEFAULT_TABLESPACE partiti
I believe any non empty password works.
cheers
andrew
Oliver Elphick wrote:
Following instructions on
http://developer.postgresql.org/docs/postgres/cvs.html does not
currently work:
$ cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot login
Logging in to
:pserver:[EMAIL PROTECTED]:2401/projects/cv
Oh, sorry. This HP-UX 11.x. But you can get the same using shl_load (HP-UX
10.x) and pass the flag DYNAMIC_PATH provided the executable is linked with
+s. So it's still no showstopper.
If you do find that it is impossible on some older OS (HP-UX 11 arrived 4
years ago), then why not just disable t
85 matches
Mail list logo
