Tom Lane wrote:
Also, it would ideally be possible to deliberately create a new cast
that pg_dump would ignore --- you can do this for other object kinds
by creating them in the pg_catalog schema.
It's a little bit odd to think of casts as belonging to schemas,
since they don't have names in the no
Hi,
With the following patch, the crash still occurs in the same way. But
it does seem, reading the code, that it still may be necessary.
Re-reading the backtrace, here is another strange thing:
[...]
#7 0x001b79a0 in dopr (buffer=0xa4f8 "", format=0x22eab7 ".*g",
args=0xb514 "", end=0x
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Is PostgreSQL supposed to enforce a LATIN1/ISO-8859-1 encoding if that's
> the database encoding?
AFAIK, there are no illegal characters in 8859-1, except \0 which we
do reject.
regards, tom lane
-
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2005-04-12, Robert Treat <[EMAIL PROTECTED]> wrote:
>> One potential ugly way to do it would be to use the magical "last system
>> oid"
> That is what pg_dump does when talking to pre-7.2 databases. But it isn't
> entirely reliable because oid
Is PostgreSQL supposed to enforce a LATIN1/ISO-8859-1 encoding if that's
the database encoding?
Because people using this database can happily insert any old non-LATIN1
junk into the database, then when I export as XML, all XML validation
fails because the encoding is not correct.
If this is n
On 2005-04-12, Robert Treat <[EMAIL PROTECTED]> wrote:
> One potential ugly way to do it would be to use the magical "last system oid"
> as a differentiator between those created by pg and those created by the
> user. It would be different for every version so that might be a problem.
That is
On Sunday 10 April 2005 19:10, Jim C. Nasby wrote:
> In working on the newsysviews project we've discovered that there's no
> definitive way to determine if a cast is a system cast (system as in
> part of postgresql/created by createdb) or not. What pg_dump does (and
> what we're doing now for lack
Hi Michael, I'll have a look at it this afternoon, unless Lee wants first go.
Regards, Philip.
On Tuesday 12 April 2005 00:28, Michael Meskes wrote:
> Hi,
>
> I recently got the following bug report. It appears to be a bug in
> pthread implementation in ecpglib/connect.c where
>
> pthread_gets
Simon Riggs wrote:
>>I assume this replaces the current logging on Parse to avoid duplicate
>>logging?
>
>
> Well, I'm open to discussion, but that isn't what the patch does.
I guess I'll wait for your patch and take a look rather than try to
guess about what it does, then.
> My thinking was t
Just to prevent a copy/paste error, I'd correct "will no fail" to "will
now fail" in the suggested text below...
-tfo
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
Strategic Open Source: Open Your i™
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37
=?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> writes:
> The crash occurs in pg_sprintf, work on which has been done beginning
> march 11th
Offhand I'd bet it's overrunning its malloc'd arrays because the loop at
the top doesn't count "*" as needing a fmtpos position.
Reinhard Max <[EMAIL PROTECTED]> writes:
> it appears all of PostgreSQL's binaries are linked against libreadline and
> libncurses, but the only one that really needs them seems to be psql.
> Is there a reason behind this other than that it might be easier to have
> only one set of linker switche
On Mon, Apr 11, 2005 at 02:46:09PM +0200, Reinhard Max wrote:
> it appears all of PostgreSQL's binaries are linked against libreadline and
> libncurses, but the only one that really needs them seems to be psql.
>
> Is there a reason behind this other than that it might be easier to have
> only
On Sun, 2005-04-10 at 17:54 +1200, Oliver Jowett wrote:
> Simon Riggs wrote:
>
> > I've got a patch to submit that logs the EXEC phase, so you get just the
> > SQL, not the parameters. [...]
Just testing against cvstip and wrapping now...
> I assume this replaces the current logging on Parse to
Hi,
My buildfarm member, osprey, has been crashing on the union regression
test on CVS tip since after march 11th with a segmentation fault.
See the backtrace further down.
The crash occurs in pg_sprintf, work on which has been done beginning
march 11th
I'm not sure I'm reading the trace c
Hi,
it appears all of PostgreSQL's binaries are linked against libreadline and
libncurses, but the only one that really needs them seems to be psql.
Is there a reason behind this other than that it might be easier to have
only one set of linker switches that can be used for everything?
cu
Tom,
> There's not any special smarts for seqscans, but the counter should
> handle that.
So all pages start out with the same counter, except VACUUM tuples?
BTW, I found this paper on RDBMS memory management, which probably could have
saved us some weeks of discussion:
http://www.cs.usask.ca/~
Tom, Neil,
> > Oh, and incidentally, can I use the same database files for 8.0.2 and
> > 8.1cvs 3/10/05?
>
> Sorry, we forced initdb already several times...
D'oh. Better see if I can get a second machine, then, since build of a 100G
DBT3 database takes 20 hours.
--
Josh Berkus
Aglio Database
"John Hansen" <[EMAIL PROTECTED]> writes:
> create table foo ( id serial primary key, path text);
> alter table foo add ref foo;
> Is this a bug or a random feature?
I'd say it's a random misfeature ;-). I certainly don't care to promise
that it's supported ... but on the other hand, preventing
Hi,
I recently got the following bug report. It appears to be a bug in
pthread implementation in ecpglib/connect.c where
pthread_getspecific(actual_connection_key);
doesn't return the value of actual_connection, the variable used for
non-threaded mode. Problem is I never really used threading i
Consider the following:
create table foo ( id serial primary key, path text);
alter table foo add ref foo;
Table "public.foo"
Column | Type | Modifiers
+-+-
id | integer |
21 matches
Mail list logo
