From Bill Todd's post:
This is the simple 'two-phase commit, presumed-abort' mechanism. It has no
problems guaranteeing distributed consistency, but does suffer from the
problem that if the coordinator *never* recovers some of the other nodes may
be left 'in doubt' about the
On Monday 23 June 2003 21:54, 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
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
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
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?
1) Avoid if
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
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'd
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
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
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: ' '
VERSION:
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
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 catcache is hardly an
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,
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)
, 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 analyze is your
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?
You
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.
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*
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 INDEX
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
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:'.'
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 wonder if that's
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, 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 fails, and I
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:15 +0200
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]
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
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 does not
, 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 connect to database
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
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
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 settings? Do
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
output
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 that string
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
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 easy to miss
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
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 when YACC is
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 project,
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.too.old and
, 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 special value like
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
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.
, 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 meant an echo
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
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 snapshot they
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.
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_update:
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
---(end
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
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
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
distribution? IF so,
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
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 do is
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
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.
I don't know
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 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 locale per connection,
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 think it's
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 record
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 bison's
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 changes
62 matches
Mail list logo
