to estimate with inadequate stats.
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
Andres Freund and...@anarazel.de writes:
On Thursday, January 12, 2012 01:01:01 AM Tom Lane wrote:
Looks pretty bogus to me. You're essentially assuming that the side of
the join without statistics is unique, which is a mighty dubious
assumption.
It sure is a bit dubious. But assuming
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
-8601
convention that positive timezone offsets are east of Greenwich.
This is not a bug, or at least not our bug --- we're just doing the best
we can to cope with inconsistent standards documents.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
Martin Pitt mp...@debian.org writes:
Tom Lane [2011-12-21 10:55 -0500]:
For the moment I'm inclined to consider using these functions *only* on
ARM, so as to limit our exposure to such bugs. That would also limit
the risk of using an inappropriate choice of lock width.
OK, fair enough. New
be pgtypes_date.h
Fixed, thanks for the report!
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
--
{,:,//,blahblah.com,/}
although I cannot tell whether that generalizes to your real 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
in a hurry
the patch is here:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=6cf639dfbddbc44d027730ad1504886312bc905a
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
it by keeping a separate private
copy of the dest pointer. However, it would also be fair to ask whether
there's not a cleaner solution. Perhaps the intoRel stuff should be
saving/restoring the original destreceiver instead of just blindly
overwriting it.
regards, tom lane
--
Sent
I wrote:
Perhaps the intoRel stuff should be
saving/restoring the original destreceiver instead of just blindly
overwriting it.
I concluded that was the best fix, and have committed it.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
not sure how much there is to be done about that case, since
there's probably no good way to distinguish it from a query that
takes a really long time. But if we're going to think about this,
we might as well think about all the cases.
regards, tom lane
--
Sent via pgsql-bugs
for asserting we don't support CIFS in
general? It's probably not terribly bulletproof, but any worse than NFS?
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 mag...@hagander.net writes:
On Mon, Jan 2, 2012 at 21:14, Tom Lane t...@sss.pgh.pa.us wrote:
I'm wondering what's your basis for asserting we don't support CIFS in
general? It's probably not terribly bulletproof, but any worse than NFS?
Yes, it is a lot worse than NFS from
Magnus Hagander mag...@hagander.net writes:
On Mon, Jan 2, 2012 at 21:28, Tom Lane t...@sss.pgh.pa.us wrote:
it seems like EINVAL is a considerably more reasonable thing to return
than EBADF, if the filesystem is trying to tell you that it won't fsync
a directory. So I'm a bit surprised
moments 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
.
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
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Dec 29, 2011 at 2:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I see no memory leak with this example.
This is by the way a FAQ:
http://wiki.postgresql.org/wiki/FAQ#Why_does_PostgreSQL_use_so_much_memory.3F
Well, to be fair, the FAQ entry didn't
. (Speaking of which, does that box have ECC memory?)
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
tracy.ander...@teamquest.com writes:
Intermixed slashes caused Backup Exec to fail.
That sounds like Symantec's bug, not ours.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
rewind and rescan the cursor (ie, MOVE BACKWARD ALL and re-fetch),
the function would be executed multiple times too. If you don't want
that to happen, the best way would be to commit the transaction
immediately, not fetch some rows and then commit.
regards, tom lane
calculation steps as-is, whereas
NaN might have less predictable behavior.
There was also some support for throwing an error in the previous
thread, though I can't say I like that answer myself.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
issue a
DROP against its database (or table, for that matter).
If there's a bug here, you've not explained what it is.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
things depending on usage regarding this
methodology).
The PostgreSQL project doesn't have any direct control over Red Hat's
spec files, although Tom Lane, a PostgreSQL core team member, also
works at Red Hat. I would suggest that you take this up with Red Hat
directly
the possibility of exclusion constraints naming the same column
more than once, which may explain why nobody tried using such an
index for queries. I'll see about fixing this in HEAD, although
my initial guess is that it will be too invasive to back-patch.
regards, tom lane
some very old versions of selinux policy would sometimes
block postgres log messages, for example. If you've got selinux enabled
it'd be worth checking for avc messages in the kernel logs.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
Martin Pitt mp...@debian.org writes:
Tom Lane [2011-12-20 21:14 -0500]:
Another thing that is bothering me is that according to the gcc
manual, eg here,
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
__sync_lock_test_and_set is nominally provided for datatypes 1, 2,
4, or 8
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
m...@msys.ch writes:
A role can be deleted although it is still referenced in a column privilege.
Hmm, it looks like ALTER TABLE OWNER forgets to update the grantors in
column privileges. Table privileges are processed properly, but not
columns.
regards, tom lane
? libpq
clearly thinks it's waiting for a message from the server, but I wonder
what the server thinks. Also, what connection status does netstat
show on each side?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
queue? Surely
the kernel should be reporting that the socket is read-ready, if it's
got some data. I think you've found an obscure kernel bug somehow
it's failing to wake the poll() caller.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
it missed this
comment.
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
in your trigger logic.
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
, resulting in catastrophic degradation of the generated
plans, such that they took a lot longer than you were accustomed to
(they shouldn't have been hung though).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
/boost/ticket/2525
Google is also finding some rather worrisome suggestions that
__sync_lock_test_and_set might involve a kernel call on some flavors of
ARM. That would be pretty disastrous from a performance standpoint.
regards, tom lane
--
Sent via pgsql-bugs mailing
our Itanium (and possibly ARM, too) implementation
of S_UNLOCK() is wrong as it is.
Hmm. Anybody got a large itanium box we could play with? If it is
wrong, I'd expect it would show up pretty quickly under pgbench or
similar.
regards, tom lane
--
Sent via pgsql-bugs
that this applies to Itanium, because I don't see
any memory fence instruction in the TAS macro. If we needed one in
S_UNLOCK I'd rather expect there to be one in TAS as well.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
this.
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
of constraint whatsoever on aas is going
to end up with the crummy plan where the whole lower join gets computed.
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
in your timezone, then
this behavior is neither surprising nor a 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
)::text 'DEPLOZ'::text))
Filter: ((discriminator)::text ~~ 'DEPLOY%'::text)
(4 rows)
count
---
500
(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
this on, exactly? I tried it on Fedora 14.
What are the values of relevant locale-type env vars when you ran initdb on
your test sys?
Shrug ... C. That's my normal working environment. I did try it with
en_US.utf8 too, just for grins.
regards, tom lane
--
Sent via pgsql
and LC_CTYPE set to C? I am not sure that createdb pays
attention to those as locale settings.
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
evidently isn't, even if it calls itself an ARM.
It's also possible that his target processor actually can do swpb, but
he needs to use some other gcc flags to persuade gcc of that.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
functions than strictly necessary but I guess thats ok.
Seems like the correct fix is to revert these functions to the former
behavior, ie they should be using the PP macros not the unpacking ones.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
collation to use for string comparison
HINT: Use the COLLATE clause to set the collation explicitly.
FWIW, I tried to replicate this on the basis of the limited information
you gave, and could not. Can you provide a self-contained test case?
regards, tom lane
--
Sent via
it on
PostgreSQL 9.0.5 on x86_64-unknown-linux-gnu, compiled by GCC gcc
(GCC) 4.1.2 20080704 (Red Hat 4.1.2-50), 64-bit
Yeah, this is fixed as of 9.0.5:
http://git.postgresql.org/gitweb/?p=postgresql.gita=commitdiffh=bbfcc7149
regards, tom lane
--
Sent via pgsql-bugs mailing list
.
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
this by hacking the ts parser so that it would
also apply the hyphenated-word rules to a hostname containing a dash.
In general though, there are always going to be cases where prefix
match doesn't work because of dictionary transformations ...
regards, tom lane
--
Sent via
Jeff Davis pg...@j-davis.com writes:
On Wed, Nov 30, 2011 at 5:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The result of parse analysis for that query is a stored date constant
(in a Const node) with a cast-to-text on top of it. The system is aware
that cast-date-to-text isn't immutable, so
maxim.bo...@gmail.com writes:
SELECT ARRAY(SELECT ...)
doesn't work when subselect return any array.
Is that syntax supposed to work with anyarray types?
No.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
* we will emit a parameterless CREATE LANGUAGE command, which will
* require PL template knowledge in the backend to reload.)
*/
An actual add-on procedural language would not fall foul of this.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
not going to change it in 8.3.x 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
be something
broken about your VM environment. Can you reproduce it outside the VM,
or even better create a reproducible test case?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
. You should reread the manual's discussion of
LIKE:
http://www.postgresql.org/docs/8.4/static/functions-matching.html
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
to make that a bit more
obvious.
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
:2008 doesn't actually require anything
beyond a simple integer constant here.
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 rolled back.
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
interpreted differently.
You could argue it either way 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.
regards, tom lane
?
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
Josh Kupershmidt schmi...@gmail.com writes:
On Wed, Nov 30, 2011 at 9:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Can you try that on 9.1 branch tip to see if it's already fixed?
Hrm, don't think that helped - I get the same error in the logs using
a checkout of branch REL9_1_STABLE.
Well
in
pg_dump. Usually we prefer to retrieve names from the server as-is,
then apply fmtId() when printing them --- this is more flexible than
having possibly-pre-quoted names in pg_dump's internal state.
Will fix it the latter way. Thanks for the report!
regards, tom lane
Ronan Dunklau rdunk...@gmail.com writes:
How will this bug be handled with regards to releases ?
It'll be fixed in next week's releases.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
at outermost recursion level.)
So the problem seems to be only due to your ALTER EXTENSION DROP command
having left an incomplete set of extension dependencies behind.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
some dangling entries in pg_depend --- manually
deleting any rows that reference the missing pg_extension OID should 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
/gitweb/?p=postgresql.git;a=commitdiff;h=871dd024a6adf7766702b1cdacfb02bd8002d2bb
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
refused it.
LOG: unexpected EOF on client 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
Maxim Boguk maxim.bo...@gmail.com writes:
Is that fix will be included to the next minor versions releases?
Yes, it's in already:
http://git.postgresql.org/gitweb/?p=postgresql.git
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
Sidar Lopez sidar.lo...@gmail.com writes:
Operating system: Mac OS X
Description:Startup Script
Log file is not being created at ${PGLOG} location.
Hmm, yeah, that's overly-quoted. Will fix, thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs
functions that were mutually dependent in that way? And actually did
something useful (not recurse till stack overflow) when called?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
, an argument is considered terminated
only by unquoted whitespace or backslash.
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
stable branch. It seemed like enough of a
behavioral change to be too risky to put into minor releases.
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
lindebg lind...@gmail.com writes:
On 11/19/2011 04:34 AM, Tom Lane wrote:
Color me skeptical. Under what conceivable use-case could you have
functions that were mutually dependent in that way? And actually did
something useful (not recurse till stack overflow) when called?
Does this mean
anybody suggested raising the log_min_messages setting?
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
of update releases, or if you're in a big
hurry you can get the patch here:
http://archives.postgresql.org/pgsql-committers/2011-10/msg7.php
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
with something else yields null. You might possibly want to spell
the above as SET comment = '...' || coalesce(comment, null) ..., if you
want to pretend that a null is the same thing as an empty string.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
I wrote:
You might possibly want to spell
the above as SET comment = '...' || coalesce(comment, null) ...
Sheesh. coalesce(comment, '') of course. Need more caffeine.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
) TO stdout;
The least painful solution might be to always quote *every* identifier
in commands sent to the source server, since we don't especially care
how nice-looking those are.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
to reproduce this here, and a look at the code responsible for
xid epoch maintenance reveals no obvious way that it could have been
bypassed. So there's some fairly critical piece of context that you're
not telling us ...
regards, tom lane
--
Sent via pgsql-bugs mailing
Peter Eisentraut pete...@gmx.net writes:
On tor, 2011-11-10 at 19:30 -0500, Tom Lane wrote:
I think psql only pays attention to its locale when stdout is a tty.
Now *why* it acts like that, I'll leave for Peter to defend.
We would have to review the original discussion about that. I can see
Maksym Boguk maxim.bo...@gmail.com writes:
Description:Is ALTER ROLE set client_encoding broken in 9.1?
No, but I think psql prefers to set its encoding according to its locale
enviroment these days.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql
' | head -10
client_encoding
-
KOI8R
(1 row)
I think psql only pays attention to its locale when stdout is a tty.
Now *why* it acts like that, I'll leave for Peter to defend.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 3, 2011 at 5:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We probably ought to have something in there to throw an error ...
Probably not for rules in general, but we shouldn't let people turn
tables into views if they are involved in table
/libodbcpsqlS.so
FileUsage = 1
Depending on which build of postgresql-odbc you're using, the driver
library file might be named psqlodbcw.so instead; but in any case
libodbcpsql.so is not something to trust.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
would guess that you are using an old JDBC driver that
isn't prepared for standard_conforming_strings to be turned on.
If that isn't it, I'd suggest asking for help on the pgsql-jdbc mailing
list; I'm not sure how many of those guys read pgsql-bugs.
regards, tom lane
for it to be.
We probably ought to have something in there to throw an error ...
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
). So either my analysis was wrong at the time,
or some later change has eliminated the need for two flags, or the
regression tests aren't covering the problematic case. Will investigate
further once I've absorbed some caffeine.
regards, tom lane
--
Sent via pgsql-bugs
of pessimizing normal cases.
A patch along these lines should be pretty localized. Has anyone
got an opinion on whether to back-patch or not? This seems like a
performance bug, but given the lack of prior complaints, maybe we
shouldn't take any risks for it.
regards, tom lane
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 31, 2011 at 12:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
A patch along these lines should be pretty localized. Has anyone
got an opinion on whether to back-patch or not? This seems like a
performance bug, but given the lack of prior
.
But adminpack.sql is not found.
It's called adminpack--1.0.sql these days, and is installed using a
different command than your version of pgAdmin is probably trying
to use.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
. AFAICT there are no such
locales anyway, other than POSIX for which we definitely don't want to
believe the empty-string setting.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
of locales where the decimal point isn't a single byte?
I'm wondering if that assumption needs to be got rid of too.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Robert Haas robertmh...@gmail.com writes:
On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Noah Misch n...@leadboat.com writes:
I think we should merge #3 into #2; nothing about the REPLICATION setting
justifies a distinct paradigm.
Yeah, there's much to be said
(and yes, it's a kluge) is that
it supposes that you migrated EVERY local service to the other machine.
Which, obviously, you did not.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
the local machine; there are Internet standards
saying so. On the other hand, client applications that assume the
database server is on the same machine they are on are definitely
broken, and need to be fixed.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs
while searching the RFC archives.)
And, given that we've been doing it this way since 2001 without
previous complaints, the number of systems that fail to do it
must be pretty small.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
hasn't been out for very long, so maybe expectations aren't
too settled yet, but changing security-critical behavior in back
branches doesn't seem like a wonderful idea; and I think I mildly
prefer the current semantics to the proposed ones.
+1
regards, tom lane
of later computer-oriented
standards. But it's wrong, no matter how many places say that. Ask an
astronomer rather than a computer scientist, if you're not convinced.
/pedantry
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
bogus to start with.
rolcatupdate isn't a very good precedent to rely on because it's never
been documented or used to any noticeable extent, so there's no reason
to think that it provides a tested-and-accepted behavior.
regards, tom lane
--
Sent via pgsql-bugs mailing
: The database uses plpython and postgis.
Hmm, did you change postgis versions at the same time? If so, which
upgrade caused the problem, postgres or postgis?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
Maksym Boguk maxim.bo...@gmail.com writes:
Somehow pg_database_size producing results which are 2Ñ
more then reality.
I can't reproduce any such problem here. I suspect you overlooked some
tablespaces in your manual du commands.
regards, tom lane
--
Sent via pgsql
701 - 800 of 6572 matches
Mail list logo
