Hi, all.
I built pgsql with following regulation (for buildfarm new entry).
- Windows Server 2008 64bit
- VC2005
- 9.0dev (HEAD near alpha5) 64bit
And I got a fail at "vcregress contribcheck" about only pgcrypto.
All CREATE FUNCTION of pgcrypto got ERROR.
(It passed "vcregress check")
STATEME
On Fri, Apr 2, 2010 at 11:11 PM, Magnus Hagander wrote:
> More to the point, I'm not sure I like the creation of yet another DLL
> to deal with this. The reason this isn't just exported from the main
> backend is the same reason we created the libpqwalreceiver library I'm
> sure - bt that means we
Hi, all.
I built pgsql with following regulation (for buildfarm new entry).
- Windows Server 2008 64bit
- VC2005
- 9.0dev (HEAD near alpha5) 64bit
And I got a fail at "vcregress contribcheck" about only pgcrypto.
All CREATE FUNCTION of pgcrypto got ERROR.
(It passed "vcregress check")
STATEME
Josh Berkus 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 (no
updates, 64
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 pg_database;
Tom Lane wrote:
> Takahiro Itagaki 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 9.0
> would mean changing the behavior of x
Tom Lane wrote:
> Andrew Dunstan 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.
--
Bruce Momjia
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
> >>
> >
> >
Andrew Dunstan 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 pgsql-hackers mai
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 FD_SE
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 ins
On Fri, Apr 2, 2010 at 2:44 PM, Robert Haas wrote:
> On Apr 2, 2010, at 12:34 PM, Kevin Grittner
> wrote:
>> Josh Berkus wrote:
>>
>>> Robert,
>>
>>> do you think you could put up replacement tarballs today?
>>
>> If you don't hear from him soon, perhaps he's traveling:
>>
>> http://archives.pos
On Sun, Apr 4, 2010 at 9:59 PM, Tom Lane wrote:
> Jaime Casanova writes:
>> On Sat, Apr 3, 2010 at 5:27 PM, Tom Lane 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
"Erik Rijkers" 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, though,
Tom Lane wrote:
> Bruce Momjian 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 that
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:
> 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 src
Andrew Dunstan 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 pgindent up on my Linux
Jaime Casanova writes:
> On Sat, Apr 3, 2010 at 5:27 PM, Tom Lane 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 seems very dangerous (at least if i forg
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 be
2010/4/5 Josh Berkus :
> On 4/4/10 9:19 AM, Tom Lane wrote:
>> Hitoshi Harada 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 thi
2010/4/5 Tom Lane :
> Hitoshi Harada 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 connectio
Peter Eisentraut 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 maybe. "p
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 lite
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 ge
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 tell
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 lör, 2010-04-03 at 11:13 -0400, 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.
>
> > #:
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 mode
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 fam
On Sun, Apr 4, 2010 at 11:57 AM, Tom Lane 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...
--
Atentamente,
On 4/4/10 9:19 AM, Tom Lane wrote:
> Hitoshi Harada 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 before?
--
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:
Hitoshi Harada 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 confess to having
little c
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:
> http://wiki
Jaime Casanova 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
state than on-disk state,
36 matches
Mail list logo
