a long way from 8.17.2 to 8.17.10. It might be better
> if this section were recast to use a standalone example --- Jeff, what do
> you think?
That sounds reasonable, patch attached. Minor change, so if nobody has
any more suggestions I'll commit it tomorrow night.
Regards,
> $PGDATA/pg_xlog.
Either 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
in 8.3.8, but it is in 8.3.9.
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
d, perhaps the error message should be improved? I'm not
sure what it should say 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
resolutio
er to write range_parse() such that whitespace is included
> within tokens:
There was some discussion about it, and the decision was made to match
record literal parsing for the sake of consistency. In a record literal,
spaces are considered to be a part of the value, so they are for range
types
ot simply
> forbid all forms of ALTER on nonlocal temp rels, right up at the top.
Do you see any path where an ALTER can get 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
--
Sen
an we just use isTempOrToastNamespace
within RELATION_IS_OTHER_TEMP?
#define RELATION_IS_OTHER_TEMP(relation) \
((relation)->rd_rel->relpersistence == RELPERSISTENCE_TEMP \
&& !isTempOrToastNamespace((relation)->rd_rel->relnamespace))
(I haven't analyzed the a
I couldn't 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
On Mon, 2012-12-10 at 20:27 -0500, Tom Lane wrote:
> Jeff Davis 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 lowe
two, so we can redefine my_log2 to require 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
But it assumed that init_htab could deal with INT_MAX. 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
ink of (aside from
dropping the separate TRIGGER 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 subscr
own the table?
My guess is that it's to prevent someone from 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
ainly not rely 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
th
> failure.
Or a lack of failure, I 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 m
predicate. In order to
do that, you need to use an exclusion constraint:
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) defer
On Thu, 2012-09-13 at 12:39 -0400, Robert Haas wrote:
> On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis 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&#
ec6df9d4, because that bug 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
ce set.
One 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 l
constraint, null values are not considered
equal."
-- http://www.postgresql.org/docs/9.2/static/sql-createtable.html
NULLs can be confusing, I know.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your su
context is passed 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
If you'd like private, personalized 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
idea:
http://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 pgsq
$ cat /tmp/a.copy
1
\0
COPY TO seems to follow the documentation, inserting 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 o
On Sat, 2012-03-24 at 19:07 -0400, Tom Lane wrote:
> Jeff Davis 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 be
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 shou
rely we don't want it to be set from 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
On Thu, 2012-01-26 at 20:43 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > => select ntile(3) OVER ( ORDER BY CASE WHEN count(i) = 0 THEN NULL ELSE
> > count(i) END asc ) from ( SELECT NULL::integer as i limit 0 ) s ;
> > ERROR: cannot extract attribute from empty tuple
key item to
sort"), but it's fixed sometime later in the 9.1 series.
If you get rid of the CASE statement, then it still fails in 8.4 and
9.0, but it succeeds in 9.1.0 and beyond.
Regards,
Jeff Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To ma
t 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@postgr
a bug", though it appears to work in 8.3.
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
e of those 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
row. That seems 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 s
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,
terpretation() so 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
e complex, 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
On Sat, 2011-07-02 at 18:38 -0400, Tom Lane wrote:
> Jeff Davis 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:
> >> ...
> >> How
pclasses.
I suppose this is another argument for type interfaces.
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
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
ll.
PostgreSQL is a SQL DBMS, and in SQL, NULL affects everything. I'm sure
there are places 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&#
s worth the
bookkeeping effort though.
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
mining which files should 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
broot.glob->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
y "reset", I do not mean "overflow". I mean that the
sequence might 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 (p
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
he backup, and you'll get a PANIC.
This seems like a pretty 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 ar
istent to raise syntax errors in all these
> cases.
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
inology issue, however).
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
kpoint. I haven't tested your
patch 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 p
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_ki
y entry and then silently ignores the fact that it
couldn't copy the contents. Another concern is: what if they are using
some kind of filesystem mirroring tool that doesn't take consistent
snapshots (do such tools exist?)? Are there other system-level tools
that people might be using th
On Mon, 2010-10-18 at 17:51 -0400, Robert Haas wrote:
> On Mon, Oct 18, 2010 at 2:07 PM, Jeff Davis 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 abou
> simpler than 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-bu
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 cra
nt 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 Davis
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
x is ROW(1,NULL),
then the former 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
--
nestly, 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
ecause I wasn't 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
hackers
is better for problems 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
can't be planned this way, 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,
a feature
to make the optimizer 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@pos
On Tue, 2010-08-31 at 14:13 -0400, Tom Lane wrote:
> Jeff Davis 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
On Mon, 2010-08-30 at 20:06 -0400, Tom Lane wrote:
> Jeff Davis 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
t4)) =
(1::numeric + 1e-7::numeric)::float4;
?column?
--
f
(1 row)
> My own WAG is that we're talking about a GiST bug that causes it to
> recognize or not recognize duplicates depending on order of insertion.
> But that's theorizing far in advance of the data.
Seems
g-point value, and then reload it, it may 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.
R
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 sh
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 sm
_data call
PageInit() if it's a new page. 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
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...@
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,
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 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
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 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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
(x tsvector, y pg_catalog.tsvector) RETURNS integer
LANGUAGE sql
AS $$ select 1; $$;
It seems like pg_dump tries fairly hard to make the output readable in
the typical case. It does seem a little inconsistent that the list of
types that make up another type don't follow the exact same
a-qualify it".
Have you considered working from the "custom" format rather than text?
I'm 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
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 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
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
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
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
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 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
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)
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
1 - 100 of 128 matches
Mail list logo
