Dear Thomas,
I'm trying to change the Makefile system for PL/Java so that it uses PGXS
instead of compiling using a complete PostgreSQL source tree. As it turns
out, the directory include/port/win32 is not present in the PostgreSQL
binary installation. Without it, it's not possible to
Fabien,
There's quite a few issues. Here's what I had to do in order to get my
stuff working. I don't think it's any use for me to submit changes in
form of a patch at this point since pgxs seems to be a bit on the
drawing table still. I started another thread that was not win32 related
also
Dear Thomas,
There's quite a few issues. Here's what I had to do in order to get my stuff
working. I don't think it's any use for me to submit changes in form of a
patch at this point since pgxs seems to be a bit on the drawing table still.
Well, it is supposed to work;-)
pgxs is just a
Fabien,
ifdef PGXS
override CPPFLAGS := -I$(includedir_server)
-I$(includedir_server)/port/win32 -I$(includedir_internal) $(CPPFLAGS)
else # not PGXS
...
Why can't you #include port/win32/some_file.h which would (I think)
avoid the issue without adding a win32 specific -I to all
Dennis Bjorklund wrote:
I've looked into storing charset/collation in the string values. This
means that we change varchar/text/BpChar to be structures that have a
charset oid field and a collation oid field, the rest of the Datum is the
string data.
I think the number of charset/collation
Memory allocation in access/gist/gist.c is pretty heinous, IMHO. There
are retail pallocs and pfrees all over the place, and the requirements
for which allocations need to be released and by whom is pretty messy.
AFAICS, GiST doesn't take any advantage of the palloc() infrastructure
beyond
Neil Conway [EMAIL PROTECTED] writes:
I'm not sure how we should handle \dn schema_name. (notice the period;
assuming a schema with that name exists). The current behavior of
listing all schemas is obviously wrong, but I'm not sure what the right
behavior is. Perhaps we should reject the
Hi all,
I don't know how much is effective or if it's applicable
to postgresql processe but it's an interesting article:
http://www.onlamp.com/pub/a/onlamp/2004/10/28/design_by_contract_in_c.html
Regards
Gaetano Mendola
---(end of broadcast)---
TIP
Neil Conway [EMAIL PROTECTED] writes:
AFAICS, GiST doesn't take any advantage of the palloc() infrastructure
beyond treating palloc() as a better malloc().
This is pretty much true of all the index AMs, I think. I looked
briefly at using a short-term memory context in the btree code, but
gave
Tom Lane wrote:
Devrim GUNDUZ [EMAIL PROTECTED] writes:
Try removing the 2/dev/null bit so that you can see if any error
messages come out from psql.
Ok, we have a detailed error now:
/home/pgsql80/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql:
Thomas Hallgren [EMAIL PROTECTED] writes:
I think the number of charset/collation combinations will be relatively
few so perhaps it would be space efficient to maintain a table where
each combination is given an oid and have string values store that
rather than two separate oid's?
In fact,
On Mon, 1 Nov 2004, Tom Lane wrote:
I think the number of charset/collation combinations will be relatively
few so perhaps it would be space efficient to maintain a table where
each combination is given an oid and have string values store that
rather than two separate oid's?
In
Andrew Dunstan [EMAIL PROTECTED] writes:
pg_regress: could not set database default locales
I have just seen this failure on Windows - it appears to have nothing to
do there with finding an out of date libpq.
Actually, *any* failure in pg_regress's first attempt to invoke psql
yields this
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
pg_regress: could not set database default locales
I have just seen this failure on Windows - it appears to have nothing to
do there with finding an out of date libpq.
Actually, *any* failure in pg_regress's first
Hello, recently I've been trying to write a plperlu function like this:
CREATE FUNCTION foo RETURNS bytea AS '
use Storable qw(freeze thaw);
my @a = (1,2,3,4,5);
return freeze ([EMAIL PROTECTED]);
' LANGUAGE plperlu;
In other words, serialize some data (maybe some rows, would be a great
It makes no difference on any of my systems, so at least it doesn't
completely solve the problem. I haven't heard any confirmation on wether
it partially solves it.
//Magnus
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Where are we on this patch?
Hi all,
I missed the discussion on hacker about this, and
I'd like to give my HO.
The fact that a non-volatile function can not perform
update is a good improvement but on the other side will
limit too much if I know what I'm doing.
I did a sort of Lookup framework and this is extensively
used in
se, it is that our pipe-based emulation of signals isn't ready to
collect signal messages until some time after the child
process starts.
Could this be fixed by having the postmaster set up the pipe
*before* it
forks/execs the child? We'd probably need to pass down some
additional
info
Gaetano Mendola [EMAIL PROTECTED] writes:
The fact that a non-volatile function can not perform
update is a good improvement but on the other side will
limit too much if I know what I'm doing.
I've got zero sympathy for this argument. It's been documented right
along that functions with
Magnus Hagander [EMAIL PROTECTED] writes:
[ proposed fix ]
As you can see, this is quite a bit more complicated than the simple
CreateProcess() call we have now.
...
If this seems like a reasonable approach, I can see if I can get
something together. But it's a fairly large change..
It
[ proposed fix ]
As you can see, this is quite a bit more complicated than the simple
CreateProcess() call we have now.
...
If this seems like a reasonable approach, I can see if I can get
something together. But it's a fairly large change..
It sounds reasonable to me, in the sense that it
Magnus Hagander [EMAIL PROTECTED] writes:
Basically, I think internal_forkexec() needs to be split up into two -
one win32 and one other. For win32 version, it needs to CreateProcess()
*before* it does write_backend_variables(), and then pass the process id
as a parameter to
Basically, I think internal_forkexec() needs to be split up
into two -
one win32 and one other. For win32 version, it needs to
CreateProcess()
*before* it does write_backend_variables(), and then pass
the process id
as a parameter to write_backend_vars().
Huh? Why?
Because we need to
Magnus Hagander [EMAIL PROTECTED] writes:
Huh? Why?
Because we need to write the duplicated socket structure/pipe handle to
the parameter file. I guess we could create a separate parameter file
just for these things, but that seemed a bit unnecessary.
Do we actually need to pass the handle,
Huh? Why?
Because we need to write the duplicated socket
structure/pipe handle to
the parameter file. I guess we could create a separate parameter file
just for these things, but that seemed a bit unnecessary.
Do we actually need to pass the handle, or could the subprocess reopen
the pipe
Magnus Hagander [EMAIL PROTECTED] writes:
Nope, we need to pass the handle. Only one process can be the
server-side of the pipe, and once the postmaster has opened it, the
child process can't do it - the only way to get it is through
inheritance.
Grumble. Having to call
Hello All,
this is a resend, because the original post seems to be lost.
-Original Message-
From: Roland Volkmann [mailto:[EMAIL PROTECTED]
Sent: Sunday, October 31, 2004 9:09 PM
To: [EMAIL PROTECTED]
Subject: Charset WIN1252
Hello Developers,
now, where the native Win32-Version of
Nope, we need to pass the handle. Only one process can be the
server-side of the pipe, and once the postmaster has opened it, the
child process can't do it - the only way to get it is through
inheritance.
Grumble. Having to call write_backend_variables from two different
places seems Really
Magnus Hagander [EMAIL PROTECTED] writes:
I was also hoping to piggyback the socket fix on top of this
infrastructure. And that *requires* the write-files-after-createprocess
method. There is no other way.
Oh, I had forgotten about that part of the problem. Okay, just gotta
hold our noses and
I was also hoping to piggyback the socket fix on top of this
infrastructure. And that *requires* the
write-files-after-createprocess
method. There is no other way.
Oh, I had forgotten about that part of the problem. Okay, just gotta
hold our noses and do it I guess.
(Just to be clear: the
Here are a few compile warnings I am seeing on Windows. I will try to
look at some in due course, but I am out of action for at least 2 days,
so if anyone wants to jump on them please do.
open.c:55: warning: no previous prototype for `win32_open'
dynloader.c:7: warning: no previous prototype
For now, yes, plperl needs to return the text representation of bytea
data. perhaps we can change that in a future release.
Storable in general is definitely not appropriate for plperl, as it does
IO which is forbidden for trusted languages. I at least do not have the
energy to go through
On Wed, 2004-10-27 at 01:39, Josh Berkus wrote:
Thomas,
As a result, I was intending to inflate the value of
effective_cache_size to closer to the amount of unused RAM on some of
the machines I admin (once I've verified that they all have a unified
buffer cache). Is that correct?
On Mon, 1 Nov 2004, Tom Lane wrote:
I think the number of charset/collation combinations will be relatively
few so perhaps it would be space efficient to maintain a table where
each combination is given an oid and have string values store that
rather than two separate oid's?
Tatsuo Ishii wrote:
Right. AFAIK nobody has proposed charsets/collations onto disk.
--
My apologies in that case. I triggered on Dennis wording If we want to
avoid storing charset/collation both in the column type and in each row,
we would need an extra layer that transforms the Datums before
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I got an error in make check now, in horology test:
http://postgresql.gunduz.org/regression.diffs
Is it related to this commit?
Regards, Devrim
On Mon, 1 Nov 2004, Tom Lane wrote:
Log Message:
---
timestamptz_trunc() should only recalculate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Tue, 2 Nov 2004, Devrim GUNDUZ wrote:
I got an error in make check now, in horology test:
http://postgresql.gunduz.org/regression.diffs
Is it related to this commit?
Ok, it seems no (tested with revision 1.113 for double-check). I've just
read
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
The fact that a non-volatile function can not perform
update is a good improvement but on the other side will
limit too much if I know what I'm doing.
I've got zero sympathy for this argument. It's been documented right
along
It used to be that calling
initdb -D /some/where
suggested starting
postmaster -D /some/where
and
./mydir/bin/initdb -D ./mydir/var/data
suggested starting
./mydir/bin/postmaster -D ./mydir/var/data
In the current sources, the path to the postmaster is fully expanded in
Andrew Dunstan wrote:
Tom Lane wrote:
Somebody just yesterday stuck an
fprintf(stderr,...); exit(1) into one of the pgport routines. This
sucks, but there is not a lot else that can be done if the code needs
to exist in both backend and clients. It'd be better to propagate the
error
Tatsuo Ishii [EMAIL PROTECTED] writes:
Right. AFAIK nobody has proposed charsets/collations onto disk.
Oh?
Personally, I'd much sooner eat those few bytes than try to impose a
regime where in-memory representation is different from on-disk.
regards, tom lane
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Somebody just yesterday stuck an
fprintf(stderr,...); exit(1) into one of the pgport routines. This
sucks, but there is not a lot else that can be done if the code needs
to exist in both backend and clients. It'd
On Tue, 2004-11-02 at 02:20, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
(the observation here is that 99% of the allocations done by
gist.c are for internal use only -- we rarely allocate anything that
needs to live longer than the current GiST API call).
You sure about
Tom Lane [EMAIL PROTECTED] writes:
On the whole I'm unconvinced that this is worth the trouble. One of the
reasons for allowing people to move databases around is to determine
where their temp files go.
The one scenario I would expect to see is having the temp files on filesystem
all to
Dear Thomas,
ifdef PGXS
override CPPFLAGS := -I$(includedir_server)
-I$(includedir_server)/port/win32 -I$(includedir_internal) $(CPPFLAGS)
else # not PGXS
Why can't you #include port/win32/some_file.h which would (I think)
avoid the issue without adding a win32 specific -I to all
45 matches
Mail list logo
