lined to say "no", but could be
> RH> persuaded otherwise.)
>
> +1 for this. Pre-7.3 syntax is dead in fact for many years.
...this is not something we're going to back-patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Jul 5, 2011 at 11:30 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 5, 2011 at 11:06 AM, Alvaro Herrera
>> wrote:
>>> I assume it's not in unreserved_keyword because it would cause a
>>> shift/reduce conflict elsewhere.
>
>> Yeah
it would cause a
> shift/reduce conflict elsewhere.
Yeah. In particular, it conflicts with the ancient copy syntax which
we still support for backwards compatibility with versions < 7.3. We
can fix the immediate problem with something like the attached.
(a) Should we do that?
(b) Should we
ying from a separate file.
>
> The attached patch seems like an appropriate fix. However, I'm unsure
> whether to apply it to released branches ... does anyone think this
> might break somebody's application?
I think this is pretty safe.
--
Robert Haas
EnterpriseDB: http:
by
> syslogd.
You can recompile with -DPG_SYSLOG_LIMIT=.
We could add a configuration setting for this, if it's affecting a lot
of people.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
in higher version of postgresql?
> please give better comments
> thanks in adavance
Data from older versions of PostgreSQL can generally be restored to
newer versions just fine. But it's not really clear what problem you
are having here, so it's hard to provide any more h
2011/6/16 Luiz K. Matsumura :
> Em 16/06/2011 16:39, Robert Haas escreveu:
>
> 2011/6/10 Luiz K. Matsumura :
>
> I need help to know if the follow scenario is a expected behaviour, a bug of
> postgres or a bug of slony:
>
> Postgres v8.4.8
> Slony-I v 2.0.5
>
> I
mes in french?)
>
> I use pgAdmin Version 1.12.2 rev: REL-1-12-2
You might want to ask about this on pgadmin-support. I'm guessing
there is an encoding setting wrong somewhere, but as a non-user of
pgAdmin I'm not sure where to look for it.
--
Robert Haas
EnterpriseDB: http://w
would say something like "you don't have package X installed (as
judged by the fact that I couldn't compile with #include )".
But it doesn't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
r ODBC Administrator stopped working.
> The same client with the same pSQLODBC 9.03 but 32 bits works fine.
I haven't seen a reply to this bug report; you may want to try the
psql-odbc mailing list.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL C
ion to use for lower() function
> HINT: Use the COLLATE clause to set the collation explicitly.
I don't see a reply to this bug report, but I believe Tom fixed it in beta2.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
int "t3_t1_id_fkey"
> DETAIL: Key (t1_id)=(1) is not present in table "t1".
>
>
> BUT
> SELECT t1_id FROM t1 WHERE t1_id = 1;
> -->1
When you use a foreign key with inheritance, only the rows that are
actually in the parent table itself are consid
e2 is not replicated why they triggers dont fire even
> by a update command in
> a trigger of a replicated table ?
I'm confused. If you enable the trigger on table2, it's going to fire
when someone updates table2. Whether or not the update is coming from
another tr
; It was in SQL 92, but removed in 99, so it's technically no longer part
> of the standard.
It's still extremely widely used though, I think, and very useful. I
don't feel we have to support GROUP BY 1 COLLATE whatever, but it
might be worth the trouble to at least emit a decent HINT
On Tue, Jun 7, 2011 at 6:06 PM, Robert Haas wrote:
>> But for the planner, why not just put the same kind of test in
>> get_relation_info, just after it does heap_open?
>
> OK, let me try that.
Seems to work beautifully, so committed that way.
--
Robert Haas
On Tue, Jun 7, 2011 at 5:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 7, 2011 at 3:53 PM, Tom Lane wrote:
>>> It might be that it'd be best just to have both the planner and executor
>>> throwing errors on unlogged tables, rather than rejiggering p
On Tue, Jun 7, 2011 at 3:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> I found a few other holes in my previous patch as well. I think this
>> plugs them all, but it's hard to be sure there aren't any other calls
>> to RelationGetNumberOfBlocks() that could bom
On Tue, Jun 7, 2011 at 2:05 PM, Robert Haas wrote:
> On Tue, Jun 7, 2011 at 11:50 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Patch along these lines attached.
>>
>> Frankly, I find this quite ugly, and much prefer the general approach of
>> your previo
On Tue, Jun 7, 2011 at 11:41 AM, Tom Lane wrote:
> Robert Haas writes:
>> If your point here is that you don't want to spend time hacking on
>> this because it's a fairly marginal feature and therefore not terribly
>> high on your priority list, I can understand t
On Tue, Jun 7, 2011 at 11:50 AM, Tom Lane wrote:
> Robert Haas writes:
>> Patch along these lines attached.
>
> Frankly, I find this quite ugly, and much prefer the general approach of
> your previous patch in .
>
> However, I don't like where you put the execution-t
On Fri, Jun 3, 2011 at 2:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jun 3, 2011 at 1:19 PM, Tom Lane wrote:
>>> Now, if the query doesn't involve any explicit reference to "joinalias.*",
>>> we could probably fake it with some ugly thin
to say I'm not open to other ideas, but just to give a
brief history of how I ended up where I am.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Fri, Jun 3, 2011 at 1:01 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of vie jun 03 12:44:45 -0400 2011:
>> On Wed, Jun 1, 2011 at 2:28 PM, Robert Haas wrote:
>
>> > (4) It strikes me that it might be possible to address this problem a
>>
On Fri, Jun 3, 2011 at 1:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jun 3, 2011 at 10:59 AM, Tom Lane wrote:
>>> Personally my advice is to avoid USING: it wasn't one of the SQL
>>> committee's better ideas.
>
>> I don't underst
of the SQL
> committee's better ideas.
I don't understand why we can't just translate the USING into some
equivalent construct that doesn't involve USING. I proposed that a
while ago and you shot it down, but I didn't find the reasoning very
compelling.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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, Jun 1, 2011 at 2:28 PM, Robert Haas wrote:
> On Thu, May 26, 2011 at 12:34 PM, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> Excerpts from Euler Taveira de Oliveira's message of jue may 26 12:00:05
>>> -0400 2011:
>>>> I think we should emi
in a one-line patch...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
e other, and to then try to
truncate the parent table, so I'm somewhat disinclined to put in the
time to fix this.
However, patches are welcome...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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, Jun 1, 2011 at 1:15 PM, Robert Haas wrote:
> 2011/5/31 Andres Freund :
>> On Tuesday, May 31, 2011 03:27:22 Alvaro Herrera wrote:
>>> Excerpts from Andres Freund's message of lun may 30 20:47:49 -0400 2011:
>>> > On Tuesday, May 31, 2011 02:35:58 AM Andr
is causing this problem is
almost certainly gone in more recent versions. It would be nice to
track done and fix whatever is wrong in the older branches, but we'd
probably need a reproducible test case of some sort. I don't think it
craps out like that EVERY time you interrupt it...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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, May 25, 2011 at 7:29 AM, Susanne Ebrecht
wrote:
> I think we should fix the documentation here.
Patch?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to y
ably
want to check your drive write caches and the integrity of your hardware.
This kind of thing usually means that corruption is happening somewhere, and
if you don't track it down and fix it, eventually it will probably add up to
something serious.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
pefully what they're doing), and
to get stack traces of where they are stuck using "gdb".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
nk the current default is good, because it means you only need to
change ONE parameter to switch from async rep to sync rep (namely,
synchronous_standby_names).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsq
lined to go this route even
though it would require touching a bit more code. We've already
whacked around RelationGetNumberOfBlocks() a bit in this release (the
function that formerly had that name is now
RelationGetNumberOfBlocksInFork(), and RelationGetNumberOfBlocks() is
now a macro that
It's possible that we're calling the wrong locale-aware
functions on Windows, or just different ones, but I wouldn't even know
where to start looking for that sort of problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgs
anyway. I
> personally don't realy like the placement of that piece of code very much.
> Doing it in index_build seems to be the wrong place. I don't think there
> really is a good place for it right now.
I'm open to suggestions on how to rearrange this, but I think
that's a 9.2 project.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
list of mailing
lists and pick one which seems appropriate.
http://archives.postgresql.org/
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
nt tm_mday; /* day of month (1 - 31) */
> int tm_mon; /* month of year (0 - 11) */
> int tm_year; /* year - 1900 */
>
> The only clear answer I can think of is that "month" has five letters,
> and "year" and "day" have
Which "*stack trace on the assertion failure*" do you want to have ?
>
Well, when a backend crashes, it would be helpful to know what was going on
when it crashed. See this wiki page:
http://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Sun, May 15, 2011 at 5:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, May 12, 2011 at 6:20 PM, Tom Lane wrote:
>>> One possibility is to start showing "default" when the ACL is null,
>>> which would be quite easy to implement:
>>>
>
t;
> Fixed in the attached plus added regression tests for both issues (use
> strict; && Global symbol "$_TD" requires explicit package name, test
> recursive trigger calls). Although Ill admit, given the point we are
> in the release I could see a revert also being j
;
> COALESCE(array_to_string(c.relacl, E'\n'), 'default')
>
> But that might be too big a change.
I don't think that's too big a change. ISTM we ought to change
something. Another idea would be to always show the permissions, even
if nothing has
r does not shut down
You may want to try shutting down with "-m fast". Without that, it
waits for all clients to disconnect before shutting down, and
sometimes clients don't do that quickly, or at all.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreS
e the permissions on your ~/Library folder or
remove any of your data. Improving things so that sysctl.conf is less
likely to require alteration is on our radar screen, but changing that
file is not normally a dangerous operation. I am not sure what went
wrong for you.
--
Robert Haas
EnterpriseD
Windows-only bug is looking more probable. Could someone
> reproduce this and get a stack trace?
> http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
Based on Tom's recent commits, this might now be fixed in the latest sources.
--
; The final statement causes postmaster to crash.
>
> Hmm, cannot duplicate this here ... can anyone else? Windows-specific
> issue perhaps?
Will commit 2e82d0b396473b595a30f68b37b8dfd41c37dff8 have possibly fixed this?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
would seem unwise to multiplex a
server connection across different sessions while leaving a
transaction open. Presumably each client should commit after it
finishes its own work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bu
the directions that are in the pg_hba.conf file
for instructions on what to put in there, or here:
http://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list
rtualization tool you are using.
Any way to get a stack trace on the assertion failure?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.po
bitrock installer log and send and attach it to your reply?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
twork path in Query.
No, but you can use the psql command \lo_import instead.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
you run ldd on
/usr/lib/postgresql/8.4/bin/pg_ctl?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
quest
> .LOG: autovacuum launcher shutting down
> ..
>
> Above test let me know the DBI-LINK crushed by DBI->connect, I think the
> really reason is one of these:
> 1.postgresql create backend process has a bug,most likely with bad process
>
that would reveal the server? Have you any suggestions?
If you haven't already, you might want to try this question on the
pgadmin-support mailing list.
http://archives.postgresql.org/pgadmin-support/
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
-
sation failed
> Details:
>
> While installing postgresql-9.0.3-2-windows it prompt the message at the end
> that "Problem running post installation step. Installation may not be
> complete correctly. The database cluster initialisation failed."
The contents of the Bitrock
ehavior caused by some
non-obvious aspect of your configuration. The EnterpriseDB team has
made multiple attempts to reproduce this internally, and while we've
managed to create various weird behaviors, they aren't obviously the
same as what's happening to you. :-(
--
Robert Haas
n-gracefully via software
> control (for example a C funcion: elog(FATAL, "Terminating connection...");)
> then no.
A smart shutdown waits for clients to exit on their own. A fast or
immediate shutdown kills them immediately, even mid-query.
--
Robert Haas
EnterpriseDB: http://www.en
On Mon, Apr 25, 2011 at 11:06 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Apr 20, 2011 at 7:13 PM, Tom Lane wrote:
>>> I have stated previously my opinion that this is a misconceived feature,
>>> and it's now apparent that the implementation is as p
and let us know how it goes.
If the crash is still happening on 8.3.14, then it would be helpful if
you could attempt to obtain a stack backtrace.
http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
--
Robert Haas
EnterpriseDB: http://www.enterprisedb
l-9.1alpha5/src/test'
>> make: *** [check] Error 2
>>
>> real 0m3.253s
>> user 0m1.666s
>> sys 0m1.141s
>
> I did some bisecting, and it appears the problem was introduced in the
> commit "Improved parallel make support" on November 12, 2010.
I suspect this needs a
a better solution here would be to derive the creation
namespace before we break up the statement into subcommands, and pass
the OID around after that. Then we wouldn't be doing it multiple
times and hoping to get the same answer, and the permissions checking
would be happening at the beginning
d with the patch they succeed. I have
> also confirmed that the isolation test suite continues to succeed
> with this patch applied.
I committed the one-line fix, and the additional regression tests.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Compan
On Tue, Apr 5, 2011 at 12:13 PM, Kevin Grittner
wrote:
> I wrote:
>> Robert Haas wrote:
>>
>>> If you could send a revised patch, that would be great.
>>
>> Attached. I put it in the same spot relative to the lock
>> acquisition that was used earlie
32.
Can you see whether the following patch fixes it for you? It seems to
work on MacOS X, but I don't have a mingw environment handy.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
disable-shared.patch
Description: Binary data
--
Sent via pgsql-
On Tue, Apr 5, 2011 at 11:18 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> This patch looks reasonable, but I'm a bit concerned about the
>> chunk immediately preceding the patched area.
>>
>> When we do this:
>>
>> LWLockRelease(Ser
he partitionLock that's keeping the PREDICATELOCKs from
bouncing out from under us, so if we release it, aren't we potentially
point off into thin air?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs maili
On Mon, Mar 28, 2011 at 12:29 AM, Tom Lane wrote:
> Robert Haas writes:
>> I think we've had a number of pieces of evidence that suggest that
>> extending 8kB at a time is too costly, but I agree with Greg that the
>> idea of extending an arbitrarily large table by
some state in shared memory about
the tables people were using - for example, in this case, we could
cache the table size, or the fact that vacuum has just truncated away
N blocks, or, uh, something. *waves hands* But it's hard to know how
such an area could reasonably be sized or manag
llocating in really big chunks might help the filesystem lay out the
space more contiguously on disk. But I'd want to see some careful
testing that reveals exactly what is needed to get that benefit before
we go too crazy with it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
> try and understand why configure does not see these libraries.
Maybe you have the readline and zlib packages installed, but not
readline-devel and zlib-devel? That's usually what bites me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Se
list by filling out this form:
>
> http://www.postgresql.org/community/lists/subscribe
>
> and selecting pgsql-general list.
Or better yet, contact Poker Tracker, since this doesn't actually
appear to be a question about PostgreSQL.
--
Robert Haas
EnterpriseDB: http://www.ent
h
>
> The problem is that the password is disclosed in a surprising way.
> .pgpass files are explicitly put there by a user, so they know what
> they've done.
>
> Putting a password in cleartext somewhere is an issue if people don't
> know about it.
I agree completely.
--
again 'EST'. So:
SET is a session-local command. You may want to update it in
postgresql.conf (and then reload the config using pg_ctl reload). Or
you could use ALTER ROLE .. SET or ALTER DATABASE .. SET, if you don't
want to change it globally.
--
Robert Haas
EnterpriseDB: http:/
On Fri, Mar 11, 2011 at 9:31 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Thu, Mar 10, 2011 at 10:37 PM, Bruce Momjian wrote:
>> > Robert Haas wrote:
>> >> On Thu, Mar 10, 2011 at 4:08 PM, Bruce Momjian wrote:
>> >> > Was this fixed?
>>
ption: PostgreSQL8.2
> Details:
>
> I am getting an error in my PostGreSQL8.2
>
> Error 1053: The service did not respond to the start or control request in a
> timely fashion
What do you see in the server log file?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.co
On Fri, Mar 11, 2011 at 10:05 AM, Bruce Momjian wrote:
> Also, it seems this was addressed in January:
>
> commit af84bee43e356866dc46c95ae5bf77996a8237ff
> Author: Robert Haas
> Date: Sat Jan 8 06:12:05 2011 -0500
>
> Remove bogus claims
The default is to be asked
>> Shall the new role be a superuser? (y/n)
>> Shall the new role be allowed to create more new roles? (y/n)
>
> Sorry for the late reply. If you press "enter", "no" is the default.
That's a lame answer. Surely this is a
On Fri, Mar 11, 2011 at 5:56 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Tue, Jan 25, 2011 at 10:54 AM, Kevin Grittner
>> wrote:
>> > Robert Haas wrote:
>> >> I think this patch would only be adding to the confusion. ?When
>> >> PQget
On Thu, Mar 10, 2011 at 10:37 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Thu, Mar 10, 2011 at 4:08 PM, Bruce Momjian wrote:
>> > Was this fixed?
>>
>> Not yet. I can probably fix it, if nobody else wants to do it.
>
> Well, it has languished for fi
On Thu, Mar 10, 2011 at 4:08 PM, Bruce Momjian wrote:
> Was this fixed?
Not yet. I can probably fix it, if nobody else wants to do it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.
though the
description says scaling/rotation.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
mmit changed it to check for language ownership.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
of "role ownership" like this. Who would want a mere member of some
> group role to be able to set that role's security label?
>
> Comments, objections?
I think it's a good change, but we should make sure to release-note it
properly, along with the change you made for P
non-convex polygons. Now they check that all line
>> segments of one polygon are contained in the other.
>
> Thank you. How about the point of more informative docs that would
> explain supported types, automatic conversions and all such caveats
> (also for 8.3 and 8.4)?
and another time numbers are after letters. Then the index appears to be
> broken...
>
> So definitely it's not a postgresql bug. It'd be nice if there are some
> safeguards against this mismatch, although I don't know how to do it...
Wow. That sucks. But thanks for repor
in the resulting column header.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
rhaas=# select debug_query('SELECT * FROM foo');
NOTICE: (1,Richard)
NOTICE: (2,Robert)
NOTICE: (3,Tom)
debug_query
-
(1 row)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@po
select upper('i') --> Uppercase of turkish small returns I where it should
> be I-with dot.
I might be wrong about this, but I think this behavior is determined
by the operating system behavior of the locale you've selected, and we
just believe whatever the OS says.
--
ts out well enough for debugging. Or at least it's never
bothered me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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, Mar 3, 2011 at 11:51 AM, David Schmitt wrote:
> On 03.03.2011 16:08, Robert Haas wrote:
>>
>> On Tue, Feb 8, 2011 at 2:19 AM, David Schmitt wrote:
>>>
>>> Example query:
>>>
>>> SELECT column as zurück FROM table;
>>>
>>
iff the master version of
each file with the standby version and see what pops out.
> The strange thing is that this only affects streaming replication standby,
> not wal files shipping standby. Maybe we're doing something wrong...
Maybe, but I can't think what would cause this.
deleting my .pg_history file.
>
> Perhaps it is more accurate that this is a problem with termcap?
More likely libedit, which FWICT seems to be riddled with bugs. :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailin
On Thu, Mar 3, 2011 at 11:38 AM, Dave Page wrote:
> On Thu, Mar 3, 2011 at 8:30 PM, Robert Haas wrote:
>> On Wed, Feb 2, 2011 at 4:06 PM, R. Engmann wrote:
>>>
>>> The following bug has been logged online:
>>>
>>> Bug reference: 5863
>>
you figure out how to get it working, I think we'd be happy to
accept a patch that fixes it, unless it's only failing due to some
funky detail of your configuration, which I suspect isn't the case
based on a quick look at my system.
--
Robert Haas
EnterpriseDB: http://www.enterpr
t
>> relhassubclass, no?
>
> Yep, duplicated the issue that way.
I think ATExecAddInherit() and MergeAttributes() need to take
ShareUpdateExclusiveLock instead of AccessShareLock to prevent this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
/share/postgres.bki
>
> run cmd "initdb -E UTF-8 -D temp --local=chs"
>
> it can init successful,then i start the server,run sql:
> "SELECT * from pg_database_test" ,the result show "Chinese_Peoples Republic
> of China.936".
> yes ,the single quote
g list. You might want to try here:
http://archives.postgresql.org/pgsql-es-ayuda/
It'd also probably be helpful to provide more details about the problelm.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.
nse. It looks like Thom Brown also noticed
this, and it's fixed now.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
201 - 300 of 787 matches
Mail list logo
