that, or write() wrote less than expected but did not set errno.
It looks like we assume ENOSPC when errno is not set.
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
,
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
exactly, though.
Regards,
Jeff Davis
[1] To make it more plausible, tstzrange2 might have a canonicalization
function that turns it into a discrete range (kind of like date but at a
resolution smaller than a day).
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
,
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
a hold on a non-local temp
table? Or do you just mean as a sanity check? Either way, blocking it at
the top sounds good to me.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
RELATION_IS_OTHER_TEMP(relation) \
((relation)-rd_rel-relpersistence == RELPERSISTENCE_TEMP \
!isTempOrToastNamespace((relation)-rd_rel-relnamespace))
(I haven't analyzed the above code very carefully; it's just for
illustration purposes).
Regards,
Jeff Davis
--
Sent via pgsql-bugs
, because the caller would see that it returns a long
(and compiler, but I don't seem to get a warning for implicit long-int
conversions).
Both of the callers that actually want a log2 already assume that the
input is a power of two, so we can redefine my_log2 to require it.
Regards,
Jeff
On Mon, 2012-12-10 at 20:27 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
It looks like all of the callers, except two, immediately shift the
result. So perhaps it would be better to make a new function (something
like ceil_pow2) that returns the lowest power of two greater
think of a reason for
something outside to call them.
Regards,
Jeff Davis
[1]: The test case will just eat a lot of memory right now, but that's
only because I set work_mem so high. So, it doesn't actually complete,
but it no longer corrupts the HASHHDR.
htab.patch.gz
Description: GNU
. In practice,
work_mem will usually be the limiting factor anyway, but not if it's set
high.
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
dropping a trigger created
by someone else.
I agree that it's inconsistent. I'm not sure why they added the separate
TRIGGER privilege in the first place, but it was done more than 10
years ago.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
privilege) is to track the owner of the
trigger separately from the owner of the table, but that would be
strange, too.
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 an IMMUTABLE function to be called a
specific number of times.
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
presume.
This is reading from a 9.0.8 Postgres.
Any indication whether it's present on other versions or does it appear
to be isolated to 9.0.X?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
:
http://www.postgresql.org/docs/9.2/static/sql-createtable.html#SQL-CREATETABLE-EXCLUDE
To make it equivalent to UNIQUE, set all operators to =, e.g.:
CREATE TABLE xyz(i int, exclude (i WITH =) where (i 10) deferrable);
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql
On Thu, 2012-09-13 at 12:39 -0400, Robert Haas wrote:
On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis pg...@j-davis.com wrote:
This bug seems particularly troublesome because the right fix would be
to include the relpersistence in the WAL records that need it. But that
can't be backported
was hiding
this one.
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
of the consequences is that you can get buffers with the wrong flags
set; in particular, missing BM_PERMANENT, which seems like it could be a
serious problem.
Are there other areas where we might have similar problems?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs
to
hash_create(), and no hash_destroy() is called. Unless I'm missing
something, that's a leak in TopMemoryContext.
Regards,
Jeff Davis
#0 0x004683a2 in extractRelOptions (tuple=0x11cd528,
tupdesc=0x7fc9e499b420, amoptions=0) at reloptions.c:778
#1 0x008513f8
support, it is available from these
companies:
http://www.postgresql.org/support/professional_support/
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
://thoughts.davisjeff.com/2009/08/02/what-is-the-deal-with-nulls/
Jose was not wrong about the inconsistency between UNIQUE and GROUP BY.
But the answer is that we do it that way because the standard says so.
And that's a good reason.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs
On Sat, 2012-03-24 at 19:07 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
Surely we don't want it to be set from the environment, right?
Why not?
I agree that we shouldn't change the documented behavior of those GUCs.
But a SQL command like CREATE DATABASE being environment
the null string
without modification into the output file. COPY FROM seems to de-escape
the input before trying to match it against the null string, leading to
the invalid byte sequence.
standard_conforming_strings is on.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql
On Sun, 2012-03-11 at 11:20 -0700, Jeff Davis wrote:
The problem seems to be in check_locale(), which just checks for a
non-NULL return value from setlocale(). However, the manual for
setlocale() says:
If locale is , each part of the locale that should be modified
is set according
the environment, right?
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
operation. When you execute the query, it displays the date
constant using the now-current datestyle.
Another thought: why does it execute the type input function (which is
dependent on a GUC), but not the cast?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
results is correct?
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
as to which result is more correct,
but I doubt we're going to try to do something about that. Best advice
is to avoid ambiguous input, or if you can't, at least avoid flipping
your datestyle on the fly.
I'm fine calling that not a bug, though it appears to work in 8.3.
Regards,
Jeff Davis
pretty
useless, so I'm thinking it's not worth back-patching a fix for.
Comments?
Agreed. I'm not worried about backpatching 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
In branch postgresql/master:
SELECT SUM(SUM(a)) OVER ()
FROM (SELECT NULL::int4 AS a WHERE FALSE) R;
ERROR: XX000: cannot extract attribute from empty tuple slot
Honestly, I'm not sure what the semantics of that are supposed to be. Is
it even allowed by the standard?
Regards,
Jeff
, and I
don't think we have a lot of test coverage in this area (and I didn't
see an easy way to add many tests), so this will need some review.
Regards,
Jeff Davis
rowcmp2.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
it can return amoplefttype
and amoprighttype too, but given the small number of callers, an API
change for it doesn't seem like a problem.
Sounds good to me.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
On Sat, 2011-07-02 at 18:38 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
On Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote:
Interesting problem... the bug is in get_op_btree_interpretation() which
has code like this:
...
However, that's a bogus test, because btree_gist
.
The alternatives don't seem very attractive. To get it to work with one
lookup we'd have to either clutter the btree opclasses with , or
invent a new syscache that has the AM as a key so we can filter out
non-btree opclasses.
I suppose this is another argument for type interfaces.
Regards,
Jeff Davis
http://archives.postgresql.org/pgsql-bugs/2011-06/msg00167.php
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 the documentation that could be improved, but
warnings on every page would be counterproductive.
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 Sat, 2011-06-18 at 13:20 -0700, Jeff Davis wrote:
Interesting problem... the bug is in get_op_btree_interpretation() which
has code like this:
/*
* If we can't find any opfamily
be removed at recovery time is
challenging?
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
-paramlist, and uses it in
subsequent iterations; but that isn't copied before the context is
reset. It looks like there are other things that need copying as well,
but it wasn't immediately clear to me what the best fix is.
Regards,
Jeff Davis
begin;
create table parent1( a int);
create table
have been recreated somehow.
Try to provide more detail in your bug report. See:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Thu, 2010-11-11 at 18:20 +0200, Heikki Linnakangas wrote:
On 11.11.2010 02:20, Jeff Davis wrote:
There is a problem with this patch. ReadRecord() not only modifies
global variables, it also modifies the location pointed to by record,
which is later used to set wasShutdown. How about
serious issue to me (backups could appear
unrecoverable), so please consider this before the next patch-level
release so that the bad fix doesn't go out to the world. Also, you might
want to double-check that there aren't other side effects that we're
still missing.
Regards,
Jeff Davis
.
I don't really see a bug here. Is this causing you some kind of
problem?
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
yet, but it looks like some of the following code depends on
ReadRecord(NULL,...) fetching the record right after the checkpoint
record; so I think something else is required if you want to use
ReadRecord.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
).
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, 2010-10-19 at 09:51 -0700, Jeff Davis wrote:
On Tue, 2010-10-19 at 12:26 +0300, Heikki Linnakangas wrote:
Excluding pg_xlog is just a recommendation at the moment, though, so we
would need a big warning in the docs. And some way to enforce that
just_kidding is not included
your proposed patch (i.e., check whether REDO location exists).
Either is fine with me.
Do users have any expectation that they can restore a backup without
using recovery.conf by merely having the WAL segments in pg_xlog?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list
On Mon, 2010-10-18 at 17:51 -0400, Robert Haas wrote:
On Mon, Oct 18, 2010 at 2:07 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2010-10-18 at 17:02 +0900, Fujii Masao wrote:
Yep, to automatically delete backup_label and continue recovery seems to be
dangerous. How about just emitting
On Fri, 2010-10-15 at 15:58 -0700, Jeff Davis wrote:
I don't have a fix yet, because I think it requires a little discussion.
For instance, it seems to be dangerous to assume that we're starting up
from a backup with access to the archive when it might have been a crash
of the primary system
the initial ones) before making permanent changes. It was pretty
painful trying to work backwards on this problem from the final
controldata (where checkpoint and prior checkpoint are the same, and
redo is before both), a crash, a PANIC, a backup_label.old, and not much
else.
Regards,
Jeff
will evaluate to TRUE, and the latter will evaluate to
FALSE. Enjoy.
= select ROW(1, NULL) IS NOT NULL;
?column?
--
f
(1 row)
= select NOT ROW(1, NULL) IS NULL;
?column?
--
t
(1 row)
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
sure if it's safe to do that
before DisableCatchupInterrupt().
Regards,
Jeff Davis
[1] http://www.mail-archive.com/pgsql-bugs@postgresql.org/msg00225.html
Note: I couldn't even find that in our email archive, but thanks to our
new git repo, I found the commit fix by Bruce
, and openly; even though it seemed like the
most trivial bug that I could imagine at the time.
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
smarter.
The optimizer will never be so good that it always picks the best path.
Consider a 100-table join: would it be a bug if it didn't find the
perfect join order?
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
, there are particular properties of MAX that
allow the optimization:
1. MAX(x) can be rewritten as: ORDER BY x DESC LIMIT 1
2. The MAX of set S is the MAX of the MAXes of each partition of S
The optimizer knows about the former, but not the latter.
Regards,
Jeff Davis
--
Sent via pgsql
without an obvious solution, where discussion is
required.
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, 2010-08-30 at 20:06 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
On Mon, 2010-08-30 at 19:40 -0400, Tom Lane wrote:
That's really *not* supposed to happen, assuming that both machines have
IEEE float arithmetic and competently written float I/O code.
On my machine
On Tue, 2010-08-31 at 14:13 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
On Mon, 2010-08-30 at 20:06 -0400, Tom Lane wrote:
You need extra_float_digits cranked up. Which pg_dump knows about.
I can't reproduce the problem with float4/8, but I still see a problem
be
different than the one you started with. That can cause a problem with
either UNIQUE or EXCLUDE constraints.
If you are not using floating point values, please try to make a
self-contained test case that includes data that can reproduce the
problem.
Regards,
Jeff Davis
--
Sent via pgsql
On Thu, 2010-07-22 at 23:50 -0700, Jeff Davis wrote:
I was investigating some strange page corruption today in which the page
was completely zeroed except for the LSN and TLI.
I see that this was added to the 9.0 open items list, but it affects
versions 8.3 and later.
I should have indicated
. Are there other areas where a similar
problem might exist?
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-07-22 at 23:50 -0700, Jeff Davis wrote:
I think the simple fix would be to have copy_relation_data call
PageInit() if it's a new page.
On second thought, why are PageSetLSN and PageSetTLI being called from
log_newpage(), anyway? It says that all of the callers use smgr
directly
for 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...@tao:/usr/local/pgsql
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,
Jeff Davis
---
Jeff
://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 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 pgsql-bugs
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=# select version
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 subscription:
http
,
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
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 4b0b723..e544e3e
. 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-bugs mailing list (pgsql-bugs
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 rewinds.
I don't know what you
,
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
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
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/copy.c
@@ -487,6 +487,17 @@ static int
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 mailing list (pgsql-bugs@postgresql.org)
To make changes to your
. 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
DoingCommandRead 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
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
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
not sure whether it solves your problem, but I think it provides the
most 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
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
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,
Jeff Davis
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@postgresql.org)
To make
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 about 30 minutes on CVS HEAD
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 freeing the space
?
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)
print DELETE FROM foo WHERE i %d; % (i)
print VACUUM foo;
i
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.
...
It's possible that this has something to do
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
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
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
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 works.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs
, 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,
Jeff Davis
---(end of broadcast)---
TIP 6: explain analyze
.
Regards,
Jeff Davis
---(end of broadcast)---
TIP 6: explain analyze is your friend
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
understand what's going on).
Regards,
Jeff Davis
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through
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
1 - 100 of 118 matches
Mail list logo
