Friends
src/tools/find_typedef has in its prolog:
# This script attempts to find all typedef's in the postgres binaries
# by using 'nm' to report all typedef debugging symbols.
#
# For this program to work, you must have compiled all binaries with
# debugging symbols.
#
#
Hello:
Did you figure this out? I can't see any way that a Sync message would
close a transaction started with BEGIN (or START TRANSACTION). It runs
the same code we run at the end of a simple-Query message, and we'd
definitely have noticed if that were causing premature commit ...
Thanks for an
On 15 Jul 2003, Sailesh Krishnamurthy wrote:
>
> Friends
>
> src/tools/find_typedef has in its prolog:
Pass -gstabs to gcc.
Gavin
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
I'm getting far too many errors while trying to compile gram.c in the
backend/parser, that I must be missing something.. Story so far
gmake distclean
cvs update
configure --enable-debug --enable-cassert
gmake
gmake[3]: Entering directory `/usr/src/local/pgsql/src/backend/parser'
gcc -O2 -pipe -g -
diff -u -r ../postgresql-snapshot/src/backend/utils/adt/nabstime.c
../pgsql/src/backend/utils/adt/nabstime.c
--- ../postgresql-snapshot/src/backend/utils/adt/nabstime.c 2003-05-13
07:08:50.0 +0800
+++ ../pgsql/src/backend/utils/adt/nabstime.c 2003-07-15 11:08:06.0
+0800
@@ -76,7
I am getting the following error
gmake[4]: Entering directory
`/usr/local/postgres/pgsql/src/backend/access/commo
n'
gcc -O2 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../../sr
c/include -I/usr/local/ssl/include -c -o printtup.o printtup.c
In file included from ../../../../sr
Patrick Welche <[EMAIL PROTECTED]> writes:
> I'm getting far too many errors while trying to compile gram.c in the
> backend/parser, that I must be missing something.
I think you need to force gram.c to be regenerated. Try removing it
(and parse.h too) before building.
> % cvs diff src/backend/p
On Tue, Jul 15, 2003 at 11:21:51AM -0400, Tom Lane wrote:
> Patrick Welche <[EMAIL PROTECTED]> writes:
> > I'm getting far too many errors while trying to compile gram.c in the
> > backend/parser, that I must be missing something.
>
> I think you need to force gram.c to be regenerated. Try removi
Patrick Welche <[EMAIL PROTECTED]> writes:
> /usr/bin/flex -CF -o'scan.c' scan.l
> gcc -O2 -pipe -g -Wall -Wmissing-prototypes -Wmissing-declarations -I.
> -I../../../src/include -c -o gram.o gram.c
> In file included from gram.y:7990:
> scan.c:121: parse error before string constant
> scan.c:24
Samuel A Horwitz <[EMAIL PROTECTED]> writes:
> I am getting the following error
> ../../../../src/include/libpq/pqcomm.h:60: `int64_t' undeclared here (not
> in a function)
There's a patch floating around the list to remove use of int64_t, which
is evidently not too portable. I'll try to get it a
> > I am getting the following error
> > ../../../../src/include/libpq/pqcomm.h:60: `int64_t' undeclared here (not
> > in a function)
>
> There's a patch floating around the list to remove use of int64_t, which
> is evidently not too portable. I'll try to get it applied soon.
int64_t is a C99 da
Philip Yarra <[EMAIL PROTECTED]> writes:
> int64-pqcomm.patch: changes int64_t to int64 in src/include/libpq/pqcomm.h
> tested on RedHat Linux 7.3 and OSF
Applied (along with some further hacking to make the struct padding
logic more robust).
> osf-template.patch: adds pthread support for OSF
> t
Sean Chittenden <[EMAIL PROTECTED]> writes:
> int64_t is a C99 data type that hasn't existed prior to recent
> versions of gcc, but is quite valid/correct. I'd think that int64_t
> support should be fudged on platforms where in64_t isn't defined as
> long long.
We have int64 defined (and well tes
On Tue, 15 Jul 2003, Sean Chittenden wrote:
> > > I am getting the following error
> > > ../../../../src/include/libpq/pqcomm.h:60: `int64_t' undeclared here (not
> > > in a function)
> >
> > There's a patch floating around the list to remove use of int64_t, which
> > is evidently not too portable
hi,
1)If the same PROCLOCK has some already-granted locks and
be waiting for more, how do we know?
I currently use the holding array of PROCLOCK to figure out what lockmodes a transaction(process) has been granted on LOCK,and if holdings sum comes to 0 that means this PROCLOCK is waiting
hi,
why when i revoke all on scheme pg_catalog from all (with public)
i can make select from pg_ tables and views as ordinary user ??
I can usage this scheme so why i can makeing select ?
Then i remove SELECT perm from PUBLIC on pg_ tables and then i cant
makeing select from this tables , but i c
On Tue, Jul 15, 2003 at 01:56:55PM -0400, Tom Lane wrote:
> Philip Yarra <[EMAIL PROTECTED]> writes:
> > int64-pqcomm.patch: changes int64_t to int64 in src/include/libpq/pqcomm.h
> > tested on RedHat Linux 7.3 and OSF
>
> Applied (along with some further hacking to make the struct padding
> logic
Hi all,
As many of you know, PostgreSQL, Inc. has determined that Real Soon
Now is the time to release their older version of eRServer as a
contribution back to the rserv project. That Has Not Happened Yet,
and I Do Not Speak For Them, and so on. But I have agreed to do some
of the legwork for t
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> On Tue, Jul 15, 2003 at 01:56:55PM -0400, Tom Lane wrote:
>> Applied (along with some further hacking to make the struct padding
>> logic more robust).
> I'm not sure what you did exactly, or why you think it's better.
> But it seems you removed the "6 byt
On Tue, Jul 15, 2003 at 04:28:49PM -0400, Tom Lane wrote:
> Kurt Roeckx <[EMAIL PROTECTED]> writes:
> > On Tue, Jul 15, 2003 at 01:56:55PM -0400, Tom Lane wrote:
> >> Applied (along with some further hacking to make the struct padding
> >> logic more robust).
>
> > I'm not sure what you did exactl
"Kuhn, Dylan K (4520500D)" <[EMAIL PROTECTED]> writes:
> [ tries to restore a dump into a database with a different name ]
> pg_restore: [archiver (db)] could not execute query: ERROR: Database commen=
> ts may only be applied to the current database
> I'm not sure how to get around this one. Can
> Hm. Evidently not :-(. The COMMENT ON DATABASE facility is a bit bogus
> anyway (since there's no way to make the comments visible across
> databases). You might be best advised not to use it.
>
> Hackers: this seems like an extremely bad side-effect of what we thought
> was a simple addition
Rod Taylor <[EMAIL PROTECTED]> writes:
>> Hackers: this seems like an extremely bad side-effect of what we thought
>> was a simple addition of a helpful check. I am thinking we should
>> either remove the check again, or downgrade it to a WARNING (though I'm
>> not quite sure how to phrase the war
> 3. Ignore the specified DB name, store the comment as the description
>of the current DB; possibly give a warning saying we're doing so.
>This would allow correct restoration of dumps into different DBs,
>but I think people would find it awfully surprising :-(
I like this one for 7.4
On Tue, Jul 15, 2003 at 04:03:13PM -0400, Tom Lane wrote:
> Given the current implementation, it seems like there are three possible
> behaviors for COMMENT ON DATABASE when the database name isn't the same
> as the current database:
There's a fourth possibility: ignore the command and issue a W
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> Note that the RFC has 2 examples, one without sa_len, an other
> with sa_len.
If you're talking about RFC 3493, the example with ss_len is flat wrong,
since it fails to allow for the (strong) possibility that there will be
a pad byte between ss_len and ss_
On Tue, Jul 15, 2003 at 05:14:52PM -0400, Tom Lane wrote:
>
> BTW, where are we getting the "SALEN" macro from, and how are we sure
> that it tells the truth about whether the platform expects an ss_len
> field?
I'm not sure, it was used before.
Kurt
---(end of broadca
From SCO:
We probably want to be aware of this for a threaded libpq for 7.4.
LER
Forwarded Message
Larry Rosenman wrote:
identity suppressed for NDA reasons
wrote:
So, what I was doing was probably screwing up the syscalls that
libthread wraps?
Or possibly,
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> On Tue, Jul 15, 2003 at 05:14:52PM -0400, Tom Lane wrote:
>> BTW, where are we getting the "SALEN" macro from, and how are we sure
>> that it tells the truth about whether the platform expects an ss_len
>> field?
> I'm not sure, it was used before.
Before
On Tue, Jul 15, 2003 at 05:37:39PM -0400, Tom Lane wrote:
>
> > I'm not sure, it was used before.
>
> Before when? A quick grep finds it nowhere in either the 7.2 or 7.3
> trees ... which means we have zero field experience with it. My guess
> is that someone threw it in and punted on making co
On Tue, 2003-07-15 at 16:19, Andrew Sullivan wrote:
> pro contrib/:
> - it's not that big, and since it's replacing code now there, it
> won't bloat the tarball
>
> pro gborg:
> - allows rserv to attain a separate release schedule, and there's
> plenty of work to do on this code, so it may see
Hi all,
we are going to move our production postgres box ( on Linux )
in a new machine, I'm wondering if I shall leave the Hyperthreading
feature on or disable it.
Anyone have experience on this?
Thank you in advance
Gaetano
PS: Is really faster postgresql compiled with Intel compiler ?
---
since Postgres is one process/client, It depends on what folks are doing.
And, how smart the scheduling algorithms within your OS are.
LER
--On Wednesday, July 16, 2003 03:46:27 +0200 Mendola Gaetano
<[EMAIL PROTECTED]> wrote:
Hi all,
we are going to move our production postgres box ( on Linux
Iam trying to acquire rowlevel locks in postgresql. I try doing this:
'select * from students where name='Larry' for update;
But by looking at the holding array of proclock , I've noticed that by doing this only
AccessShareLock gets acquired which is a table level lock.
How do I acquire row
Does anyone know what purpose MAKE_PTR ( defined in shmem.h) servers?
thanks
jennyAdd photos to your messages with MSN 8. Get 2 months FREE*.
Gaetano
> Hi all,
> we are going to move our production postgres box ( on Linux )
> in a new machine, I'm wondering if I shall leave the Hyperthreading
> feature on or disable it.
> Anyone have experience on this?
I have been running Postgres on an SMP MIPS machine for quite
a while. I haven't b
Mendola Gaetano wrote:
Hi all,
we are going to move our production postgres box ( on Linux )
in a new machine, I'm wondering if I shall leave the Hyperthreading
feature on or disable it.
Anyone have experience on this?
Just FYI.
We turned Hyperthreading off for our production *dual* Xeon box. Thi
37 matches
Mail list logo
