Mario wrote:
I'd like to help :-) I wanted to avoid a core dumped but you told
me that's a normal thing for a SIGQUIT signal.
Did you try running `ulimit -c 0` first? That should do what you want -
prevent generation of the dump file.
Regards, Philip.
--
Philip Yarra
Senior Software
. The difference between your machine and your
friend's is likely just the ulimit settings.
Regards, Philip.
--
Philip Yarra
Senior Software Engineer, Utiba Pty Ltd
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: Have you checked our extensive
On Mon, 3 Apr 2006 06:13 am, Neil Conway wrote:
I've committed a patch to HEAD that should improve this behavior. Let me
know if the current behavior is still unsatisfactory.
Yes, thanks, it fixes the stuff that bugged me:
[EMAIL PROTECTED] pgsql]$ psql -p5434 -dpyarra
[snip opening car chase]
On Wed, 29 Mar 2006 08:46 am, Philip Yarra wrote:
OK, how about on \d+, if the object is not on pg_default or pg_global,
print the tablespace that this object is on? That way, people not using
tablespaces won't ever see it.
Tom, does this answer your objection? If so, I'll produce a patch
On Wed, 29 Mar 2006 08:46 am, Philip Yarra wrote:
OK, how about on \d+, if the object is not on pg_default or pg_global,
print the tablespace that this object is on? That way, people not using
tablespaces won't ever see it.
Tom, does this answer your objection? If so, I'll produce a patch
Hi folks, I've found that CVS HEAD psql's \c doesn't quite behave as expected
when postmaster is listening on non-default port. In this case I have
postmaster listening on port 5434:
[EMAIL PROTECTED] pgsql]$ /usr/local/pgsql-cvs-head/bin/psql -p5434 -dpyarra
Welcome to psql 8.2devel, the
On Wed, 29 Mar 2006 01:36 am, Tom Lane wrote:
Philip Yarra [EMAIL PROTECTED] writes:
Someone else might be able to see a better way to write this query, but I
think it would be good if \d could show this information, when you really
want to know which tablespace an object is on.
If \d
Hi folks after discussing this on IRC today (thanks G_SabinoMullane!), I'm
still surprised by this behaviour on 8.1.3:
pyarra=# create TABLESPACE spctables location '/mnt/pg_tables/data';
CREATE TABLESPACE
pyarra=# create table foo(id int) tablespace spctables;
CREATE TABLE
pyarra=# \d foo
On Wed, 23 Nov 2005 11:23 am, Gavin Sherry wrote:
Along those lines, is there anything else that would benefit from being
moved? pg_clog and pg_subtrans come to mind; but maybe pg_multixact and
pg_twophase are candidates as well?
pgsql_tmp
Does anyone have any recommendations about which
On Fri, 18 Nov 2005 05:29 am, Tom Lane wrote:
It does seem a bit inconsistent that psql wouldn't connect to the
specified database in order to do -l, if one is specified.
Anyone want to look and see if it's easy to change?
It also breaks the ability to psql -l against older installations: e.g.
I assume CREATE TABLESPACE refuses to use a non-empty directory because of the
risk of trashing existing files. Makes sense, but consider the following:
# mkfs -t ext2 /dev/sdc1
# mount -t ext2 /dev/sdc1 /mnt/pg_tables
# chown postgres /mnt/pg_tables
# su -c psql pyarra
pyarra=# CREATE
Just testing pl/pgsql functions in 8.1beta4, I see failures for syntax that
works in 8.0.3. The simplest test case for this is:
create table ptest(foo int, bar varchar(10));
create or replace function modify_ptest(
foo int,
bar varchar)
returns numeric as $$
declare
res
On Fri, 28 Oct 2005 01:37 pm, Stephan Szabo wrote:
The function below fails for me similarly in 8.0.3 on execution. 8.1
merely tells you at creation time.
Ah, good point... works for very small values of works then :-) My
mistake.
Using bar and foo as both parameter names and the field
On Fri, 28 Oct 2005 02:10 pm, Tom Lane wrote:
Without really wishing to volunteer myself: should plpgsql allow using
parameters with the same name as the columns being referred to within the
function, provided they're qualified as function_name.parameter?
No, because that just changes
On Fri, 28 Oct 2005 03:03 pm, Tom Lane wrote:
Philip Yarra [EMAIL PROTECTED] writes:
Hmmm... is it feasible to make the error message a little more useful?
People who didn't use the old-style positional parameters might not
understand where $1 and $2 are coming from.
Not sure how
On Thu, 6 Oct 2005 05:10 am, elein wrote:
Generally a short sed (or perl if you like) script will fix
these up. But it is really pretty obscure trail for people
to find the exact problem.
Yeah, it's not that it's hard to fix when you know where to look, but my aim
is to produce a site
Hi Devrim, I ran into another RPM issue, this time with Slony.
I grabbed the RPM from
http://developer.postgresql.org/~devrim/slony/1.1.0/rpms/PG8.0.3/
Trying to run slon_start, I got errors such as:
$ slon_start --config /etc/slon_tools.conf 2
Invoke slon for node 2 - @@@/slon -s 1000 -d2 -g
Hi Devrim,
On Thu, 6 Oct 2005 12:32 am, Devrim GUNDUZ wrote:
Thanks for the report. It will fixed in CVS and all the RPM sets later
today. Always feel free to send me a patch if you want, I can apply your
patch, too.
OK, you got my previous email about why pgsql-libs was dependent on
Devrim, I had some problems installing on RedHat ES3.0 with the RPMs. This
issue turned out to be that I needed the compat libs to provide the old libs
before I could install the new libs.
I found a link to
http://developer.PostgreSQL.org/~devrim/compat-postgresql-libs-3-3PGDG.i686.rpm
in an
Hi Devrim, thanks for the quick response.
We haven't discussed it before, but I think we can't put the RPM among
PGDG RPMs. The main reason is that this is not a piece of software that's
included within that release of PostgreSQL. Also, this compat RPM is not
needed if you don't have a
Hi Tom,
On Tue, 4 Oct 2005 11:36 am, Tom Lane wrote:
I think there's no question that this represents an RPM-building error.
We haven't entirely figured out what's causing it though.
Right, gotcha. I think this may be the issue:
[EMAIL PROTECTED] 8.x]# rpm -ql postgresql-libs-8.0.3-1PGDG
sizeof(Datum) == sizeof(long) - is that compatible with %d formatting (I'm
guessing something like vsprintf takes place in elog)? Wouldn't this need %ld
or %lu?
Sorry if this misses the point, I wasn't clear from original post if the
segfault was on elog or after it.
Regards, Philip.
On
Hi Michael, I'll have a look at it this afternoon, unless Lee wants first go.
Regards, Philip.
On Tuesday 12 April 2005 00:28, Michael Meskes wrote:
Hi,
I recently got the following bug report. It appears to be a bug in
pthread implementation in ecpglib/connect.c where
Hi all, before I delve too deeply into this, has anyone else tried building
7.4.6 on Solaris 9 (sparc) ? I'm seeing build failures using Sun's cc:
make[4]: Entering directory `/tmp/postgresql-7.4.6/src/backend/access/heap'
cc -Xa -O -v -I../../../../src/include -c -o tuptoaster.o tuptoaster.c
On Fri, 3 Dec 2004 01:43 pm, Michael Fuhr wrote:
gcc 3.4.2 on Solaris 9 doesn't complain about this.
Yes, I found Tom's response to the issue from March here:
http://archives.postgresql.org/pgsql-ports/2004-03/msg9.php
and this on the Sun CC forum, confirming that the compiler is borked:
On Wed, 25 Aug 2004 03:54 pm, Mark Kirkwood wrote:
Greg Stark wrote:
It's only allowed when the transaction is in READ UNCOMMITTED
isolation level.
Something Postgres doesn't currently support. In fact I'm not aware of any
SQL database that supports it, though I'm sure there's one
On Mon, 17 May 2004 05:29 pm, Marko Karppinen wrote:
If the default will be to listen on all interfaces, not just 127.0.0.1,
then this IS a security risk. And if that's not the plan, what good does
this change do? Any real use of tcp would still require a
configuration
change anyway.
From
On Fri, 12 Dec 2003 10:36 am, Bruce Momjian wrote:
I think we should switch to -R in our code.
Both -r and -R are supported on Linux (fileutils 4.1), Tru64 v4.0 and Solaris
(at least as far back as 2.6) so no complaints here.
Regards, Philip.
---(end of
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
suggestions?
There may be some wierdness on my build host, so when time permits I'll try on
a different alpha machine. I've also attached make.out.gz - the output of
make.
Regards, Philip Yarra.
regression.out.gz
Description: GNU Zip compressed data
regression.diffs.gz
Description: GNU Zip
On Fri, 17 Oct 2003 09:43 am, Josh Berkus wrote:
(I predict that we're going to get many more questions about Bison after we
release 7.4, since many major Linux distros don't yet include 1.875)
You only need bison if you are building from CVS - tarballs include the bison
output files (AFAIK -
or ucode file specified
main.c:46: output pipe has been closed
Regards, Philip Yarra.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
On Fri, 26 Sep 2003 04:51 pm, Christopher Kings-Lynne wrote:
Yes I do, but sometimes as different users you don't know what the path
is. I guess I can just go --version.
Perhaps add
alias initdb='initdb --version; initdb'
to /etc/profile so that all accounts get an alias?
Regards, Philip
On Fri, 26 Sep 2003 01:18 am, Greg Stark wrote:
Well if you're only going to do one threading API you may as well pick the
POSIX standard. Windows threading is only useful for windows, POSIX
threading would work on every other OS, Solaris, Linux, BSD, etc.
Is there a POSIX threads wrapper for
to. I have trouble believing MySQL was suggested as a viable
alternative.
I know I'm preaching to the choir here, but thought you might find it of
interest.
Regards, Philip Yarra.
---(end of broadcast)---
TIP 6: Have you searched our list
On Wed, 10 Sep 2003 02:39 pm, Tom Lane wrote:
A thread-safe implementation of
libpq is of zero value to an application unless it also has thread-safe
implementations of the other libraries it depends on.
Not necessarily so - we've managed okay so far (several years) working on
platforms
On Thu, 4 Sep 2003 05:36 am, Bruce Momjian wrote:
I would like every operating system that supports thread-safety to run
this program and report back the results.
Okay, here's results from the machines I have access to... I think what you're
going to find is that an awful lot of platforms that
On Wed, 10 Sep 2003 11:46 am, Bruce Momjian wrote:
I see --- looks bad failures below for OSF, Solaris, and FreeBSD
below.
Actually, I am not sure the OSF failure is correctly reported... your test app
had me a little baffled in that case.
We would have to get some thread mutex, make
On Wed, 10 Sep 2003 12:29 pm, Bruce Momjian wrote:
--- anyway, it is probably threadsafe, but strerror isn't, so we are
dead anyway. :-)
Oh, I see. Yep, good point. Strange that strerror isn't threadsafe when
everything else is... maybe Strange is OSF's middle name.
#ifdef SOME_DEF (sorry,
On Wed, 10 Sep 2003 02:15 pm, Bruce Momjian wrote:
Tom Lane wrote:
It doesn't seem to me that we should take on the job of providing
thread-safe implementations of basic libc functions. If a particular
OS cannot manage to offer that functionality, then we should mark it
not-thread-safe
and was unpleasantly surprised when it didn't.
Best Regards, Philip Yarra.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
I thought some of you might find this interesting in light of recent issues
with SCO cc:
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00191.html
In short, the FSF is discussing the possibility of dropping support for SCO
Unix in GCC.
---(end of
Something odd going on with the list - I never saw the original that Chris is
replying to.
Philip.
On Fri, 15 Aug 2003 12:22 pm, Christopher Kings-Lynne wrote:
I've been doing all my freebsd/alpha build with --enable-thread-safety for
weeks and I haven't seen any compile or running
that developer.postgresql.org is
displaying an apache test page? I assume this might be an indicator of work
in progress.
Regards, Philip Yarra.
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Wed, 16 Jul 2003 03:56 am, Tom Lane wrote:
osf-template.patch: adds pthread support for OSF
tested on OSF (uname -a: OSF1 hostname V4.0 1229 alpha)
Applied; it would be a good idea to get some more testing of it, but
that's what beta is for ...
Yes, I only have access to one version of
On Thu, 10 Jul 2003 12:35 pm, Christopher Kings-Lynne wrote:
When I run psql on freebsd/alpha with latest CVS and no postmaster running,
I get this:
bizarre socket name
Interesting... I'm running OSF on Alpha and I get the usual
/tmp/.s.PGSQL.5432. Perhaps it's related to IPv6 socket changes?
On Thu, 10 Jul 2003 01:33 pm, Christopher Kings-Lynne wrote:
FreeBSD alpha.cacheboy.net 4.7-STABLE FreeBSD 4.7-STABLE #0: Mon Feb 3
Hmm... I have 7.4devel built on FreeBSD 4.8 Intel running ipv6 at home - I'll
try the same tonight. It might help determine if it's architecture or OS.
Regards,
to different OSF versions test pthread-safety as well?
Regards, Philip Yarra.*** pgsql-old/src/include/libpq/pqcomm.h Wed Jun 25 10:42:16 2003
--- pgsql/src/include/libpq/pqcomm.h Mon Jul 7 17:30:11 2003
***
*** 38,44
* Desired design of maximum size and alignment
*/
#define
]: Leaving directory `/files1/home/philip/install/pgsql/src/backend'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/files1/home/philip/install/pgsql/src'
gmake: *** [all] Error 2
Any ideas how I can resolve this?
Regards, Philip Yarra.
---(end of broadcast
On Mon, 7 Jul 2003 02:19 pm, Tom Lane wrote:
Is type int64_t defined anywhere in your system headers? If so, where?
Er... no... this:
int main()
{
printf(sizeof is: %d\n, sizeof(int64_t));
}
fails with:
cc: Error: l.c, line 2: In this statement, int64_t is not declared.
On Mon, 7 Jul 2003 02:53 pm, you wrote:
Without some #include's, I'd expect it to fail, because int64_t isn't
built into the C compiler. The question is exactly which #include
are we missing.
Okay, got it: db.h
---(end of broadcast)---
TIP
On Mon, 7 Jul 2003 03:09 pm, Joe Conway wrote:
I found it on my Red Hat 9 box in sys/types.h:
snip
# if __GLIBC_HAVE_LONG_LONG
__extension__ typedef long long int int64_t;
# endif
And on RedHat 7.3 it's in stdint.h - they must move it around to keep the
snipers guessing.
If you haven't
starts multiple threads of execution through the ECPG libs... the
ECPG libs (and libpq) start multiple sockets to the back-end - one for each
thread. No changes to the back-end.
That's my understanding - Lee did most of the work, so maybe he can confirm
that.
Regards, Philip Yarra
and Sybase) will have an easier time of it.
Regards, Philip Yarra.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Thu, 26 Jun 2003 11:19 am, Philip Yarra wrote:
there appears to still be a problem
occurring at EXEC SQL DISCONNECT con_name. I'll look into it tonight if I
can.
I did some more poking around last night, and believe I have found the issue:
RedHat Linux 7.3 (the only distro I have access
On Fri, 27 Jun 2003 11:58 am, AgentM wrote:
According to POSIX 1003.1c-1995, no such mutex-altering function exists.
Thanks for the info - useful to know.
lock the mutex- potentially again). Either that or the recursive locks
can be eliminated.
Avoiding recursive locks is my preference - the
On Wed, 18 Jun 2003 02:58 pm, Philip Yarra wrote:
Hi all, it looks like Lee's ECPG (and libpq) thread-safety patches
have been applied, and configure --with-threads is also added. I
have been doing some testing, and I still encounter a
threading problem.
For those interested, I tested
could try this sample app to
confirm whether I am doing something wrong, or my environment is
faulty, or if there is still a thread problem.
Build env:
Linux 2.4.18-3
gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-113)
Philip Yarra.
/* on linux, you can compile with:
ecpg cn.pgc gcc -I/usr
On Wed, 11 Jun 2003 12:10 pm, The Hermit Hacker wrote:
you have to give it a password ... any password, but a password non the
less ... someone else asked me this also, and if I enter no passwd, I can
get the same error message ...
The reason for the confusion might be because here:
59 matches
Mail list logo
