OTICE: 4 3
psql:stupid_plperl.sql:29: NOTICE: 2 1
untrustedsort
---
1
(1 row)
DROP FUNCTION
DROP FUNCTION
--
Jeff Trout <[EMAIL PROTECTED]>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Nov 4, 2008, at 2:27 PM, Alex Hunsaker wrote:
On Tue, Nov 4, 2008 at 09:02, Jeff <[EMAIL PROTECTED]> wrote:
I've ran into this interesting problem.
It seems that while you can call sort() in a trusted plperl func
you cannot
access $a & $b which effectively makes it usele
= sub ($$) { $_[0] <=> $_[1] };
my @vals = (5,3,4,2,7);
return join(' ',sort $sfunc @vals);
$f$;
Andrew for the win!
Thanks a lot!
I agree, a documentation note would be fine for this rather doing all
sorts of complicated perl trickery.
--
Jeff Trout <
the array being produced by
a subselect that uses array_accum to gather a list of ids to pull up.
If this is the proper behavior I'll deal with it (in the end the
result is the same - no rows). Just a bit surprised by it.
--
Jeff Trout
http://www.stuarthamm.net/
http://www.dellsmart
On Mar 25, 2010, at 11:44 AM, Tom Lane wrote:
Hmm, that case is supposed to work, in 8.3 and later ... but it
doesn't
because of a stupid typo in contrib/intarray.
This works. -
thanks!
--
Jeff Trout
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/
--
Sent via pgsql
select to_date('December 12 2002','Month dd ');
to_date
2002-12-02
select to_date('January 12 2002','Month dd ');
to_date
0005-06-24 <- Problem right there.
select to_date('January 12, 2002','Month dd, ');
to_date
-
Thanks for clarifying. I've submitted a note on the interactive
version of the docs, and attached a small patch to make explicit that
a window function is followed _immediately_ by an OVER clause, as the
syntax[1] indicates.
Regards,
Jeff
[1]
http://www.postgresql.org/docs/cu
The following bug has been logged online:
Bug reference: 6038
Logged by: Jeff
Email address: jeffadam...@gmail.com
PostgreSQL version: 9.0.4
Operating system: Windows XP 32bit
Description:configure warnings on sys/socket.h and netinet/in.h,
make fails
Details
The following bug has been logged on the website:
Bug reference: 6704
Logged by: Jeff Frost
Email address: j...@pgexperts.com
PostgreSQL version: 9.1.4
Operating system: Windows and Linux
Description:
DROP and CREATE extension appear to work fine, but if you ALTER
The following bug has been logged on the website:
Bug reference: 7902
Logged by: Jeff Frost
Email address: j...@pgexperts.com
PostgreSQL version: 9.2.3
Operating system: Ubuntu 12.04
Description:
While doing acceptance testing on a new Ubuntu 12.04 PostgreSQL server
The following bug has been logged on the website:
Bug reference: 8225
Logged by: Jeff Frost
Email address: j...@pgexperts.com
PostgreSQL version: 9.1.8
Operating system: various
Description:
I've seen this a few times on client servers but still can't seem
The following bug has been logged on the website:
Bug reference: 8315
Logged by: Jeff Frost
Email address: j...@pgexperts.com
PostgreSQL version: 9.2.4
Operating system: Scientific Linux 6
Description:
Simple test case:
pgx-test:~ $ createdb permtest
pgx-test
nextval(), and each call of nextval() returns a different value.
One way to think about it is that a rule doesn't save any values away in
variables. Functions do save the arguments as variables on the stack,
and those variables can be used multiple times, so that's why calling a
function
The following bug has been logged online:
Bug reference: 4324
Logged by: Jeff Galyan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3
Operating system: Linux
Description:Default value for a column is not returned in select
when column has not been
I'm
not really sure what the behavior is supposed to be, but the output
shouldn't depend on the optimizer.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Mon, 2008-08-25 at 22:26 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > => select max(a), generate_series(1,2) as g from foo order by g desc;
> > ERROR: set-valued function called in context that cannot accept a set
>
> This strikes me as
to do with the ORDER BY, so that part of my
example was unnecessary.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
than a UNION ALL
view.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
in 8.4 more
apparent?
Regards,
Jeff Davis
i = 1
print "set search_path = mytest, public;"
print "drop table if exists foo;"
print "create table foo (i int unique);"
while 1:
print "INSERT INTO foo select generate_series(%d, %d);" % (i, i + 9)
On Mon, 2008-10-06 at 11:10 +0300, Heikki Linnakangas wrote:
> Jeff Davis wrote:
> > I am seeing index bloat in the current head when the indexed values are
> > constantly increasing, and the lower values are being constantly
> > deleted.
> >
> > ...
> > I
On Tue, 2008-10-07 at 11:04 +0300, Heikki Linnakangas wrote:
> Jeff Davis wrote:
> > I see this problem on 8.3.3 now, too. Originally, I suppose my test was
> > not long enough, but now I see the problem after about 10 minutes of
> > running.
>
> I ran the script for a
On Tue, 2008-10-07 at 08:14 -0700, Jeff Davis wrote:
> In the VACUUM VERBOSE output I included, you can see that the heap is
> only 785 pages (after 200M rows went through that table), and it
> maintains that consistently. That means to me that the VACUUMs are
> running and properly
The following bug has been logged online:
Bug reference: 4491
Logged by: Jeff Frost
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.4
Operating system: Fedora 9/Gentoo/Mac OS X
Description:regression in gist indexes
Details:
It seems that 8.3.4 has a
Looks like this is a dup of #4479:
http://archives.postgresql.org/pgsql-bugs/2008-10/msg00094.php
-- Forwarded message --
Date: Wed, 22 Oct 2008 19:11:51 -0300
From: [EMAIL PROTECTED]
To: Jeff Frost <[EMAIL PROTECTED]>
Subject: Stalled post to pgsql-bugs
Your message to
This does not look right to me:
=# select regexp_split_to_array('dsf,sdfsdf',',')::text[][100];
regexp_split_to_array
---
{dsf,sdfsdf}
(1 row)
Is this known?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@pos
violation of the SQL standard. I've been wrong about the
SQL standard plenty of times though, so don't take my word for it ;)
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Mon, 2009-01-05 at 15:42 -0500, Tom Lane wrote:
> The only way to avoid this would be to lock before the sort, which could
> have the effect of locking more rows than are returned (if you also use
> LIMIT);
How would that work in the case of an index scan sort?
Regards,
J
schema paths as well, if it's not in some expected place (I think it
does so for all schemas other than pg_catalog).
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Thu, 2009-02-26 at 15:52 -0800, Josh Berkus wrote:
> Jeff,
>
> > Functions are similar, actually. The argument list needs to specify
> > schema paths as well, if it's not in some expected place (I think it
> > does so for all schemas other than pg_catalog).
>
On Thu, 2009-02-26 at 21:42 -0800, Josh Berkus wrote:
> Jeff,
>
> > In the general case though, for any object that refers to multiple other
> > objects, I don't see any way around explicit schema qualification. I
> > suppose it could be smart and say "foo_type i
PE mytype2 AS (
j mytype
);
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
NT or SIGTERM to the backend.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
l.org/docs/8.3/static/server-shutdown.html
If you have an open COPY and no data is moving, it simply won't
terminate it. You can terminate it with ctrl-C from psql, but not a
SIGINT to the postmaster or a SIGINT or SIGTERM to the backend.
Regards,
Jeff Davis
--
Sent via pgsql-bugs m
That's perfectly acceptable to me. I'm only concerned about the shutdown
case, and that's the only case that's in conflict with the docs.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
mmandRead protect us in the SIGINT case?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
SIGINT to a
backend. And in the case of SIGTERM to a backend, the connection will be
terminated anyway.
Regards,
Jeff Davis
diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c
index c8223bf..c0d3622 100644
--- a/src/backend/commands/copy.c
+++ b/src/backend/commands/cop
s us in a state so unsafe that we can't even abort the
transaction nicely.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
g/docs/8.4/static/sql-select.html#SQL-DISTINCT
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
but the start point of a
synchronized scan is stored in shared memory; otherwise, it wouldn't
know where to stop.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Tue, 2009-06-09 at 10:51 -0700, Jeff Davis wrote:
> On Tue, 2009-06-09 at 12:07 -0400, Tom Lane wrote:
> > We could probably fix this specific issue by refactoring things in such
> > a way that the seqscan start point is frozen on the first read and
> > re-used after rewin
The following bug has been logged online:
Bug reference: 4952
Logged by: Jeff Janes
Email address: jeff.ja...@gmail.com
PostgreSQL version: 8.4.0
Operating system: Linux 2.4.21-15.0.3.ELsmp
Description:commit_delay ignored because CountActiveBackends always
returns
The following bug has been logged online:
Bug reference: 4965
Logged by: Jeff Janes
Email address: jeff.ja...@gmail.com
PostgreSQL version: 8.4.0
Operating system: Linux
Description:missing tests in tools/fsync/test_fsync.c
Details:
In the part that implements
the same readfile() function in initdb.c. I
assume it's not a practical problem there, but it should be fixed.
Thanks to Corry Haines (chaines at truviso dot com) for reporting the
problem.
Regards,
Jeff Davis
diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c
index
hose desirable behaviors unless you are
somehow aware that "'January 01, 2009'" is something more malleable than
"now()" in example #2. Calling the RHS "unknown" in example #2 gives us
that information.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Tue, 2009-09-01 at 22:01 -0400, Tom Lane wrote:
> Huh, interesting corner case. I'd be inclined to fix by initializing
> maxlength to 1 though.
>
> Where's the memory leak?
The xstrdup() on the zero-length string.
Regards,
Jeff Davis
--
Sent via pgsql-bu
rals; but I disagree that using implicit casts to make up for a lack
of an "unknown" type will improve matters (either for convenience or
safety).
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Fri, 2009-09-04 at 11:15 -0400, Tom Lane wrote:
> On the whole, throwing an error seems better from a usability
> perspective.
>
> Comments?
Agreed.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscr
If I create a gist index over a box and a circle, the index attributes
appear to both have type box.
I don't see any other, similar situations with other types, and I
haven't investigated the cause yet. Most similar situations work fine.
Regards,
Jeff Davis
postgres=# sele
On Wed, 2009-09-16 at 10:36 -0400, Tom Lane wrote:
> This is expected, no? Those opclasses use the STORAGE option.
I see, that makes sense. I was making the assumption that the types
matched in my new patch, and obviously that's incorrect.
Regards,
Jeff Davis
--
Sent via pg
The following bug has been logged online:
Bug reference: 5154
Logged by: Jeff Shanab
Email address: jsha...@earthlink.net
PostgreSQL version: 8.3.5
Operating system: Linux
Description:ERROR: cannot assign non-composite value to a row
variable
Details:
As discussed
The following bug has been logged online:
Bug reference: 5157
Logged by: Jeff Janes
Email address: jeff.ja...@gmail.com
PostgreSQL version: 8.4.1
Operating system: Linux
Description:Hash index not concurrency safe
Details:
Hash index is not concurrency safe
On Sun, Nov 1, 2009 at 8:52 AM, Tom Lane wrote:
> "Jeff Janes" writes:
>> Hash index is not concurrency safe, starting in REL8_4_0 and up to HEAD.
>
> Ouch. This used to be okay, because adding new entries to a hash page
> always added them at the end. The 8.4 cha
nd here:
http://www.postgresql.org/docs/8.4/static/datatype-xml.html
http://www.postgresql.org/docs/8.4/static/functions-xml.html
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Thu, 2010-02-25 at 23:15 -0500, Bruce Momjian wrote:
> Was this ever addressed?
>
It doesn't appear to be fixed, and I don't see it on the TODO, either.
Should we add it there?
Regards,
r the config we used."
I was trying to sort this bug out somewhat before posting, but we
weren't able to reproduce it (it happened near the end of testing, and
people were leaving), and I didn't have much chance to investigate in
the last week.
Regards,
Jeff Davis
postg...@
I looked at the TODO before sending this, and found
nothing regarding listen/unlisten.
I was unable to find the bug report sumission page at
www.postgresql.org, even though it was mentioned in
this template.
Your name : Jeff Davis
Your email address : [EMAIL
this form.
POSTGRESQL BUG REPORT TEMPLATE
Your name : Jeff Davis
Your email address : [EMAIL PROTECTED]
System Configuration
-
Ar
Title: date bug
Strange date behavior as shown below.
create table "holidays" ("date" date NOT NULL,"name" varchar(25));
insert into holidays values ('01-01-2001'::date,'New Years');
insert into holidays values ('01-15-2001'::date,'Kings Birthday');
insert into holidays values ('02-19-2
The following bug has been logged online:
Bug reference: 2455
Logged by: Jeff Ross
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: OpenBSD 3.9 -current
Description:psql failing to restore a table because of a constaint
violation.
Details
e interpretation of other
postgresql.conf settings?
What if you have a path set for archive_command and then you change the
standard_conforming_strings GUC and SIGHUP the server? Will the path be
incorrect?
Regards,
Jeff Davis
---(end of broadcast)--
The following bug has been logged online:
Bug reference: 2678
Logged by: Jeff Trout
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: OSX 10.4.8 (Also occurs on FC4 w/kernel 2.6.16
Description:Create or replace function with OUT args
The following bug has been logged online:
Bug reference: 2678
Logged by: Jeff Trout
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: OSX 10.4.8 (Also occurs on FC4 w/kernel 2.6.16
Description:Create or replace function with OUT args
riggering query
occurred within a function: the trigger is invoked before the function
proceeds to its next operation. For example, if a function inserts a new
row into a table, any nondeferred foreign key checks occur before
proceeding with the function."
Regards,
Jeff Davis
Ste
ls up. Or maybe we can somehow avoid needing to record the
relnodes to be deleted in order for the abort to succeed.
I'm still not sure why foreign keys on large insert statements don't eat
memory on 7.4, but do on 8.0+.
Regards,
Jeff Davis
---(e
On Wed, 2006-10-25 at 16:20 -0300, Alvaro Herrera wrote:
> Jeff Davis wrote:
> > I found the root cause of the bug I reported at:
> >
> > http://archives.postgresql.org/pgsql-bugs/2006-10/msg00211.php
> >
> > What happens is this:
> > * Out of memor
On Wed, 2006-10-25 at 18:15 -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Jeff Davis wrote:
> >> * smgrGetPendingDeletes() calls palloc()
> >> * palloc() fails, resulting in ERROR, causing infinite recursion
>
> > Hmm, mayb
se /some/file contains invalid UTF8 sequences, even
though it's the same file you copied out.
It seems to be essentially a data corruption issue if applications
insert binary data in text fields using escape sequences. Shouldn't
PostgreSQL reject an invalid UTF8 sequence in any
On Fri, 2006-10-27 at 14:42 -0700, Jeff Davis wrote:
> It seems to be essentially a data corruption issue if applications
> insert binary data in text fields using escape sequences. Shouldn't
> PostgreSQL reject an invalid UTF8 sequence in any text type?
>
Another note: P
On Fri, 2006-10-27 at 14:42 -0700, Jeff Davis wrote:
> You can insert invalid UTF8 bytes sequences into a TEXT type on an 8.1
> installation by doing something like:
>
I created a patch that appears to fix the problem, and does not appear
to break anything else.
Is this acceptable?
On Tue, 2006-10-31 at 16:13 -0500, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > I created a patch that appears to fix the problem, and does not appear
> > to break anything else.
>
> ... except maybe bytea ...
>
Ok. So then it seems that the only po
On Tue, 2006-10-31 at 23:18 -0500, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > Is this not a bug?
>
> I don't actually see that it is. The documentation is perfectly clear
> on the point:
>
> (It is your responsibility that the byte seq
rd. On 8.2 this returns 10. It appears to
be applying the filter too soon, and then it does an outer join which
violates the WHERE.
Regards,
Jeff Davis
test=> SELECT version();
tbrokendp(12345);
commit;
\q
pg_dump broken1 > broken1.sql
createdb broken2
psql -f broken1.sql broken2
You'll see the numbers go radically different
(ie 9.375 changing to 5.39500333695425e-315)
and when you restore the backup, the getBrokenDP function will not
make a datatype complai
On Jan 24, 2007, at 12:24 PM, Tom Lane wrote:
Jeff Trout <[EMAIL PROTECTED]> writes:
I just ran across this, and I do not think it is entirely a PG bug or
even something that the backend can detect and handle.
The problem stems from swapping a table definition from under a
function.
I am sending this email on behalf of Russel Smith. He discovered this
bug and his description follows:
Verified on 8.2.3 on Fedora Core 6
Verified on 8.1.3 on RHEL4, custom compile. (I can't control the update to
8.1.8)
The output of an empty role name would possibly not be a problem, but when
the
ALTER TABLE ... OWNER TO syntax, which properly honors -O.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
On Wed, 2007-04-25 at 11:36 -0700, Jeff Davis wrote:
> pg_dump -O apparently removes all instances of ALTER TABLE ... OWNER TO
> from the output, but does not remove ALTER SEQUENCE ... OWNED BY from
> the output.
>
> Specifically this is with SERIAL sequences, which are dumped us
On Wed, 2007-04-25 at 16:44 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > pg_dump -O apparently removes all instances of ALTER TABLE ... OWNER TO
> > from the output, but does not remove ALTER SEQUENCE ... OWNED BY from
> > the output.
>
?
>
We could handle it essentially like a volatile set-returning function.
It may be easy to shoot oneself in the foot, but that is true for many
uses of volatile functions.
If the argument is that we shouldn't make it any easier, that's a fair
point, but this is one possible definit
On Tue, 2007-05-29 at 22:41 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > On Tue, 2007-05-29 at 18:10 +0100, Gregory Stark wrote:
> >> It has the same problem that SELECT triggers have. How many rows should you
> >> expect that subquery to
':3"
This has the same result on beta1 and beta2.
I'm using en_US.UTF-8 on FreeBSD.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
eg in size, so I can either upload it to
our web site or e-mail it directly to someone if anyone is interested.
Thanks,
Jeff Ross
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Shelby Cain wrote:
I believe this is expected behavior the Ctrl-\ keystroke will cause a SIGQUIT
to the current process. Any program that doesn't explicitly handle SIGQUIT
will abort.
Regards,
Shelby Cain
Okay, thanks for the reply, and sorry for the noise.
t; (a PostgreSQL user) for tracking this bug
down.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 6: explain analyze is your friend
l works just fine now, and
that TCP is explicitly designed to prevent these kinds of problems, and
we only see this problem because FreeBSD 6.1 TCP is broken.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 6: explain analyze is your friend
ny return value at all (and thus do
not retransmit the message). I agree that is a problem (assuming I
understand what's going on).
Regards,
Jeff Davis
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appro
the results are. If
that is faster, the planner is not choosing the right plan. Try ANALYZE
to update the statistics, and if that doesn't work, post EXPLAIN
results.
Also, this post is somewhat off-topic for -bugs, try posting to -general
or -performance with this type of question.
Regards,
The following bug has been logged online:
Bug reference: 4085
Logged by: Jeff Dwyer
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Mac OS X
Description:No implicit cast after coalesce
Details:
This works fine:
select 1 where
OK, worksforme. I guess I still find it odd, but I much prefer
explicitness & robustness to small values of 'work'.
Thanks for the prompt response.
-Jeff
On Apr 2, 2008, at 7:15 PM, Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Jeff Dwyer wrote:
This se
organizations and org_details.
Thanks,
Jeff Post
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
The "VACUUM ANALYZE tablename" command does not have the same effect on
table metadata under 7.2.1 and 7.2.3. In particular, I've noted that
pg_class.reltuples is not updated by vacuuming after a delete.
Here is a sequence of SQL commands to demonstrate the difference. Under
7.2.1, the result
happened on a Sunday morning, my weekend
experiment to see how pg_autovacuum would maintain our test database was
rather spoiled ... 8-(
--
Jeff Boes vox 269.226.9550 ext 24
Database Engineer fax 269.349.9076
Nexcerpt, Inc.
it like:
psql -d template1 -U postgres -f pg_crash
Thanks,
- Jeff
2004-03-01 10:32:24 [471] LOG: connection received: host=[local] port=
2004-03-01 10:32:24 [471] LOG: connection authorized: user=username
database=cos
2004-03-01 10:32:34 [471] LOG: statement: create temp table foo as
I should have a patch later today.
Great! I'd like to try out the patch when it's ready.
Thanks,
- Jeff
--
Jeff Bohmer
VisionLink, Inc.
_
303.402.0170
www.visionlink.org
_
People. Tools. Change.
Jeff Bohmer <[EMAIL PROTECTED]> writes:
Great! I'd like to try out the patch when it's ready.
Here ya go.
Works for me on OS X and Linux.
Thank you very much!
- Jeff
--
Jeff Bohmer
VisionLink, Inc.
_
303.402.0170
ww
is OpenBSD 3.6.
I'm currently running 7.3.5, which I'd love to upgrade but I'm a little
leary until I can determine what is causing this error.
Any thoughts greatly appreciated!
Jeff Ross
---(end of broadcast)---
TIP 6: Have you se
ssors with 2 GB of RAM. Operating
system is OpenBSD 3.6.
I'm a little leary of upgrading my PostgreSQL installation with those
kind of failure rates.
I'd appreciate any insight as to why so many tests would fail when run
on disk and pass when run in ram.
Th
Tom Lane wrote:
Michael Fuhr <[EMAIL PROTECTED]> writes:
On Fri, Jan 21, 2005 at 05:03:08PM -0700, Jeff Ross wrote:
If I put the same source code up on a ram disk, configure and compile it
the same way, all 96 tests pass.
Interesting. Is this behavior consistent? What's different
Tom Lane wrote:
Jeff Ross <[EMAIL PROTECTED]> writes:
Rather than post it in the e-mail, I've put the postmaster.log at
http://www.openvistas.net/postmaster.log
I see multiple occurrences of
LOG: could not fork new process for connection: Resource temporarily
unavailable
so
The following bug has been logged online:
Bug reference: 1938
Logged by: Jeff MacDonald
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.3
Operating system: FreeBSD 5.2.1
Description:pg_dump mis-intreprets "default now()";
Details:
Hi,
I did a b
1 - 100 of 255 matches
Mail list logo
