It seems that a value of addr->ai_socktype returned by getaddrinfo in
pg_stat.c is not SOCK_DGRAM.
Kenji Sugita
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 2 Jul 2003, Behdad Esfahbod wrote:
>> so I have wrote my 10lines function as a wrapper around
>> setlocale, that is attached.
> Hmm, I'd think there'd be some potential for danger there. I don't play
> with the locale stuff, but if the collation
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > This would turn off the make failure when an old bison is called from
> > the makefile?
>
> Rephrase that as "this would give bison the right to fail of its own
> accord, rather than our prejudging its ability to cope."
>
> Given bis
Bruce Momjian <[EMAIL PROTECTED]> writes:
> This would turn off the make failure when an old bison is called from
> the makefile?
Rephrase that as "this would give bison the right to fail of its own
accord, rather than our prejudging its ability to cope."
Given bison's on-again-off-again track re
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I don't see a reason to have a flag to turn it off --- has anyone
> > reported that the version check failed?
>
> Since that version check has only been in CVS tip a month or two, and
> has not seen a release cycle, it'd be folly to t
On Wed, 2 Jul 2003, Behdad Esfahbod wrote:
> On Tue, 1 Jul 2003, Stephan Szabo wrote:
>
> >
> > On Wed, 2 Jul 2003, Behdad Esfahbod wrote:
> >
> > > I'm new to the list, so don't flame at the first date ;).
> > >
> > > I usually use PostgreSQL for multiple languages, so I needed to
> > > set local
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't see a reason to have a flag to turn it off --- has anyone
> reported that the version check failed?
Since that version check has only been in CVS tip a month or two, and
has not seen a release cycle, it'd be folly to think it's bulletproof.
On Tue, 1 Jul 2003, Stephan Szabo wrote:
>
> On Wed, 2 Jul 2003, Behdad Esfahbod wrote:
>
> > I'm new to the list, so don't flame at the first date ;).
> >
> > I usually use PostgreSQL for multiple languages, so I needed to
> > set locale per connection, or can change the locale on the fly.
> >
On Wed, 2 Jul 2003, Behdad Esfahbod wrote:
> I'm new to the list, so don't flame at the first date ;).
>
> I usually use PostgreSQL for multiple languages, so I needed to
> set locale per connection, or can change the locale on the fly.
> I don't know if there is any such ability integrated in or
> I usually use PostgreSQL for multiple languages, so I needed to
> set locale per connection, or can change the locale on the fly.
> I don't know if there is any such ability integrated in or not,
> so I have wrote my 10lines function as a wrapper around
> setlocale, that is attached. So what I d
On Wed, Jul 02, 2003 at 07:22:51AM +0430, Behdad Esfahbod wrote:
> Another silly question, isn't any way to get rid of seqscan, when
> doing 'SELECT count(*) FROM tab;'?
No :-( If you want to do that frequently, you should try to find
another way to keep the count.
--
Alvaro Herrera ()
"Crear
On Tue, 1 Jul 2003, Jan Wieck wrote:
> Marc G. Fournier wrote:
> > On Wed, 25 Jun 2003, Robert Treat wrote:
> >
> >> Seems like we should also allow for a windows specific distribution of libpq
> >> as well.
> >
> > I thought that the win32 stuff was being included as part of the base
> > distribu
Hi all,
I'm new to the list, so don't flame at the first date ;).
I usually use PostgreSQL for multiple languages, so I needed to
set locale per connection, or can change the locale on the fly.
I don't know if there is any such ability integrated in or not,
so I have wrote my 10lines function a
Yes, I was wrong. I now see it can't be a loadable module. I actually
thought it was for data warehousing and not standard SQL.
---
Christopher Kings-Lynne wrote:
> > First, read the developer's FAQ. Second, you probably w
> First, read the developer's FAQ. Second, you probably will want to look
> at /contrib and see if it can be made into a loadable module. I am not
> sure we would want to have the datacube stuff in the main backend source
> tree.
Why not? It's in SQL99...
Chris
---(en
> There would be *zero* activity on a table undergoing vacuum full, unless
> your app has found a way around vacuum full's exclusive lock. You sure
> this wasn't a plain vacuum?
Hmm...correct. So I don't know what happened.
> > Then vacuum full failed after a while:
> > ERROR: simple_heap_upda
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I can see making a new bison required only when the version is *devel.
> > That way, folks testing CVS and even the *devel snapshots would need a
> > new bison, but our normal users wouldn't.
>
> Even then, if they're using a snapsho
Is it not possible to check when configure is run for the presence of the
bison output files, and only fail if one or more is absent and the bison
version is too low?
just a thought.
andrew
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Bruce Momjian" <[EMAIL PROTECTED]
Marc G. Fournier wrote:
On Wed, 25 Jun 2003, Robert Treat wrote:
Seems like we should also allow for a windows specific distribution of libpq
as well.
I thought that the win32 stuff was being included as part of the base
distribution? IF so, wouldn't such already be included in any
libpq.tar.gz w
В Срд, 02.07.2003, в 01:10, Alvaro Herrera пишет:
> On Wed, Jul 02, 2003 at 12:56:11AM +0200, Markus Bertheau wrote:
>
> > Maybe add a comment to the Makefile where bison is called that gives a
> > hint to the user in case bison fails.
>
> Not too many people read Makefiles these days
Sorry, I me
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I can see making a new bison required only when the version is *devel.
> That way, folks testing CVS and even the *devel snapshots would need a
> new bison, but our normal users wouldn't.
Even then, if they're using a snapshot they shouldn't need it.
P
On Wed, Jul 02, 2003 at 12:56:11AM +0200, Markus Bertheau wrote:
> But it seems weird to require a switch for the normal case, i.e. a
> tarball build, and not require it for a cvs build.
Yeah, I agree. Maybe the configure script should be built different for
the releases, so users downloading ta
В Срд, 02.07.2003, в 00:42, Tom Lane пишет:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Maybe make configure act as though bison is missing? Not sure. It
> >> seems like that could create unnecessary problems in other cases.
>
> > One trick would be to set YACC to some s
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Maybe make configure act as though bison is missing? Not sure. It
> >> seems like that could create unnecessary problems in other cases.
>
> > One trick would be to set YACC to some special value like
> > "bison
Larry Rosenman <[EMAIL PROTECTED]> writes:
> what version of bison are you using? I believe we require 1.875
> these days.
It would be nice to be able to say --without-ecpg at configure time.
Ecpg is the only part of pg that requires this version of bison and
and is not a core part of the projec
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Maybe make configure act as though bison is missing? Not sure. It
>> seems like that could create unnecessary problems in other cases.
> One trick would be to set YACC to some special value like
> "bison.too.old" and test for that wh
Usual installs don't need bison because the tarball has pregenerated
bison output files.
---
Alvaro Herrera wrote:
> On Tue, Jul 01, 2003 at 06:12:31PM -0400, Tom Lane wrote:
> >
> > I believe 'configure' will bleat about a
Tom Lane wrote:
> Markus Bertheau <[EMAIL PROTECTED]> writes:
> >> what version of bison are you using? I believe we require 1.875 these days.
>
> > 1.35. I'll upgrade. Thanks.
>
> I believe 'configure' will bleat about a too-old bison, but it won't
> refuse to proceed --- and the warning is eas
On Tue, Jul 01, 2003 at 06:12:31PM -0400, Tom Lane wrote:
>
> I believe 'configure' will bleat about a too-old bison, but it won't
> refuse to proceed --- and the warning is easy to miss in the pages of
> output that configure produces.
Maybe it should throw an error and refuse to continue if the
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The best way is to use pg_get_indexdef(indexOID), same as pg_dump and
>> psql do.
> [ doesn't want to parse the pg_get_indexdef output... ]
Well, I guess if you just want one column it's kind of a pain.
> pg_get_indexdef converts tha
Markus Bertheau <[EMAIL PROTECTED]> writes:
>> what version of bison are you using? I believe we require 1.875 these days.
> 1.35. I'll upgrade. Thanks.
I believe 'configure' will bleat about a too-old bison, but it won't
refuse to proceed --- and the warning is easy to miss in the pages of
outp
Markus Bertheau <[EMAIL PROTECTED]> writes:
>>> make check fails, and I have absolutely no idea where to look:
>>
>> (scratches head...) make check should automatically adopt your current
>> username as the postgres superuser name, AFAIK. Perhaps there is some
>> conflict in your environment sett
Stuart wrote:
Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
As a side question, it looks to me that the code stores the first trigger
records in memory and then after some point starts storing all new records
on disk. Is this correct? I'd wonder if that's really what you want in
gen
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
I noticed the new expression functionality of indices and while
implementing them in pgadmin3 was wonderingnow to extract the definition
from the catalog.
The best way is to use pg_get_indexdef(indexOID), same as pg_dump and
psql
В Втр, 01.07.2003, в 23:30, Tom Lane пишет:
> Markus Bertheau <[EMAIL PROTECTED]> writes:
> > make check fails, and I have absolutely no idea where to look:
>
> > running on port 65432 with pid 631
> > == creating database "regression" ==
> > createdb: could not con
Markus Bertheau <[EMAIL PROTECTED]> writes:
> make check fails, and I have absolutely no idea where to look:
> running on port 65432 with pid 631
> == creating database "regression" ==
> createdb: could not connect to database template1: FATAL: user
> "postgres" do
The Postgres core committee would like to announce that we are now in
feature-freeze mode for the 7.4 release.
All patches already received in pgsql-patches will be considered in the
usual fashion (and yes, we'll allow some slack for fixing problems in
them). New features arriving in the future w
Are you looking for:
gmake installcheck
LER
--On Tuesday, July 01, 2003 17:21:37 -0400 Jeff <[EMAIL PROTECTED]>
wrote:
On Tue, Jul 01, 2003 at 11:09:15PM +0200, Markus Bertheau wrote:
Subject: Re: [HACKERS] make check fails: user "postgres" doesn't exist
From: Markus Bertheau <[EMAIL PROTECTED
On Tue, Jul 01, 2003 at 11:09:15PM +0200, Markus Bertheau wrote:
> Subject: Re: [HACKERS] make check fails: user "postgres" doesn't exist
> From: Markus Bertheau <[EMAIL PROTECTED]>
> To: Jeff <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> X-Mailer: Ximian Evolution 1.4.0
> Date: 01 Jul 2003 23:09:
В Втр, 01.07.2003, в 22:53, Jeff пишет:
> On Tue, Jul 01, 2003 at 10:28:12PM +0200, Markus Bertheau wrote:
> > make check fails, and I have absolutely no idea where to look:
> >
> > running on port 65432 with pid 631
> > == creating database "regression" ==
> > crea
On Tue, Jul 01, 2003 at 10:28:12PM +0200, Markus Bertheau wrote:
> Subject: [HACKERS] make check fails: user "postgres" doesn't exist
> From: Markus Bertheau <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> X-Mailer: Ximian Evolution 1.4.0
> Date: 01 Jul 2003 22:28:12 +0200
>
> Hi,
>
> make check
Hi,
make check fails, and I have absolutely no idea where to look:
running on port 65432 with pid 631
== creating database "regression" ==
createdb: could not connect to database template1: FATAL: user
"postgres" does not exist
pg_regress: createdb failed
make: *
On Tue, 1 Jul 2003, Stuart wrote:
> Tom Lane wrote:
>
> > Stephan Szabo <[EMAIL PROTECTED]> writes:
> >
> >>As a side question, it looks to me that the code stores the first trigger
> >>records in memory and then after some point starts storing all new records
> >>on disk. Is this correct? I'd w
Oleg Bartunov kirjutas T, 01.07.2003 kell 15:49:
> Hi there,
>
> attached archive contains simple parser demonstrating our
> problem. untar it, make, make test
>
> Good test:
> echo -n 12 34.1234 ... | ./parser
> INTEGER:'12'
> CHAR: ' '
> VERSION:'34.1234'
> CHAR: ' '
> DOT:
CVS checks for an old bison, though it just throws a warning, not an
error.
---
Markus Bertheau wrote:
> ? ???, 01.07.2003, ? 21:41, Larry Rosenman ?:
> > what version of bison are you using? I believe we require 1.875
Dear PostgreSQL community,
it is with great pleasure that I would like to let you all know that I
recently joined Afilias, a domain name registry services company that
runs the .info top level domain and also provides core registry services
to .org and a variety of other country code TLDs. (http:/
Andreas Pflug <[EMAIL PROTECTED]> writes:
> I noticed the new expression functionality of indices and while
> implementing them in pgadmin3 was wonderingnow to extract the definition
> from the catalog.
The best way is to use pg_get_indexdef(indexOID), same as pg_dump and
psql do.
> CREATE
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I was running a long-running vacuum full, and then halfway thru that our
> background vacuum process started. As well as this, there was light
> activity on a users table from which vacuum full was removing 9 rows.
There would be *zero*
First, read the developer's FAQ. Second, you probably will want to look
at /contrib and see if it can be made into a loadable module. I am not
sure we would want to have the datacube stuff in the main backend source
tree.
On Tue, Jul 01, 2003 at 09:39:59PM +0200, Markus Bertheau wrote:
> bison -y -d preproc.y
> preproc.y:6214: fatal error: maximum table size (32767) exceeded
> make[4]: *** [preproc.h] Error 1
> make[4]: Leaving directory
> `/home/bert/src/pgsql/src/interfaces/ecpg/preproc'
>
> What's the problem?
В Втр, 01.07.2003, в 21:41, Larry Rosenman пишет:
> what version of bison are you using? I believe we require 1.875 these days.
1.35. I'll upgrade. Thanks.
--
Markus Bertheau.
Berlin, Berlin.
Germany.
---(end of broadcast)---
TIP 8: explain analy
what version of bison are you using? I believe we require 1.875 these days.
LER
--On Tuesday, July 01, 2003 21:39:59 +0200 Markus Bertheau
<[EMAIL PROTECTED]> wrote:
Hi,
I'm trying to build cvs, but it fails:
bison -y -d preproc.y
preproc.y:6214: fatal error: maximum table size (32767) exce
Hi,
I'm trying to build cvs, but it fails:
bison -y -d preproc.y
preproc.y:6214: fatal error: maximum table size (32767) exceeded
make[4]: *** [preproc.h] Error 1
make[4]: Leaving directory
`/home/bert/src/pgsql/src/interfaces/ecpg/preproc'
What's the problem?
--
Markus Bertheau.
Berlin, Berl
Mendola Gaetano wrote:
> "Tom Lane" <[EMAIL PROTECTED]> wrote:
> > "Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> > > I'm improving the Dllist in these direction:
> >
> > AFAIR, catcache.c is the *only* remaining backend customer for Dllist,
> > and so any improvement for Dllist that breaks catcac
On Mon, 2003-06-23 at 16:24, Hans-Jürgen Schönig wrote:
> A few days ago I have posted a pre-beta version of dblink_ora which is
> supposed to solve some problems we had here at Cybertec (getting data
> from an Oracle DB and merge it with PostgreSQL). I have implemented a
> simple piece of code
Sorry,
forgot to attach archive :)
Oleg
On Tue, 1 Jul 2003, Oleg Bartunov wrote:
> Hi there,
>
> attached archive contains simple parser demonstrating our
> problem. untar it, make, make test
>
> Good test:
> echo -n 12 34.1234 ... | ./parser
> INTEGER:'12'
> CHAR: ' '
> VERSIO
Hi there,
attached archive contains simple parser demonstrating our
problem. untar it, make, make test
Good test:
echo -n 12 34.1234 ... | ./parser
INTEGER:'12'
CHAR: ' '
VERSION:'34.1234'
CHAR: ' '
DOT:'.'
DOT:'.'
DOT:'.'
Wrong:
echo -n 12 34.1234. ... | ./parser
On Mon, 23 Jun 2003, Hans-Jürgen Schönig wrote:
> A few days ago I have posted a pre-beta version of dblink_ora which is
> supposed to solve some problems we had here at Cybertec (getting data
> from an Oracle DB and merge it with PostgreSQL). I have implemented a
> simple piece of code (more p
Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
As a side question, it looks to me that the code stores the first trigger
records in memory and then after some point starts storing all new records
on disk. Is this correct? I'd wonder if that's really what you want in
general, since I'
I noticed the new expression functionality of indices and while
implementing them in pgadmin3 was wonderingnow to extract the definition
from the catalog.
Consider an index that looks like this:
CREATE INDEX foo ON bar (numcol, length(txtcol), intcol2,
length(txtcol2))
Looking at pg_index:
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> > I'm improving the Dllist in these direction:
>
> AFAIR, catcache.c is the *only* remaining backend customer for Dllist,
> and so any improvement for Dllist that breaks catcache is hardly an
> improvement, no?
Hi,
I was running a long-running vacuum full, and then halfway thru that our
background vacuum process started. As well as this, there was light
activity on a users table from which vacuum full was removing 9 rows.
Then vacuum full failed after a while:
ERROR: simple_heap_update: tuple con
elein kirjutas T, 24.06.2003 kell 00:42:
There is a realtively clean hack one can use to convert plpython
functions to plpythonu manually - just rename the language for the time
of loading functions - do as superuser
update pg_language set lanname = 'plpython' where lanname = 'plpythonu';
LOAD Y
63 matches
Mail list logo
