On Mon, February 20, 2006 11:00, Marc G. Fournier wrote:
>> Speaking for libpqxx, my only concern with that is the mailing list.
>> Would those have to move to different addresses--or conversely, would a
>> forced migration make it much easier to move *all* GBorg mailing lists
>> to
>> pgFoundry a
On Sun, Feb 19, 2006 at 11:32:53PM -0500, Tom Lane wrote:
> Would you try the patch proposed at
> http://archives.postgresql.org/pgsql-patches/2006-01/msg00299.php
> and see if it fixes the problem? That patch has *not* gotten applied,
> probably because no one confirmed that it worked.
This test
On Mon, Feb 20, 2006 at 01:28:50PM +1300, Mark Kirkwood wrote:
> uwcssa wrote:
> >I am using version 8.0.3. i installed using the
> >--without-readline option.
>
> Platform and os version would be good too :-), along with the client you
> are using to elicit this behavior (e.g, psql, Pgadm
Relating to this. If anyone can find govt or other free db's and
convert them into pgsql format, I will host them on the dbsamples page.
The dbsamples are _really_ popular!
Chris
Scott Marlowe wrote:
On Fri, 2006-02-17 at 10:51, Ron wrote:
I assume we have such?
Depends on what you wanna
Albert Chin <[EMAIL PROTECTED]> writes:
> On Sun, Feb 19, 2006 at 09:56:20PM -0500, Tom Lane wrote:
>> Hmm, where is it then?
> getaddrinfo is a macro in :
Yes, we know that. The question was where does the macro point.
> The solution is to either revert to the 8.1.1 code (my recommendation)
>
On Mon, 20 Feb 2006, Jeroen T. Vermeulen wrote:
On Sun, February 19, 2006 05:10, Bruce Momjian wrote:
I don't care what direction we go, just kill one.
Speaking for libpqxx, my only concern with that is the mailing list.
Would those have to move to different addresses--or conversely, would a
On Sun, Feb 19, 2006 at 10:34:02AM -0800, elein wrote:
> On Sun, Feb 19, 2006 at 01:26:31AM -0500, Tom Lane wrote:
> > elein <[EMAIL PROTECTED]> writes:
> > > I've got a domain based on a text type.
> > > I've overridden the equal operator with
> > > lower(text) = lower(text).
> >
> > This won't w
On Sun, February 19, 2006 05:10, Bruce Momjian wrote:
> I don't care what direction we go, just kill one.
Speaking for libpqxx, my only concern with that is the mailing list.
Would those have to move to different addresses--or conversely, would a
forced migration make it much easier to move *all
On Sun, Feb 19, 2006 at 09:56:20PM -0500, Tom Lane wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
>
> > AC_REPLACE_FUNCS([getaddrinfo]) will not detect getaddrinfo() on Tru64
> > UNIX because getaddrinfo is not in libc.
>
> Hmm, where is it then?
getaddrinfo is a macro in :
#if defined (_SOC
Albert Chin <[EMAIL PROTECTED]> writes:
> On Sun, Feb 19, 2006 at 09:02:48PM -0500, Tom Lane wrote:
>> We changed that code specifically so it *would* work on Tru64 --- see
>> this thread:
>> http://archives.postgresql.org/pgsql-hackers/2006-01/msg00511.php
> From my reading, no completed patch wa
On Sun, Feb 19, 2006 at 09:02:48PM -0500, Tom Lane wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
> > AC_REPLACE_FUNCS([getaddrinfo]) won't correctly detect getaddrinfo on
> > Tru64 UNIX because the function doesn't exist under that name in libc.
>
> We changed that code specifically so it *woul
Albert Chin <[EMAIL PROTECTED]> writes:
> AC_REPLACE_FUNCS([getaddrinfo]) won't correctly detect getaddrinfo on
> Tru64 UNIX because the function doesn't exist under that name in libc.
We changed that code specifically so it *would* work on Tru64 --- see
this thread:
http://archives.postgresql.org
Not really, but you can check out the sample databases project:
http://pgfoundry.org/projects/dbsamples/
Chris
Ron wrote:
I assume we have such?
Ron
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Albert Chin <[EMAIL PROTECTED]> writes:
> On Sun, Feb 19, 2006 at 05:14:32PM -0500, Tom Lane wrote:
>> Why in the world would you not install 8.1.3 instead? Or are you hoping
>> to get burnt by one of the *other* bugs in 8.1.1?
> We've already deployed 8.1.1 to some customers. We will offer 8.1.3
uwcssa <[EMAIL PROTECTED]> writes:
> i am using psql client. On Fedora core (linux core: 2.4.20-8 )
> as well on Suze 10.0 (core: 2.6.13-15.7-smp). Both has the same problem.
Please send a test case (shell script that shows the behavior). I can
do
$ psql -f foo.sql doug
where 'foo.sql' in
i am using psql client. On Fedora core (linux core: 2.4.20-8 )
as well on Suze 10.0 (core: 2.6.13-15.7-smp). Both has the same problem.
thanks
/19/06, Mark Kirkwood <[EMAIL PROTECTED]> wrote:
> uwcssa wrote:
> > I am using version 8.0.3. i installed using the
> > --without-readline opti
uwcssa wrote:
I am using version 8.0.3. i installed using the
--without-readline option.
Platform and os version would be good too :-), along with the client you
are using to elicit this behavior (e.g, psql, Pgadmin etc).
Cheers
Mark
---(end of broadcast)
On Sun, Feb 19, 2006 at 11:34:21PM +0100, Martijn van Oosterhout wrote:
> On Sun, Feb 19, 2006 at 01:36:41PM -0800, elein wrote:
> > On Sun, Feb 19, 2006 at 10:29:35PM +0100, Martijn van Oosterhout wrote:
> > > On Sun, Feb 19, 2006 at 12:59:35PM -0800, elein wrote:
> > > > On Sun, Feb 19, 2006 at 0
On 2/20/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> A prepared xact is the same as an open xact as far as vacuum is
> concerned. It's a bad idea to sit on either open or prepared xacts
> for long periods ...
I completely understand that, however it can be occured...
Prepared xacts never die...
> >
AC_REPLACE_FUNCS([getaddrinfo]) won't correctly detect getaddrinfo on
Tru64 UNIX because the function doesn't exist under that name in libc.
>From :
#if defined (_SOCKADDR_LEN) || defined (_XOPEN_SOURCE_EXTENDED)
#define getaddrinfo ngetaddrinfo
#else
#define getaddrinfo ogetaddrinfo
#end
uwcssa <[EMAIL PROTECTED]> writes:
> I am using version 8.0.3. i installed using the
> --without-readline option.
What client are you using?
> is there a quick workaround?
The limit shouldn't be there. If you can post a test case that
demonstrates the problem, perhaps someone can help.
I am using version 8.0.3. i installed using the
--without-readline option.
is there a quick workaround?
On 2/19/06, Douglas McNaught <[EMAIL PROTECTED]> wrote:
> uwcssa <[EMAIL PROTECTED]> writes:
>
> > I found any query exceeds 4096 charactors will be pruned automatically. i
> am
> > won
On Sun, Feb 19, 2006 at 01:36:41PM -0800, elein wrote:
> On Sun, Feb 19, 2006 at 10:29:35PM +0100, Martijn van Oosterhout wrote:
> > On Sun, Feb 19, 2006 at 12:59:35PM -0800, elein wrote:
> > > On Sun, Feb 19, 2006 at 07:57:42PM +0100, Martijn van Oosterhout wrote:
> > > > ORDER BY x ASC is a synon
On Sun, Feb 19, 2006 at 05:14:32PM -0500, Tom Lane wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
> > Does the patch below look like the correct fix to CVE-2006-0553 if
> > running 8.1.1?
>
> Why in the world would you not install 8.1.3 instead? Or are you hoping
> to get burnt by one of the *o
On Feb 19, 2006, at 10:59 AM, Mark Woodward wrote:
"Mark Woodward" <[EMAIL PROTECTED]> writes:
DNS isn't always a better solution than /etc/hosts, both have
their pros
and cons. The /etc/hosts file is very useful for "instantaneous,"
reliable, and redundent name lookups. DNS services, espci
Albert Chin <[EMAIL PROTECTED]> writes:
> Does the patch below look like the correct fix to CVE-2006-0553 if
> running 8.1.1?
Why in the world would you not install 8.1.3 instead? Or are you hoping
to get burnt by one of the *other* bugs in 8.1.1?
regards, tom lane
-
Does the patch below look like the correct fix to CVE-2006-0553 if
running 8.1.1? I just scanned cvs log from the 8.1 branch, looking for
CVE-2006-0553 and picked out the diffs.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: src/backend/commands/variable.c
===
On Sun, Feb 19, 2006 at 04:35:56PM -0500, Andrew Dunstan wrote:
> Have you looked at the code of citext? Unless I'm misreading, it creates
> a lowercase copy of each string for each comparison. And it doesn't look
> to me like it's encoding/locale aware.
Its cilower function isn't terribly great
On Sun, Feb 19, 2006 at 10:29:35PM +0100, Martijn van Oosterhout wrote:
> On Sun, Feb 19, 2006 at 12:59:35PM -0800, elein wrote:
> > On Sun, Feb 19, 2006 at 07:57:42PM +0100, Martijn van Oosterhout wrote:
> > > ORDER BY x ASC is a synonym for ORDER BY x USING >. That's the way it
> > > is currently
Martijn van Oosterhout wrote:
On Sun, Feb 19, 2006 at 10:34:02AM -0800, elein wrote:
Actually I can do and have done this. It is being tested now.
I did create an opclass. It creates a UNIQUE index just fine
for the type using the lower() functionality. *If* it passes
all of my testing
FYI - as a positive enhancement, Greenplum donated a beefy server to host
pgFoundry.
- Luke
On 2/18/06 10:34 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Thomas Hallgren <[EMAIL PROTECTED]> writes:
>> Bruce Momjian wrote:
>>> Having run had both pgfoundary and gborg for several years, I think we
On Sun, Feb 19, 2006 at 12:59:35PM -0800, elein wrote:
> On Sun, Feb 19, 2006 at 07:57:42PM +0100, Martijn van Oosterhout wrote:
> > ORDER BY x ASC is a synonym for ORDER BY x USING >. That's the way it
> > is currently. To use ORDER BY by itself you need to call your operators
> > < and >.
> >
>
uwcssa <[EMAIL PROTECTED]> writes:
> I found any query exceeds 4096 charactors will be pruned automatically. i am
> wondering which knob should i change to make it larger , say, 1
> charactors. i searched for a while but was not able to find it online. so if
> anyone has a quick nswer that
I found any query exceeds 4096 charactors will be pruned automatically. i am wondering which knob should i change to make it larger , say, 1 charactors. i searched for a while but was not able to find it online. so if anyone has a quick nswer that will be highly appreciated.
On Sun, Feb 19, 2006 at 07:57:42PM +0100, Martijn van Oosterhout wrote:
> On Sun, Feb 19, 2006 at 10:34:02AM -0800, elein wrote:
> > Actually I can do and have done this. It is being tested now.
> > I did create an opclass. It creates a UNIQUE index just fine
> > for the type using the lower() fu
"Mark Woodward" <[EMAIL PROTECTED]> writes:
>> Um, is there something wrong with having multiple DNS servers in
>> resolv.conf? Other than having to time out on #1 before you try #2?
>> I'm genuinely curious.
>
> What is the "timeout" of that DNS lookup, before it goes to the second DNS
> server?
On Sun, Feb 19, 2006 at 10:34:02AM -0800, elein wrote:
> Actually I can do and have done this. It is being tested now.
> I did create an opclass. It creates a UNIQUE index just fine
> for the type using the lower() functionality. *If* it passes
> all of my testing I'll publish it tomorrow on ge
On Sun, Feb 19, 2006 at 01:26:31AM -0500, Tom Lane wrote:
> elein <[EMAIL PROTECTED]> writes:
> > I've got a domain based on a text type.
> > I've overridden the equal operator with
> > lower(text) = lower(text).
>
> This won't work, you need to make a type instead.
>
Actually I can do and have
> "Mark Woodward" <[EMAIL PROTECTED]> writes:
>
>> DNS isn't always a better solution than /etc/hosts, both have their pros
>> and cons. The /etc/hosts file is very useful for "instantaneous,"
>> reliable, and redundent name lookups. DNS services, espcially in a large
>> service environment can get
> Mark Woodward wrote:
>> Don't get me wrong, DNS, as it is designed, is PERFECT for the
>> distributed nature of the internet, but replication of fairly static
>> data under the control of a central authority (the admin) is better.
>
> What about this zeroconf/bonjour stuff? I'm not familiar with
> Martijn van Oosterhout writes:
>> I think the major issue is that most such systems (like RFC2782) deal
>> only with finding the hostname:port of the service and don't deal with
>> usernames/passwords/dbname. What we want is a system that not only
>> finds the service, but tells you enough to co
Martijn van Oosterhout writes:
> I think the major issue is that most such systems (like RFC2782) deal
> only with finding the hostname:port of the service and don't deal with
> usernames/passwords/dbname. What we want is a system that not only
> finds the service, but tells you enough to connect.
On Sun, Feb 19, 2006 at 12:13:48PM -0500, Tom Lane wrote:
> Florian Weimer <[EMAIL PROTECTED]> writes:
> > Uh-oh, this is my fault. PQescapeString should escape all characters
> > greater than 126.
>
> No, that doesn't work, because the de-escaping on the backend side
> happens *after* conversion
On Sat, Feb 18, 2006 at 02:49:08PM -0500, Tom Lane wrote:
> Perhaps we should make a concerted effort to split the libpq docs into a
> section "for programmers" vs one "for users", the latter part covering
> the libpq behavior that is interesting to users of a libpq-based app.
> .pgpass, pg_service
Florian Weimer <[EMAIL PROTECTED]> writes:
> Uh-oh, this is my fault. PQescapeString should escape all characters
> greater than 126.
No, that doesn't work, because the de-escaping on the backend side
happens *after* conversion to the backend encoding. If you insert escapes
into the middle of mu
"Satoshi Nagayasu" <[EMAIL PROTECTED]> writes:
> When I was playing with VACUUM, I found that if I have prepared xacts
> on the database A, I can't vacuum full on the database B.
A prepared xact is the same as an open xact as far as vacuum is
concerned. It's a bad idea to sit on either open or pr
"Mark Woodward" <[EMAIL PROTECTED]> writes:
> DNS isn't always a better solution than /etc/hosts, both have their pros
> and cons. The /etc/hosts file is very useful for "instantaneous,"
> reliable, and redundent name lookups. DNS services, espcially in a large
> service environment can get bogged
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Mark Woodward wrote:
>> Don't get me wrong, DNS, as it is designed, is PERFECT for the
>> distributed nature of the internet, but replication of fairly static
>> data under the control of a central authority (the admin) is better.
>
> What about this
On Sun, Feb 19, 2006 at 04:56:11PM +0100, Peter Eisentraut wrote:
> Mark Woodward wrote:
> > Don't get me wrong, DNS, as it is designed, is PERFECT for the
> > distributed nature of the internet, but replication of fairly static
> > data under the control of a central authority (the admin) is bette
Mark Woodward wrote:
> Don't get me wrong, DNS, as it is designed, is PERFECT for the
> distributed nature of the internet, but replication of fairly static
> data under the control of a central authority (the admin) is better.
What about this zeroconf/bonjour stuff? I'm not familiar with it, but
> On Sun, 2006-02-19 at 10:00 -0500, Mark Woodward wrote:
>> > On Fri, Feb 03, 2006 at 08:05:48AM -0500, Mark Woodward wrote:
>> >> Like I said, in this thread of posts, yes there are ways of doing
>> this,
>> >> and I've been doing it for years. It is just one of the rough eges
>> that
>> >> I
>>
> On Sun, Feb 19, 2006 at 10:00:01AM -0500, Mark Woodward wrote:
>> > It turns out what you like actually exists, lookup the "service"
>> > parameter in the connectdb string. It will read the values for the
>> > server, port, etc from a pg_service.conf file.
>> >
>> > There is an example in the tre
On Sun, Feb 19, 2006 at 09:58:01AM -0500, Douglas McNaught wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > A server-side (i.e. centrally managed) name server seems like an
> > improvement over the client-side solutions described, IMHO, but I'd
> > leave it to others to describe how that mig
Simon Riggs <[EMAIL PROTECTED]> writes:
> A server-side (i.e. centrally managed) name server seems like an
> improvement over the client-side solutions described, IMHO, but I'd
> leave it to others to describe how that might work. (e.g. DNS is a
> better solution than multiple distributed /etc/hos
On Sun, Feb 19, 2006 at 10:00:01AM -0500, Mark Woodward wrote:
> > It turns out what you like actually exists, lookup the "service"
> > parameter in the connectdb string. It will read the values for the
> > server, port, etc from a pg_service.conf file.
> >
> > There is an example in the tree but i
On Sun, 2006-02-19 at 10:00 -0500, Mark Woodward wrote:
> > On Fri, Feb 03, 2006 at 08:05:48AM -0500, Mark Woodward wrote:
> >> Like I said, in this thread of posts, yes there are ways of doing this,
> >> and I've been doing it for years. It is just one of the rough eges that
> >> I
> >> think coul
> On Fri, Feb 03, 2006 at 08:05:48AM -0500, Mark Woodward wrote:
>> Like I said, in this thread of posts, yes there are ways of doing this,
>> and I've been doing it for years. It is just one of the rough eges that
>> I
>> think could be smoother.
>>
>> (in php)
>> pg_connect("dbname=geo host=dbser
Hi again,
Meh, the list server didn't like the attached test script, so I put it
here:
http://people.debian.org/~mpitt/test-pg_restore-existing.sh
Martin
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
In a world wi
Hi again,
Tom Lane [2006-02-18 14:34 -0500]:
> >>> The core problem is that we want to not restore objects (mainly
> >>> tables) in the destination database which already exist.
> >>
> >> Why is this a problem? It's already the default behavior --- the
> >> creation commands fail but pg_restore k
On Sat, Feb 18, 2006 at 09:27:47PM -0800, elein wrote:
> I've got a domain based on a text type.
> I've overridden the equal operator with
> lower(text) = lower(text).
>
> I created a table containing my new domain type
> and can see that the equals operator is not
> being used to determine unique
Dave Page wrote:
Moving CVS is not a problem - each project has their own repo on both systems.
The problem is moving all the database stuff such as the bug trackers and todo
lists, for which I'm told there are no working scripts.
The other one that caused me great pain when I moved psqlODBC
On Thu, Feb 16, 2006 at 10:52:19AM -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Am Donnerstag, 16. Februar 2006 02:50 schrieb Tom Lane:
> >> That's fine for users, but what new demands are you about to place on
> >> developers? Does this require tools not already neede
Hi Tom!
Tom Lane [2006-02-18 14:34 -0500]:
> Hm. Rather than a variant of the -L facility (which is hard to use,
> and I don't see your proposal being much easier), maybe what's wanted
> is just a flag saying "don't try to restore data into any table whose
> creation command fails". Maybe that s
> >> Uh-oh, this is my fault. PQescapeString should escape all characters
> >> greater than 126. Unfortunately, there is nothing we can do about
> >> this in the current function because tha twould need four times the
> >> lenggth of the input string (plus one). Drat.
> >
> > Please don't do tha
* Tatsuo Ishii:
>> Uh-oh, this is my fault. PQescapeString should escape all characters
>> greater than 126. Unfortunately, there is nothing we can do about
>> this in the current function because tha twould need four times the
>> lenggth of the input string (plus one). Drat.
>
> Please don't d
> * Tatsuo Ishii:
>
> > Users can input value for "var" from a web form. The attacker inputs
> > following string:
> >
> > (0x95+0x27);DELETE FROM members;--
> >
> > where 0x95+0x27 is actually a SJIS mutibyte KANJI. Programmer applies
> > PQescapeString() to it and gets:
> >
> > 0x95+0x27+0x27;DE
* Tatsuo Ishii:
> Users can input value for "var" from a web form. The attacker inputs
> following string:
>
> (0x95+0x27);DELETE FROM members;--
>
> where 0x95+0x27 is actually a SJIS mutibyte KANJI. Programmer applies
> PQescapeString() to it and gets:
>
> 0x95+0x27+0x27;DELETE FROM members;--
-Original Message-
From: [EMAIL PROTECTED] on behalf of Joshua D. Drake
Sent: Sun 2/19/2006 12:35 AM
To: Bruce Momjian
Cc: Christopher Browne; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Pgfoundry and gborg: shut one down
> This is not "get everything everyone wants before shu
Hi all,
When I was playing with VACUUM, I found that if I have prepared xacts
on the database A, I can't vacuum full on the database B.
Scenario:
1.) Prepare some transaction on "testdb" database.
2.) Create database "pgbench".
3.) Run "pgbench -i" to load pgbench data on "pgbench" database
4.) D
69 matches
Mail list logo
