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
Senio
. 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 exte
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'
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 Postgr
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'
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
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
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.
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 TABLESPACE
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
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 chang
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 fiel
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 n
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 inst
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
compa
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 80
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
[sni
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 sof
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
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 Tue
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
>
> pthread_gets
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:
ht
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 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
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.
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 broadcast)
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 fin
mething wrong... can anyone provide further
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 compr
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 -
..]
$ gcc -pipe main.c
as: Error: no source, object 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 ali
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
n if
we wanted 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 y
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 t
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-threa
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 (sor
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 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 tha
it to "just work" and was unpleasantly surprised when it didn't.
Best Regards, Philip Yarra.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
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 problems.
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 broadcast)--
B interface on that platform is
thread-safe. It'll never get multiple threads running through it anyway.
Regards, Philip Yarra.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
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 versi
else noticed 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 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,
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 chan
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
On Mon, 7 Jul 2003 04:30 pm, Kurt Roeckx wrote:
> I used int64_t because that's standard (C99). But int64 will do
> too.
Okay... looks like it's only in a couple of places. I'll fix for Tru64 when I
get a chance. I don't have commit access, so Tom, shall I send a patch to
you?
Regards, Philip.
On Mon, 7 Jul 2003 03:09 pm, Joe Conway wrote:
> I found it on my Red Hat 9 box in sys/types.h:
>
> # 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 h
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)---
T
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.
(undecl
;
gmake[2]: *** [access-recursive] Error 2
gmake[2]: 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,
why not).
So my app 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
th
ime (like Informix 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 Fri, 27 Jun 2003 12:16 pm, Bruce Momjian wrote:
> BSD/OS supports:
>
> The pthreads library conforms to IEEE Std1003.1c
> (``POSIX'').
>
> How is that different from UNIX98?
Just checked up on this: apparently version "g" of the standard does contain
such manipulation functions...
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 - t
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
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 int
n)
I'd really appreciate it if someone 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 20000731 (Red Hat Linux 7.3 2.96-113)
Philip Yarra.
/* on linux, you
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:
http://d
62 matches
Mail list logo
