Hi,
i was running installcheck on a 9.0 installation and get 6 failed
tests, but when reading the regression.diff i found a lot of this
messages:
"""
+ WARNING: could not open statistics file "pg_stat_tmp/pgstat.stat":
Stale NFS file handle
"""
and when listing the file i get this:
"""
postg...@
On Sat, Apr 3, 2010 at 5:27 PM, Tom Lane wrote:
> I wrote:
>> Yeah. The problem here is that once you've created an entry in
>> pg_default_acl, there is no way to make it go away.
>
> Actually that's not true: you can get rid of it with DROP OWNED BY.
> This fact is even documented in the ALTER D
I wrote:
> Yeah. The problem here is that once you've created an entry in
> pg_default_acl, there is no way to make it go away.
Actually that's not true: you can get rid of it with DROP OWNED BY.
This fact is even documented in the ALTER DEFAULT PRIVILEGES manual
page:
If you wish to dro
Jaime Casanova writes:
> I create some default privileges, now i'm trying to drop those roles
> but i get this error:
> mic=# drop role jcm;
> ERROR: role "jcm" cannot be dropped because some objects depend on it
> DETAIL: owner of default privileges on new relations belonging to
> role jcm in
Jaime Casanova writes:
> then, something is wrong because \ddp+ should be giving an error
> (because that command doesn't exist and \dd seems to be accepting the
> p+ as a parameter)
No, it's just ignoring the p+, not treating it as a parameter. I agree
this is bogus --- patch committed.
On Sat, Apr 3, 2010 at 4:46 PM, Tom Lane wrote:
> Jaime Casanova writes:
>> are we requiring a space between the command and it's first parameter?
>
> Yes.
>
then, something is wrong because \ddp+ should be giving an error
(because that command doesn't exist and \dd seems to be accepting the
p+
Hi,
I create some default privileges, now i'm trying to drop those roles
but i get this error:
"""
mic=# drop role jcm;
ERROR: role "jcm" cannot be dropped because some objects depend on it
DETAIL: owner of default privileges on new relations belonging to
role jcm in schema public
"""
So i look
Jaime Casanova writes:
> are we requiring a space between the command and it's first parameter?
Yes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
Hi,
Seems like \dd and \ddp+ gives the same answer...
The reason this is misleading is that \ddp is a command and i was
trying to get extra info with \ddp+ (which doesn't exist)
are we requiring a space between the command and it's first parameter?
--
Atentamente,
Jaime Casanova
Soporte y capac
Hi,
By default, the application_name of pgbench is "[unknown]". But I think
that pgbench should use fallback_application_name as psql, pg_dump,
etc does. Is it worth creating the patch?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent
Robert Haas writes:
> On Apr 3, 2010, at 11:13 AM, Tom Lane wrote:
>> What do you not like about it, exactly? Perhaps it should be
>> "NOTIFY queue is x% full"?
> I think maybe the question is why the user should care, or what they
> are expected to do about it?
The errdetail and errhint that
On Sat, Apr 3, 2010 at 9:02 PM, Robert Haas wrote:
> On Apr 3, 2010, at 11:13 AM, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> The following messages from the postgres catalog either appear to be
>>> internal errors that should be marked differently, or they are in my
>>> estimation unintelli
On Apr 3, 2010, at 11:13 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> The following messages from the postgres catalog either appear to be
>> internal errors that should be marked differently, or they are in my
>> estimation unintelligible to users and should be rephrased.
>
>> #: commands/
Hi,
I saw you changed my "warn about hidden vars" patch
to ET_ERROR instead of ET_FATAL. My thinking in using
ET_FATAL was that this is an error level that immedately
quits processing and deletes its output file. However,
you are right that we might want to report all such errors
in one run of ECP
Following up Tom's complaint about behaviour of pgindent, I have been
wrestling with it a bit. I noticed several things.
First awk on my box spits out fairly useless warnings about regular
expressions containing a literal '\*'. These warnings are silenced by
replacing those with '[*]', which
Mike Rylander wrote:
Here's my idea: the datatype should only allow strict JSON, but there
should be a function that accepts a liberal format, cleans it up to
make it strict JSON, and converts it to JSON. I think making strict
JSON the default makes the most sense because:
* Inputs to the da
Peter Eisentraut writes:
> The following messages from the postgres catalog either appear to be
> internal errors that should be marked differently, or they are in my
> estimation unintelligible to users and should be rephrased.
> #: commands/async.c:1424
> msgid "pg_notify queue is %.0f%% full"
On Sat, Apr 3, 2010 at 8:59 AM, Joseph Adams wrote:
> I've been wondering whether the JSON datatype should be strict or
> conservative.
>
> For one, there's strict JSON (following the exact specification).
> Then there's more conservative JSON variants. Some JSON parsers
> support comments, some
Hi,
Michael Tharp wrote:
I have been spending a little time making the internal SQL parser
available to clients via a C-language SQL function.
This sounds very much like one of the Cluster Features:
http://wiki.postgresql.org/wiki/ClusterFeatures#API_into_the_Parser_.2F_Parser_as_an_independen
I've been wondering whether the JSON datatype should be strict or conservative.
For one, there's strict JSON (following the exact specification).
Then there's more conservative JSON variants. Some JSON parsers
support comments, some support invalid number formats (e.g. '3.' or
'+5'), etc..
The c
On Sat, 2010-04-03 at 11:00 +0300, Peter Eisentraut wrote:
> The following messages from the postgres catalog either appear to be
> internal errors that should be marked differently, or they are in my
> estimation unintelligible to users and should be rephrased.
OK, will look.
--
Simon Riggs
The following messages from the postgres catalog either appear to be
internal errors that should be marked differently, or they are in my
estimation unintelligible to users and should be rephrased.
#: commands/async.c:1424
msgid "pg_notify queue is %.0f%% full"
#: storage/ipc/procarray.c:2224
m
22 matches
Mail list logo
