On Mon, 2002-09-16 at 10:52, Christopher Kings-Lynne wrote:
Developers mailing list: [EMAIL PROTECTED]
Hmm, that list does not appear on the sourceforge Lists page. Why?
--
Markus Bertheau.
Berlin, Berlin.
Germany.
---(end of broadcast)---
TIP
could be done based on IP (yes it is inaccurate but it is close enough
and has the same net effect: pushing people off the main web server) or
it could be done by simply redirecting to a random mirror.
Have tried both in the past with disastrous results ...
What method will be
On Thu, 2002-09-26 at 22:42, Tom Lane wrote:
Jim Mercer [EMAIL PROTECTED] writes:
as best i can understand, there is no way to get apach/php/pgsql configured
(using PostgreSQL's native access mappings) that would disallow php code
in one virtual host from connecting to any database on the
AFAIK it's because it is a members-only list. It is archived and the
archives are web viewable if you know where to look (not that I can
remember, but I have done it before).
Robert Treat
On Fri, 2002-09-27 at 02:48, Markus Bertheau wrote:
On Mon, 2002-09-16 at 10:52, Christopher Kings-Lynne
On Thu, 26 Sep 2002 16:32:08 -0700
Joe Conway [EMAIL PROTECTED] wrote:
Masaru Sugawara wrote:
The previous patch fixed an infinite recursion bug in
contrib/tablefunc/tablefunc.c:connectby. But, other unmanageable error
seems to occur even if a table has commonplace tree data(see below).
Michael Meskes wrote:
into. As far as I understand the problem, the application uses stored
procedures for each and every select statement. Thus he needs his
procedures to return the whole query result, which is not doable with
our functions.
It is in 7.3.
If the return tuple definition is
Tom Lane [EMAIL PROTECTED] writes:
We'd be happiest with a filesystem that journals its own metadata and
not the user data in the file(s). I dunno if there are any.
Most journalling file systems work this way. Data journalling is not
very widespread, AFAIK.
--
Florian Weimer
Yesterday I reported a WAL problem that could lead to tuples not being
marked as committed-good or committed-dead after we'd already removed
the pg_clog segment that had their transaction's commit status.
I wasn't completely satisfied with that, though, because on further
reflection it seemed a
Tom Lane wrote:
Yesterday I reported a WAL problem that could lead to tuples not being
marked as committed-good or committed-dead after we'd already removed
the pg_clog segment that had their transaction's commit status.
I wasn't completely satisfied with that, though, because on further
OK, we need a decision on whether we are going to do a 7.2,3 or just
have it in beta3. If it is in 7.2.3, I would not mention it in the
beta3 release notes.
---
Tom Lane wrote:
Yesterday I reported a WAL problem that
From: Tom Lane [EMAIL PROTECTED]
However, if we are going to put that kind of knowledge into pg_dump,
it would only be a small further step to have it dump these triggers
as ALTER TABLE ADD CONSTRAINT commands instead. Which would be a lot
better for forward compatibility than dumping the
Hackers,
Seems the functionality to detect old versions of the postmaster with
newer psql doesn't work. Here, server is 7.2.1:
$ psql alvherre
ERROR: parser: parse error at or near .
Welcome to psql 7.3b1, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
I didn't think we were supposed to throw an error on a mismatch, were
we?
---
Alvaro Herrera wrote:
Hackers,
Seems the functionality to detect old versions of the postmaster with
newer psql doesn't work. Here, server
Both are done, and in CVS in /contrib/adddepend.
---
Matthew T. O'Connor wrote:
From: Tom Lane [EMAIL PROTECTED]
However, if we are going to put that kind of knowledge into pg_dump,
it would only be a small further
Okay, I did some more research into this area. It looks like it will
be feasible to use large TLB pages for PostgreSQL.
Tom Lane [EMAIL PROTECTED] writes:
It wasn't clear from your description whether large-TLB shmem segments
even have IDs that one could use to determine whether the segment
15 matches
Mail list logo
