Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think we should move /contrib/retep to gborg. It is 400k and isn't
> anywhere near our core functionality. I will add to TODO:
> Move /contrib/retep to gborg
> Can I move this during beta? I don't think so.
Why not?
Feature addition during be
I have put the latest patch at:
http://downloads.rhyme.com.au/postgresql/pg_dump/
along with two dump files of the regression DB, one with 4 byte
and the other with 8 byte offsets. I can read/restore each from
the other, so it looks pretty good. Once the endianness is tested,
we should be OK
At 12:07 AM 19/10/2002 +0200, Peter Eisentraut wrote:
Any old machine has a 4-byte off_t if you configure with
--disable-largefile.
Thanks - done. I just dumped to a custom backup file, then dumped it do
SQL, and compared each version (V7.2.1, 8 byte & 4 byte offsets), and they
all looked OK.
I am curious as to why it is necessary to add PL/pgSQL as a language
instead of including it by default.
Is it to save space on small systems or???
Since the code necessary PL/pgSQL is very small, it does not seem like
there would be much savings. I imagine that there is occasionally some
confusi
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> I am curious as to why it is necessary to add PL/pgSQL as a language
> instead of including it by default.
I believe security was one of the reasons.
regards, tom lane
---(end of broadcast)---
On Fri, Oct 18, 2002 at 10:28:38AM -0400, Tom Lane wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
> > On Thu, 2002-10-17 at 22:20, Tom Lane wrote:
> >> Simple: respond to 'em all with a one-line answer: "convince us why we
> >> should use it". The burden of proof always seems to fall on the wr
On 18 Oct 2002 at 18:10, Ulrich Neumann wrote:
> Marc,
>
> not only the global variables are a problem. PostgreSQL doesn't clean
> up
> all the memory before a process terminates and you must deal with
> signals between threads.
OK, first of all let me say this. I am interested in seeing postgre
going to be dealing with this this weekend ... Bruce already asked me as
well, just been busy during the week, so had to defer to the weekend ...
if its not in place by tomorrow around, so, 8pm GMT,please feel free to
email-nag me :)
On Fri, 18 Oct 2002, Michael Meskes wrote:
> Could anyone ple
On Fri, 18 Oct 2002, Mike Mascari wrote:
> Gavin Sherry wrote:
> > On Fri, 18 Oct 2002, Tom Lane wrote:
> >
> >
> >>Anyone see a way out of this catch-22? If not, which is the least
> >>bad alternative?
> >
> >
> > Ultimately, fix TRUNCATE to be transaction safe. This is non-trivial,
> > I kn
On Fri, 2002-10-18 at 22:03, Marc G. Fournier wrote:
> On Fri, 18 Oct 2002, Tom Lane wrote:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Larry Rosenman wrote:
> > >> Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly
> > >> by).
> >
> > > I can confirm that:
> > > htt
On Fri, 18 Oct 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Larry Rosenman wrote:
> >> Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly
> >> by).
>
> > I can confirm that:
> > http://ftp.gnu.org/gnu/bison/
> > Attached is the Changelog since 1.50.
I think we should move /contrib/retep to gborg. It is 400k and isn't
anywhere near our core functionality. I will add to TODO:
Move /contrib/retep to gborg
Can I move this during beta? I don't think so.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PRO
Mike Mascari wrote:
> Gavin Sherry wrote:
> > On Fri, 18 Oct 2002, Tom Lane wrote:
> >
> >
> >>Anyone see a way out of this catch-22? If not, which is the least
> >>bad alternative?
> >
> >
> > Ultimately, fix TRUNCATE to be transaction safe. This is non-trivial,
> > I know :-).
> >
> > Regar
Gavin Sherry wrote:
On Fri, 18 Oct 2002, Tom Lane wrote:
Anyone see a way out of this catch-22? If not, which is the least
bad alternative?
Ultimately, fix TRUNCATE to be transaction safe. This is non-trivial,
I know :-).
Regardless, the first option seems the less of the two evils.
Even
On Fri, 18 Oct 2002, Tom Lane wrote:
> Anyone see a way out of this catch-22? If not, which is the least
> bad alternative?
Ultimately, fix TRUNCATE to be transaction safe. This is non-trivial,
I know :-).
Regardless, the first option seems the less of the two evils.
Gavin
--
Bruce Momjian wrote:
Joe Conway wrote:
Bruce Momjian wrote:
most useful approach. The analogy to SET hadn't occurred to me.
Yea, the SET behavior appeared pretty queer to me, but now that I have
used it, I am getting used to it.
In the last case, the TRUNCATE will happen, and the INS
Joe Conway wrote:
> Bruce Momjian wrote:
> >>most useful approach. The analogy to SET hadn't occurred to me.
> >
> >
> > Yea, the SET behavior appeared pretty queer to me, but now that I have
> > used it, I am getting used to it.
> >
>
> So does that mean:
>
>set autocommit to off;
>b
Bruce Momjian wrote:
most useful approach. The analogy to SET hadn't occurred to me.
Yea, the SET behavior appeared pretty queer to me, but now that I have
used it, I am getting used to it.
So does that mean:
set autocommit to off;
begin;
insert into foo values('a');
insert into ba
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > ... I think we
> > should just do an automatic COMMIT if it is the first statement of a
> > transaction, and if not, throw the same error we used to throw. We are
> > performing autocommit for SET at the start of a transaction now any
Bruce Momjian <[EMAIL PROTECTED]> writes:
> ... I think we
> should just do an automatic COMMIT if it is the first statement of a
> transaction, and if not, throw the same error we used to throw. We are
> performing autocommit for SET at the start of a transaction now anyway,
> so it isn't totally
Tom Lane wrote:
> There are a number of statements, such as TRUNCATE TABLE, that refuse to
> run in a transaction block because they perform actions that can't be
> rolled back later.
>
> These statements currently do not look at autocommit, which means that
> if autocommit is off, their tests wil
Tom Lane wrote:
There are a number of statements, such as TRUNCATE TABLE, that refuse to
run in a transaction block because they perform actions that can't be
rolled back later.
These statements currently do not look at autocommit, which means that
if autocommit is off, their tests will succeed .
There are a number of statements, such as TRUNCATE TABLE, that refuse to
run in a transaction block because they perform actions that can't be
rolled back later.
These statements currently do not look at autocommit, which means that
if autocommit is off, their tests will succeed ... but then a
tra
Neil Conway <[EMAIL PROTECTED]> writes:
> I see the following error with the current CVS code:
> copy.c:425: `errno' undeclared (first use in this function)
Hmm. Needs a "#include " seemingly; but surely that error
has been there awhile?
(light dawns...) I'll bet it was masked by all the bogus
I see the following error with the current CVS code:
make[3]: Entering directory `/home/nconway/pgsql/src/backend/commands'
[ ... ]
gcc -O2 -DLINUX_PROFILE -g -pg -Wall -Wmissing-prototypes -Wmissing-declarations
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The HAS_CRYPT_R is true because the function is available even without the
> prototype, but the struct is not. A plain bug in Perl's configury
> mechanism.
Yeah, that's true. The question is whether it's worth working around
the bug. IMHO, yes -- but
Peter Eisentraut wrote:
> Michael Meskes writes:
>
> > Could anyone please tell me if we found a solution? It seems I missed
> > any discussion or whatsoever. The only things I know is that
> > postgresql.org still has bison 1.35 installed and 7.3 release is
> > nearing.
>
> I suggest that you me
$ ./clusterdb
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
psql: could not connect to server: No such file or directory
Is the server running locally and accep
Michael Meskes writes:
> Could anyone please tell me if we found a solution? It seems I missed
> any discussion or whatsoever. The only things I know is that
> postgresql.org still has bison 1.35 installed and 7.3 release is
> nearing.
I suggest that you merge your branch as soon as you are ready
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I am cleaning up /contrib by adding "autocommit = 'on'"
>
> Is everyone in the world now required to add "autocommit = on" in all
> scripts, interfaces, programs, applications that are not strictly personal
> use? Is there no better solution?
Philip Warner writes:
>
> I have made the changes to pg_dump and verified that (a) it reads old
> files, (b) it handles 8 byte offsets, and (c) it dumps & seems to restore
> (at least to /dev/null).
>
> I don't have a lot of options for testing it - should I just apply the
> changes and wait for t
Neil Conway writes:
> #ifdef HAS_CRYPT_R
> #if CRYPT_R_PROTO == REENTRANT_PROTO_B_CCD
> CRYPTD* _crypt_data;
> #else
> struct crypt_data _crypt_struct;
> #endif
> #endif /* HAS_CRYPT_R */
>
> The "crypt_data" struct is defined in crypt.h, but only if _GNU_SOURCE
> is defined -- just li
On Fri, 2002-10-18 at 13:51, Tom Lane wrote:
> Michael Meskes <[EMAIL PROTECTED]> writes:
> >> those now, you can, because I assume your bison 1.50 output will get
> >> into CVS. I have bison 1.50 here too.
>
> > The changes are there already, I just have to fold the ecpg.big branch
> > into HEAD
Michael,
Please post instead of sending private email.
On Fri, Oct 18, 2002 at 12:08:02PM +0200, Michael Steiner wrote:
> FAQ says: "A native port to MS Win NT/2000/XP is currently being worked
> on."
>
> => When is it expected to be available as a stable release?
I don't know.
> Will it be ba
Michael Meskes <[EMAIL PROTECTED]> writes:
>> those now, you can, because I assume your bison 1.50 output will get
>> into CVS. I have bison 1.50 here too.
> The changes are there already, I just have to fold the ecpg.big branch
> into HEAD.
Probably you should refrain from doing that until Marc
Michael Meskes <[EMAIL PROTECTED]> writes:
> I was just approached with an optimizer question I cannot answer. Does
> our optimizer know how expensive different comparisons are?
It does not, because there's noplace it could look to find the info.
> If there are different comparisons in a where cl
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> pg_encoding doesn't reject invalid input (like 'pg_encoding foo'). I
> think it should exit with a non-zero status.
Seems reasonable to me ... shouldn't it complain on stderr as well?
regards, tom lane
--
On Fri, Oct 18, 2002 at 11:48:33AM -0400, Bruce Momjian wrote:
> Yes, we are going to upgrade to bison 1.50 on our main server as soon as
> Marc gets it installed. If you want to make your changes and commit
Okay.
> those now, you can, because I assume your bison 1.50 output will get
> into CVS.
Hi,
I was just approached with an optimizer question I cannot answer. Does
our optimizer know how expensive different comparisons are? That is can
it do something like:
If there are different comparisons in a where clause check the ints
first, then the strings, then everything with regexp, or lik
Seems we aren't the only ones concerned about memset-like optimizations:
http://www.bsdforums.org/forums/showthread.php?threadid=3778
This talks about using MMX assembly instructions for memcpy.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
Teodor Sigaev writes:
> wow=# select 5.3::float;
> ERROR: Bad float8 input format '5.3'
Does it accept '5,4'::float? Try running initdb with --locale=C.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsu
Marc,
not only the global variables are a problem. PostgreSQL doesn't clean
up
all the memory before a process terminates and you must deal with
signals between threads.
I've modified PostgreSQL that it is completely thread based and nearly
clean
with allocating/deallocating memory and I'm using
pg_encoding doesn't reject invalid input (like 'pg_encoding foo'). I
think it should exit with a non-zero status.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Fri, 2002-10-18 at 09:28, Tom Lane wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
> > On Thu, 2002-10-17 at 22:20, Tom Lane wrote:
> >> Simple: respond to 'em all with a one-line answer: "convince us why we
> >> should use it". The burden of proof always seems to fall on the wrong
> >> end
Yes, we are going to upgrade to bison 1.50 on our main server as soon as
Marc gets it installed. If you want to make your changes and commit
those now, you can, because I assume your bison 1.50 output will get
into CVS. I have bison 1.50 here too.
---
Could anyone please tell me if we found a solution? It seems I missed
any discussion or whatsoever. The only things I know is that
postgresql.org still has bison 1.35 installed and 7.3 release is
nearing.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux
Tom Lane wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
> > On Thu, 2002-10-17 at 22:20, Tom Lane wrote:
> >> Simple: respond to 'em all with a one-line answer: "convince us why we
> >> should use it". The burden of proof always seems to fall on the wrong
> >> end in these discussions.
>
> >
Greg Copeland <[EMAIL PROTECTED]> writes:
> On Thu, 2002-10-17 at 22:20, Tom Lane wrote:
>> Simple: respond to 'em all with a one-line answer: "convince us why we
>> should use it". The burden of proof always seems to fall on the wrong
>> end in these discussions.
> ... Now, it seems, that
> peop
Mats Lofkvist <[EMAIL PROTECTED]> writes:
> It does indeed look like a great improvement, so is the fix
> going to be merged to the 7.3 branch or is it too late for that?
Yes, been there done that ...
regards, tom lane
---(end of broadcast)
On Thu, 2002-10-17 at 22:20, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Let me add one more thing on this "thread". This is one email in a long
> > list of "Oh, gee, you aren't using that wizz-bang new
> > sync/thread/aio/raid/raw feature" discussion where someone shows up and
Philip Warner <[EMAIL PROTECTED]> writes:
> I don't have a lot of options for testing it - should I just apply the
> changes and wait for the problems, or can someone offer a bigendian machine
> and/or a 4 byte off_t machine?
My HP is big-endian; send in the patch and I'll check it here...
[EMAIL PROTECTED] (Tom Lane) writes:
[snip]
>
> So this does seem to be a nice win, and unless I hear objections
> I will apply it ...
>
It does indeed look like a great improvement, so is the fix
going to be merged to the 7.3 branch or is it too late for that?
_
Mats Lofkvist
[EMAIL PRO
52 matches
Mail list logo
