: ((id IS NULL) OR (visible_for = ANY
> ('{0,1}'::integer[])))
> Total runtime: 0.464 ms
> (13 rows)
Hmm, it shouldn't be pushing the OR qual down to the base scan like that
...
Do you have an index on albums.visible_for? Experimenting here, it
seems that this fail
tgresql.org/pgsql-committers/2008-06/msg00336.php
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
replace rule redirect as on insert to foo do instead
insert into foo1 values(new.*) returning foo1.*;
ERROR: RETURNING list has too few entries
which does seem like a bug but it's not what you are describing.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
really necessary, or if
renumbering the targetlist's resnos would be enough to make RETURNING
work? I forget whether we select RETURNING elements by resno or
physical position.
Anyway, I have other things to do that strike me as higher priority.
Anyone want to tackle this one?
ust be set--see zic
manual" where the timezone should be? Are you intentionally selecting
the "Factory" zone?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ugh to make you set
the zone correctly ;-)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ing an strace on this process shows that it is trying to write 8K of
> zeros to a file called 023D in pg_clog but fails at 224K and it just keeps
> trying forever.
What PG version is this, exactly? What files did you delete (any of
Postgres' files)?
regards, t
we do not claim support for feature F641.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Pv4-only functionality, I think the inet4 type on
pgfoundry has this behavior already.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Valentin Bogdanov <[EMAIL PROTECTED]> writes:
>> What PG version is this, exactly? What files did you
>> delete (any of Postgres' files)?
> It's 8.1 and no I didn't delete any postgres files, just some old proxy logs.
8.1.what?
regard
Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes:
> On 01.07.2008 16:32, Tom Lane wrote:
>> This is not a bug, since we do not claim support for feature F641.
> Thanks for the information. Is there any plan to support that feature in
> 8.4?
I don't know of anyone w
re's any plan change involved here. What I
think is happening is that the first row is being selected as the
quicksort pivot item.)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ay in CVS HEAD ... not sure if a small back-port is possible,
though.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
mingly not so hard to fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
l in the RESTRICT case when there were dependencies between objects
owned by different users.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Actually, on looking closer, the problem is that recursiveDeletion fails
>> to pass alreadyDeleted down to (and through) deleteDependentObjects.
> Hmm, in this case I wonder if this could show up in othe
aram/parParam signaling. Not sure
yet if it's a planner or executor bug, but more likely the former.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ent in subselect.c). I'm surprised we've
not seen reports of it before.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
itance state just to cover this.)
> According to the documentation, this should not be the case.
Please state where you think the documentation says that, so we
can fix it.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make cha
ment to have any
chance of working. In general, I think this has zero chance of working
without implementing a pretty complete XPath parser. We need to find
another way.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
statements and watch the postmaster
log). See if you can put together a self-contained script that causes
the crash. That will let us fix the problem, and it might let you find
a workaround to reload your data even in advance of a real fix.
regards, tom lane
--
Sent via p
bles involve non-built-in
datatypes? An out-of-date .so file for an add-on datatype could easily
lead to crashes in these operations.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
=?iso-8859-2?q?Micha=B3_Szel=B1g?= <[EMAIL PROTECTED]> writes:
> Dnia poniedzia³ek, 14 lipca 2008, Tom Lane napisa³:
>> You still haven't given anywhere near enough information to identify the
>> bug. I wonder though if any of these tables involve non-built-in
>>
ior is not a bug, it is
the expected behavior of any program using a network connection.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
is, please put together a self-contained
test case. Assuming it's real, perhaps a simple custom script for
pgbench would serve to show the problem.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
s not
>> get blocked for ~15 minutes.
> Absent threads I think you have to use alarm() and a SIGALRM signal handler.
On most modern platforms you can adjust the TCP timeouts for the
connection. There's no explicit support for that in libpq, but
you can just get the socket FD from
ute the below query
> "select * from myTable where somedate = '2008-07-18'"
> I only get 145 rows back from the database.
Is there an index on somedate, and if so does reindexing it help?
regards, tom lane
--
Sent via pgsql-bugs mailing li
Looking at the code, apostrophe seems to be allowed as the first
character of the REPL field, but not anywhere else (in particular,
not after transitioning into PAE_INREPL state). Dunno if this is
a bug or intentional.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
nf function reads
> until it finds a blank space, tab or new line, so if the string contains any
> blank space after the last ':' everything else is ignored!
Fixed, thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bug
ct * from foo;
f1 | b
+---
1 | t
2 | t
(2 rows)
Please provide a concrete test case to demonstrate what you are seeing.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
h postgresql
> 8.0. It complains that the table test does not exist!
I get the same complaint in both versions; which I find unsurprising
because the whole querystring is parsed and planned before execution
begins.
regards, tom lane
--
Sent via pgsql-bugs mailing list
can actually reproduce this
problem, please show an exact test case, not hand-waving.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.conf?
AFAIK there is no such thing as a "Bonjour connection"; Bonjour just
provides a means for the server to advertise its IP address. I
speculate that what it's advertising is a port that you have configured
to be trusted.
regards, tom lane
--
Sent
27;d suggest
enabling log_connections so you can see what address the connections
are actually coming in on.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ttp://archives.postgresql.org/pgsql-bugs/2008-06/msg00110.php
It's fixed in CVS but we haven't made a new release yet.
If you need the patch right away, see
http://archives.postgresql.org/pgsql-committers/2008-06/msg00226.php
regards, tom lane
--
Sent via pgsq
g, and/or put some debug logging into
cost_sort to see what it's passing to log(), and see what you can learn.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
I speculate that your scripting language is losing the
embedded double-quotes somewhere before psql gets them. I don't know
much about Windows scripting so it's hard to say more than that; but
an extra interpretation pass over the command string would probably
cause such a problem.
nt
locale setting, probably "C". Unfortunately, that requires dump,
re-initdb with the correct locale option, reload :-(
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
adjust your list of trusted
CAs to determine whether you'll accept it or not.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
re's really little reason
> otherwise for the call to exist.
Er, we don't *have* a verify_peer callback.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ase
that no one has noticed in many years might be counterproductive.
Thoughts?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
from outside don't even know it exists,
Say again? Both the SCROLL option to DECLARE CURSOR and FETCH PRIOR are
straight out of the SQL92 spec.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
h
not only complicate ExecUnique but back-patch the result
clear back to 7.4. I'm not even sure how to fix it (the nasty case
is changing directions partway through the scan); let alone how to
fix it in a way that's obviously enough right to make me feel
comfortable in back-patching.
cause '=' is not part of the
varchar_pattern_ops operator class.
(Things will be better in 8.4, but it's not possible to fix it in
existing release branches.)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> ... I'm not even sure how to fix it (the nasty case is
>> changing directions partway through the scan); let alone how to fix it in a
>> way that's obviousl
-locale=C" might be what you want.)
For comparison's sake, I get this on a modern Linux system:
$ cat testdata
Ta, A
Ta, Z
Tab, A
$ LANG=C sort testdata
Ta, A
Ta, Z
Tab, A
$ LANG=en_US sort testdata
Ta, A
Tab, A
Ta, Z
regards, tom lane
--
Sent via pgsql-b
t;
8.2.what?
If it's pre-8.2.5, I'd venture that the archive file has been truncated
and you're seeing a variant of this problem:
http://archives.postgresql.org/pgsql-patches/2007-08/msg00059.php
regards, tom lane
--
Sent via pgsql-bugs mailing lis
where specifying a different location
wouldn't be broken?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Well, if you think it's easy, the best form of criticism is a patch.
>> The change-of-direction problem seems to me to be messy --- not
>> insoluble, but messy
n the logic that manages REINDEX applied to
pg_class itself. There's a mighty delicate dance that goes on there,
and we haven't tested it too much lately.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to yo
t now. I'm sure this is related to the
fancy dance we do for pg_class reindexing, but not sure yet where
to fix it.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Gregory Stark <[EMAIL PROTECTED]> writes:
> Uhm. Is it possible we're mistakenly doing a HOT update because we're lying
> about what indexes exist?
Yup, exactly. Here's my proposed fix...
regards, tom lane
Index:
u can't rely on a default TS configuration when using the
functional-index approach to text searching, because of the restriction
that index contents can't depend on mutable state.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
7;);
sid | name | rollup_time | count_rows | avg_value
-+--+-++---
(0 rows)
It's possible that I'm missing the failure for lack of suitable test
data, but right offhand I'd bet that the problem is that there are
dropped columns in your copy
ything in the subquery rtable, not just what was
referenced?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
#x27;s a bit beyond my threshold of ugliness...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think it might be better to fix the problem in
>> pull_up_union_leaf_queries instead; given that it wasn't broken till
>> recently, I think it's arguably t
ding was guaranteed to visit only subquery-type RTEs
but I'm much less convinced about this one. It might
be better to say
if (rte->rtekind == RTE_SUBQUERY)
IncrementVarSublevelsUp(...);
Or maybe it's okay; I'm too lazy to recheck the representation of
UNI
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm, the "Assert(rte->subquery != NULL)" doesn't seem right ...
>> couldn't there be non-RTE_SUBQUERY rtes in the child?
> Oh, indeed it's not okay. The original
hat would be 11 if they included
a null terminator, but we don't require that.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
walker
directly as you have here.
Looks good except IncrementVarSublevelsUp_rtable really ought to have
a comment. Please fix that, commit, and backpatch as needed.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
xid(text) AS
IMPLICIT;
CREATE CAST
regression=# select cast (text 'blabla' as pxgt_xid);
pxgt_xid
-------
(,blabla)
(1 row)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Er, we don't *have* a verify_peer callback.
>>
>> Uh, the user reported running Postgres 7.3 and we have improved SSL
>> quite a bit since then so perhaps an upgrade and reading the curr
At least the basic checks (expiration, chaining back to a valid root)
> occur?
[ shrug... ] We do whatever OpenSSL's default validation behavior is.
If that's inadequate you probably ought to be taking it up with them,
instead of trying to get downstream projects to fix it one at a time
requirement, we'd have to forbid naming the server
by IP address or via a domain-search-path abbreviation.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ms a bit large/invasive/new-feature-ish for a backpatch.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
archives from around then
to see why this was considered a good idea.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think the commit you're looking for is this one:
>> 2002-09-26 00:41 momjian
> No, that's not the one. It's the one after that one, at:
No, that one is just fallout from having removed t
for thread-safety and Windows-portability issues ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
"didn't work
according to Peter", but I can't find anything in Sept 2002
pgsql-hackers suggesting exactly what was wrong.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
behavior on Fedora 9, but not on HPUX. Investigation shows
that F9's strtod returns EDOM not ERANGE for this case. Seems like a
glibc bug ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
tring back out for the
client, and the worst would be one of those recursive encoding-error-
during-error-reporting crashes.
I think the short answer is that the OP needs to fix his client code to
not generate queries that are illegally encoded according to what he has
set client_encoding to be
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is there any TODO here?
It's clearly broken, if that's what you mean. I don't know enough XPath
to speculate about an appropriate fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
ldn't it?
[ you just made me spill coffee all over my keyboard... ] It's never
a good idea to use "Windows" and "robust" in the same sentence.
Try googling for "windows duplicate guids" and similar phrases.
I get 226000 hits on that one.
That assumption is false, so it's not entirely clear to me exactly what
you are complaining about. Please provide a specific test case --- what
did you do, what happened, what would you like to happen instead?
regards, tom lane
--
Sent via pgsql-bugs mailing list
"Daniel Migowski" <[EMAIL PROTECTED]> writes:
> The option documentation misses the fact that you can produce gzipped output
> files with text format.
Huh, so you can. I wonder if anyone but Philip Warner ever knew that.
Docs updated ...
regards,
t bother me. It's mostly accidental that there are any
variants that do work, I think. Why would you want a SRF in a sort key?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
the whole, since "public" is a quasi-built-in object, it doesn't seem
like a very good idea to depend on being able to alter its properties.
Why not attach your version comment to some other, entirely user-defined
object? "CREATE SCHEMA version" perhaps ...
Jeff Davis <[EMAIL PROTECTED]> writes:
> On Mon, 2008-08-25 at 22:26 -0400, Tom Lane wrote:
>> ... It's mostly accidental that there are any
>> variants that do work, I think. Why would you want a SRF in a sort key?
> The following line was added to the regressio
he same
> values against PG 8.3.3 as well.but now this vaule is inserted
> successfully.I was thinking is this expected ,or was broken in PG 8.2 ?
It's not particularly surprising; we now allow denormalized numbers if
the platform supports them.
regards, tom lan
but not
>> a computer in the general case.
> How is that different from any other syntax error?
It's not a syntax error, it's an encoding error, and we daren't try to
spit the data back out for fear of getting more encoding errors and
ending up in an infinite recursion in elo
aybe it's been masked for common uses.
I'm not entirely sure if we should add SRF support to Agg/Group or just
write it off as being a deprecated feature anyhow. Given the
definitional issues involved with multiple SRFs in the same targetlist,
putting more effort into the feature doesn&
meantime, why aren't you just using clock_timestamp()?
timeofday() is deprecated.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It sounds like a mind-numbingly tedious task though :-(
> Added to TODO:
> {{TodoItemEasy
> |Revise the src/timezone/tznames abbreviation files:
BTW, it just occurred to me to wonder whether we couldn't
s been set
in one way or another.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
see what else is on that page first. Check the PG archives for
discussions of recovering from corrupted-data scenarios.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
lot of other things that likely would break first,
though, so that doesn't seem very probable.
Is this transaction longer than any comparable one you ever did before?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes t
Michael Milligan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Huh, that shouldn't happen. What object is that? The 16385 should be
>> a database OID, and the 16467 is most likely a table's OID within that
>> database.
Please answer the above question.
Michael Milligan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Once you've determined which table the error message is talking about,
>> please show us what the transaction does with that table.
> You mean like:
> BEGIN;
> PREPARE msg (...) INSERT INT
urce.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ink that's just a hack. A cleaner fix would be to teach
exec_move_row to present the correct column type in all cases.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
dropped columns
in the right places. I think we'd consider adding such functionality
as a new feature not a back-patchable bug fix.
The best near-term workaround would be to handle changes like this by
means of ALTER COLUMN TYPE rather than dropping and re-adding columns.
oduce that here, at least not with versions newer than
8.0. Maybe you were testing a case that also involved dropped columns?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
/msg00241.php
I believe this is something that's fixed as of 8.2.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
, it'd behoove us to do something
about that in 8.4 or beyond.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t is that you've overlooked a trigger someplace...)
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
refix=/Users/rleitgeb/pq_x86_64
I don't think it's really as "easy" as all that with the 8.3 source tree.
This might possibly work with CVS HEAD due to recent changes in our
build process, but I'll bet that you simply aren't getting fully 64-bit
executables this way in
pty database. A "pg_dump -s" script is usually
a good starting place for making that.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
d 8.3.
I see no crash as described, and there are no unexpected compile warnings
either. So I now concur with Euler's theory that there's something
broken about your copy of libedit. (One possibility is that you're not
using Apple's libedit, but a locally installed copy of lib
hem
as soon as they're deleted, which seems a pretty odd choice.
regards, tom lane
--
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 7582 matches
Mail list logo
