Marc,
will hub.org::postgresql-ftp works
Oleg
On Sun, 30 Sep 2001, Marc G. Fournier wrote:
>
> now that the 18gig is in place and I have space once more to work,
> ftp.postgresql.org now points at the new server (~ftp for those that
> login) ... let me know if there are any problems ...
Something is broken with anon cvs:
cvs server: Updating pgsql/contrib/pgstattuple
cvs server: failed to create lock directory for
/projects/cvsroot/pgsql/contrib/pgstattuple'
(/projects/cvsroot/pgsql/contrib/pgstattuple/#cvs.lock): Permission denied
cvs server: failed to obtain dir lock in repo
"Joe Conway" <[EMAIL PROTECTED]> writes:
> I just grabbed cvs tip this afternoon and ran into two issues:
> - First one is that the regression fails on "geometry" on what appears to be
> a difference in the 13th decimal place of the output value. See the attached
> regression diff.
Looks like it
Per Tom's request(1000 concurrent backends), I tried current on IBM
AIX 5L and found that make check hungs:
parallel group (13 tests): float4 oid varchar
pgbench hungs too if more than 4 or so concurrent backends are
involved. Unfortunately gdb does not work well on AIX, so I'm stucked.
Maybe a
At 08:16 PM 30-09-2001 -0600, Steve Wolfe wrote:
>> >
>> > How hard would it be to pre-fork an extra backend for the database a
>> > user just requested so if they next user asks for the same database, the
>> > backend would already be started?
>
> Perhaps I'm missing something, but it seems to m
> > >
> > > How hard would it be to pre-fork an extra backend for the database a
> > > user just requested so if they next user asks for the same database, the
> > > backend would already be started?
>
> Perhaps I'm missing something, but it seems to me that the cost of forking
> a new backend
I just grabbed cvs tip this afternoon and ran into two issues:
- First one is that the regression fails on "geometry" on what appears to be
a difference in the 13th decimal place of the output value. See the attached
regression diff.
- Second was on reloading my data, I got the following error me
web server and ftp server are now on the same machine, actually .
everything is now merged together once more ...
On Sun, 30 Sep 2001, Bruce Momjian wrote:
> >
> > now that the 18gig is in place and I have space once more to work,
> > ftp.postgresql.org now points at the new server (~ftp fo
> >
> > How hard would it be to pre-fork an extra backend for the database a
> > user just requested so if they next user asks for the same database, the
> > backend would already be started?
Perhaps I'm missing something, but it seems to me that the cost of forking
a new backend would be prett
> This is a well-known problem: plpgsql caches a query plan that refers
> to the first version of the temp table, and it doesn't know it needs
> to rebuild the plan. AFAIK the only workaround at present is to use
> EXECUTE for queries referencing the temp table.
But EXECUTE does not support sele
On Sun, 30 Sep 2001, Bruce Momjian wrote:
> > On Mon, 1 Oct 2001, Peter Eisentraut wrote:
> >
> > > Bruce Momjian writes:
> > >
> > > > Don't rush. I am setting up my system to check the SGML docs every 15
> > > > minutes and rebuild if necessary. Overnight builds are not frequent
> > > > enoug
> On Sun, 30 Sep 2001, Bruce Momjian wrote:
>
> > > On Mon, 1 Oct 2001, Peter Eisentraut wrote:
> > >
> > > > Bruce Momjian writes:
> > > >
> > > > > Don't rush. I am setting up my system to check the SGML docs every 15
> > > > > minutes and rebuild if necessary. Overnight builds are not freque
> On Mon, 1 Oct 2001, Peter Eisentraut wrote:
>
> > Bruce Momjian writes:
> >
> > > Don't rush. I am setting up my system to check the SGML docs every 15
> > > minutes and rebuild if necessary. Overnight builds are not frequent
> > > enough for people modifying the SGML files.
> >
> > This is n
> Bruce Momjian writes:
>
> > Don't rush. I am setting up my system to check the SGML docs every 15
> > minutes and rebuild if necessary. Overnight builds are not frequent
> > enough for people modifying the SGML files.
>
> This is news to me... Do you mean you commit stuff and then wait 15
>
Jean-Michel POURE wrote:
>
> Hello friends,
>
> int4eq (xid, int4) seems to be needed for proper support of MS Access2K:
> CREATE FUNCTION "int4eq" (xid, int4)
> RETURNS bool
> AS 'int4eq'
> LANGUAGE 'internal'
>
> Is int4eq function included in PostgreSQL 7.2?
I added a '=' operator between xi
I have just found a nasty portability problem in the new statistics
stuff. It assumes that it can store int64 values in hashtable entries
... but the dynahash module hands back pointers that are only aligned
to sizeof(long). On a machine where int64 has to be 8-byte-aligned,
instant coredump.
I
On Mon, 1 Oct 2001, Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Don't rush. I am setting up my system to check the SGML docs every 15
> > minutes and rebuild if necessary. Overnight builds are not frequent
> > enough for people modifying the SGML files.
>
> This is news to me... Do y
Bruce Momjian writes:
> Don't rush. I am setting up my system to check the SGML docs every 15
> minutes and rebuild if necessary. Overnight builds are not frequent
> enough for people modifying the SGML files.
This is news to me... Do you mean you commit stuff and then wait 15
minutes to see
>
> Once we have schemas (7.3, I hope), I think a lot of installations will
> have only one production database. However, if we were going to do this
> what we'd probably do is allow the DBA to configure the postmaster to
> start N pre-forked backends per database, where N can depend on the
> d
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, I think we are on track for Monday beta.
>
> One thing that I think absolutely *must* happen before we can go beta
> is to fix the documentation build process at hub.org. Until the online
> developer docs are up-to-date, how are beta testers go
> On Sun, 30 Sep 2001, Bruce Momjian wrote:
>
>
> > >
> > >
> > > just about to be moved to the new server, now that the new 18gi drive has
> > > been installed ... plan on getting that done this afternoon ...
> >
> > Don't rush. I am setting up my system to check the SGML docs every 15
> > min
On Sun, 30 Sep 2001, Bruce Momjian wrote:
> >
> >
> > just about to be moved to the new server, now that the new 18gi drive has
> > been installed ... plan on getting that done this afternoon ...
>
> Don't rush. I am setting up my system to check the SGML docs every 15
> minutes and rebuild if
>
> now that the 18gig is in place and I have space once more to work,
> ftp.postgresql.org now points at the new server (~ftp for those that
> login) ... let me know if there are any problems ...
I wonder if we should be allowing people to use non-anonymous ftp. There is
no password protection
Marko Kreen <[EMAIL PROTECTED]> writes:
> I am suggesting this.
> [ code snipped ]
Okay, that would mean that "-o '-S nnn'" still works, but "-o -F"
doesn't.
But ... the thing is, there is no reason for -o to exist anymore other
than backwards compatibility with existing startup scripts. -o doe
now that the 18gig is in place and I have space once more to work,
ftp.postgresql.org now points at the new server (~ftp for those that
login) ... let me know if there are any problems ...
---(end of broadcast)---
TIP 5: Have you checked our ext
done already, ftp should be accessible as it was before ...
On Sun, 30 Sep 2001, Bruce Momjian wrote:
> >
> >
> > just about to be moved to the new server, now that the new 18gi drive has
> > been installed ... plan on getting that done this afternoon ...
>
> Don't rush. I am setting up my sys
>
>
> just about to be moved to the new server, now that the new 18gi drive has
> been installed ... plan on getting that done this afternoon ...
Don't rush. I am setting up my system to check the SGML docs every 15
minutes and rebuild if necessary. Overnight builds are not frequent
enough fo
On Sun, Sep 30, 2001 at 02:13:34PM -0400, Bruce Momjian wrote:
> > Marko Kreen <[EMAIL PROTECTED]> writes:
> > >> I wonder whether we should retire -o.
> >
> > > How about putting -o stuff after -p? That way only postmaster
> > > code can set PGC_POSTMASTER options for a backend, no way for
> >
Patch applied. Thanks.
> Please apply attached patch to current CVS tree.
>
> Changes:
>
> 1. gist__int_ops is now without lossy
> 2. added sort entry in picksplit
>
> Regards,
> Oleg
> _
> Oleg Bartunov, sci.r
> Marko Kreen <[EMAIL PROTECTED]> writes:
> >> I wonder whether we should retire -o.
>
> > How about putting -o stuff after -p? That way only postmaster
> > code can set PGC_POSTMASTER options for a backend, no way for
> > user to mess up. ATM this would break -o -F tho'.
Not sure what you are
Bradley McLean <[EMAIL PROTECTED]> writes:
> Is it useful if it only works for one database within a server?
Once we have schemas (7.3, I hope), I think a lot of installations will
have only one production database. However, if we were going to do this
what we'd probably do is allow the DBA to c
just about to be moved to the new server, now that the new 18gi drive has
been installed ... plan on getting that done this afternoon ...
On Sun, 30 Sep 2001, Peter Eisentraut wrote:
> I've built the docs on cvs.postgresql.org, but where are the ftp and www
> areas these days and how does one
Doug McNaught wrote:
>
> You can pass open file descriptors across Unix domain sockets on most
> systems, which is a possible way to address the problem, but probably
> not worth it for the reasons discussed earlier.
I think that it does solve the problem. The only drawback is that it's not
port
Tatsuo Ishii wrote:
> In the attached script, second call to test1() causes error:
Well known error.
PL/pgSQL creates saved execution plans for almost every
expression and query using SPI_prepare(), SPI_saveplan(). If
any of the objects, referenced from such a plan
I've built the docs on cvs.postgresql.org, but where are the ftp and www
areas these days and how does one get stuff onto them?
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 6: Have you s
* Gavin Sherry ([EMAIL PROTECTED]) [010930 06:13]:
> On Sat, 29 Sep 2001 [EMAIL PROTECTED] wrote:
>
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > How hard would it be to pre-fork an extra backend
> > >
> > > How are you going to pass the connection socket to an already-forked
> > > chi
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Maybe PL/pgSQL cache problem?
This is a well-known problem: plpgsql caches a query plan that refers
to the first version of the temp table, and it doesn't know it needs
to rebuild the plan. AFAIK the only workaround at present is to use
EXECUTE for quer
Marko Kreen <[EMAIL PROTECTED]> writes:
>> I wonder whether we should retire -o.
> How about putting -o stuff after -p? That way only postmaster
> code can set PGC_POSTMASTER options for a backend, no way for
> user to mess up. ATM this would break -o -F tho'.
Indeed. If we're going to force
On Sun, Sep 30, 2001 at 12:54:25AM +0200, Peter Eisentraut wrote:
> Tom Lane writes:
> > While that's not a fatal problem, I could imagine *much* more serious
> > misbehavior from inconsistent settings of some GUC parameters. Since
> > backends believe that these parameters have PGC_POSTMASTER pr
Gavin Sherry <[EMAIL PROTECTED]> writes:
> This aside, isn't it possible to just copy the socket and some
> data about the database required into shared memory and have the preforked
> children pick the socket up from there.
Ummm No. There's no Unix API for doing so.
You can pass open fil
In the attached script, second call to test1() causes error:
select test1();
test1
---
0
(1 row)
select test1();
psql:/home/t-ishii/tmp/aaa.sql:13: NOTICE: Error occurred while executing PL/pgSQL
function test1
psql:/home/t-ishii/tmp/aaa.sql:13: NOTICE: line 5 at select into variab
On Sat, 29 Sep 2001 [EMAIL PROTECTED] wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > How hard would it be to pre-fork an extra backend
> >
> > How are you going to pass the connection socket to an already-forked
> > child process? AFAIK there's no remotely portable way ...
>
> Umm.
42 matches
Mail list logo
