Mike Rylander wrote:
As an alternative, what would be the possibility of creating a new PL
as a contrib module, say PLPGSQL_NG, to move forward with extensions
like this and perhaps EVALUATE?
I think the idea of rewriting PL/PgSQL from scratch has merit (and it's
something that I think would be
Bruce Momjian wrote:
My guess is the existing behavior was designed to allow waking of
multiple waiters _sometimes_ without starving of exclusive waiters.
Well, I think the current algorithm *does* allow starvation, at least in
some situations. Consider a workload in which a new shared reader
Bruce Momjian wrote:
I thought the new readers will sit after the writer in the FIFO queue so
the writer will not starve.
AFAICS, that is not the case. See lwlock.c, circa line 264: in LW_SHARED
mode, we check if exclusive is zero; if so, we acquire the lock
(increment the shared lock count and
Peter Eisentraut wrote:
--help and --version are the standard options that are supported
everywhere. In the era before we had long options everywhere, we
implemented -V as an alternative in some programs, in particular those
in and around initdb, because of the version cross-checking it does
On Wed, 2004-11-24 at 23:30 -0500, Tom Lane wrote:
It is not a 100% solution because it does not
cover the case where a waiting exclusive locker is released, then a new
shared locker arrives at the lock before the exclusive locker is given
any cycles to acquire the lock. However I don't see
The --help output for most of the binaries we install does not include
the -V option (just its alias, --version). Is this intentional?
(Note that we still document this option in the reference pages for some
commands, and initdb's help output does include -V.)
Speaking of command-line options,
On Thu, 2004-11-18 at 13:18 +, Matt wrote:
I got extremely frustrated with having to create a temp table every time
I wanted to access an arbitrary column from a record plpgsql.
FYI, one thing I want to implement is an EVALUATE statement in plpgsql
(analogous to eval() in Perl, for
On Mon, 2004-11-22 at 10:57 -0500, Tom Lane wrote:
I'm confused. How/why is this different from EXECUTE?
EVALUATE would take a string and evaluate it as a PL/PgSQL statement;
EXECUTE takes a string and executes it as a SQL statement. We've
discussed this before (although I may not have called
On Mon, 2004-11-22 at 10:06 +, Matt wrote:
This would execute a string and pass back the result?
It would evaluate a string as a PL/PgSQL statement (which means you
could construct any PL/PgSQL statement dynamically, including access to
fields of a RECORD determined at runtime).
I don't
Ruey-Lung Hsiao wrote:
My problem is: I can't find a way to compare strings in C preprocessor
directive since PG_VERSION is defined as something like 7.4.3 or
7.4.6.
You could try using CATALOG_VERSION_NO in src/include/catversion.h as a
substitute for the version number.
I think it would
On Fri, 2004-11-19 at 16:17 +1300, Dru wrote:
Though one of hte developers
tells me that sometimes it gets a link resource allocation error on
opening connections to the database server which i dont know if that is
related.
I'm not sure what you mean by a link resource allocation error.
On Fri, 2004-11-19 at 17:15 +1300, Dru wrote:
Ok rules out that possibility also. Is there any stress testing
software for postgresql to find out how and when it breaks?
Try contrib/pgbench.
The website uses php,
the problem could be in the wrapper code for PHP though. I havnt
got much
On Wed, 2004-11-17 at 14:59 -0500, Tom Lane wrote:
Would it not be possible to suppress the warnings just for the
flex-generated code?
IMHO it's not worth the trouble.
I think this is the better course. At least here, flex-generated files
produce warnings even without
On Wed, 2004-11-17 at 20:22 -0500, Tom Lane wrote:
That's because you're using a badly broken flex
Sure, but my point is just that different versions of flex, in general,
will provoke different compiler warnings. I don't see that it is a net
win to disable a flag across the _whole_ source tree
On Wed, 2004-11-17 at 20:44 -0500, Tom Lane wrote:
It does, although I find that the warnings are of little use since
people tend not to read every line of configure's output.
AFAICS no such warning is emitted. Perhaps you are thinking of the
warnings about using the wrong version of bison, or
On Tue, 2004-11-16 at 16:25 +1100, Neil Conway wrote:
Attached is a revised patch
Applied to HEAD, and backpatched to REL7_4_STABLE.
-Neil
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Sun, 2004-11-14 at 18:29 -0500, Tom Lane wrote:
Good analysis. We can't check earlier than DefineRelation AFAICS,
because earlier stages don't know about inherited columns.
On reflection I suspect there are similar issues with SELECTs that have
more than 64K output columns. This
On Sun, 2004-11-14 at 11:24 +, Simon Riggs wrote:
This seems too obvious a problem to have caused a bug
Well, I'd imagine that we've checked CREATE TABLE et al. with
somewhat-too-large values (like 2000 columns), which wouldn't be
sufficiently large to trigger the problem.
presumably this
On Mon, 2004-11-15 at 21:08 -0500, Tom Lane wrote:
Are we going to try to test whether the behavior is appropriate when
running out of memory to store the tlist?
We absolutely should: segfaulting on OOM is not acceptable behavior.
Testing that we recover safely when palloc() elogs (or _any_
On Mon, 2004-11-15 at 10:19 -0500, Tom Lane wrote:
I'm not familiar with the details of the GiST code, but would it work to
generalize PickSplit to return a three-way classification? That is,
instead of actually splitting the node, have it identify each item as
definitely left, definitely
On Mon, 2004-11-15 at 20:53 -0500, Tom Lane wrote:
I think the SELECT limit should be MaxTupleAttributeNumber not
MaxHeapAttributeNumber.
Ah, true -- I forgot about the distinction...
What I think needs to happen is to check p_next_resno at some point
after the complete tlist has been built.
Oleg Teodor,
If I understand the code correctly, GiST will only pass the first
attribute of each index tuple to the user-defined PickSplit method when
it wants to split a node. (see circa line 1269 of gist.c)
Is this a wise design decision? Granted, in many situations the first
attribute in
Joachim Wieland wrote:
this query makes postmaster (beta4) die with signal 11:
(echo CREATE TABLE footest(;
for i in `seq 0 66000`; do
echo col$i int NOT NULL,;
done;
echo PRIMARY KEY(col0));) | psql test
ERROR: tables can have at most 1600 columns
LOG: server
On Sun, 2004-11-14 at 11:06 +, Simon Riggs wrote:
HASH - works OK, but a pain to administer, no huge benefit in using
At least in theory, I think this could offer better performance for
equality searches than b+-tree. Given how common those kinds of queries
are, I still think hash indexes
On Sun, 2004-11-14 at 18:54 -0500, Tom Lane wrote:
It's probably just a hangover from the days when GiST didn't support
multi-column indexes at all. I agree it should be changed.
I'm not sure the right way to fix it (at least without significant
changes to the GiST API). At present, the
On Thu, 2004-11-11 at 04:11, Tom Lane wrote:
You can't override a builtin C function that way because there is a
built-in map from function OID to builtin function address, and it's
consulted before trying to look in pg_proc.
This behavior is not really open to negotiation
Then shouldn't we
Does anyone know what the expected range of the penalty GiST method
is? (i.e. Is the legal range documented anywhere? Failing that, what
does existing GiST-based code expect?)
While rewriting gistchoose() in gist.c to be less obfuscated, it
occurred to me that (a) I don't think the existing code
In the context of an index scan, what does NoMovementScanDirection
indicate? On the one hand, relation.h comments:
* 'indexscandir' is one of:
*ForwardScanDirection: forward scan of an ordered index
*BackwardScanDirection: backward scan of an ordered index
*
On Mon, 2004-11-08 at 13:56, Tom Lane wrote:
However execMain.c uses NoMovementScanDirection to denote do nothing,
and so es_direction will never have this value at runtime.
Ah, okay. I'll remove gistscancache() then, as this seems to be dead
code.
Not sure if it's worth factoring the enum
Gaetano Mendola wrote:
Right but we can create a new segment and use it too. I don't know how
these segments are used but I used to do it in the past, of course you have
to create a memory manager that handle not ccntinuous segments.
The TelegraphCQ folks have already done this:
Thomas Hallgren wrote:
Another compelling reason to use SVN is that one of their long term
goals is to use an SQL backend.
That is about as far from a compelling reason to use a particular
version control system as I can imagine.
-Neil
---(end of
Tom Lane wrote:
I don't believe memory context creation is very much worse than a malloc
(and it's certainly not that much worse than a context reset).
If you can't buy back the time spent by avoiding some retail pfrees, then
this whole exercise becomes very questionable anyway.
Hmm, okay -- I'll
On Tue, 2004-11-02 at 01:44, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
I think there needs to be a way to list all the objects in a schema.
This doesn't seem especially helpful to me, because you'd have to fit a
bunch of different object types into a one-size-fits-all output
Memory allocation in access/gist/gist.c is pretty heinous, IMHO. There
are retail pallocs and pfrees all over the place, and the requirements
for which allocations need to be released and by whom is pretty messy.
AFAICS, GiST doesn't take any advantage of the palloc() infrastructure
beyond
On Tue, 2004-11-02 at 02:20, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
(the observation here is that 99% of the allocations done by
gist.c are for internal use only -- we rarely allocate anything that
needs to live longer than the current GiST API call).
You sure about
On Mon, 2004-11-01 at 07:51, Tom Lane wrote:
I looked at this a bit more and found that on Linux, the dynamic
loader is documented to search rpath before LD_LIBRARY_PATH;
so had we not specified an rpath when building the psql executable,
pg_regress would have worked as intended. Sounds like
On Sat, 2004-10-30 at 00:50, Tom Lane wrote:
(1) What are the protection requirements for this variable?
I think it can be USERSET -- most commands let the user specify a
tablespace explicitly, and this is basically just another way of doing
that. The user executing the query will need CREATE
On Sun, 2004-10-31 at 05:32, Tom Lane wrote:
The behaviors you mention were written at different times by different
people, and mostly have nothing to do with schemas per se. I agree that
some more consistency would probably be good. Do you have a specific
proposal?
Sure, I just thought I'd
On Fri, 2004-10-29 at 07:35, Josh Berkus wrote:
Is there any reason that we don't have pg_functions, pg_users, pg_groups and
other system views?pg_tables and pg_views is really useful, but it would
be good to cover the other items as well.
pg_functions might be useful, but what would
psql's slash commands for schemas seem a little weird to me. For
example:
neilc=# \d nonexistent
Did not find any relation named nonexistent.
neilc=# \dt nonexistent
No matching relations found.
neilc=# \dn nonexistent
List of schemas
Name | Owner
--+---
(0 rows)
-- Is there a good
I'd like to provide a way for DBAs to specify that the temporary files
needed to for sorting, holdable cursors and similar operations should be
created in a particular tablespace. (Right now these files are created
in the tablespace associated with the current database.)
Two ways to do this come
On Wed, 2004-10-27 at 03:57, Tom Lane wrote:
No doubt this is from the PG_TRY that Neil added a couple days ago.
I think he is going to take it out again in favor of using AllocateFile,
so ignore the warnings for now (they're obviously bogus anyway).
Sorry, I didn't see those compile warnings
Tom Lane wrote:
Possibly we should make ALTER COLUMN strip any implicit coercions that
appear at the top level of the default expression before it adds on the
implicit coercion to the new column datatype.
That seems like a kludge. When processing a column default expression, we:
(1) Accept the
On Mon, 2004-10-25 at 00:30, Tom Lane wrote:
Not without an initdb (to have another column to put it in).
We're already requiring an initdb for beta4; if this is the right way to
fix this (and I'm not insisting that it is), then ISTM we can just push
back beta4 a few days.
And it
would
On Fri, 2004-10-22 at 07:54, Simon Riggs wrote:
If I could go further, I'd like to add this as an option on the command if
possible, rather than a presumption that all such statements should not be
logged.
Why is that necessary?
-Neil
---(end of
On Tue, 2004-10-19 at 02:45, Andrew Dunstan wrote:
*shrug* OK. Then plperl should probably not be regarded as being as
trusted as we would like. Note that old versions of Safe.pm have been
the subject of security advisories such as this one
http://www.securityfocus.com/bid/6111/info/ for
On Wed, 2004-10-20 at 06:18, Rod Taylor wrote:
http://secunia.com/advisories/12860/
This seems like a rather inconsequential problem, but it should be
fixed. The first two ideas that come to mind: use temporary files in
$PWD rather than /tmp, or create a subdirectory in /tmp to use for the
I've got the CREATE TABLE AS restructuring almost finished, but came
across something that I could use some advice on. The current code
stores the into relation (and whether or not that relation has OIDs)
in the Query struct. This is ugly[1], but I'm not sure how to fix it.
The main reason Query
On Mon, 2004-10-18 at 11:53, Tom Lane wrote:
Only once we've begun to spin. The first time through, it's not at all
clear whether the extra test is worthwhile --- it's certainly a win if
the lock is always already held, and certainly a loss if the lock is
always free
Granted, but I think
Recent versions of GCC support some additional warning flags that I
think would be useful to enable for building PostgreSQL:
-Wmissing-declarations (Warn if a global function is defined without a
previous declaration.)
-Wdeclaration-after-statement (Recent versions of GCC allow declarations
Currently, the assembly for TAS() on x86 does a non-locking test before
using an atomic operation to attempt to acquire the spinlock:
__asm__ __volatile__(
cmpb$0,%1 \n
jne 1f \n
lock\n
On Mon, 2004-10-18 at 04:13, Tom Lane wrote:
Do you have any actual evidence for that opinion? ISTM this is
dependent on a large set of assumptions about the CPU's bus behavior,
boiling down to the conclusion that an extra conditional branch is
cheaper than a locked bus cycle.
I think the
On Mon, 2004-10-18 at 03:50, Tom Lane wrote:
-Wmissing-declarations (Warn if a global function is defined without a
previous declaration.)
Hm? We have always used that one.
We've always used -Wmissing-prototypes. The documentation states that
-Wmissing-prototypes instructs GCC to:
On Mon, 2004-10-18 at 12:03, Tom Lane wrote:
We've always used -Wmissing-prototypes.
We've always used both.
My apologies -- I don't know where I got the opposite impression.
Hmm, it looks like -Wmissing-prototypes may be a superset of
-Wmissing-declarations --- it seems to say that the
Gaetano Mendola wrote:
Are you going to fix it for the 8.0 and/or back patch it ?
http://archives.postgresql.org/pgsql-committers/2004-10/msg00229.php
http://archives.postgresql.org/pgsql-committers/2004-10/msg00191.php
plus backpatches to older branches (REL7_3_STABLE, REL7_2_STABLE).
Has there
On Sun, 2004-10-10 at 03:36, Chris Browne wrote:
There are doubtless cases where the optimizer won't use them where it
would be plausible to do so; that suggests, to me, possibilities for
enhancing the optimizer.
Speaking of which, if anyone has any examples of queries for which we
ought to be
On Tue, 2004-10-12 at 08:13, Bin Liu wrote:
Can somebody explain how the 'parsetree' in the parser( ) function get
populated? What I saw is just a NIL. And it is not touched else where
in this file.
parsetree is a global variable; it is defined in parser.c, but
declared (via extern) in gram.y.
[ apologies if this mail is poorly formatted, posted via webmail ]
Gavin Sherry said:
For the latest few weeks Neil and I have been discussing unit testing as
a means of testing Postgres more rigorously.
I should note that we've also been looking at some other ideas, including
different
Andrew Dunstan wrote:
2. Won't dissolving away static cause naming conflicts?
It might, yes. Those can be resolved, I think. I don't see a good reason
why function names can't be unique across the source tree; at the very
least, it means less irritation for anyone using tags.
3. Unit testing
The memory context created at src/backend/utils/mmgr/portalmem.c:183
shares the name of the memory context created at portalmem.c:279 (they
are both called PortalHeapMemory). Is there a reason for this?
-Neil
---(end of broadcast)---
TIP 5: Have
On Tue, 2004-10-12 at 00:43, Tom Lane wrote:
Most likely (and I for one will for sure resist any attempt to force
global uniqueness on static names).
You're right that the issue can be avoided easily enough, but what need
is there _not_ to have globally unique function names?
-Neil
On Tue, 2004-10-12 at 05:08, Greg Stark wrote:
But it seems to me that most of the really hard bugs to find involve subtle
interactions between functions and the state of the database.
You wouldn't be able to find errors in the semantics of xids for example, or
in the WAL logic that didn't
On Tue, 2004-10-12 at 09:40, Tom Lane wrote:
Copy-and-paste oversight I'd say. Probably the latter ought to be
PortalHoldContext or some such.
Thanks, that's what I suspected. I've applied the attached fix to HEAD.
-Neil
Index: src/backend/utils/mmgr/portalmem.c
Gaetano Mendola wrote:
Here http://www.sans.org/top20/#u9
are listed postgres vulnerability it's sad see that almost all
are related to third part components
Almost all? By my count, 12 of the 17 vulnerabilities refer to
legitimate problems in PostgreSQL, its RPM distribution, or the ODBC
On Fri, 2004-10-01 at 06:48, Bruce Momjian wrote:
Yes, that is what I am thinking. I have worked around other bugs in the
C code before by doing things with the shell script though this problem
seems hard to clean up with a shell script. I found GNU indent to be
even harder to fix.
Have you
Profile-guided optimization is a relatively new GCC feature that
improves the quality of generated code by:
- compiling a copy of the source program with some profiling hooks
- running this copy of the program on some representative input data
- recompiling the program using the profiling data
On Thu, 2004-09-30 at 19:49, Peter Eisentraut wrote:
I doubt that the regression tests are anywhere near representative input
data. They run a proportion of borderline and error cases that is much
higher than I would expect in normal use.
That's definitely true. At first glance, the
On Fri, 2004-09-24 at 19:28, Neil Conway wrote:
On Fri, 2004-09-24 at 05:52, Alvaro Herrera wrote:
I don't think we can do that in a standard function, at least not
without a lot of work.
Can you elaborate on why this would be so difficult?
I never got a reply to this question -- someone
On Wed, 2004-09-29 at 21:37, Bruce Momjian wrote:
The reason MemSet is a win is not that the C code is great but because
it eliminates a function call.
A reasonable compiler ought to be able to implement memset() as a
compiler intrinsic where it makes sense to do so. MSVC++ can certainly
do
On Fri, 2004-09-24 at 12:30, Neil Conway wrote:
Barring any objections, I intend to apply the attached patch to HEAD
later today.
Applied to HEAD.
-Neil
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister
On Fri, 2004-09-24 at 04:12, Josh Berkus wrote:
My comments are based on having professionally written several hundred
thousand lines of procedural code for PostgreSQL, SQL Server, and Oracle.
I haven't used stored procedures as implemented elsewhere, so I
appreciate your comments.
If we go
On Fri, 2004-09-24 at 01:56, Joe Conway wrote:
As other's have pointed out, this is very common in the MS SQL Server
world (and I believe Sysbase also supports it).
From looking at the docs, it appears this isn't supported by Oracle or
DB2 (correct me if I'm wrong). I can see how it would be
On Fri, 2004-09-24 at 05:52, Alvaro Herrera wrote:
I don't think we can do that in a standard function, at least not
without a lot of work.
Can you elaborate on why this would be so difficult?
-Neil
---(end of broadcast)---
TIP 8: explain
On Fri, 2004-09-24 at 02:40, Tom Lane wrote:
I concur with Grant Finnemore's objection as well: people expect
procedures to be able to return resultsets, ie SETOF something,
not only scalar values.
IMHO most products (and the standard) define stored procedures as not
returning _anything_,
There's a bunch of very ugly code in backend/main/main.c that involves
the preprocessor constants NOFIXADE and NOPRINTADE. The code seems
to be related to support for Alpha and/or ultrix4. NOFIXADE is defined
by port/osf.h and port/ultrix4.h, while NOPRINTADE is not defined as far
as I can tell
On Fri, 2004-09-24 at 00:35, Tom Lane wrote:
I would be inclined to get rid of the separate NOPRINTADE code and make
NOFIXADE select both flags.
Barring any objections, I intend to apply the attached patch to HEAD
later today.
-Neil
Index: src/backend/main/main.c
On Wed, 2004-09-22 at 15:29, James William Pye wrote:
I think so.
Patch applied with some additional fixes -- the patch as I applied it is
attached. Thanks!
-Neil
Index: doc/src/sgml/installation.sgml
===
RCS file:
On Wed, 2004-09-22 at 00:16, Bruce Momjian wrote:
So distutils is now required to build python? If that is intended, I
will just skip building python. I didn't realize we had new
requirements for python, but that is fine.
Should this be documented in the installation instructions?
-Neil
On Fri, 2004-09-17 at 01:43, Tom Lane wrote:
PS: this points up once again that the regression tests do not do very
well at testing concurrent behavior. We need to think about some sort
of parallel-test harness that would let us write tests that have better
odds of catching bugs like this.
I
On Fri, 2004-09-17 at 13:18, Tom Lane wrote:
In my mind this is just a clearer statement of what the policy always
was ;-). The patch review/application load was never supposed to fall
entirely on Bruce. The list he maintains is just there to ensure that
nothing slips through the cracks.
On Fri, 2004-09-17 at 00:34, Tom Lane wrote:
I think Andrew has a point: why aren't they the same issue? It would
certainly be no harder to support
func( ... );
as a SQL statement than as something allowed only in plpgsql.
If there's a consensus that it is better to modify the main
On Thu, 2004-09-16 at 08:52, Marc G. Fournier wrote:
In recognition of his role as lead developer on the internationalization
front, as well as his invaluble work in both the build and release
processes, Peter Eisentraut has been invited, and has accepted, to join
the Core Committee.
On Thu, 2004-09-16 at 01:05, Tom Lane wrote:
That seems fairly unworkable. For example
SELECT (2,3,4);
is valid SQL.
Good point. The disambiguation algorithm I suggested isn't sufficient,
but I think there ought to be _some_ reasonable algorithm.
From glancing over the SQL
On Thu, 2004-09-16 at 01:19, Andrew Dunstan wrote:
ISTM that this is being done at the wrong level anyway. I'd like to see
a facility available in our SQL, e.g.
CALL foo();
with the restriction that foo() should be declared to return void.
I think these are two distinct issues. The
I ran the postmaster under valgrind, and ran the regression tests (make
installcheck) against it. Curiously, this resulted in an assertion
failure:
TRAP: FailedAssertion(!(lock-shared 0), File:
/home/neilc/pgsql/src/backend/storage/lmgr/lwlock.c, Line: 443)
The error is pretty reproducible (it
I'd like to make it possible to perform function calls in PL/PgSQL
without needing to use PERFORM. I think this would be useful because (a)
it is closer to how PL/SQL works (b) PERFORM is (IMHO) a kludge, and
making it unnecessary would make programming in PL/PgSQL more natural.
Attached is a
On Thu, 2004-09-16 at 00:06, Neil Conway wrote:
Attached is a proof of concept patch that implements this.
Woops, the patch is really attached this time.
-Neil
Index: src/pl/plpgsql/src/gram.y
===
RCS file: /home/neilc/private
Christopher Kings-Lynne wrote:
Out of interest, do you have free reign to code whatever you want, or do
you have a specific set of things to do for Fujitsu? Also, will you be
working on the open source server, or Fujitsu proprietary extensions?
I'll be working on a bit of everything; my initial
I've accepted an offer from Fujitsu Australia Software Technologies to
work on PostgreSQL full-time for them for the next twelve months in
Sydney, Australia. I'll be working with Gavin Sherry and two other
full-time developers from FAST. I'm grateful to Fujitsu for giving me
the opportunity to
Josh Berkus wrote:
I'll have to admit to having only a beginner's grasp of this stuff, but I do
believe that that was what the OSDL patch did. Jan also tried a simpler
patch, which didn't work either.Both Jan and Tom have expressed the
opinion that the only solution is to make the
make check produces the following regression.diffs:
*** ./expected/geometry.out Fri Oct 31 22:07:07 2003
--- ./results/geometry.out Thu Aug 26 00:51:46 2004
***
*** 117,123
| (5.1,34.5) | [(1,2),(3,4)] | (3,4)
| (-5,-12) |
Tom Lane wrote:
But yes, a yield primitive would be nice, and so would knowing the
number of CPUs.
I'm planning on submitting a patch shortly that determines the number of
CPUs in the machine and adjusts the spinlock behavior accordingly (there
are various APIs for getting the # of CPUs, like
Tom Lane wrote:
Associating such a thing with spinlocks seems certain to be a dead loss,
as the amount of time we normally hold a spinlock is much less than the
time to make one kernel call, let alone two.
Yeah, I was thinking about this. ISTM the only way that Sun would bother
to provide an API
I get the following warnings compiling current sources:
/Users/neilc/pgsql/src/bin/pg_dump/pg_backup_db.c: In function
`_isIdentChar':
/Users/neilc/pgsql/src/bin/pg_dump/pg_backup_db.c:874: warning:
comparison is always true due to limited range of data type
Tom Lane wrote:
Okay, I don't want to force an initdb just for this either. But if we
do one for other reasons, it's toast.
I don't see why an initdb is required: if we want to remove it, we can
replace the function's implementation with elog(ERROR, this function
has been removed), or the like.
Tom Lane [EMAIL PROTECTED] writes:
So, if you've got any fixes you wanted to get into those branches,
time to get on it.
I just wanted to note that IMHO a fix for the PL/PgSQL crash in
7.4.1 and HEAD (not sure about 7.3.x) that Chris Campbell recently
reported should definitely be included in
Tom Lane [EMAIL PROTECTED] writes:
The difficulty with acquiring lock earlier is that to acquire lock,
you need to know the relation's shared/unshared status as well as
its OID. We'd need to do something with all the code that assumes
that an OID is sufficient information for opening
Tom Lane wrote:
ISTM we had decided that putting vast amounts of documentation into the
file comments was exactly the thing *not* to do. It duplicates the SGML
documentation, thereby doubling the maintenance effort, to very little
purpose.
I agree. If people really think that adding more comments
Tom Lane wrote:
So I disagree with the premise. Measuring these things in KB is not an
improvement.
I agree, although I think changing effective_cache_size to be
measured in KB/MB is worth doing.
-Neil
---(end of broadcast)---
TIP 9: the planner
I see the following on this machine: (OSX 10.3.4, gcc 3.3)
[neilc:/Users/neilc/build-pgsql/contrib]% make -s all
ld: warning multiple definitions of symbol _nextval
pending.o definition of _nextval in section (__TEXT,__text)
../../src/backend/postgres definition of _nextval
ld: warning multiple
501 - 600 of 1081 matches
Mail list logo
