On Sat, 22 Nov 2003, Joshua D. Drake wrote:
Does that mean I have supplied Logictree Systems PostgreSQL? PostgreSQL with
Logictree Systems TSearch2?
Actually to some degree, yes. Of course a lot would depend on the type
of contract you have with them you may be responsible for that code.
On Sat, Nov 22, 2003 at 11:32:18PM -0400, Marc G. Fournier wrote:
I suspect it might be because I'm running in a jail'd environment, but
what should I be looking at to confirm?
could not create socket for statistics collector: Protocol not supported
You probably shouldn't worry about it.
Rod Taylor wrote:
There might be discussions whether its better to script
CREATE TABLE xxx ..;
ALTER TABLE xxx ADD PRIMARY KEY ;
ALTER TABLE xxx ADD FOREIGN KEY ;
or
CREATE TABLE xxx (, PRIMARY KEY (..), FOREIGN KEY (..));
I'd opt for the second version (a little formatted, maybe :-)
On Sun, 23 Nov 2003, Oleg Bartunov wrote:
does tsearch2 in 7.4 still has the problem ? I apologies if we miss your
patches but certainly we're interested in clear explanation of the problem.
The problem was memory allocations made through malloc and family were not
being checked for failure
I'm in the middle of implementing function parameter names. In pg_proc
the types of the parameters are currently stored as an oidvector, but
how should I store the parameter names?
Would it be a good idea to create a namevector in the same way as
oidvector? Would a normal array like name[] be
Dennis Bjorklund writes:
I'm in the middle of implementing function parameter names.
How will that work in arbitrary procedural languages?
Would it be a good idea to create a namevector in the same way as
oidvector? Would a normal array like name[] be better?
What is the reason for the
Peter Eisentraut [EMAIL PROTECTED] writes:
Dennis Bjorklund writes:
I'm in the middle of implementing function parameter names.
So these two reasons make a namevector impractical: First, it would
probably not be in the performance critical path. Second, it would use up
a fixed length of
Here is what I get:
peter ~$ pg-install/bin/initdb pg-install/var/data
...
creating directory pg-install/var/data ... initdb: failed
No points for details in the error message here either.
If I create pg-install/var first, then it work.
--
Peter Eisentraut [EMAIL PROTECTED]
On Sun, 23 Nov 2003, Peter Eisentraut wrote:
How will that work in arbitrary procedural languages?
It is passed along to the handler of the language, and if the language
wants, it can insert these into its environment before execution. I plan
to look at the languages pgsql and sql, but any
On Sun, 23 Nov 2003, Tom Lane wrote:
Actually I'd suggest text[], as there is no good reason to pad the
array entries to a fixed length.
The only reason against is that all other identifiers have this arbitrary
limit. But sure, text[] would work just as well and without any
restriction.
Is
Rod Taylor [EMAIL PROTECTED] writes:
Well.. the second one will be much slower when the foreign keys verify.
Primary, unique constraints I'll buy in the create statement. Check
constraints and defaults are a little fuzzier.
FK, primary, and unique constraints are already split out from the
Kurt Roeckx [EMAIL PROTECTED] writes:
On Sat, Nov 22, 2003 at 11:32:18PM -0400, Marc G. Fournier wrote:
I suspect it might be because I'm running in a jail'd environment, but
what should I be looking at to confirm?
could not create socket for statistics collector: Protocol not supported
Dennis Bjorklund [EMAIL PROTECTED] writes:
Is the reason to use name at all in pg just about speed, or is there
some other reason?
Peter already explained it: we like fixed-width fields in system
catalogs so that we can overlay C struct definitions onto the tuples.
This is a fairly significant
Peter Eisentraut wrote:
Here is what I get:
peter ~$ pg-install/bin/initdb pg-install/var/data
...
creating directory pg-install/var/data ... initdb: failed
No points for details in the error message here either.
If I create pg-install/var first, then it work.
I will check it out. I know I
Dennis Bjorklund [EMAIL PROTECTED] writes:
And the cost will be fairly large for named parameters as well then. On
the other hand, if one omits the parameter names one would get almost the
same speed as before (an extra test is needed to see if we have any
parameter names that needs to be
On Sun, 23 Nov 2003, Tom Lane wrote:
Kurt Roeckx [EMAIL PROTECTED] writes:
On Sat, Nov 22, 2003 at 11:32:18PM -0400, Marc G. Fournier wrote:
I suspect it might be because I'm running in a jail'd environment, but
what should I be looking at to confirm?
could not create socket for
Marc G. Fournier [EMAIL PROTECTED] writes:
Is it easy to do a quick message change to state that it was the IPv6
socket that failed?
I deliberately did not do that because we were well past error message
freeze for 7.4, but we certainly should fix it for 7.5.
regards,
Andrew Dunstan [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
creating directory pg-install/var/data ... initdb: failed
I will check it out. I know I spent quite some time making sure this
worked, but I might have missed something obvious. I wonder if it is
platform specific?
AFAICS
Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
Well.. the second one will be much slower when the foreign keys verify.
Primary, unique constraints I'll buy in the create statement. Check
constraints and defaults are a little fuzzier.
FK, primary, and unique constraints are already
While people add more executable files to CVS (cf. initdb.c), can we do
something about it?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Tom Lane wrote:
AFAICS mkdatadir() shouldn't consider subdir == NULL as a reason to
fail rather than trying mkdir_p. Indeed, if anything the opposite:
when subdir isn't NULL the immediately prior directory level should
exist already.
Right. In fact, I can't see any good reason to call mkdir
Peter Eisentraut wrote:
While people add more executable files to CVS (cf. initdb.c), can we do
something about it?
Sure. I logged into the main server machine and cd'ed to CVSROOT. I
then when to the src/bin/initdb directory, and because I didn't have
permisssions, I moved initdb.c,v to
Andrew Dunstan wrote:
Peter Eisentraut wrote:
Here is what I get:
peter ~$ pg-install/bin/initdb pg-install/var/data
...
creating directory pg-install/var/data ... initdb: failed
No points for details in the error message here either.
If I create pg-install/var first, then it work.
I will
Bruce Momjian [EMAIL PROTECTED] writes:
Sure. I logged into the main server machine and cd'ed to CVSROOT. I
then when to the src/bin/initdb directory, and because I didn't have
permisssions, I moved initdb.c,v to another file name then copied it to
the original name so I owned the file. I
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
AFAICS mkdatadir() shouldn't consider subdir == NULL as a reason to
fail rather than trying mkdir_p.
Right. In fact, I can't see any good reason to call mkdir and then
mkdir_p at all. See my patch from this afternoon.
I'm unsure
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Sure. I logged into the main server machine and cd'ed to CVSROOT. I
then when to the src/bin/initdb directory, and because I didn't have
permisssions, I moved initdb.c,v to another file name then copied it to
the original name so I
On Sun, Nov 23, 2003 at 06:59:45PM -0500, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Sure. I logged into the main server machine and cd'ed to CVSROOT. I
then when to the src/bin/initdb directory, and because I didn't have
permisssions, I moved initdb.c,v to another file name
Alvaro Herrera wrote:
On Sun, Nov 23, 2003 at 06:59:45PM -0500, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Sure. I logged into the main server machine and cd'ed to CVSROOT. I
then when to the src/bin/initdb directory, and because I didn't have
permisssions, I moved
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Um. Can anyone else check into those files now?
Yes, I think so. The file used to be owned by Peter, but now by me:
Oh, okay. I had the idea they should all be owned by the cvs daemon,
but I guess that's not required.
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
BTW, I can see a whole lot of files with the executable bit:
find pgsql-server/ -type f -perm +0333 -ls
That command doesn't seem to work for me.
He's looking for *either* write or execute permissions. AFAIK there is
no reason
On Mon, 24 Nov 2003 11:41 am, Bruce Momjian wrote:
find pgsql-server/ -type f -perm +0333 -ls
That command doesn't seem to work for me. I see:
I think that should be -perm +0111:
from man find:
-perm +mode
Any of the permission bits mode are set for the file.
This would find
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
AFAICS mkdatadir() shouldn't consider subdir == NULL as a reason to
fail rather than trying mkdir_p.
Right. In fact, I can't see any good reason to call mkdir and then
mkdir_p at all. See my patch from
The other things that are executable look like they legitimately are
scripts.
If we consider that group-writability is bad (which ISTM we ought to)
then there are a *ton* of files with the wrong permissions. I'd
recommend getting Marc to fix it instead of hacking about with a
one-file-at-a-time
Christopher Kings-Lynne wrote:
The other things that are executable look like they legitimately are
scripts.
If we consider that group-writability is bad (which ISTM we ought to)
then there are a *ton* of files with the wrong permissions. I'd
recommend getting Marc to fix it instead
Bruce Momjian [EMAIL PROTECTED] writes:
Christopher Kings-Lynne wrote:
You could consider adding a script to CVSROOT module to fix permissions
upon commit?
Some files need execute bits, like perl scripts.
Sure, but couldn't we automatically turn off the write bits?
--- Tom Lane [EMAIL PROTECTED] wrote:
FK, primary, and unique constraints are already split out from the
CREATE TABLE for performance reasons. We could think about folding them
back in in a schema-only dump, but in a full dump I don't think it's
negotiable --- you really want to load the
On Sun, 23 Nov 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Christopher Kings-Lynne wrote:
You could consider adding a script to CVSROOT module to fix permissions
upon commit?
Some files need execute bits, like perl scripts.
Sure, but couldn't we automatically turn
Marc G. Fournier [EMAIL PROTECTED] writes:
On Sun, 23 Nov 2003, Tom Lane wrote:
Sure, but couldn't we automatically turn off the write bits?
Just curious, but what do the write bits harm?
They're just extra protection against making a dumb mistake; the old
belt-AND-suspenders theory.
If we
Hi,
Is there demand for this syntax:
ALTER SEQUENCE ON table(col) CYCLE 100;
It would allow us to become sequence-name independent...
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send
On Mon, 24 Nov 2003, Christopher Kings-Lynne wrote:
Is there demand for this syntax:
ALTER SEQUENCE ON table(col) CYCLE 100;
It would allow us to become sequence-name independent...
The above is an operation that would not help me a lot, but a way of
performing currval() without knowing
Is there demand for this syntax:
ALTER SEQUENCE ON table(col) CYCLE 100;
It would allow us to become sequence-name independent...
The above is an operation that would not help me a lot, but a way of
performing currval() without knowing the sequence name would be good.
It will help in cases
Tom Lane writes:
Besides, it's a tad odd to see files that are marked group writable but
not owner writable. You've got to agree there's not much sense in that.
How else are you going to commit files? /usr/bin/cvs is not setuid, so
the only way you can write to these files is being in the
42 matches
Mail list logo
