There's a minor bug in the ON_ERROR_ROLLBACK code in psql. In HEAD, at
line 878 the storage pointed to by "results" is released by a PQclear(),
but is referenced by the PQcmdStatus() calls on lines 898, 899, and 900.
I'm busy at the moment -- if someone wants to fix this (backport to 8.1
please!),
When integer datetimes are in use, the legal range of the "date" type
actually exceeds that of the "timestamp" type. However, the cast from
date => timestamp fails to take this into account:
postgres=# select '01-01-5874896'::date::timestamp;
timestamp
--
On Wed, 2007-16-05 at 11:46 -0400, Bruce Momjian wrote:
> This has been saved for the 8.4 release
No, this is a bug, and should be fixed in 8.3 and likely backported. I
haven't had a chance to get to it yet, though.
-Neil
---(end of broadcast)---
On Sat, 2007-02-06 at 14:25 +0200, Frank van Vugt wrote:
> BEGIN;
> SELECT * INTO STRICT myrec FROM emp WHERE empname = myname;
> EXCEPTION
> WHEN NO_DATA_FOUND THEN
> RAISE EXCEPTION 'employee % not found', myname;
> WHEN TOO_MANY_ROWS THEN
> RAISE E
On Thu, 2007-07-05 at 16:32 -0400, Tom Lane wrote:
> By and large we don't try to support nonstandard compilers on Linux.
We support icc on Linux, at least to some degree (buildfarm members
mongoose and dugong, for example). I don't see anything wrong with
supporting Sun Studio on Linux, if someon
On Mon, 2007-09-07 at 10:39 -0400, Tom Lane wrote:
> When applied to "numeric" input, stddev_pop produces the same result as
> stddev_samp, and var_pop produces the same result as var_samp. This
> is because whoever wrote numeric_stddev_internal() forgot that the
> divisor is different for the sam
On Tue, 2007-17-07 at 00:51 +, Chris Bowlby wrote:
> Using a temporary table of the same name in repeated calls to a stored
> procedure are causing OID failure issues
This is a (well) known bug. The problem arises because plpgsql caches
the query plan used to access the temporary table, which
On Sun, 2007-09-16 at 20:34 +0200, Martin Pitt wrote:
> users=> begin;
> BEGIN
> [...]
> users=> \q
> $ ...
>
> It would be really nice if psql prompted me whether I wanted to do
> this. As it stands, it just rolls back the transaction."
At a minimum, I think we could make the fact that the trans
Martin Pitt said:
> If you just output a rollback command on exit, then it is already too
> late to rescue the pending transaction, so I'm not sure whether that
> would help this use case so much.
Well, the DBA can always replay the transaction manually -- I think
notifying the DBA that their modi
I wouldn't call this behavior buggy, but I found it somewhat surprising.
expression_tree_walker() assumes that the walker has already been
invoked on the current node (the node that a given recursive call of
expression_tree_walker() has been invoked on). Therefore, calling
expression_tree_walker()
27;v') and
substr(relname,1,3)='org'
... which suggests to me that, at least for the common case, views are
supported for line completion.
Can you give us a reproducible test-case that demonstrates the problem?
Cheers,
Neil
--
Neil Conway <[EMAIL
How many updates are you performing? How fast is the table growing?
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]>
PGP Key ID: DB3C29FC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
ad of gcc ... -fpic ...) and of course the fpic
> command does not exist.
Oh? Where in the Makefile?
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]>
PGP Key ID: DB3C29FC
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
y tweak the buffer manager: the large but infrequently accessed
table will likely not have very many buffers kept in memory.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
---(end of broadcast)---
TIP 3: if pos
omes back up.
What version of PostgreSQL is this?
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[EMAIL PROTECTED] writes:
> bison -y -d preproc.y
> preproc.y:5560: fatal error: maximum table size (32767) exceeded
You need to use Bison 1.50 or greater -- although if you're building
an official source release (e.g. 7.3beta3), Bison shouldn't be
required at all.
Cheers,
ORE/reentr.h:602: field
> `_crypt_struct' has incomplete type
This is a bug in Perl 5.8.0. To workaround it, add '-D_GNU_SOURCE' to
the CFLAGS for PL/Perl.
I'm planning to send in a patch that works around this problem for 7.3
final, but I haven't got a chance yet (if s
shut
down failed
pg_ctl: postmaster does not shut down
We should probably check the exit code produced by kill(1).
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
---(
enough -- so is there any way to improve this behavior?
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
tent. It would be nice to fix in 7.3.1 or 7.4.
Unless anyone sees a problem with this, I'll work on this. I
definately think it's inappropriate for 7.3.1 though.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Bruce Momjian <[EMAIL PROTECTED]> writes:
> "Random" randomly fails. It is OK.
So why is it a regression test, then?
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
---(end of broadcast)---
TI
lib/i686/libc-2.2.5.so)
> ==30439==by 0x80491E1: (within
> /home/chatgris/code/mastermailings/code/daemons/email_manager/email_manager.o)
> ==30439==Address 0x402544D0 is not stack'd, malloc'd or free'd
ISTM that indicates a problem in your application, not in libpq.
Chee
x27; like 'C%'
Can you elaborate on exactly what behavior you'd expect this to produce?
We already support this syntax:
[ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP
On Wed, 2002-11-27 at 12:13, Szabó Roland wrote:
> Reading the archives I understand this is a problem of postgres version
> prior 7.1, and I'm experiencing the very same error as Steve Riley
> reported last month.
I searched the archives but I couldn't find the bug report you're
referring to.
>
1=# create schema a;
CREATE SCHEMA
template1=# alter user nobody set search_path to 'a';
ALTER USER
template1=# alter user nobody set search_path to default;
ALTER USER
template1=#
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
-
On Sun, 2002-12-01 at 17:03, Dustin Sallings wrote:
> Around 16:54 on Dec 1, 2002, Neil Conway said:
>
> # Works for me:
>
> Well that's unfortunate, it crashes consistently for me.
Heh, ok. I thought my post implied "given the information you've given
me,
gt;From that page: "Tip: There are no performance differences between
these three types, apart from the increased storage size when using the
blank-padded type."
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
---(end of br
On Thu, 2002-12-12 at 13:13, Rudy Lippan wrote:
> I know this is a broken install, but postmaster should not segfault when
> it can't find a file.
>
> postgres@war PGDATA $ ../pgsql7.3/bin/postmaster
> LOG: load_hba: Unable to open authentication config file
> "/usr/local/PGDATA/pgsql7.3/pg_hba
On Thu, 2002-12-12 at 17:18, [EMAIL PROTECTED] wrote:
> plpgsql 'raise notice' > 4000 chars disconnects pgsql backend 7.2.1
> It will cause you (et al) to get disconnected from the back end.
Works for me (i.e. no crash, a long elog() is returned to the client as
expected), using CVS HEAD as of a
On Sat, 2002-12-14 at 15:33, [EMAIL PROTECTED] wrote:
> PostgreSQL 7.2 will allways do a full table scan when the index field
> is a bigint. even with a "where bigkey = 99" clause.
This is a known problem: you need to enclose the integer literal in
single quotes, or cast it to int8 for the optimiz
rashes would
also be helpful -- if you could also recompile with debugging symbols
(--enable-debug), that would be good.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
---(end of broadcast)---
TIP 3: if posting/rea
he query both before and after
running VACUUM ANALYZE?
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
On Thu, 2003-03-20 at 19:26, Robert E. Bruccoleri wrote:
> MIPS Pro 7.4 and MIPS Pro 7.3.1.3, 64 bit compilation model.
I've seen some other people having troubles with PostgreSQL compiled
with Mips Pro on IRIX/MIPS -- does the problem persist if you recompile
PostgreSQL with gcc?
Cheers,
Neil
On Sun, 2003-03-30 at 19:20, Bruce Momjian wrote:
> The issue was that you might want to increase server logging in certain
> clients to help debug a problem.
That seems a little obscure to me -- IMHO it's not really worth adding
additional GUC complexity to account for it. Why not just use SUSET,
On Fri, 2003-09-05 at 10:01, Stephan Szabo wrote:
> This is the section in create function reference page about immutable. I'd
> thought it was clear, but do you have a better suggested wording?
While we're on the subject, this adjacent paragraph of the docs seems
unclear:
STABLE indicate
On Sat, 2003-09-27 at 14:23, Tom Lane wrote:
> /*
> * If the user is attempting to dump a specific table, check to ensure
> * that the specified table actually exists (and is a table or a view,
> * not a sequence).
> */
> if (selectTableName)
> {
> for (i = 0
On Wed, 2003-10-15 at 02:08, Nayib Kiuhan wrote:
> In versions before 7.4beta3 I use to have tables with
> "date" timestamp DEFAULT 'now'
> It use to works properly, placing the actual date at the moment a new
> record was inserted. Now it always have the same date which correspond
> to the d
On Wed, 2003-10-15 at 13:29, Nayib Kiuhan wrote:
> It is a good idea to through out an error during the table creation if
> the format is not as indicated (now()), because when I created my
> tables with the old format, it did not show any problem
I agree that this kind of silent backward-incompat
On Fri, 2003-10-31 at 12:25, Nitz wrote:
> You were right, the volume of the data changes the optimizer's
> willingness to use indexes.
AFAICS, the optimizer seems to be making exactly the right guesses for
the production data -- i.e. there's no problem/bug.
> Another funny thing though... I ac
On Fri, 2003-10-24 at 22:59, Clifford T. Matthews wrote:
> Using initlocation from postgresql 7.3.4 I managed to blow away some
> important data tonight due to "exit_nicely"'s "rm -rf".
Has there been any followup on this? IMHO this is a bug we should fix.
-Neil
---(end
Thomas Erskine <[EMAIL PROTECTED]> writes:
> A before trigger doesn't always fire. If a column being inserted into is
> too small for the incoming data, psql complains:
> ERROR: value too long for type ...
> without giving the trigger procedure a chance to deal with it.
I believe this is a
"Przemysław" <[EMAIL PROTECTED]> writes:
> Hello
> I dont know is this a bug but when I use COPY to load data into table
> sequence of the primary key in this table have always start value =
> 1.
Doesn't sound like a bug. If the input data for COPY does not include
PK values, you should not includ
Tom Lane <[EMAIL PROTECTED]> writes:
> Paul Tillotson <[EMAIL PROTECTED]> writes:
>> pg_dumpall does not save all access control permissions on a database.
>> (This is true for at least the CREATE permission.)
>
> This is fixed as of 7.4.
Is this a candidate for being back-patched to 7_3_STABLE? I
Tom Lane <[EMAIL PROTECTED]> writes:
> Well, it was done as part of a significant set of changes to
> pg_dumpall:
Are there plans for a 7.3.5 release? If not, we needn't worry about
it, IMHO. But if there are, I can take a look at producing a low-risk
version of this changed for application to REL
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> I don't know how the check for the data integrity is implemented but if
> is a trigger
It isn't -- trigger firing order is irrelevant to the original
question.
> 1) Create table
> 2) create a before insert trigger: trigger_a
> 3) create a before ins
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Well, it is. If the data integrity was done with a system trigger
> created at table creation time the firing order is relevant.
Right, but the data integrity check is _not_ done via a system
trigger. Hence, "trigger firing order is irrelevant to the o
The pgsql-bugs mailing list is intended for bug reports about
PostgreSQL, not support requests.
"lucas sultanum" <[EMAIL PROTECTED]> writes:
> I have been reading a lot about PostGreSQL but until now I haven't
> found anything stating if the PostGreSQL database has any locking
> mechanism. If so,
Theodore Petrosky <[EMAIL PROTECTED]> writes:
> After about two hours of hunting pecking and anything
> else I found where you control this in OSX 10.3
>
> you must edit the /etc/rc file.
>
> /System/Library/StartupItems/SystemTuning/SystemTuning
> does nothing
Should we update the document
Theodore Petrosky <[EMAIL PROTECTED]> writes:
> I find it difficult to understand exactally what
> reasonable values are.
This page in the documentation includes a table that specifies
"reasonable values" for all of the SysV IPC settings:
http://candle.pha.pa.us/main/writings/pgsql/sgml/kernel-r
Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
>> If not, we needn't worry about it, IMHO. But if there are, I can
>> take a look at producing a low-risk version of this changed for
>> application to REL7_3_STABLE.
>
>
"Alex Albarracin" <[EMAIL PROTECTED]> writes:
> Hello, i have a problem related to the partition memory where
> postgres is installed, this has increased so much that the partition
> is full and postgres can not start up. The message postmaster sends
> when i want to restart is insuficient disk spa
Tom Lane <[EMAIL PROTECTED]> writes:
> What PG version is this? We've fixed a number of bugs with that
> symptom, IIRC ...
When we were discussing this on IRC, I made sure to check it was a
recent version of PG -- I believe it is 7.4.0. The last reported
instance I could see of a bug with this sy
Margus Väli <[EMAIL PROTECTED]> writes:
> COPY command tries to create a buffer too large in size when the
> file copied is larger than about 500 bytes.
Can anyone else reproduce this? I did the following with a fairly
recent CVS snapshot:
1. Copied the supplied text data to a file, fixed up
"Steve Thames" <[EMAIL PROTECTED]> writes:
> The SQL command:
> SELECT last FROM table WHERE symbol='Symbol' AND expmoyr='Mmm-YY' ORDER BY
> qdate DESC LIMIT 1;
>
> This query works fine when there is more than one record meeting the
> criteria. When there is only 1, the query locks and no result
Josh Berkus <[EMAIL PROTECTED]> writes:
> Summary: attempting to connect via MD5 authentication as a user
> who has no password triggers a core dump of Postmaster.
[...]
> Core dump file is available.
Can you post a stacktrace? (Building the postmaster with debugging
symbols first would be n
Olaf Hartmann <[EMAIL PROTECTED]> writes:
> We expirience a memory leak with every connection when using an SSL
> encrypted TCP connection to connect a postgres database.
I can verify this locally. Unfortunately, my copy of valgrind doesn't
seem to be picking up the debugging symbols for OpenSSL,
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> I have installed the Postgres by the procedure by. it got installed
> at /usr/local/pgsql/bin but, when i re-start the system. the
> postgres service starts from /usr/bin.
>
> what shall i do i have tried it by editing the
> /etc/rc.d/inid.d /
Neil Conway <[EMAIL PROTECTED]> writes:
> I can verify this locally. Unfortunately, my copy of valgrind doesn't
> seem to be picking up the debugging symbols for OpenSSL
Ok, some progress. I installed a development snapshot of OpenSSL, and
confirmed that the problem still occur
Okay, I've attached a patch that fixes the problem for me. The problem
turned out to be pretty simple: the PostgreSQL code (both backend and
frontend SSL support) was calling SSL_get_peer_certificate() without
properly free'ing its return value.
I haven't actually confirmed the backend memory leak
Tom Lane <[EMAIL PROTECTED]> writes:
> Kris Jurka <[EMAIL PROTECTED]> writes:
>> When the JDBC driver tries to query the information schema running against
>> cvs head, it gets an assertion failure.
>
> Duplicated here, will fix.
Is it worth including some variant of this query in the regression
t
PostgreSQL Bugs List wrote:
This works fine on Linux using 7.3.4. It also worked on 7.2.x on Cygwin.
FWIW, I can reproduce this problem with CVS HEAD.
-Neil
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://ww
Bruce Momjian wrote:
Yea, we probably aren't releasing any more 7.1.X releases though.
Perhaps it is worth applying to the 7.1 CVS branch, at least?
BTW, I can't really see the harm in putting out 7.1.x and 7.2.x
releases to fix compilation issues on modern systems. For example, I
believe that 7
Tom Lane wrote:
The "harm" is the developer time spent on doing so. Releasing back
versions takes nontrivial effort (witness what it took to get 7.3.6
out the door :-().
True; that said, much of this overhead is (IMHO) avoidable. There
should be little or no manual intervention needed in the rele
On 18-Mar-04, at 9:47 PM, John Muzzatti wrote:
I've downloaded and installed PostgreSQL 7.4 onto a Red Hat Linux
Advanced Server release 2.1AS (Pensacola) server.
[ ... ]
I created a database and expected to see 7.4 when I query the version;
instead it seems that the version is 7.1.3.
You have ev
Using a fresh checkout from CVS HEAD, I get the following on my machine:
% ipcclean --version
/Users/neilc/local/pgsql-cvs/bin/ipcclean: line 114: ipcs: command not
found
This machine is running a pretty standard install of OSX 10.3.3.
At the very least, we shouldn't bother installing ipcclean
On 23-Apr-04, at 10:37 PM, Tom Lane wrote:
We install ipcclean on all platforms whether it functions or not.
Right; my question is why we do that. What purpose does it serve to
install a script that has no hope of working on this particular
platform?
-Neil
---(end of bro
On 2-May-04, at 2:05 PM, Ted Kremenek wrote:
I'm from the Stanford Metacompilation research group where we use
static analysis to find bugs.
Neat. BTW, I saw a talk last summer from Madanlal Musuvathi on some
model checking work which I believe is being done by a related group at
Stanford; it wa
Tom Lane wrote:
This isn't a division problem --- the difficulty is there's no check for
overflow in int4 multiplication. (Nor in any of the other integer
arithmetic operations, for that matter.)
It seems to me that SQL2003, Section 6.26 (,
"General Rules", item 5) requires that we check for over
On Sun, 2004-09-05 at 14:37, Wes wrote:
> System: Mac OS X 10.3.5
> Pg: 8.0.0 b2
Thanks for the report. This is a known issue (it's nothing to worry
about).
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PRO
On Fri, 2004-10-08 at 14:45, XceXac XbdXaa wrote:
> psql:zouxian-data-bak:243910: PANIC: ERRORDATA_STACK_SIZE exceeded
> psql:zouxian-data-bak:243921: server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while
On Wed, 2004-10-13 at 10:23, Fahad G. wrote:
> I checked and I don't have 'readline' installed. --without-readline did the
> trick, but shouldn't this be handled automatically?
This is intentional -- what's wrong with stopping? ISTM that stopping
and letting the user know what went wrong is probab
On Thu, 2004-10-14 at 14:02, Tom Lane wrote:
> The FOR UPDATE part executes after the LIMIT part. Arguably this is a
> bad thing, but I'm concerned about the compatibility issues if we change
> it.
I agree backward compat is a concern, but it seems pretty clear to me
that this is not the optimal
On Fri, 2004-10-15 at 14:22, Tom Lane wrote:
> Allowing FOR UPDATE in sub-selects opens a can of worms that I do not
> think we'll be able to re-can (at least not without the proverbial
> larger size of can).
Ah, I see. I had tried some trivial queries to determine if we supported
FOR UPDATE in su
On Fri, 2004-10-15 at 15:30, Tom Lane wrote:
> Au contraire: every row that gets locked will be returned to the client.
> The gripe at hand is that the number of such rows may be smaller than
> the client wished, because the LIMIT step is applied before we do the
> FOR UPDATE step
Ah, my apologies
On Fri, 2004-10-01 at 01:11, Hussein Patni wrote:
> I noticed in plpgsql that a semi colon is not always requiredafter
> the END statement.
Yeah, I've noticed this as well (although it doesn't appear to be
documented). Would we gain anything by enforcing this restriction? IMHO
not a lot...
-Neil
On Fri, 2004-10-01 at 02:26, Tom Lane wrote:
> EXECUTE does not set the FOUND flag.
Is there a good reason for this behavior?
-Neil
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs
On Fri, 2004-10-01 at 13:46, Tom Lane wrote:
> We specifically do not require a semicolon at the very end of the
> function definition.
Yeah, makes sense. Attached is a doc patch. Barring any objections I'll
apply it to HEAD by end-of-day today.
-Neil
Index: doc/src/sgml/plpgsql.sgml
===
On Fri, 2004-10-01 at 13:39, Tom Lane wrote:
> Possibly not. Can EXECUTE determine how the executed statement would
> have set the flag?
At the moment, EXECUTE just feeds the string it finds to spi_execute().
We could probably hack it to figure out how to modify FOUND, but I think
it would be ugl
Bruce Momjian wrote:
Improved wording that doesn't telegraph, "Look at me!":
Each declaration and each statement within a block is terminated by a
semicolon, though the final END that concludes a
function does not require one.
Patch applied.
-Neil
---
Tom Lane wrote:
Yeah, this has been on my to-do list for awhile...
Ah, ok. Is this something you want to handle, or should I take a look?
One question here is whether Oracle's PL/SQL has a
precedent, and if so which way does it point?
I did some limited testing of this, and it appears that PL/SQL's
On Mon, 2004-10-18 at 12:55, Theodore Petrosky wrote:
> I just tried the newest beta (3) and for the first
> time I am getting multiple errors in 'make check'.
Can you post the regression.diffs file produced by "make check" (should
be in src/test/regress under the directory in which you build
Post
On Tue, 2004-10-19 at 10:36, Tom Lane wrote:
> --disable-shared means you do not get any of the backend extensions that
> come as shared libraries; this includes plpgsql (and the other PL
> languages if you had tried to build 'em) as well as character set
> conversions. I think the tests that fail
Enrico Riedel wrote:
To the setup: I use the Win32 version of PGRE SQL8. The table that I am
working with has about 1.1M records in it and is indexed on several columns.
By searching the indexed columns the DB used to be very fast. The data
retrieval used to be more or less instantaneous. In Beta 3
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 defa
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 prod
On Mon, 2004-11-01 at 10:49, Martin Pitt wrote:
> The current Debian package has some patches that tweak the building of
> contrib modules. I think they would be interesting for other
> distributions, too. Most of this stuff was contributed by users who
> actually use these modules.
Thanks for let
On Tue, 2004-11-16 at 21:13 +0100, Magnus Hagander wrote:
> Upon reviewing this patch, I notice this horrible line slipped into the
> patch earlier up (in the #ifdef WIN32 section):
> + printf("uhh\n");fflush(stdout);
>
> Oopsie. Could you remove that, or do you want a patch to do it?
Tom Lane wrote:
There is no ELSEIF construct.
Sure, but it would be nice to throw a syntax error rather than silently
accepting the function. Unfortunately the way PL/PgSQL's parser works
doesn't make this very easy. (BTW, I think that fixing how we do parsing
would be one of the prime motivatio
Neil Conway wrote:
(BTW, another thing this example exposes is that we don't issue warnings
about trivially-dead-code, such as statements in a basic block that
follow a RETURN. This would probably be also worth doing.)
Attached is a patch that implements this. Specifically, if there ar
On Sat, 2004-11-27 at 12:55 -0500, Tom Lane wrote:
> This seems like the most appropriate answer to me; I was thinking of
> doing that earlier when Fabien and I were fooling with plpgsql error
> reporting, but didn't get around to it.
Attached is a patch that implements a rough draft of this (it a
On Mon, 2004-11-29 at 17:10 -0600, Michael Owens wrote:
> This problem seems to be related to the .psql_history file. If I
> delete the file, the problem does not occur and psql starts up fine.
> However, when I run psql again (after the previous session had
> generated a .psql_history file), the p
On Tue, 2004-11-30 at 22:19 +, PostgreSQL Bugs List wrote:
> This means that using a prepared statement instead of a direct query is *40*
> times slower!
Yes, it's a known (documented) issue that you can get inferior query
plans using prepared statements. I don't know of an easy way to fix
th
On Wed, 2004-12-01 at 21:41 -0700, Michael Fuhr wrote:
> % oid2name -d test -f 173181
> From database "test":
> oid2name in free(): warning: junk pointer, too low to make sense
> oid2name in free(): warning: junk pointer, too low to make sense
> Filenode Table Name
> --
>
On Sun, 2004-12-05 at 09:43 +, PostgreSQL Bugs List wrote:
> In 8.0 RC1, because of bug in -D parsing in pg_ctl I am unable to run
> postgres as service when I have space in data path - when i register it with
> pg_ctl register -D "C:\Program Files\PostgreSQL\data" and try to run it then
> i
On Mon, 2005-01-24 at 23:50 +0100, Pavel Stehule wrote:
> FOR EACH STATEMENT trigger with plperl crash backaned. FOR EACH ROW
> trigger works well.
I believe this is fixed in 8.0.0
-Neil
---(end of broadcast)---
TIP 7: don't forget to increase y
On Thu, 2005-02-10 at 02:37 +, Brian B. wrote:
> I am loading some spam/ham data/tokens, to be used for the dspam anti-spam
> software, into PostgreSQL. After a few hours of inserting and updating the
> existing data, the backend crashes with a signal 10 (bus error). I am also
> running an ANAL
Tom Lane wrote:
Hmm, 64meg should certainly be far past where check_stack_depth will
start to complain, so there's something else going on here.
Right; if those really are the stack size limits for the crashing
backend, I guess my initial analysis must have been mistaken. But I'm
mystified as to
Richard Sang wrote:
I have a view defined as :
create view calling_view as
(
select d.*,c.patient_id as id_m,c.result as r_m from
(select a.*,b.patient_id as id_f,b.result as r_f from
( select substr(a.family_id,1,4) as fid,b.* from denver_person a,
luminex b
where a.id=b.patient_id and
Shujun Huang wrote:
RENCENTLY I RAN INTO THIS ERROR CODE 25P01 WHICH IS "NO ACTIVE SQL
TRNASACTION". THE POSTMASTER IS RUNNING OK. THIS HAPPENED AFTER WE UPGRADED
FROM 7.4.6 TO 7.4.7.
ANY INSERT/UPDATE QUERY RUNS OK, A SIMPLE RETRIEVE QUERY IS ALSO RUNNING OK,
ANY RETRIEVE QUERIES INVOLVE IN CURSO
[EMAIL PROTECTED] wrote:
I have a PLpgSQL function that returns a string (varchar): if this string
is over 256 characters long then the last three characters are corrupted:
replaced by the string ' (.'
I'm skeptical: there is nothing special about 256 characters as far as
the varchar implementa
1 - 100 of 133 matches
Mail list logo
