On Fri, 26 Jan 2001, Peter Eisentraut wrote:
Bruce Momjian writes:
If we have to do it, let's make it an #ifdef __linux__ option.
What does Linux have to do with it? FreeBSD does the same thing, only
every three days. I dont' know whether it's not enabled on a fresh
install, but it's there,
Jan Wieck wrote:
Peter Eisentraut wrote:
Jan Wieck writes:
Exactly the way you want it to do (open(2) and close(2) of a
UNIX domain socket) was what I had to do to get an old
Mach3-4.3BSD combo into a kernel-panic.
The lock file is an ordinary file.
At 14:56 24/01/01 -0500, Rod Taylor wrote:
pg_dump -c database
The \connect is after the DROP TABLE statements where I believe it
should come first. (Gotta connect as the right user before dropping
everything).
This is now fixed.
Tom Lane wrote:
Meanwhile, it's not the RPMs' place to editorialize on which contrib
items are useful. Package 'em all, unless we hit build problems.
Interesting point of view :-). Going into 'Uncle Martin' mode (obscure
joke alert...).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
A fatal scanner error (likely a memory exhaustion problem) causes a
straight exit() without clean up, which causes a system-wide restart.
This should fix it:
*** scan.l 2001/01/24 19:43:03 1.85
--- scan.l 2001/01/27 14:14:29
***
*** 55,60
--- 55,62
/* No
This happened on SuSE 7.0, compiling with gcc 2.95. Maybe I downloaded some
stale corrupted tarball with a file missing - I went to
.http://www.pgsql.com/download/ and just clicked on the top "Download"
button. Where is F_OIDEQ supposed to be defined anyway?
here:
I'm using PostgreSQL on WinNT to support (along with Zope) several
websites. I've currently got postmaster running as an NT service by
wrapping it with the 'invoker' utility, but I'd prefer to have it run
directly as a service so that it can be stopped cleanly. I now know
the basics of how to
d) How can we insure that the ipc-daemon service starts before the
postgres/postmaster service? I believe that NT has some facility that
allows one service to request start-up of another service, but I have
no idea how to make that happen.
You can use Service Dependencies for this. In you
Fred Yankowski [EMAIL PROTECTED] writes:
a) The 'install' and 'remove' code is quite bulky, although simple.
Is it OK to create a new source file for it, rather than working it
into some existing file?
I think this'd be a lot easier to sell (and probably to implement)
if the NT-specific stuff
Peter Eisentraut [EMAIL PROTECTED] writes:
A fatal scanner error (likely a memory exhaustion problem) causes a
straight exit() without clean up, which causes a system-wide restart.
This should fix it:
*** scan.l 2001/01/24 19:43:03 1.85
--- scan.l 2001/01/27 14:14:29
On Friday 26 January 2001 19:04, The Hermit Hacker wrote:
Need more information ... specifically what OS are you running? I *just*
built PgSQL 7.0.3 on my freshly installed FreeBSD 4.2-RELEASE box, and it
compiled cleanly ...
This happened on SuSE 7.0, compiling with gcc 2.95. Maybe I
/tmp is for *temporary* files. Such a lock is not a temporary file, it
should go somewhere in /var, why not in /var/lib/pgsql/data ?
The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock
file after the server has run 6 days. This will be a problem.
We could touch
My guess is that there is some old/other include that is interfering
with our includes. This it the first OID_EQ compile error I can
remember seeing.
This happened on SuSE 7.0, compiling with gcc 2.95. Maybe I downloaded some
stale corrupted tarball with a file missing - I went to
Jan Wieck wrote:
Peter Eisentraut wrote:
Jan Wieck writes:
Exactly the way you want it to do (open(2) and close(2) of a
UNIX domain socket) was what I had to do to get an old
Mach3-4.3BSD combo into a kernel-panic.
The lock file is an
Applied to CVS. Thanks.
Bruce Momjian wrote:
Constantin Teodorescu wrote:
I'll fix it this weekend!
OK, let me know if you release a new pgaccess and I will add it to CVS.
Bug fixed. Ross patches applied.
HTML documentation updated with what's new.
Hope it's fine!
Here are the open items for 7.1. Much shorter:
+ Runtime btree recovery
Vadim
This is fixed in the pgaccess version in CVS.
On Wed, 31 May 2000, Bruce Momjian wrote:
I assume this is fixed?
Oh, it is really old letter from me. I total forget...
Hmm, I haven't here last version of CVS, but pgaccess in my comp has this
bug still..
Bruce, thanks
Florent Guillaume wrote:
/tmp is for *temporary* files. Such a lock is not a temporary file, it
should go somewhere in /var, why not in /var/lib/pgsql/data ?
/var/lib is also not for locks, per FHS.
/var/lock/pgsql (or /var/lock/postgresql) would be the FHS-mandated
place for such a
first off, the lock file is put in by an unprivileged user, so /tmp works
on all systems ...
second, /tmp on a large portion of systems gets cleaned out after a
reboot, so there are no 'stray locks' to generally worry about...
On Sat, 27 Jan 2001, Lamar Owen wrote:
Florent Guillaume wrote:
Oleg Bartunov [EMAIL PROTECTED] writes:
btw, is there way to specify default ops for index ?
Sure, that's what pg_opclass is for. Just insert the opclass name
and the OID of the type you want it to be the default index opclass
for.
regards, tom lane
The Hermit Hacker wrote:
On Sat, 27 Jan 2001, Lamar Owen wrote:
Comments? _Why_ is the lock in /tmp? Won't the lock always be put into
place by the uid used to run postmaster? Is a _world_ writeable
temporary directory the right place?
first off, the lock file is put in by an
Lamar Owen writes:
I understand why the socket needs to be in /tmp, but why the lockfile?
The lock file protects the Unix domain socket. Consequently, the name of
the lock file needs to be derivable from the name of the socket file, and
vice versa. Also, the name of the socket file must not
Peter Eisentraut wrote:
Lamar Owen writes:
I understand why the socket needs to be in /tmp, but why the lockfile?
The lock file protects the Unix domain socket. Consequently, the name of
the lock file needs to be derivable from the name of the socket file, and
vice versa. Also, the name
I understand why the socket needs to be in /tmp, but why the lockfile?
It would probably be better if the socket files weren't in /tmp but in
a postgres-owned directory. However, at this point we have a huge
backwards compatibility problem to overcome if we want to move the
socket files. The
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
However I'm suspicious if KEY_CHANGED check is necessary.
Removing KEY_CHANGED stuff seems to solve the TODO
FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation"
though it may introduce other bugs.
It would probably be better if the socket files weren't in /tmp but in
a postgres-owned directory. However, at this point we have a huge
backwards compatibility problem to overcome if we want to move the
socket files. The location of the socket files is essentially a core
part of the
Bruce Momjian wrote:
Note: programs that run as non-root users may be unable to create files un
der
/var/run and therefore need a subdirectory owned by the appropriate user.
This is the killer. We can't require root. Seems we are stuck with
/tmp.
I'd be surprised to learn
"Oliver Elphick" [EMAIL PROTECTED] writes:
/var/run/postgresql
There's another reason why the standard socket directory is /tmp,
and that's that it exists everywhere. Not all Unix systems even *have*
a /var hierarchy, let alone one that the admin will let you have a
playpen in.
Max Rudensky wrote:
Guys,
Thomas said he won't look into GPL'ed code for ideas.
Well, I re-read GPL and found that it's up to author whether is to allow or not
to use code for using in programs with another open-source license. So this isn't
a problem - you may use my program and include
At 07:24 26/01/01 +0900, Tatsuo Ishii wrote:
Fix for pg_dump of bad system tables
Ok. I have made patches for fixing some of pg_dump problems(see
attached patches).
...
Also I'm not quite sure "#arg" (stringification) is
portable enough in all platforms.)
The patch looks fine to me, but I
Philip Warner [EMAIL PROTECTED] writes:
Also I'm not quite sure "#arg" (stringification) is
portable enough in all platforms.)
The patch looks fine to me, but I have no idea how portable #arg is
Use the CppAsString macro from our c.h ... that's what it's for.
It's actually fairly unlikely
At 07:24 26/01/01 +0900, Tatsuo Ishii wrote:
Fix for pg_dump of bad system tables
Ok. I have made patches for fixing some of pg_dump problems(see
attached patches). The patches address the problem with user defined
functions, operators and aggregates.
These have now been applied with minor
I assume this addresses the open item:
Fix for pg_dump of bad system tables
I will remove it from the list. Thanks.
At 07:24 26/01/01 +0900, Tatsuo Ishii wrote:
Fix for pg_dump of bad system tables
Ok. I have made patches for fixing some of pg_dump problems(see
attached
At 23:14 27/01/01 -0500, Bruce Momjian wrote:
I assume this addresses the open item:
Fix for pg_dump of bad system tables
I will remove it from the list. Thanks.
I'd remove it from the 'Required for 7.1' list, but leave it on the TODO
list, since the task is not quite
At 23:14 27/01/01 -0500, Bruce Momjian wrote:
I assume this addresses the open item:
Fix for pg_dump of bad system tables
I will remove it from the list. Thanks.
I'd remove it from the 'Required for 7.1' list, but leave it on the TODO
list, since the task is not quite complete.
At
Hannu Krosing wrote:
If it's all your code, then you are free to license it under any licence
you desire.
...
What you probably can't do is to revoke the GPL license.
You can't revoke it from existing copies "out there", but you can from any
copies you release from now on, even of the
36 matches
Mail list logo
