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
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
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*.
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
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
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 ?
---
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
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
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
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,
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
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 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
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
> 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
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
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
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,
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
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
> 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
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
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
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
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
> > 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
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
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
"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
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:
> 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
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
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'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 -
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
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
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.
#
#
37 matches
Mail list logo
