[ Charset ISO-8859-1 unsupported, converting... ]
> On Mi? 01 Nov 2000 20:57, Martin A. Marques wrote:
>
> Seeing that nobody responded to my questions, here I go. ;-)
>
> I think one of the poor partes about postgres is the administration tools. I
> am not a PostgreSQL hacker (would like to be
I have added this to the developers FAQ. However, the developers FAQ
isn't accessible from the web site, and I have contacted Vince on this.
---
13) What is CommandCounterIncrement()?
Normally, transactions can not see the
One idea I had from this is actually truncating pg_log at some point if
we know all the tuples have the special committed xid. It would prevent
the file from growing without bounds.
Vadim, can you explain how WAL will make pg_log unnecessary someday?
> We've expended a lot of worry and discuss
On Vie 03 Nov 2000 22:16, Tom Lane wrote:
>
> Hm, how do your system's include files declare accept()?
>
> It would help to see the part of the config.log file that shows the
> errors configure gets while trying to find workable input types for
> accept().
The config.log file starts given fails a
Seems we call the command create language and drop language, but the
syntax requires CREATE PROCEDURAL LANGUAGE and DROP PROCEDURAL LANGUAGE.
I am going to change the docs and grammar so PROCEDURAL is optional. Is
this OK?
--
Bruce Momjian| http://candle.pha.pa.us
Remember the CVS problems I had grabbing the logs from just one branch
of cvs?
Well, it turns out it is a cvs bug. CVS is fine with showing logs from
just a branch iff the file existed when the branch was created. For
post-branch files like pgsql/GNUmakefile.in, you see all changes.
I received
"Martin A. Marques" <[EMAIL PROTECTED]> writes:
> On Vie 03 Nov 2000 22:16, Tom Lane wrote:
>> Hm, how do your system's include files declare accept()?
> The config.log file starts given fails at this point:
> configure:5475: conflicting types for `accept'
> /usr/include/sys/socket.h:384: previou
Looks like someone changed an error message, but didn't upgrade the
expected file...
(Current sources/multibyte/UnixWare 7.1.1)
*** ./expected/geometry.out Tue Sep 12 16:07:16 2000
--- ./results/geometry.out Sat Nov 4 15:55:05 2000
***
*** 127,133
| (-5,-12)
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Looks like someone changed an error message, but didn't upgrade the
> expected file...
Yup. I just undid the error message change, because the new text did
not seem like an improvement...
regards, tom lane
* Tom Lane <[EMAIL PROTECTED]> [001104 18:40]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Looks like someone changed an error message, but didn't upgrade the
> > expected file...
>
> Yup. I just undid the error message change, because the new text did
> not seem like an improvement...
I ag
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> A separate function for formatting output seems necessary, but if we don't
> reach an agreement though, it ought to work to cast CIDR to INET to get
> all four octets, no?
Uh, weren't you one of the people objecting to relying on cidr-to-inet
casts t
As everyone knows, there was discussion this week about a new utility to
be added to 7.0.3. The final decision was that the utility should go
into /contrib, and that the utility will not be mentioned in the release
notes.
I think we can learn some things from this episode.
Certainly, this had m
Bruce Momjian wrote:
> Basically, it seems that while we will have missteps like this from time
> to time, our ability to resolve them is unhampered.
> Apologies to those who felt this week's discussion was too lengthy.
> This is the only way we have to make fair, informed decisions that take
>
> > So, we'll have to abort some long running transaction.
>
> Well, yes, some transaction that continues running while ~ 500 million
> other transactions come and go might give us trouble. I wasn't really
> planning to worry about that case ;-)
Agreed, I just don't like to rely on assumptions
> Thomas, you've been muttering about altering the type resolution rules
> so that "unknown" will be treated as "text" when all else fails. Are
> you planning to commit such a thing for 7.1? If not, I'll probably have
> to hack up parse_coerce.c's select_common_type(), along the lines of
I'm *f
Tom Lane wrote:
>
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > What part of "no new features in bug-fix releases" is giving people
> > trouble?
>
> Interesting observation here: the key developers seem to be much more
> exercised about this than the rest of the community. Counting core
>
I've been working on date/time issues over the last few weeks (at least
one or two from reports on the list, others that I've stumbled across,
and even one or two planned ones ;)
Anyway, the INTERVAL type output representation has trouble with values
such as
'-1 month +2 hours'
since it assum
In order that we can get a few days of testing on these, make sure the
packaging is right and whatnot, we are holding off on a formal release
until early->mid next week ...
I've just put pre-release tar balls into:
ftp://ftp.postgresql.org/pub/source/v7.0.3
Please take a minute to down
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> But RelFileNode already claims to store the identity of the table space,
> being the database oid. This doesn't work because a location can contain
> more than one database. So effectively we'd need to redefine RelFileNode
> something like 'struct {
On Fri, 3 Nov 2000, Bruce Momjian wrote:
> I have talked to GB and they understand their error.
Until the next time? This isn't the first time you've "talked to
them" ...
> >> I think that to handle locations we could symlink catalogs - ln -s
> >> path_to_database_in_some_location .../base/DatabaseOid
>
> > But that's a kludge. We ought to discourage people from messing with the
> > storage internals.
>
> It's not a kluge, it's a perfectly fine implementation.
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > What part of "no new features in bug-fix releases" is giving people
> > trouble?
>
> Interesting observation here: the key developers seem to be much more
> exercised about this than the rest of the community. Counting core
> members and Peter w
Martin A. Marques writes:
> checking types of arguments for accept()... configure: error: could not determine
>argument types
According to the documentation for Solaris 7 it should be 'accept(int,
struct sockaddr *, socklen_t *)', which is the same on my system, so the
problem is elsewhere. On
Tom Lane wrote:
>
Thanks for doing it ;)
I have some comments too ...
> One of the
> longest-running parts of the discussion had to do with giving good error
> messages and how it is hard to get friendly messages when you rely on the
> database to do error checking. I thought this pointed up t
24 matches
Mail list logo
