Bruce Momjian wrote:
Well, we don't want to use debug for non-gcc (no optimization) so do we
do -g for gcc, and then --enable-debug does nothing. Seems people can
decide for themselves.
But doesn't --enable-debug turn off optimization?
It's really a question of what the default behavior
Yup, that works fine (just a few warnings about ERROR being redefined).
Thanks, Dave.
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 27 October 2003 02:50
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Call for port reports (Win32 Client)
On Sun, 2003-10-26 at 19:22, Gaetano Mendola wrote:
Hi all,
why START TRANSACTION READ ONLY is allowed
and not BEGIN READ ONLY ?
As Chris KL points out, it's not required by the standard (since BEGIN
isn't part of the standard to begin with). I suppose we could add it,
but it seems a little
Christopher Kings-Lynne wrote:
I think because START TRANSACTION is SQL standard? However, I thought
BEGIN WORK was SQL standard, and we don't support READ ONLY there
either --- hmmm.
BEGIN is no part of the SQL standard. The only way to begin a
transaction under the SQL standard is
On Sat, 2003-10-25 at 21:29, Bruce Momjian wrote:
configure --enable-debug will use -g for the compile, and with
optimization.
I'm just curious: would there be any benefit to using -g3 when
--enable-debug is specified and -g3 is supported by gcc? From the gcc
man page:
-glevel
[...]
On Sun, 2003-10-26 at 17:24, Oliver Elphick wrote:
If it were possible to have two separate versions of the PostgreSQL
packages installed simultaneously, it would be simple to do database
upgrades by dumping from the old version and uploading to the new.
You'd need some mechanism to prevent
Hello:
In src/backend/utils/adt/timestamp.c, interval_send looks like what you
are looking for.
Thanks :)
--
Best regards
Carlos Guzmán Álvarez
Vigo-Spain
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL
Hi,
Last week, there was a thread whether solely in memory vacuum can be performed
or not.(OK, that was a part of thread but anyways)
I suggested that a page be vacuumed when it is pushed out of buffer cache. Tom
pointed out that it can not be done as index tuples stote heap tuple id and
Dear pg-hackers,
Making an aggregate I want to stuff all input values (detoasted)
in an array and process them all togheter with finalfunc.
This is because in order to process them a conversion is involved
and I'm trying to reduce the number of conversions to the lowest
possible.
My question
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
Tom Lane writes:
What Peter was advocating in that thread was that we enable -g by
default *when building with gcc*. I have no problem with that, since
there is (allegedly) no performance penalty for -g
strk [EMAIL PROTECTED] writes:
My question is: if I write in the state array
pointers to DETOASTED input args,
will I find them intact at finalfunc time ?
No, not without pushups. You are called in a short-lived memory
context. You could allocate query-lifetime memory in fcinfo-fn_mcxt,
but
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
The latter...why won't it affect the postmaster state?
Because it's a *comment*.
Shouldn't it revert to the default value?
No, not unless you think the postmaster should react to comments in the
postgresql.conf file, which is rather against
Shridhar Daithankar [EMAIL PROTECTED] writes:
What are (more) reasons for not adding transaction information to
index tuple, in addition to heap tuple?
Cons are bloated indexes. The index tuple size will be close to 30
bytes minimum.
And extra time to perform an update or delete, and extra
Windows client port list updated:
http://momjian.postgresql.org/main/writings/pgsql/sgml/supported-platforms.html
---
Dave Page wrote:
Yup, that works fine (just a few warnings about ERROR being redefined).
Thanks,
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Shouldn't it revert to the default value?
No, not unless you think the postmaster should react to comments in the
postgresql.conf file, which is rather against my idea of a comment.
However, you're not the first to get burnt by this
pgman wrote:
Jan Wieck wrote:
What Peter was advocating in that thread was that we enable -g by
default *when building with gcc*. I have no problem with that, since
there is (allegedly) no performance penalty for -g with gcc. However,
the actual present behavior of our
Anthony W. Youngman [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED], Marshall Spight
[EMAIL PROTECTED] writes
Unless one has data independence, one does not have
this option; one will be locked into a particular
performance model. This is why I found the MV
guy's obvious pleasure at being
Anthony W. Youngman wrote:
In article [EMAIL PROTECTED], Anthony W. Youngman
[EMAIL PROTECTED] writes
Really, however you calculate it, it is an order of magnitude less
than your alternative.
And please don't tell me that using indexes is not fair or not in the
spirit of the
relational model
Christopher Browne [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Anthony W. Youngman [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED], Marshall Spight
[EMAIL PROTECTED] writes
Unless one has data independence, one does not have
this option; one will be locked into a
Lauri Pietarinen [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Anthony W. Youngman wrote:
In article [EMAIL PROTECTED], Anthony W. Youngman
[EMAIL PROTECTED] writes
But it does seem strange indexing on a composite field
like that ...
But why does it seem strange?
He only
In article [EMAIL PROTECTED], Anthony W. Youngman
[EMAIL PROTECTED] writes
Really, however you calculate it, it is an order of magnitude less
than your alternative.
And please don't tell me that using indexes is not fair or not in the
spirit of the
relational model ;-)
Well, it does result in
Yurgis Baykshtis [EMAIL PROTECTED] writes:
In pgerr.log this always go together:
WARNING: ShmemAlloc: out of memory
ERROR: FreeSpaceMap hashtable out of memory
If you have a large number of tables in your database, it might be that
you need to increase max_locks_per_transaction.
Andrew Dunstan [EMAIL PROTECTED] writes:
We can also try to come up with a better scheme for verifying that we
have started properly - I will think about that.
There have been previous suggestions for a pg_ping functionality, in
which you could simply send a packet to the postmaster and it
In article [EMAIL PROTECTED], Marshall Spight
[EMAIL PROTECTED] writes
Bob Badour [EMAIL PROTECTED] wrote in message news:W46dnf4tbfF1DwiiU-
[EMAIL PROTECTED]
All physical structures will bias performance for some operations and
against others.
This strikes me as a succinct statement of the
In article [EMAIL PROTECTED], Lauri Pietarinen lauri.pie
[EMAIL PROTECTED] writes
Anthony W. Youngman wrote:
In article [EMAIL PROTECTED], Lauri Pietarinen
[EMAIL PROTECTED] writes
Anthony W. Youngman wrote:
Fine. But MV *doesn't* *need* much of a cache. Let's assume both SQL and
MV
I am putting together a DB that records information about a set of web
sites and how they link to one another. As one site refers to another, I
monitor the first site and then record when I find the referred site.
I have a table called sa_site like this:
ensa1.1: sa_site
Field
Type
Not
Anthony W. Youngman wrote:
In article [EMAIL PROTECTED], Lauri Pietarinen lauri.pie
[EMAIL PROTECTED] writes
Anthony W. Youngman wrote:
In article [EMAIL PROTECTED], Lauri Pietarinen
[EMAIL PROTECTED] writes
Anthony W. Youngman wrote:
Well, if it is normalised, how
Tom, thanks again for the quick answer and
sorry for the lame question about memor allocation.
I hope this is acceptable:
Is there a way to make PG_DETOAST_DATUM and friends allocate
memory in a custom memory context ?
Right now I'm DETOASTing, memcopying in a custom context
and pfreeing the
From whitin an aggregate sfunc I did:
oldcontext = MemoryContextSwitchTo(fcinfo-flinfo-fn_mcxt);
geom = (GEOMETRY *)PG_DETOAST_DATUM(datum);
MemoryContextSwitchTo(oldcontext);
And later in aggregate's finalfunc:
pfree(geom);
Result:
segfault!
What's wrong
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
We can also try to come up with a better scheme for verifying that we
have started properly - I will think about that.
There have been previous suggestions for a pg_ping functionality, in
which you could simply send a packet to the
strk [EMAIL PROTECTED] writes:
From whitin an aggregate sfunc I did:
oldcontext = MemoryContextSwitchTo(fcinfo-flinfo-fn_mcxt);
geom = (GEOMETRY *)PG_DETOAST_DATUM(datum);
MemoryContextSwitchTo(oldcontext);
And later in aggregate's finalfunc:
pfree(geom);
To add some medium-hard data to the discussion, I hacked a PG 7.3.4 a
little. The system I am talking about below run's an artificial
application that very well resembles the behaviour of a TPC-C benchmark
implementation. Without vacuuming the database, it can just so sustain a
factor 5 scaled
Jan Wieck [EMAIL PROTECTED] writes:
What happens instead is that vacuum not only evicts the whole buffer
cache by forcing all blocks of said table and its indexes in, it also
dirties a substantial amount of that and leaves the dirt to be cleaned
up by all the other backends.
[ thinks about
Gaetano Mendola wrote:
Bruce Momjian wrote:
I can confirm this bug in CVS.
Dropping the pkey from table b in fact drops the unique index from it.
The SPI plan cached to check if a row deleted from table a is still
referenced from table b can (and in your case does) use an index scan
on table
They stopped at 7.2.4 because they're finishing some usefull APIs,
which'll make the port much more easy.
Will this involve using a Linux kernel ;)
:) No, a NW kernel with a POSIX library. This'll be great, because you'll
can run powerfull opensource software with an enterprise-class NOS.
How do I find out in Embedded SQL that a transaction has been aborted
due to a deadlock?
The closes error message in sqlca seems to be:
-401 (ECPG_TRANS): Error in transaction processing line %d.
PostgreSQL signaled that we cannot start, commit, or rollback the
transaction.
but it
tgl wrote:
strk [EMAIL PROTECTED] writes:
From whitin an aggregate sfunc I did:
oldcontext = MemoryContextSwitchTo(fcinfo-flinfo-fn_mcxt);
geom = (GEOMETRY *)PG_DETOAST_DATUM(datum);
MemoryContextSwitchTo(oldcontext);
And later in aggregate's finalfunc:
Hi,
It would be great for maintainance if every object had a timestamp of
the last vaccum run on it. From time to time we're working with several
databases and I can't tell wich one needs a new vacuum.
Another important information would be the rate of disposable data in
every table (like
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
What happens instead is that vacuum not only evicts the whole buffer
cache by forcing all blocks of said table and its indexes in, it also
dirties a substantial amount of that and leaves the dirt to be cleaned
up by all the other backends.
[
ivan wrote:
hi
can we change initdb when view pg_user is createing to :
CREATE VIEW pg_user AS \
SELECT \
usename, \
usesysid, \
usecreatedb, \
usesuper, \
usecatupd, \
''::text as passwd, \
valuntil, \
useconfig \
Bruce Momjian wrote:
pgman wrote:
Jan Wieck wrote:
What Peter was advocating in that thread was that we enable -g by
default *when building with gcc*. I have no problem with that, since
there is (allegedly) no performance penalty for -g with gcc. However,
the actual present
scott.marlowe [EMAIL PROTECTED] writes:
So it would appear to be that the automatic assumptions about what is
float and what is numeric changed from 7.2 to 7.3, i.e. it's assumed that
numeric is the input type.
That's correct.
Looking at the code, round(numeric) always rounds xxx.5 values
However, you're not the first to get burnt by this mis-assumption,
so maybe we should do something about it.
The low-tech solution to this would be to stop listing the default
values as commented-out entries, but just make them ordinary uncommented
entries. That way people who think undoing my
Bruce Momjian wrote:
Jan Wieck wrote:
In fact, even though I was debugging the backend regularly, I removed -g
and added it only when I wanted to debug.
It did somethimes in the past proove to be good luck to have symbols in
a core file accidentially. If you want to find them in an arbitrary
We only have a few open items left. Can we finish them so we can move
toward final release?
---
P O S T G R E S Q L
7 . 4 O P E NI T E M S
Current at
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Changes
---
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?
feature, not bug fix, no?
---(end of broadcast)---
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Changes
---
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?
feature, not bug fix, no?
It became important when everyone realized
Hello,
Based on the current open items... when do we expect release?
Sincerely,
Joshua Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - [EMAIL PROTECTED] -
I'm still seeing Horology failures on FreeBSD 4.9...
See attached diff.
Chris
*** ./expected/horology.out Thu Sep 25 14:58:06 2003
--- ./results/horology.out Tue Oct 28 11:29:24 2003
***
*** 577,583
SELECT (timestamp with time zone 'today' = (timestamp with time zone
On Mon, 27 Oct 2003, Joshua D. Drake wrote:
Hello,
Based on the current open items... when do we expect release?
As soon as the items are fixed? :)
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
Time zone changes --- will be OK tomorrow.
---
Christopher Kings-Lynne wrote:
I'm still seeing Horology failures on FreeBSD 4.9...
See attached diff.
Chris
*** ./expected/horology.out Thu Sep 25 14:58:06 2003
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Joshua D. Drake wrote:
Hello,
Based on the current open items... when do we expect release?
As soon as the items are fixed? :)
I am confused why we aren't wrapping up these items. I have waited for
the people who proposed these ideas
Hello,
Well the reason I brought it up was the rather interesting discussion
that Jan had today about Vacuum.
I was wondering if we were going to explore that before the 7.4 release?
Sincerely,
Joshua Drake
Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Joshua D. Drake
When you do this query:
SET SEARCH_PATH TO pg_catalog;
SELECT castsource::pg_catalog.regtype AS castsource,
casttarget::pg_catalog.regtype AS casttarget,
castfunc::pg_catalog.regprocedure AS castfunc,
castfunc::pg_catalog.regproc AS castfunc2 FROM pg_catalog.pg_cast ORDER
BY 1, 2;
Only
Joshua D. Drake wrote:
Hello,
Well the reason I brought it up was the rather interesting discussion
that Jan had today about Vacuum.
I was wondering if we were going to explore that before the 7.4 release?
No, I am afraid we are way past time time for that kind of addition.
--
Bruce
On Mon, Oct 27, 2003 at 07:45:53PM -0800, Joshua D. Drake wrote:
Hello,
Well the reason I brought it up was the rather interesting discussion
that Jan had today about Vacuum.
I was wondering if we were going to explore that before the 7.4 release?
I would expect that to be left for 7.5
I thought you said that yesterday?
Chris
Bruce Momjian wrote:
Time zone changes --- will be OK tomorrow.
---
Christopher Kings-Lynne wrote:
I'm still seeing Horology failures on FreeBSD 4.9...
See attached diff.
Chris
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Changes
---
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?
feature, not bug
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I'm still seeing Horology failures on FreeBSD 4.9...
Should stop at midnight Tuesday, PST8PDT time (about 45 minutes
from now) ... see prior discussion ...
regards, tom lane
---(end of
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Changes
---
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?
Bruce Momjian [EMAIL PROTECTED] writes:
We only have a few open items left. Can we finish them so we can move
toward final release?
Okay, here's my two cents:
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?
We
I said:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I'm still seeing Horology failures on FreeBSD 4.9...
Should stop at midnight Tuesday, PST8PDT time (about 45 minutes
from now) ... see prior discussion ...
Argh ... make that 3 hours from now ... you'd think I could remember
the time
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Changes
---
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Only regproc adds the unnecessary pg_catalog. qualification, why is that?
Er, I couldn't see the part of your example where that happened?
regards, tom lane
---(end of
Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
What are (more) reasons for not adding transaction information to
index tuple, in addition to heap tuple?
Cons are bloated indexes. The index tuple size will be close to 30
bytes minimum.
And extra time to perform an update or
Thiago Fernandes Moesch wrote:
It would be great for maintainance if every object had a timestamp of
the last vaccum run on it. From time to time we're working with several
databases and I can't tell wich one needs a new vacuum.
Another important information would be the rate of disposable
what about my Privilege regression failure?
I'm not sure why it's dying...
LER
--On Monday, October 27, 2003 23:32:45 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
We only have a few open items left. Can we finish them so we can move
toward final release?
er, plus 3 hours, I think, i.e. just under 2 hours from now ... (unless you
posted this in the future :-) )
[EMAIL PROTECTED] andrew]$ TZ=PST8PDT date
Mon Oct 27 22:07:22 PST 2003
[EMAIL PROTECTED] andrew]$ date
Tue Oct 28 01:07:28 EST 2003
[EMAIL PROTECTED] andrew]$
cheers
andrew
-
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
We only have a few open items left. Can we finish them so we can move
toward final release?
Okay, here's my two cents:
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable
Oops, I have two words for you, yesterday and tomorrow. ;-)
Seems the problem spans almost three days.
---
Christopher Kings-Lynne wrote:
I thought you said that yesterday?
Chris
Bruce Momjian wrote:
Time zone
Only regproc adds the unnecessary pg_catalog. qualification, why is that?
Er, I couldn't see the part of your example where that happened?
Basically, my question is why ::regproc alone always addes the catalogue
qualification in this case?
Rows below correspond to:
::regtype
::regtype
I recently posted a patch to pg_regress to limit
parallelism for cygwin to amaximum of 10, so that "make check" could
succeed. Tom preferred that this should be settable by the user explicitly
rather than hard coded (and hidden), and not limited by platform, so that you
could say
make
Multiple database services and multiple versions on Red Hat Linux systems
The way it works is that we require a specific service script for each
database service (that is listening on each port). Each of these
services has a init script in /etc/init.d and a corresponding
configuration file in
73 matches
Mail list logo
