Jaime Casanova jcasa...@systemguards.com.ec writes:
+ WARNING: could not open statistics file pg_stat_tmp/pgstat.stat:
Stale NFS file handle
this is an ext2 filesystem in an external hard drive, could be fs corruption?
Evidently the kernel is confused. It seems more like busted in-memory
On Sat, Apr 03, 2010 at 03:17:30PM +0200, Markus Schiltknecht wrote:
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:
Hitoshi Harada umi.tan...@gmail.com writes:
I cannot figure out at all what is wrong. Have any idea?
Since nobody else is reporting this, it seems like it must be either
something messed up about your system, or something wrong with your
copy of the PG sources. In the latter connection I
Hitoshi Harada wrote:
The problem isn't in libpq, since it is that the server doesn't listen
on startup as above. No /tmp/.s.PGSQL.5432, nor LISTENING entry in
netstat.
I find this somewhat implausible. The postmaster has this code that
makes it die if it can't open a listening socket:
On 4/4/10 9:19 AM, Tom Lane wrote:
Hitoshi Harada umi.tan...@gmail.com writes:
I cannot figure out at all what is wrong. Have any idea?
We ran Make Check on 4 linux laptops and 3 macs yesterday, and did not
see a hang.
Could this be an issue with VirtualBox? Have you used this VM for
testing
On Sun, Apr 4, 2010 at 11:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
anything i could do to fix this without dropping my 90Gb test env?
Did you try rebooting the machine?
yes. i started it a few minutes ago since yesterday... so i think this
is on-disk state, i will checked the disk...
--
Hi all,
I've just released the first version (v.0.1.0) of dbt5, a fair-use
derivative of the TPC-E. This kit was initially developed by by
Rilson Nascimento as a Google Summer of Code project in 2006. The kit
can be downloaded here:
https://sourceforge.net/projects/osdldbt/files/
For those
Hackers,
Here's a way to trap yourself:
(1) Set up an HS/SR master
(2) pg_start_backup on the master
(3) clone the master to 1 or more slaves
(4) Fast shutdown the master (without pg_stop_backup)
(5) Restart the master
(6) Bring up the slaves
Result: the slaves will come up fine in recovery
On lör, 2010-04-03 at 11:13 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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.
All,
Not sure when this happened, but someone added a very informative hint
for the case where you ambiguously refer to a base table name when you
needed to refer to the alias. Nice work, we should do more of this
helpful hinting.
--
-- Josh Berkus
On 04/02/2010 04:16 PM, Tom Lane wrote:
Generally speaking I'm against
exposing that data structure to clients, because there will inevitably
be griping when we change it (as we most certainly will). Your
complaints boil down to this is hard to parse from the client side,
and that already tells
I am fooling around with deleting pg_default_acl entries when they are
changed to match the default value, as per yesterday's discussion:
http://archives.postgresql.org/pgsql-hackers/2010-04/msg00114.php
I noticed what seemed to be a bug in SetDefaultACL(): the list of old
ACL members that it
In the 9.0devel release notes
http://developer.postgresql.org/pgdocs/postgres/release-9-0.html
under
E.1.2.3. String Handling
three changes are mentioned, and for the first two changes it is said that
substring() is affected:
8
1
Properly treat ^ and $ as
Peter Eisentraut pete...@gmx.net writes:
On lör, 2010-04-03 at 11:13 -0400, Tom Lane wrote:
This one is probably my responsibility (the others all look like Simon's
code). What do you not like about it, exactly? Perhaps it should be
NOTIFY queue is x% full?
Yeah, that plus some hints
2010/4/5 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
I cannot figure out at all what is wrong. Have any idea?
Since nobody else is reporting this, it seems like it must be either
something messed up about your system, or something wrong with your
copy of the PG
2010/4/5 Josh Berkus j...@agliodbs.com:
On 4/4/10 9:19 AM, Tom Lane wrote:
Hitoshi Harada umi.tan...@gmail.com writes:
I cannot figure out at all what is wrong. Have any idea?
We ran Make Check on 4 linux laptops and 3 macs yesterday, and did not
see a hang.
Could this be an issue with
While testing pgindent the other day, I found some infelicities in
contrib/fuzzystrmatch/dmetaphone.c. From pgindent's point of view, the
problem is that the code contains two characters in case labels with the
high bits set, and this blows pgindent up on my Linux box if the locale
happens
Jaime Casanova jcasa...@systemguards.com.ec writes:
On Sat, Apr 3, 2010 at 5:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Not sure if this is good enough or we need to provide some more-obvious
way of dealing with it.
it's strange that a REVOKE doesn't clean what a GRANT did, and DROP
OWNED BY
Andrew Dunstan and...@dunslane.net writes:
While testing pgindent the other day, I found some infelicities in
contrib/fuzzystrmatch/dmetaphone.c. From pgindent's point of view, the
problem is that the code contains two characters in case labels with the
high bits set, and this blows
Tom Lane wrote:
Why has pgindent decided to screw up all the FD_SET calls in our code?
See for example
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.188;r2=1.189
Because the typedef list supplied by Andrew includes FD_SET as a
typedef. :-O See
Andrew Dunstan wrote:
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
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
+ Exclusion constraints ensure that if any two rows are compared on
+ the specified columns or expressions using the specified operators,
+ at least one of these operator comparisons will be false. The syntax
is:
Isn't
Erik Rijkers e...@xs4all.nl writes:
In 9.0devel cvs, I can find affirm the SIMILAR TO changes, but I cannot
find any changes to
substring() (other than the one under point 3.)
What's affected is the three-parameter form of SUBSTRING(). See
section 9.7.2.
The second of these is still wrong,
On Sun, Apr 4, 2010 at 9:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova jcasa...@systemguards.com.ec writes:
On Sat, Apr 3, 2010 at 5:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Not sure if this is good enough or we need to provide some more-obvious
way of dealing with it.
it's
On Fri, Apr 2, 2010 at 2:44 PM, Robert Haas robertmh...@gmail.com wrote:
On Apr 2, 2010, at 12:34 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Josh Berkus j...@agliodbs.com wrote:
Robert,
do you think you could put up replacement tarballs today?
If you don't hear from him soon,
Tom Lane wrote:
However, that doesn't solve the fundamental problem, which is that the
code in question is pretty much broken for any encoding but Latin1.
Yeah. I don't see an easy fix for it either, but there should be a
TODO entry about it. In the meantime I'm surprised we didn't
Bruce Momjian wrote:
Tom Lane wrote:
Why has pgindent decided to screw up all the FD_SET calls in our code?
See for example
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.188;r2=1.189
Because the typedef list supplied by Andrew includes
Andrew Dunstan and...@dunslane.net writes:
I've committed a fix to pgindent for this. Do we want to rerun pgindent
for these files?:
I think the plan is to redo pgindent near the end of beta. There's
probably no need to do it right now.
regards, tom lane
--
Sent via
Andrew Dunstan wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Why has pgindent decided to screw up all the FD_SET calls in our code?
See for example
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.188;r2=1.189
Because the typedef
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I've committed a fix to pgindent for this. Do we want to rerun pgindent
for these files?:
I think the plan is to redo pgindent near the end of beta. There's
probably no need to do it right now.
Sure, sounds like a plan.
--
Tom Lane t...@sss.pgh.pa.us wrote:
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Can we take the patch for 9.0? The bug is registered as an open item:
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
Given that there are still problems with it, applying the patch for
Do we still need VACUUM FULL in initdb? VACUUM FULL in 9.0 rewrites
all tables, so those operations are a little more expensive than
previous releases. Is it worth replacing them into VACUUM?
make_template0(void)
Finally vacuum to clean up dead rows in pg_database
VACUUM FULL
Josh Berkus j...@agliodbs.com wrote:
Could this be an issue with VirtualBox? Have you used this VM for
testing before?
As I've hit a few bugs in VirtualBox, this is a definite
possibility. (So is Tom's suggestion of inconsistent
sources.)
Because I could, I just installed a new CentOS 5.4
33 matches
Mail list logo
