I see the mention of -w in the main FAQ.
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > There's probably little reason to start a backend standalone. If you want
> > to do stock-of-the-trade debugging you simply start a postmaster, then
> > psql (or whatever floats your boat), and attach gd
Seems this one got lost along the way somewhere. At least, I didn't get it
back... Trying a resend.
//Magnus
> -Original Message-
> From: Magnus Hagander
> Sent: den 20 januari 2001 14:29
> To: '[EMAIL PROTECTED]'
> Subject: Postgresql on win32
>
> Hello!
>
> Here is
Peter Eisentraut writes:
> What if someone has a binary PostgreSQL package installed, then
> updates his time library to something supposedly binary compatible
> and finds out that PostgreSQL still doesn't use the enhanced
> capabilities?
You are too generous. If someone downloads a binary p
> > I made a reproduceable example of things going wrong with a "en_US"
> > locale which is the widely-used (single-byte) ISO-8859-1 Latin 1 charset.
>
> en_US uses multi-pass collation rules. It's those collation rules, not
> the charset per se, that causes the problem.
Just to understand thi
> The other category is run-time behaviour, which is the present case of
> testing whether mktime() behaves a certain way when given certain
> arguments. Another item that has been thrown around over the years is
> whether the system supports Unix domain sockets (essentially a run-time
> behavio
> > The problem is that there are strings being allocated from
> > libpq.dll using PQExpBuffers (for example, initPQExpBuffer()
> > on line 92 of input.c). These are being allocated using the
> > malloc function used by libpq.dll. This function *may* be
> > different from the malloc function
Imho the behavior of timestamp code is somewhat awkward
for dates that do not fit into a time_t (>2038 or < 1901).
Times in the time_t range are displayed in local time including DST.
Times outside that range are displayed in UTC. I would have expected
UTC plus local offset not taking DST into
Hello !
I'm using postgres quiet succsessfully on RedHat 6.2
I tried to install PostgresQL on the distribution Gentoo
(aviable for free from www.gentoo.org) because I
was curious how PostgresQL would perform on a
2.4.0 based linux system with ReiserFs as file system.
(I tested also with 2.4.1-pr
Well, I'm still for this ... how about something simiple like 'idle in
trans'? show, and easy to figure out what it means?
On Mon, 22 Jan 2001, Christof Petig wrote:
> If you don't know what is all about read the bottom (I'll requote my posting)
>
> Bruce Momjian wrote:
>
> > > On Fri, 19 Jan
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Just to understand things correctly. Is the Like optimization disabled
> for all non-ASCII char sets, or (imho correctly) for non charset ordered
> collations (LC_COLLATE) ?
Currently it's disabled whenever LC_COLLATE is neither C nor POSIX.
Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
something that everyone else has except us?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postg
Magnus Hagander <[EMAIL PROTECTED]> writes:
>> 2) PG_VERSION is no longer defined in version.h[.in], but in
>> configure.in. Since we don't do configure on native win32, we
>> need to put it in config.h.win32 :-(
Putting
> ! #define PG_VERSION 7.1
> ! #define PG_VERSION_STR "7.1 (win32)"
into
> Imho the behavior of timestamp code is somewhat awkward
> for dates that do not fit into a time_t (>2038 or < 1901).
> Times in the time_t range are displayed in local time including DST.
> Times outside that range are displayed in UTC. I would have expected
> UTC plus local offset not taking DS
On Mon, Jan 22, 2001 at 11:30:17AM -0400, The Hermit Hacker wrote:
>
> Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
> something that everyone else has except us?
Afaik either Informix or Sybase (both?) has it too. Dunno about
anything else.
>
> Marc G. Fournier
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> It is possible to make the above work (at least on MSVC).
> The switch is /MD that needs to be used for both the psql.exe and
> libpq.dll. This forces the use of Multithreaded DLL runtime libraries.
I like this answer. We should be trying to
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > It is possible to make the above work (at least on MSVC).
> > The switch is /MD that needs to be used for both the psql.exe and
> > libpq.dll. This forces the use of Multithreaded DLL runtime
> libraries.
>
> I like this answer. We shou
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> >> 2) PG_VERSION is no longer defined in version.h[.in], but in
> >> configure.in. Since we don't do configure on native win32, we
> >> need to put it in config.h.win32 :-(
>
> Putting
>
> > ! #define PG_VERSION 7.1
> > ! #define PG_VERSION_STR "
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Question: Can I assume that configure.in stays the way it is now? In the way
> that if I could just extract the line "VERSION='xyz'" from it, that will
> continue to work? It might be possible to do something around that.
That'd be OK with me. I don'
> Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
> something that everyone else has except us?
We should not only support access to all db's under one postmaster,
but also remote access to other postmaster's databases.
All biggie db's allow this in one way or another (syn
Tom Lane writes:
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > Just to understand things correctly. Is the Like optimization disabled
> > for all non-ASCII char sets, or (imho correctly) for non charset ordered
> > collations (LC_COLLATE) ?
>
> Currently it's disabled whenever LC_COLL
The Hermit Hacker writes:
> Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
> something that everyone else has except us?
It's not required by SQL, that's for sure. I think in 7.2 we'll tackle
schema support, which will accomplish the same thing. Many people
(including m
Tom Lane writes:
> That'd be OK with me. I don't suppose Win32 has "sed" though :-(
Cygwin does. We can worry about native support for PostgreSQL later ;-)
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not r
> On Mon, Jan 22, 2001 at 11:30:17AM -0400, The Hermit Hacker wrote:
>> Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
>> something that everyone else has except us?
Think "schema". I don't foresee supporting joins across multiple
databases any time soon (unless someone w
> > Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
> > something that everyone else has except us?
>
> It's not required by SQL, that's for sure. I think in 7.2 we'll tackle
> schema support, which will accomplish the same thing.
It does not (e.g. remote access).
> M
sounds like something that should be handled at the application level
though ... at least the concept of 'access to other db manufacturers' ...
no?
On Mon, 22 Jan 2001, Zeugswetter Andreas SB wrote:
>
> > Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
> > something that
Pete Forman <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>>> That'd be OK with me. I don't suppose Win32 has "sed" though :-(
> Cygwin does. We can worry about native support for PostgreSQL later ;-)
This is the native support we are talking about. The Cygwin port uses
configure, no?
> It's not required by SQL, that's for sure. I think in 7.2 we'll tackle
> schema support, which will accomplish the same thing. Many people
> (including myself) are of the opinion that not allowing cross-db access is
> in fact a feature.
I am hoping that when we get to query tree redesign we w
Tom Lane writes:
> Actually, it might be easier to go back to keeping it in a file
> version.h (NOT .in) which configure could read it out of. I never
> figured out why Peter put it directly in configure.in in the first
> place; that means it is actually hard-coded in two files (configure.in
> a
Zeugswetter Andreas SB writes:
> > It's not required by SQL, that's for sure. I think in 7.2 we'll tackle
> > schema support, which will accomplish the same thing.
>
> It does not (e.g. remote access).
Maybe this is handled better by an external corba server or some such
thing.
> > Many peopl
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Actually, it might be easier to go back to keeping it in a file
>> version.h (NOT .in) which configure could read it out of. I never
>> figured out why Peter put it directly in configure.in in the first
>> place; that means it is
Zeugswetter Andreas SB writes:
> I think in PostgreSQL there is also a third category: "features" that affect on disk
> storage of data.
We have those already, for example the locale collation order. They are
determined when initdb is run and are then fixed for the database cluster.
> > So I w
On Mon, 22 Jan 2001, Zeugswetter Andreas SB wrote:
>
> > Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
> > something that everyone else has except us?
>
> We should not only support access to all db's under one postmaster,
> but also remote access to other postmaster's
On Mon, Jan 22, 2001 at 12:18:54PM -0500, Joel Burton wrote:
> On Mon, 22 Jan 2001, Zeugswetter Andreas SB wrote:
>
> >
> > > Is anyone looking at doing this? Is this purely a MySQL-ism, or is it
> > > something that everyone else has except us?
> >
> > We should not only support access to all
Tom Lane writes:
> Putting
>
> > ! #define PG_VERSION 7.1
> > ! #define PG_VERSION_STR "7.1 (win32)"
>
> into config.h.win32 is most certainly *not* an acceptable solution.
> We are not going to start maintaining this file's idea of the version
> by hand, now that we've centralized the version in
Hey guys, I am just getting back into the swing of things (after a nice
vacation and a not-so-nice move across country).. I just installed 7.1 Beta
3 and am playing with it (I'm impressed with the speed increase I've seen
with virtually no tweaking BTW).. I see a lot of this when I'm importing
dat
On Mon, 22 Jan 2001, Ross J. Reedstrom wrote:
> And this case can be handled within one database by having multiple
> schema, one for each package. It's not there yet, but it's a simpler
> solution than the generic solution. The problem (as others have mentioned)
> is that we don't want to open t
On Mon, Jan 22, 2001 at 12:41:38PM -0500, Joel Burton wrote:
> On Mon, 22 Jan 2001, Ross J. Reedstrom wrote:
>
> > And this case can be handled within one database by having multiple
> > schema, one for each package. It's not there yet, but it's a simpler
> > solution than the generic solution. T
> I see a lot of this when I'm importing data :
>
> DEBUG: copy: line 2865, XLogWrite: new log file created -
> try to increase WAL_FILES
>
> Is that anything to be concerned about?
No, WAL_FILES affects performance only.
> Do I need to increase WAL_FILES? If so, how?
You may ignore this fo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> We're losing this battle anyway. Look into src/interfaces/libpq/libpq.rc.
Ugh. Magnus, is there any reasonable way to generate that thing on the
fly on Win32?
One could imagine fixing this in configure --- have configure generate
libpq.rc from lib
Is there any easy method for getting a hold of the OID and XID for a
given row within a plpgsql (or another type) of function?
Statements like NEW.oid appear to fail, and xid isn't to be found.
I'd like to use these to create the history of an application which
can be rolled back (by the applicat
Vadim,
I have committed changes to separate the notions of critical sections
and sections that just want to hold off cancel/die interrupts, as we
discussed. While I was doing that, I noticed a couple of places that
I think you should take a second look at:
1. src/backend/access/nbtree/nbtinsert
> sounds like something that should be handled at the application level
> though ... at least the concept of 'access to other db
> manufacturers' ...
> no?
Well I know of Informix for one, that allows transparent access to flat files
or other dbs. And this is a feature that often shows very han
> Tom Lane writes:
>
> > Putting
> >
> > > ! #define PG_VERSION 7.1
> > > ! #define PG_VERSION_STR "7.1 (win32)"
> >
> > into config.h.win32 is most certainly *not* an acceptable solution.
> > We are not going to start maintaining this file's idea of the version
> > by hand, now that we've centra
Peter Eisentraut wrote:
>
> Tom Lane writes:
>
> > Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> > > Just to understand things correctly. Is the Like optimization disabled
> > > for all non-ASCII char sets, or (imho correctly) for non charset ordered
> > > collations (LC_COLLATE) ?
> >
>
The Hermit Hacker wrote:
>
> sounds like something that should be handled at the application level
> though ... at least the concept of 'access to other db manufacturers' ...
> no?
If and when we will get functions that can return rowsets (IIRC Oracle's
RETURN AND CONTINUE)the simplest case can
At 13:01 22/01/01 -0500, Tom Lane wrote:
>Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > We're losing this battle anyway. Look into src/interfaces/libpq/libpq.rc.
>
>Ugh. Magnus, is there any reasonable way to generate that thing on the
>fly on Win32?
While on this subject, does anyone have
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Is there any possibility to use, in a portable way, only our own locale
> definition files, without reimplementing all the sorts uppercases etc. ?
AFAIK there is not --- the standard C library APIs do not specify how to
represent this information. Thu
On Mon, Jan 22, 2001 at 05:46:09PM -0500, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Is there any possibility to use, in a portable way, only our own locale
> > definition files, without reimplementing all the sorts uppercases etc. ?
>
> The situation is not too much differe
Hi Tom,
I again a little look at aset code and I probably found small performance
reserve in small chunks (chunk <= ALLOC_CHUNK_LIMIT) reallocation.
Current code for *all* small chunks call AllocSetAlloc() for new larger
chunk, memcpy() for data copy, AllocSetFree() for old chunk. But th
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I'm working on #2. Here is a partial fix for pg_dump, FYI. If it looks
> ok, I'll do more cleanup...
Looks OK as far as it goes. The other flavor of problems that pg_dump
has in this area are in doing inner joins across system catalogs ...
Karel Zak <[EMAIL PROTECTED]> writes:
> I again a little look at aset code and I probably found small performance
> reserve in small chunks (chunk <= ALLOC_CHUNK_LIMIT) reallocation.
Hmm. I wouldn't have thought that realloc got called often enough to be
worth optimizing, but it does seem to g
Tom, can you remind me where we left this?
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> >> But that is unfortunately not the problem. Looks like yet
> >> another broken compiler to me :-(
>
> > Ok, the comparison ((int) time) > ((int) 0x8001) is the problem.
> > Reading the comme
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, can you remind me where we left this?
It's done ...
regards, tom lane
There were only a few to fix, so I fixed them.
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Which one of these should we use?
> > int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no
> > DatumGetInt64; it also has DatumGetInt32 but no DatumGetInt4. fmgr has
> > PG_GETARG_INT32
> And IIRC SQL9x prescribe support for multiple locales (or at least
> multiple
> collating sequences) within one database simultaneously.
Sounds like SQL92/99 COLLATE things is the way we should go, IMHO.
--
Tatsuo Ishii
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Is there any easy method for getting a hold of the OID and XID for a
> given row within a plpgsql (or another type) of function?
> Statements like NEW.oid appear to fail, and xid isn't to be found.
The reason this doesn't work in plpgsql is that the und
Bruce Momjian <[EMAIL PROTECTED]> writes:
> There were only a few to fix, so I fixed them.
I don't think it's a good idea to write unspecified-width "int" in
the struct decls for Interval and friends. If the compiler decides
someday that that's int8, things break because the physical size of
Int
Done.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > There were only a few to fix, so I fixed them.
>
> I don't think it's a good idea to write unspecified-width "int" in
> the struct decls for Interval and friends. If the compiler decides
> someday that that's int8, things break because the
Added to TODO:
* Delay fsync() when other backends are about to commit too
[ Charset ISO-8859-1 unsupported, converting... ]
> > > BUT, do we know for sure that sleep(0) is not optimized in
> > > the library to just return?
> >
> > We can only do our best here. I think guessing wheth
Can anyone comment on this?
>
> Browsing through backend/commands/command.c I noticed the following code:
>
> if (indexStruct->indisunique)
> {
> List *attrl;
>
> /* go through the fkconstraint->pk_attrs list */
> foreach(attrl, fkconstraint->pk_attrs)
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can anyone comment on this?
The code seems to have been changed as per Philip's suggestion.
regards, tom lane
Should be fixed now. I had sent a patch in a while ago about it
and the code does seem to do an extra step now which gets the length
of the index and compares it to the length of the attribute list.
On Mon, 22 Jan 2001, Bruce Momjian wrote:
>
> Can anyone comment on this?
>
> >
> > Browsing
On Mon, Jan 22, 2001 at 10:19:00PM +, Peter Mount wrote:
> While on this subject, does anyone have a version of cygipc that works with
> the current version of CygWin? What's on postgresql.org doesn't work, and
> the link on the site was broken.
The latest cygipc distribution (source and bi
Tom, this is fixed, right?
> I've just noticed that COPY BINARY is pretty thoroughly broken by TOAST,
> because what it does is to dump out verbatim the bytes making up each
> tuple of the relation. In the case of a moved-off value, you'll get
> the toast reference, which is not going to be too
Vadim, did these patches ever make it into 7.1?
> We recently had a very satisfactory contract completed by
> Vadim.
>
> Basically Vadim has been able to reduce the amount of time
> taken by a vacuum from 10-15 minutes down to under 10 seconds.
>
> We've been running with these patches under h
Added to TODO.detail.
> parse_coerce.c contains the following conversation --- I believe the
> first XXX comment is from me and the second from you:
>
> /*
> * Still too many candidates? Try assigning types for the unknown
> * columns.
> *
> * We do this by examining eac
Tim, how is PostgreSQL working for you?
-- Start of PGP signed section.
> I thought the hackers team would be interested in knowing that SourceForge, as
> of Friday evening, is running on Postgres. Some 95,000 users and 12,500 Open
> Source projects are depending on your stuff, so I hope it's go
Can someone tell me where we are on this?
> This problem with foreign keys has been reported to me, and I have confirmed
> the bug exists in current sources. The DELETE should succeed:
>
> ---
>
> CREATE TABLE primarytest
This is Jan's reply to the issue.
> Bruce Momjian wrote:
> > > Bruce Momjian writes:
> > >
> > > > ERROR: triggered data change violation on relation "primarytest2"
> > >
> > > We're getting this report about once every 48 hours, which would make it a
> > > FAQ. (hint, hint)
> > >
> >
> >
> >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, this is fixed, right?
Yes.
regards, tom lane
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Added to TODO.detail.
Might as well take it out again; that's already done.
regards, tom lane
Removed. Thanks.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Added to TODO.detail.
>
> Might as well take it out again; that's already done.
>
> regards, tom lane
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
How are you on Alpha now?
>
> I have had the time to test today's (12/19) snapshot on my
> Linux/Alpha and the good news is that only two regression tests are
> failing. The bad news is that these regression tests do not fail on
> Linux/Intel. :( [1]
> Specifically, the oid and misc
Comments anyone?
>
> On Tue, 19 Dec 2000, Bruce Momjian wrote:
>
> > > PS. -hackers: What happen with PL/Python? Before 1/2 of year I ask if
> > > anyone works on this and answer was: "yes, but 'he' is waiting for new
> > > fmgr design". Tom's fmgr is done... IMHO it's big worse - Th
Can someone remind me what happened to this issue?
[ Charset ISO-8859-1 unsupported, converting... ]
> I've very roughly (first time I've tried anything but hello world c) hacked up
>inline comments.
>
> pg_dump -I
>
> Exports the comments generated through COMMENT ON in an appropriate manner
Would to send this over to the PHP folks for inclusion? Thanks.
> On Wed, Dec 27, 2000 at 12:56:26AM -0500, Bruce Momjian wrote:
> > I have been asked by the major PHP developer Rasmus Lerdorf to see if
> > the PostgreSQL/PHP interface needs any improvements.
> >
> > Is the current PostgreSQL
I have begun perusing the source, eventually hoping to
contribute to the development effort. I have noticed that
long ago the include files for a "component" were in the
component directory, eg src/backend/catalog/Attic/catalog.h,v
(here I'm assuming that Attic means a storage place for
items th
At 13:18 21/01/01 +0100, Alexander Jerusalem wrote:
>Hi all,
>
>I'm experiencing some strange behaviour with postgresql 7.0.3 on Red Hat
>Linux 7. I'm sending lots of insert statements to the postgresql server
>from another machine via JDBC. During that process postgresql continues to
>take up
* Peter Mount <[EMAIL PROTECTED]> [010122 13:21] wrote:
> At 13:18 21/01/01 +0100, Alexander Jerusalem wrote:
> >Hi all,
> >
> >I'm experiencing some strange behaviour with postgresql 7.0.3 on Red Hat
> >Linux 7. I'm sending lots of insert statements to the postgresql server
> >from another mach
On Fri, Jan 19, 2001 at 08:52:13PM +0100, Peter Eisentraut wrote:
> Patrick Welche writes:
>
> > Just tried it for the first time:
> > % cd src/test/locale
> > % gmake all
> > gmake: Circular test-pgsql-locale <- all dependency dropped.
> > cd: can't cd to pgsql-locale
> > gmake: *** [test-pgsql-
"Otto A. Hirr, Jr." wrote:
>
> I have begun perusing the source, eventually hoping to
> contribute to the development effort.
Welcome!
> I have noticed that
> long ago the include files for a "component" were in the
> component directory, eg src/backend/catalog/Attic/catalog.h,v
> (here I'm as
Hello!
Here is a patch to make the current snapshot compile on Win32 (native, libpq
and psql) again. Changes are:
1) psql requires the includes of "io.h" and "fcntl.h" in command.c in order
to make a call to open() work (io.h for _open(), fcntl.h for the O_xxx)
2) PG_VERSION is no longer defined
I am a Comp. Sci. student at Ryerson Polytechnic
University in toronto. I am in the midst of a software engineering project
that involves the development of a (possibly) relational database on a RedHat
6.2 development environment, we are coding in C. now my question is, how
closely related
> pga_forms | table | postgres
> pga_queries | table | postgres
> pga_reports | table | postgres
> pga_schema | table | postgres
> pga_scripts | table | postgres
>(8 rows)
>
>
>Any ideas why those pg* tables are there?
>
You have apparently used pg_access at least once. It
84 matches
Mail list logo
