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()
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
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
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 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 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 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 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)---
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
--
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!),
On Mon, 2006-03-20 at 14:27 +0530, Dhanaraj M - Sun Microsystems wrote:
> I have fixed a bug which was reported in our mailing group ealier. Can
> anybody tell me how i could test my code and then put back?
I'm not sure what you mean; if you're asking "how do I submit patches
that fix bugs?", sen
On Sat, 2006-03-18 at 15:35 -0600, Ashley Clark wrote:
> The call to DNSServiceRegistrationCreate in postmaster.c does
> incorrect byte-swapping on the port number which causes the Bonjour
> registration call to fail on Intel Macs.
Thanks for the patch -- applied to HEAD and back branches, back to
On Mon, 2006-01-30 at 20:45 -0500, Tom Lane wrote:
> You only fixed the bind-parameter case, though, no? The problem is
> still rampant in the PLs.
Right: the bug report was specific to the bind parameter case. Domain
constraints should also be checked before returning values of a domain
type fro
On Sat, 2006-01-28 at 20:17 +0100, Peter Eisentraut wrote:
> This bug was reported to Debian. Comments?
AFAICS I fixed this a few weeks ago (post-8.1.2):
http://archives.postgresql.org/pgsql-committers/2006-01/msg00209.php
http://archives.postgresql.org/pgsql-patches/2006-01/msg00139.php
I get
On Sun, 2006-01-29 at 17:03 -0800, David Fetter wrote:
> Another followup, this time with the comment done right.
+ /* Disallow the forbidden_delimiter strings */
+ if (strcspn(cstate->delim, BADCHARS) != 1)
+ elog(ERROR, "COPY delimiter cannot be %#02x",
+
On Thu, 2005-12-15 at 11:09 -0800, Jim Klo wrote:
> I’m having a similar problem:
>
> ERROR: relation with OID 7121526 does not exist
> CONTEXT: SQL statement "SELECT * INTO temp tmp_resourcequeue from
> resourcequeue where timeblockid in (select timeblockid from tmp_timeblock)"
> PL/pgSQL f
On Thu, 2005-11-17 at 13:07 -0800, David Fetter wrote:
> This is still a bug, or at least a big gotcha.
It's not a bug, merely an unimplemented feature. If no one beats me to
it I'll take a look at doing this for 8.2.
-Neil
---(end of broadcast)-
Denis Vlasenko wrote:
The same php script but done against Oracle does not have this
behaviour.
Perhaps; presumably Oracle is essentially creating a cursor for you
behind the scenes. libpq does not attempt to do this automatically; if
you need a cursor, you can create one by hand.
-Neil
--
Denis Vlasenko wrote:
Symptom: even the simplest query
$result = pg_query($db, "SELECT * FROM big_table");
eats enormous amounts of memory on server
(proportional to table size).
Right, which is exactly what you would expect. The entire result set is
sent to the client and stored in local memo
Tom Lane wrote:
System catalog lookups generally follow SnapshotNow rules, not MVCC.
So the new function definition is visible as soon as it's committed,
whether you are in a serializable transaction or not.
IMHO this is a bug, or at least not optimal behavior. But per the
discussion on -hacke
On Mon, 2005-05-30 at 19:36 +0300, Haluk GÜNÇER wrote:
> #0 0x23cf64 in CreatePortal+0x1f4 ()
> (gdb) bt
> #0 0x23cf64 in CreatePortal+0x1f4 ()
> #1 0x23ce28 in CreatePortal+0xb8 ()
> #2 0x19c094 in exec_simple_query+0x194 ()
> #3 0x19daa8 in PostgresMain+0x1520 ()
> #4 0x12f918 in main+0x1e0
Neil Conway wrote:
Ah, yeah, that works. Attached is a revised patch -- I'll apply it
tomorrow barring any objections. I also fixed the semi-colon -- thanks
for the review.
Patch applied to HEAD, REL8_0_STABLE, and REL7_4_STABLE. Thanks for the
report, Mark.
Haluk GÜNÇER wrote:
I did it with -n option. The generated core file is attached. I hope it
will help.
The core file itself is not much use -- you need to get a stack trace
from the core file (which I can't do, since I don't have the binaries
you built -- or an HPUX system for that matter). Y
Tom Lane wrote:
Considering that you're incrementing bufptr inside the macro, it hardly
seems that double-evaluation is a problem: the argument pretty much has
to be a variable. OTOH there is no reason for the input argument to be
treated that way. I'd suggest just one macro [...]
Ah, yeah, t
Haluk GUNCER wrote:
fixing permissions on existing directory /usr/local/pgsql/data ... ok
creating directory /usr/local/pgsql/data/global ... ok
creating directory /usr/local/pgsql/data/pg_xlog ... ok
creating directory /usr/local/pgsql/data/pg_xlog/archive_status ... ok
creating directory /usr/l
Tom Lane wrote:
I'm not set on it --- fix it as you suggested.
Attached is a patch that implements this. I'm not especially happy about
the implementation: defining _two_ local macros (that both
doubly-evaluate one of their arguments) is pretty ugly, but I didn't see
a cleaner alternative --
Neil Conway wrote:
I think we _can_ do it that way, it's just a question of whether that is
the best approach. I think the solution I outlined before would work
fine: pass the length of the working buffer to ParseDateTime(), and
reject the input only if the parsing process actually req
SzÅcs GÃbor wrote:
# create table foo (bar int, constraint foobar check (true));
CREATE TABLE
# \d foo
Table "public.foo"
Column | Type | Modifiers
+-+---
bar| integer |
Check constraints:
"foobar" CHECK ()
Yeah, I can repro this with current REL7_4_STABLE
Herman Bos wrote:
vib=> select * from "bedrag";
ERROR: relation "bedrag" does not exist
Naturally: there is no such table, regardless of case.
vib=> select "BEDRAG" from sancties;
BEDRAG
(0 rows)
Not with the SQL you provided:
neilc=# select "BEDRAG" from sancties;
ERROR: relation "sanc
Tom Lane wrote:
I'm too tired to think about this more tonight, but it seems like
the basic point is that we can't just construct a list of pointers
into (a copy of) the original input string.
I think we _can_ do it that way, it's just a question of whether that is
the best approach. I think the s
Tom Lane wrote:
Sorry, s/downcased/downcased and null-terminated/. I have not read the
parsing code in question lately, but offhand it seems like transferring
one token at a time into a work buffer isn't a completely broken idea...
I wouldn't call it "broken", but I don't see how it could be done
Tom Lane wrote:
I believe that the reason for the local buffer is to hold a downcased
version of the input, which we can compare to the all-lower-case tables
of relevant keywords.
Well, that's one of the reasons, but not the only one. For example, how
do you parse '17 minutes31 seconds'::interval
Tom Lane wrote:
Well, if you allow for whitespace between tokens then it's immediately
clear that there is no fixed upper bound.
Good point -- there is no upper bound on the input string, but since we
skip whitespace, AFAICS this shouldn't affect the requirements for the
size of the working buffe
Alexander Volk wrote:
configure: WARNING: you should use --build, --host, --target
checking build system type... i386-portbld-freebsd5.4
checking host system type... i386-portbld-freebsd5.4
checking which template to use... freebsd
checking whether to build with 64-bit integer date/time support...
Tom Lane wrote:
There are a lot of fixed-size local buffers in that code. The ones
used in output routines seem defensible since the string to be generated
is predictable. The ones that are used for processing input are likely
wrong. OTOH I'm not eager to throw a palloc into each of those code
p
Mark Dilger wrote:
It appears that any string representation of an interval of length greater
than 76 is rejected. (76 = 51 + 25 = MAXDATELEN + MAXDATEFIELDS). This
appears to be a limitation enforced within function interval_in() in the
file src/backend/utils/adt/timestamp.c
Yeah, this seems bog
tirny wrote:
any code instructions
***
IF FOUND AND TG_OP = 'UPDATE' THEN
***
END IF;
***
if not found plsql does't break this structure after IF FOUND and proceed
TG_OP = \'UPDATE\', what bring control structures to:
IF FOUND THEN
IF TG_OP = 'UPDATE' THEN
***
END IF;
END IF;
inconveniently,
Enrico Weigelt wrote:
BTW: real is an alias to float4 ?
Yes.
-Neil
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Alvaro Herrera wrote:
I believe on Windows the file is called pgpass.conf instead?
The SGML docs pretty consistently only mention "~/.pgpass" when
referencing this feature, so I didn't bother mentioning the other name
in the pg_autovacuum README. Perhaps someone should fix the SGML docs to
refer
Matthew T. O'Connor wrote:
I believe that pg_autovacuum will work with a .pgpass file just like any
libpq based application.
It should, yes. I've applied the attached patch to HEAD and
REL8_0_STABLE that makes the security warning about -P more broad, and
suggests using ~/.pgpass instead.
-Neil
Dan Black wrote:
Need to rename function parameters, so that their names and table fields
names are unmatched.
I don't really see a way to make the error any more obvious in the
current pl/pgsql implementation, unfortunately.
-Neil
---(end of broadcast)--
David B. wrote:
8.0.1 doesn't compile to include plpgsql.o so I can't createlang pl/pgsql.
The 8.0.1 compile does create a plpgsql.so; it is installed under
$prefix/lib.
Why don't you guys provide rpms for the major distributions anyway?
http://www.postgresql.org/ftp/binary/v8.0.1/linux/rpms/
-Ne
Richard Neill wrote:
I think that the first query ought to succeed, since although priceband is
ambiguous (it could mean either tbl_prices.priceband or
tbl_instruments.priceband), the information in the WHERE clause means that
they are explicitly equal, and so it doesn't matter which one we use.
We
[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
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
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
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
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
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 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 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 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 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 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
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
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
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?
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 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
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
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
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
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 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-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 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 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 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
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
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
---
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
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 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 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 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
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 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
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
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 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
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
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
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
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
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
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
"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 /
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,
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
"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
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
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
"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:
> 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.
>
>
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
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
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,
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
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
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
1 - 100 of 133 matches
Mail list logo
