...
(1) Major version upgrade. This is a hard one, having to dump out and restore a
database to go from 7.1 to 7.2 or 7.2 to 7.3 is really a hard sell.
Hmm, maybe it would be more acceptable if we charged $40k per license,
but refunded $40k if you *want* to dump/reload. Gets that motivation
Michael Meskes wrote:
On Thu, Apr 25, 2002 at 12:42:00PM +0100, Lee Kindness wrote:
Should the input pointers be NULL initialised? How should the memory
be freed?
A simple free() will do. You also can free all automatically
allocated memory from the most recent executed statement by
Marc G. Fournier wrote:
hr ... do you have a working Windows development environment? I'm
running WinXP at home, but don't have any of the compilers or anything
yet, so all my work for the first part is going to be done under Unix ...
but someone that knows something about building
Cyril VELTER [EMAIL PROTECTED] writes:
Also why not do the header fillup outside of PGSharedMemoryCreate ?
Well, (a) I wasn't really concerned about defining an all-new API for
shmem, and (b) I think the header is largely dependent on the semantics
of SysV shmem anyway. A different
On Sat, 2002-05-04 at 21:56, Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
We could provide a PGSemaphore based on an APR mutex and a counter,
but I'm not sure of the performance impact. We may want to implement
a
generic semaphore like this and one optimized for platforms which
we
have
Okay, lets see if i've got this right...
If I allocate the memory before the FETCH then I (naturally) free
it. However If I NULL initialise the pointer then libecpg will
allocate the memory and I must NOT free it - libecpg will free it
automatically... Yeah?
I think this highlights the need for
On Mon, May 06, 2002 at 09:37:18AM +0200, Christof Petig wrote:
Never, never mix these two! ECPGfree_auto_mem will free even memory
which has already been free'd by the user, perhaps we should get rid of
That's why I discourage the usage of ECPGfree_auto_mem by the user.
There is only one
Rather than propagating the SysV semaphore API still further,
why don't
we kill it now? (I'm willing to keep the shmem API, however.)
Would this have the benefit of allow PostgreSQL to work properly in BSD
jails, since lack of really working SysV IPC was the problem there?
I have
I forwarded the suggestion to my ISP (imeme, a Zope provider), who said
that:
This will allow you to run a single postgres in a single jail only one
user would have access to it. If you try to run more then one it will
try to use the same shared memory and crash.
Not true. But I'll
On Sat, 4 May 2002, Joel Burton wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane
Sent: Friday, May 03, 2002 6:07 PM
To: mlw
Cc: Marc G. Fournier; [EMAIL PROTECTED]
Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 06, 2002 7:36 AM
To: Joel Burton; Tom Lane; mlw
Cc: Marc G. Fournier; [EMAIL PROTECTED]
Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
I forwarded the suggestion to my ISP
On Sat, 4 May 2002, Tom Lane wrote:
Matthew Kirkwood [EMAIL PROTECTED] writes:
On Fri, 3 May 2002, Tom Lane wrote:
The SysV API lets us detect that case, but I don't see any
equally good way to do it if we are using anonymous shared memory.
It's a hack (and has slight security
On Sun, 5 May 2002, Joel Burton wrote:
Joel Burton [EMAIL PROTECTED] writes:
Rather than propagating the SysV semaphore API still further, why don't
we kill it now? (I'm willing to keep the shmem API, however.)
Would this have the benefit of allow PostgreSQL to work properly in BSD
On Mon, 6 May 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Well, I guess that just saved *me* alot of work ... thanks ...
Uh, not yet. Don't you still need a semaphore implementation that
works on Windows?
Yup ... next steps, but I believe that is what Mark is working
Or changing ISPs to a place more enlightened ...
On Mon, 6 May 2002, Joel Burton wrote:
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 06, 2002 7:36 AM
To: Joel Burton; Tom Lane; mlw
Cc: Marc G. Fournier; [EMAIL PROTECTED]
On Sat, 2002-05-04 at 21:56, Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
We could provide a PGSemaphore based on an APR mutex and a counter,
but I'm not sure of the performance impact. We may want to implement a
generic semaphore like this and one optimized for platforms which we
have
Lee Kindness wrote:
Okay, lets see if i've got this right...
If I allocate the memory before the FETCH then I (naturally) free
it. However If I NULL initialise the pointer then libecpg will
allocate the memory and I must NOT free it - libecpg will free it
automatically... Yeah?
No, I only
Cyril VELTER [EMAIL PROTECTED] writes:
Are the PGShmemHeader fields only used by PGSharedMemoryCreate ?
Other than totalsize and freeoffset, I believe so. I see no reason
that a particular port couldn't stick different fields in there if it
had a mind to.
How does that solve the problem
Marc G. Fournier [EMAIL PROTECTED] writes:
We could get around this, of course: record the port number in the data
directory lockfile, and test for existence of the old socket
independently of trying to create a new one. But it seems ugly.
How about a second, data directory based socket
On Mon, 6 May 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
We could get around this, of course: record the port number in the data
directory lockfile, and test for existence of the old socket
independently of trying to create a new one. But it seems ugly.
How about
Marc G. Fournier [EMAIL PROTECTED] writes:
Hmm ... but how do you use that to tell if there are still backends
around?
As a backend is started up, connect to that socket ... if socket is open
when trying to start a new frontend, fail as there are currently other
connections attached to it?
I said:
But the backends would only have the socket open, they'd not be actively
listening to it. So how could you tell whether anyone had the socket
open or not?
Oh, I take that back, I see how you could do it: the postmaster opens
the socket *for writing*, but never actually writes. All
On Mon, 6 May 2002, Tom Lane wrote:
I said:
But the backends would only have the socket open, they'd not be actively
listening to it. So how could you tell whether anyone had the socket
open or not?
Oh, I take that back, I see how you could do it: the postmaster opens
the socket *for
Marc G. Fournier [EMAIL PROTECTED] writes:
That would work ... but is it more portable than depending on SysV
shmem connection counts? ISTR that some of the platforms we support
don't have Unix-style sockets at all.
Wouldn't the same thing work with a simple file? Does it have to be a
Since our default behavior (at startup) is to have TCP sockets disabled,
how many OSs are there that don't support UD sockets? Enough to really be
worried about?
On Mon, 6 May 2002, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
That would work ... but is it more portable
Marc G. Fournier [EMAIL PROTECTED] writes:
Since our default behavior (at startup) is to have TCP sockets disabled,
how many OSs are there that don't support UD sockets?
A quick look in the sources shows that we #undef HAVE_UNIX_SOCKETS for
QNX, BeOS, and old cygwin versions ... which are
Nigel J. Andrews [EMAIL PROTECTED] writes:
Coming back to this subject if I may but only briefly, I hope. How
about making a slight change to current_schemas() and including an
optional argument such that something like:
current_schemas(1)
returns the complete list of schemas in the search
I've been buried in the backend parser/planner/executor now for the last
2 weeks or so, and I now have a patch for a working implementation of
SRFs as RTEs (i.e. SELECT tbl.* FROM myfunc() AS tbl). I think I'm at
a good point to get review and comments. Not everything yet has been
implemented
Hello postgresql-hackers,
Been a while sine I've particiapated on this list so I wanted to say
thank you for the great product postgresql 7.2.1 is! I have been
doing some testing in preperation of a database upgrade from 7.0.3
to 7.2.1 and I have a few small itches to scratch, so I thought I'd
Well, SharedMemoryIsInUse is *not* just about ensuring that the shared
memory gets reaped. The point is to ensure that you can't start a new
postmaster until the last old backend is gone. (Consider situations
where the parent postmaster process crashes, or perhaps is kill -9'd
by a
Tom Lane wrote:
I said:
But the backends would only have the socket open, they'd not be actively
listening to it. So how could you tell whether anyone had the socket
open or not?
Oh, I take that back, I see how you could do it: the postmaster opens
the socket *for writing*, but never
On Mon, 6 May 2002, Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
Coming back to this subject if I may but only briefly, I hope. How
about making a slight change to current_schemas() and including an
optional argument such that something like:
current_schemas(1)
returns
Nigel J. Andrews [EMAIL PROTECTED] writes:
I also got it wrong about when the temporary space is emptied. I had been
thinking it was when the connection terminated. However, I see from the same
old message that this happens when the first temporary item is created in a
session. Therefore, my
Ryan Bradetich wrote:
Can anyone think of side-affects of changing the tgname column in
the pg_trigger system table? Does this proposal seem like an
acceptable solution? Would there be interest in this if I provided
a patch to do this?
FWIW, not exactly what you are proposing, but
On Mon, 6 May 2002, Nigel J. Andrews wrote:
On Mon, 6 May 2002, Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
Coming back to this subject if I may but only briefly, I hope. How
about making a slight change to current_schemas() and including an
optional argument such
Marc G. Fournier [EMAIL PROTECTED] writes:
Since our default behavior (at startup) is to have TCP sockets disabled,
how many OSs are there that don't support UD sockets?
A quick look in the sources shows that we #undef HAVE_UNIX_SOCKETS for
QNX, BeOS, and old cygwin versions ... which are
Nigel J. Andrews [EMAIL PROTECTED] writes:
For this if we look once again at RelnameGetRelid(relname) in
backend/catalog/namespace.c wouldn't this is_visible() function simply be a
wrapper around it?
Sort of. It's there already, see RelationIsVisible.
regards, tom
On Mon, 6 May 2002, mlw wrote:
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Well, I guess that just saved *me* alot of work ... thanks ...
Uh, not yet. Don't you still need a semaphore implementation that
works on Windows?
I have a LOT of experience with Windows
Are the numbers of the directories in the base diretory and the numbers of
the directories under that, etc. traceable to a reference somewhere in the
postgresql server using that data directory (such as the pg_database table
or such)? If so, is there somewhere this is documented?
Thanks,
--
The numbers are the same as the oids found in pg_database (as you expected).
This question is better suited for the -general list, for future reference.
Regards,
Jeff
On Monday 06 May 2002 04:31 pm, Laurette Cisneros wrote:
Are the numbers of the directories in the base diretory and
Neil Conway wrote:
On Mon, 6 May 2002 08:44:27 +0900
"Hiroshi Inoue" [EMAIL PROTECTED] wrote:
-Original Message-
From: Manfred Koizar
If there is interest in reducing on-disk tuple header size and I have
not missed any strong arguments against dropping t_natts, I'll
I think the real trick is keeping track of the difference between:
begin;
ALTER TABLE tab ADD COLUMN col1 int4 DEFAULT 4;
commit;
and
begin;
ALTER TABLE tab ADD COLUMN col1;
ALTER TABLE tab ALTER COLUMN col1 SET DEFAULT 4;
commit;
The first should populate the column with the value of '4', the
Feedback: you're a legend!
I'll try to patch my CVS and test it at some point...
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Joe Conway
Sent: Tuesday, 7 May 2002 12:51 AM
To: pgsql-hackers
Subject: [HACKERS] Set Returning Functions
Rod Taylor wrote:
I think the real trick is keeping track of the difference between:
begin;
ALTER TABLE tab ADD COLUMN col1 int4 DEFAULT 4;
commit;
and
begin;
ALTER TABLE tab ADD COLUMN col1;
ALTER TABLE tab ALTER COLUMN col1 SET DEFAULT 4;
commit;
The first should populate the
44 matches
Mail list logo
