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 offset and
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. There
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 offset
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
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
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
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
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 and these
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.
Sorry, I
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 want it
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'
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 if
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
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* that
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.
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. Not
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
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
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
resolution, you
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 only
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.
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 string.h
int
add_one(int arg)
{
return arg + 1;
}
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
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];
};
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
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. Make
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
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
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 it is
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)---
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
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
source
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
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
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 fool
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
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
it
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.
Perhaps
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
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.
Perhaps
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 my
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]
bare ass guess do these headers assume sys/types.h as a
prerequisite on your system?
Not
bare ass guess do these headers assume sys/types.h 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
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
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
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-level
46 matches
Mail list logo
