PG Build Farm wrote:
> The PGBuildfarm member skylark had the following event on branch HEAD:
>
> Failed at Stage: Make
>
> The snapshot timestamp for the build that triggered this notification is:
> 2007-09-29 03:00:01
>
> The specs of this machine are:
> OS: Windows XP / SP2
> Arch: x64
> Co
On Thu, 27 Sep 2007, Tom Lane wrote:
Also, I spent a dreary two or three hours this afternoon examining the
CVS commit logs since 8.3 branched...I tried to post that info to
pgsql-docs but it broke the list's message size limits (even gzipped,
it's about 90K).
I just dumped a copy of Tom's f
I spent a bit of time tonight poking at the issue reported here:
http://archives.postgresql.org/pgsql-novice/2007-08/msg00123.php
It turns out to be quite easy to reproduce, at least for me: start CVS
HEAD on an NFS-mounted $PGDATA directory, and run the contrib regression
tests ("make installchec
On 9/29/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Has anyone every asked for this functionality?
I searched the list archives for previous mentions of the topic, and
didn't find any. So the answer to your question is "yes", but so far
it seems to be just me.
Cheers,
BJ
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2007-09-27 at 13:01 -0400, Tom Lane wrote:
>> Anyway, if you can test this tomorrow that'll be great. I have enough
>> other things to do today ...
> Looks good to me. I was and am still nervous of weird knock-on effects,
> but I think its the rig
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'd be inclined to leave it there, simply because you'll be changing
>> the conditions of the benchmark if you take it out. I have not noticed
>> any particular problems with it...
> I wonder if autovacuum itself is going to add more
Tom Lane wrote:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > Now that PostgreSQL 8.3 enables autovacuum by default, I think pgbench
> > should stop issuing vacuum in pgbench -i since an ordinary vacuum will
> > take very long time under autovacuum running. If there's no objection,
> > I will remo
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> The another question is what do when we know that this codeset/encoding
> is not supported by postgres.
Ah, I finally grasped what you were on about here. As CVS HEAD stands,
if you run initdb in an unrecognized locale, you get something like
$ LANG=z
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> On Solaris I got following problematic locales: [...]
I tried this program on Mac OS X 10.4.10 (the current release) and found
out that what that OS mostly returns is the encoding portion of the
locale name, for instance
sv_SE.ISO8859-15... ISO8
Tom Lane wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > Patch includes documentation and new regression tests. While I was in
> > there I also added regression tests for quote_ident(), which appeared
> > to be absent.
>
> This seems rather pointless, since it's equivalent to
> quot
Simon Riggs wrote:
...knock-on...
tackle
Been watching the Rugby World Cup? :)
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do
Peter Eisentraut wrote:
> Am Freitag, 21. September 2007 schrieb Abhijit Menon-Sen:
> > Regarding this item in the TODO:
> >
> > SQL*Net listener that makes PostgreSQL appear as an Oracle database
> > to clients
>
> > (IMO, the TODO item should be dropped.)
>
> Yeah, if at all, this shoul
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
On Solaris I got following problematic locales:
C ... 646- NO MATCH
POSIX ... 646- NO MATCH
cs ... 646- NO MATCH
da ... 646
On Thu, 2007-09-27 at 13:01 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > AFAICS the correct test would be
> > if (InArchiveRecovery)
> > since needNewTimeLine can only be true iff InArchiveRecovery is true.
>
> > It's often a good idea to disable archive_mode when doing
Hi,
Starting from version VC7 msvc supports __FUNCTION__, so I think this
could be enabled in pg_config.h.win32, see attached diff.
-Hannes
*** ../pgsql-cvshead/src/include/pg_config.h.win32 Mon Apr 16 20:39:19 2007
--- src/include/pg_config.h.win32 Fri Sep 28 22:32:50 2007
***
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> On Solaris I got following problematic locales:
> C ... 646- NO MATCH
> POSIX ... 646- NO MATCH
> cs ... 646- NO MATCH
> da ... 646- NO MATC
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Gregory Stark wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
Another possibility is to treat the case as a WARNING if you're
superuser and an ERROR if you're not. This would satisfy people
who are uncomfortable with the idea that CREAT
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> Another possibility is to treat the case as a WARNING if you're
>>> superuser and an ERROR if you're not. This would satisfy people
>>> who are uncomfortable with the idea that CREATEDB
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Raney wrote:
> We are pleased to announce an upcoming patch to the hash index code
> which improves build time an
>>> On Thu, Sep 27, 2007 at 4:59 PM, in message
<[EMAIL PROTECTED]>, "Kevin Grittner"
<[EMAIL PROTECTED]> wrote:
>
> By the way, I realize that the error messages are still lame.
> I'm going to do something about that.
Attached is a version as good as I know how to get it.
It works for us, so
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Not quite as good. Since the archiver process can't actually deliver
> this number in a lightweight manner, all it goes to show is that the
> filter code compares reasonably well in performance with dd and cat.
I'd definitely vote for leaving it as a
Gregory Stark wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
Another possibility is to treat the case as a WARNING if you're
superuser and an ERROR if you're not. This would satisfy people
who are uncomfortable with the idea that CREATEDB privilege comes
with a built-in denial-of-service a
Heikki Linnakangas wrote:
Zdenek Kotala wrote:
I'm Sorry for confusion, I overlooked it. You have right. Unfortunately
struct Port has been modified and by my opinion it means we must bump
major version. See
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libpq-be.h.diff?r1=1.
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Zdenek Kotala wrote:
>> struct Port has been modified and by my opinion it means we must bump
>> major version. See
>> http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libpq-be.h.diff?r1=1.62;r2=1.63
> That header file is *not* par
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Another possibility is to treat the case as a WARNING if you're
> superuser and an ERROR if you're not. This would satisfy people
> who are uncomfortable with the idea that CREATEDB privilege comes
> with a built-in denial-of-service attack, while still le
>>> On Fri, Sep 28, 2007 at 9:38 AM, in message
<[EMAIL PROTECTED]>, "Kevin Grittner"
<[EMAIL PROTECTED]> wrote:
On Fri, Sep 28, 2007 at 5:53 AM, in message
> <[EMAIL PROTECTED]>, "Zeugswetter
> Andreas ADI SD" <[EMAIL PROTECTED]> wrote:
>> archive_command=dd if=%p of=/backup/WAL/%f bs=1
I was reminded again just now of the bad consequences of selecting a
database encoding that is not compatible with your LC_CTYPE setting:
http://archives.postgresql.org/pgsql-bugs/2007-09/msg00158.php
Aside from that one, which is perilously close to being a denial of
service attack, there are know
Zdenek Kotala wrote:
Stephen Frost wrote:
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
I'm for bumbing. Because if we use same number it also means that
new binary will able to use old library. But if there are two new
functions number must be increased. Standard practice how ELF loader
w
Zdenek Kotala wrote:
> I'm Sorry for confusion, I overlooked it. You have right. Unfortunately
> struct Port has been modified and by my opinion it means we must bump
> major version. See
> http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libpq-be.h.diff?r1=1.62;r2=1.63
That head
Stephen Frost wrote:
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
I'm for bumbing. Because if we use same number it also means that new
binary will able to use old library. But if there are two new functions
number must be increased. Standard practice how ELF loader works is
following:
Eac
>>> On Fri, Sep 28, 2007 at 5:53 AM, in message
<[EMAIL PROTECTED]>, "Zeugswetter
Andreas ADI SD" <[EMAIL PROTECTED]> wrote:
> I think you misunderstood what I meant.
> The actual archive command is constructed by expanding certain
> placeholders.
> I am suggesting to add such a placeholder for
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> I am suggesting to add such a placeholder for the size of the filled
> part of the log.
The archiver has not got that information, and can't compute it any
faster than the called command could.
regards, tom lane
-
The current (CVS version) configure script has the following options
(among many others):
--enable-dtrace build with DTrace support
--with-ossp-uuidbuild with OSSP UUID library for UUID generation
--with-libxml build with XML support
--with-libxslt build
> A nice improvement on that would be to have a "rearchive_command" to
> allow to sync the new bytes written since a previous archive_command
(so
> it needs a new placeholder "start from this byte"). This allows
writing
> dd seek=%s skip=%s count=%b bs=1
But after a log switch nothing is filling
Zeugswetter Andreas ADI SD wrote:
>
> > > The probably useful next step would be to pass the current length to
> the
> > > archive_command,
> > > so it can write the filled part of the file without the need for a
> > > filter.
> >
> > I can see that helping a lot, but not by writing onto the fil
2007/9/28, Nikolay Samokhvalov <[EMAIL PROTECTED]>:
> On 9/28/07, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> > > We would create wrappers returning int[], bool[], string[], but there
> > > are several issues with such functions:
> > > - if the type of the data located on nodes that match XPath
>
* Heikki Linnakangas ([EMAIL PROTECTED]) wrote:
> Gregory Stark wrote:
> > What we want to know is that things like pgadmin can connect properly to
> > either 8.3, 8.2, and even 8.1 using the new libraries regardless of how the
> > server authentication is configured. Do they work correctly if the
On 9/28/07, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> > We would create wrappers returning int[], bool[], string[], but there
> > are several issues with such functions:
> > - if the type of the data located on nodes that match XPath
> > expression differs from what is expected, what should we d
> > The probably useful next step would be to pass the current length to
the
> > archive_command,
> > so it can write the filled part of the file without the need for a
> > filter.
>
> I can see that helping a lot, but not by writing onto the file on
disk.
> If the file is nearly empty, that wou
> We would create wrappers returning int[], bool[], string[], but there
> are several issues with such functions:
> - if the type of the data located on nodes that match XPath
> expression differs from what is expected, what should we do?
raise exception
> - in XML world, if you request for a
On 9/27/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> * Draft release notes --- can't really ship a beta without these,
> else beta testers won't know what to test. Traditionally this has
> taken a fair amount of time, but I wonder whether we couldn't use
> http://developer.postgresql.org/index.php/Wh
Gregory Stark wrote:
> What we want to know is that things like pgadmin can connect properly to
> either 8.3, 8.2, and even 8.1 using the new libraries regardless of how the
> server authentication is configured. Do they work correctly if the server
> tries to do password authentication, ident, ker
The problem with contrib/xml2's xpath_* functions (that return
scalars) was that they are very specific. If XPath expression
evaluation returns array of values (set of XML pieces), but the
function returns only the first, significant information is lost,
while there is no any gain in speed at all.
"Stephen Frost" <[EMAIL PROTECTED]> writes:
> This is where I was suggesting doing something like running the
> regression tests using old client libraries linked against the new
> library. If there's a binary-incompatible change then the path is
> clear. If the regression tests work fine then I
> > * Do we bump the .so major version number for libpq? I think we
should
> > because there are two new exported functions since 8.2, and on at
least
> > some platforms there's nothing else than major number to
disambiguate
> > whether a client needs these or not. Comments?
-1. You don't bump
45 matches
Mail list logo