On Wed, Jun 18, 2003 at 10:01:37AM +1000, Gavin Sherry wrote:
> On Tue, 17 Jun 2003, Tom Lane wrote:
> > * Consider use of open/fcntl(O_DIRECT) to minimize OS caching
> >
> > I personally disagree with this TODO item for the same reason Sean
> > cited: Postgres is designed and tuned to rely on OS-
Hi all, it looks like Lee's ECPG (and libpq) thread-safety patches
have been applied, and configure --with-threads is also added. I
have been doing some testing, and I still encounter a
threading problem.
I have done the following:
1) cvs update
2) ./configure --with-threads && make && su -c "make
Tom,
"If you insist on allowing domains in argument lists, then I think the best
approach is this: For purpose of function resolution, types and all
domains defined over them are equivalent. That would mean, for example,
that if you define positive_int as domain over int, then you cannot define
> <> do these headers assume as a
> prerequisite on your system?
I don't know - I'll check
> Not sure why it'd have just now broken, though. Take a look at the most
> recent commits to the configure stuff if you need clues.
I haven't tried a build for a few weeks...
Chris
---
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> configure: WARNING: sys/select.h: present but cannot be compiled
> configure: WARNING: sys/select.h: check for missing prerequisite headers?
> [many similar]
<> do these headers assume as a
prerequisite on your system?
Not sure why it'd hav
On Tue, Jun 17, 2003 at 23:01:27 -0500,
Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> I am going to see if adding __ works as suggested by someone else
> who replied.
This worked. I think the reason auth.c compiled was because the reference
to ss_family was in conditional code that isn't used on
On Tue, Jun 17, 2003 at 22:49:00 +0200,
Kurt Roeckx <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 17, 2003 at 03:32:32PM -0500, Bruno Wolff III wrote:
> > I was looking at this some more and now think there is something wrong
> > with the references to ss_family rather than a missing inlcude file.
> >
On Tue, Jun 17, 2003 at 22:49:00 +0200,
Kurt Roeckx <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 17, 2003 at 03:32:32PM -0500, Bruno Wolff III wrote:
> > I was looking at this some more and now think there is something wrong
> > with the references to ss_family rather than a missing inlcude file.
> >
configure: WARNING: sys/select.h: present but cannot be compiled
configure: WARNING: sys/select.h: check for missing prerequisite headers?
configure: WARNING: sys/select.h: proceeding with the preprocessor's result
checking for sys/select.h... yes
checking sys/sem.h usability... no
checking sys/sem
On Tue, Jun 17, 2003 at 23:26:07 -0300,
"Francisco Figueiredo Jr." <[EMAIL PROTECTED]> wrote:
>
>
> Hi all,
> I'm using the 7.4 cvs version on cygwin and I noticed that if I have a
> table with a field of float4 type and try to do a simple select:
> select * from table where field_float4 = 4.4
Hi all,
I'm using the 7.4 cvs version on cygwin and I noticed that if I have a
table with a field of float4 type and try to do a simple select:
select * from table where field_float4 = 4.4
it doesn't return any rows.
In the same table I have a float8 field and it works ok.
If I try with a value
> this arguments are quite academic.
You what!
> On one side, this could be
> restricted, thats what pg_depends is good for (this already happens for
> inherited tables).
> On the other side, how often do you rename columns or tables?
You what!
> On mssql, nobody cares.
You what!
> If you
I am confused why you didn't like the following patch I posted, which
pulls the family data type length right out of the structure, rather than
having to configure it for every OS that doesn't have sa_family_t?
---
deststar
Jason Tishler wrote:
On Sun, Jun 15, 2003 at 04:54:21PM +0100, deststar wrote:
On cygwin sa_family_t was undeclared, adding the following line:
typedef unsigned short sa_family_t;
to both:
src/port/getaddrinfo.c
src/include/libpq/pqcomm.h
Isn't the attached or fixing Cygwin itself a better appro
On Tue, 17 Jun 2003, Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > The reason I mention it is that Postgres already supports O_DIRECT I think
> > on some other platforms (for whatever reason).
>
> [ sounds of grepping... ] No. The only occurrence of O_DIRECT in the
David Blasby wrote:
Sebastien Lemieux wrote:
Hi,
I need to extend postgreSQL to support some specific function I
will code in C (ideally C++ if it can work!).
Be very carefull with using C++ functions inside postgresql. If the
C++ code throws an exception the postgresql backend will get
Rod Taylor wrote:
What I *really* want is having the original source stored, including
comments, version info, ... Currently, it's argued that underlying table
and column might change, braking the view/rule. This could be
restricted, or source could be dropped (alter table ... cascaded). Is it
Sebastien Lemieux <[EMAIL PROTECTED]> writes:
> Then I get:
> ERROR: Can't find function add_one in file /[PathToTheObject]/pgsql_bio.so
Hmm. I can't see anything wrong with what you did, either.
It's possible that the dynamic linker has printed additional messages to
the backend's stderr. Mak
Sebastien Lemieux wrote:
Hi,
I need to extend postgreSQL to support some specific function I will
code in C (ideally C++ if it can work!).
Be very carefull with using C++ functions inside postgresql. If the C++
code throws an exception the postgresql backend will get a SIGABRT and
terminate
My system has the same problem - struct sockaddr_storage is defined in
/usr/include/bits/socket.h :
struct sockaddr_storage
{
__SOCKADDR_COMMON (__ss_); /* Address family, etc. */
__ss_aligntype __ss_align; /* Force desired alignment. */
char __ss_padding[_SS_PADSIZE];
};
Whe
On Tue, Jun 17, 2003 at 03:32:32PM -0500, Bruno Wolff III wrote:
> I was looking at this some more and now think there is something wrong
> with the references to ss_family rather than a missing inlcude file.
> Perhaps those were supposed to be references to sa_family or there
> is a missing field
Hi,
I need to extend postgreSQL to support some specific function I will
code in C (ideally C++ if it can work!). I'm trying to run some simple
test and it doesn't seem to work. Here is the C code:
--
#include "postgres.h"
#include
int
add_one(int arg)
{
return arg + 1;
}
--
I was looking at this some more and now think there is something wrong
with the references to ss_family rather than a missing inlcude file.
Perhaps those were supposed to be references to sa_family or there
is a missing field from the socket_storage type definition.
---(end
> What I *really* want is having the original source stored, including
> comments, version info, ... Currently, it's argued that underlying table
> and column might change, braking the view/rule. This could be
> restricted, or source could be dropped (alter table ... cascaded). Is it
> really o
Tom Lane writes:
> This is a straightforward change and would not break pg_dump files,
> since fortunately pg_dump always references the underlying types and
> never refers to anything as FLOAT(p). But I wonder whether it is
> likely to break many existing applications. There is a hazard of some
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Considering that the data type float(x) isn't documented anywhere, I'm not
> worried.
Good point ... I'll fix that while I'm at it ...
regards, tom lane
---(end of broadcast)---
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Admittedly, we have trouble resolving the type to use when a function is
>> overloaded with both a domain and a base type, but that's hardly
>> surprising.
> Even if you try to work it out, it's going to be a mess. During
> resolu
Hans-Jürgen Schönig wrote:
However, my question is: Is there a way to implement it in a way that
does not depend on the remote data structure?
Is there a way to get rid of the AS without having to define a type?
Unfortunately, no. The parse and planning stages need defined types, so
waiting for t
On Mon, Jun 16, 2003 at 17:21:01 -0400,
Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Does the following patch fix the problem? It doesn't use sa_family_t
> anymore.
I tried current CVS and current CVS with the patch you attached and it
still didn't work.
---(end of bro
On Mon, Jun 16, 2003 at 05:21:01PM -0400, Bruce Momjian wrote:
>
> Does the following patch fix the problem? It doesn't use sa_family_t
> anymore.
>
> ! sa_family_t ss_family; /* address family */
[...]
> ! char dummy_sa_family[SIZEOF_SOCKADDR_FAMILY];
That is NOT going to work
On Mon, Jun 16, 2003 at 17:21:01 -0400,
Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Does the following patch fix the problem? It doesn't use sa_family_t
> anymore.
I tried using the pacth and it didn't help. I am going to get a fresh
CVS copy and see if that works.
--
Tom Lane wrote:
I recall objecting to someone who wanted to remove "unnecessary"
parentheses, but I can't see any risk in inserting unnecessary
whitespace.
That "someone" was me indeed, and as I mentioned the code is completely
separated from the code that pg_dump uses. Thus, there's *no way* tha
"Shridhar Daithankar" <[EMAIL PROTECTED]> writes:
> On 16 Jun 2003 at 18:15, Tom Lane wrote:
>> This is a straightforward change and would not break pg_dump files,
>> since fortunately pg_dump always references the underlying types and
>> never refers to anything as FLOAT(p). But I wonder whether
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> The reason I mention it is that Postgres already supports O_DIRECT I think
> on some other platforms (for whatever reason).
[ sounds of grepping... ] No. The only occurrence of O_DIRECT in the
source tree is in TODO:
* Consider use of open
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Difference from Christopher's solution is that mine utilizes completely
> separatated (copied) code, so ruleutils code is still unchanged. This
> was a concession to Tom who claimed concerns about pg_dump not being
> able to reproduce things correctly
Oleg Bartunov writes:
> I thought I could specify different encodings for different databases
> and these encodings will be used in text operations (sort, upper,lower),
> not just for conversion. But, actually, the only encoding is important
> for text operations - the one specified with 'initdb'
On Tue, 17 Jun 2003, Christopher Kings-Lynne wrote:
> "A new DIRECTIO kernel option enables support for read operations that
> bypass the buffer cache and put data directly into a userland buffer
>
> Will PostgreSQL pick this up automatically, or do we need to add extra
> checks?
You don't wa
On Tue, 17 Jun 2003, Tatsuo Ishii wrote:
> > > [I assume you enable the locale support.]
> >
> > isn't it enabled by default ?
>
> It can be off by using ---no-locale option with initdb.
>
what's the benefit of this for non-ascii world :?
> > > Dont't ask me. These are locale support problems.
>
> > [I assume you enable the locale support.]
>
> isn't it enabled by default ?
It can be off by using ---no-locale option with initdb.
> > Dont't ask me. These are locale support problems.
>
> Sorry, I just wanted to understand where I get confused.
> You're right, utf8 locale support in glibc
On Tue, 17 Jun 2003, Tatsuo Ishii wrote:
> > Tatsuo,
> >
> > recently I tried to understand why I can't get sorting works properly
> > with cyrillic characters in UTF8 datbase. I figure out the
> > reason of my confusion - I thought I could specify different encodings
> > for different databases
On Mon, 16 Jun 2003, Peter Eisentraut wrote:
> > However, if you want to produce a utf-8 file, how should that work with
> > respect to gettext()? If the message catalog is in latin1 then we need to
> > know that and convert that into utf-8.
>
> I don't think all gettext implementations support a
Christopher Kings-Lynne wrote:
We make pg_get_xxx2 functions that return a formatted version. Internally,
we just add an extra boolean parameter to the pg_get_triggerdef() function
in ruleutils and we call that true or false depending...
That's what I got too!
Several weeks ago I proposed such
Hi,
I would like to participate to PostgreSQL under
Windows platform.
What can i do to help ?
x04001
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---(end of broadcast)---
TIP 9
> > Will PostgreSQL pick this up automatically, or do we need to add
> > extra checks?
>
> Extra checks, though I'm not sure why you'd want this. This is the
> equiv of a nice way of handling raw IO for read only
> operations... which would be bad. Call me crazy, but unless you're on
The reason
> I noticed this in the FreeBSD 5.1 release notes:
>
> "A new DIRECTIO kernel option enables support for read operations
> that bypass the buffer cache and put data directly into a userland
> buffer. This feature requires that the O_DIRECT flag is set on the
> file descriptor and that both the off
On 16 Jun 2003 at 18:15, Tom Lane wrote:
> This is a straightforward change and would not break pg_dump files,
> since fortunately pg_dump always references the underlying types and
> never refers to anything as FLOAT(p). But I wonder whether it is
> likely to break many existing applications. Th
46 matches
Mail list logo
