There has been a discussion on the general list about this area. One of
the members produced a test case for demonstrating rapid size increase.
I decided to see if I could induce similar behaviour with a more
(seemingly) benign example.
I tried this :
1) Create a table and load 10 rows (wit
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 shoul
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
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
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
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
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,
--
L
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 exp
Scrach itch #2. I just figured out how to change the ownership of a
sequence:
alter table owner to .
Amazing how easy it is to figure out once you have posted the question
to the mailing list :)
thanks,
- Ryan
On Mon, 2002-05-06 at 11:52, Ryan Bradetich wrote:
.. snip ...
> Itch #
"Igor Kovalenko" <[EMAIL PROTECTED]> writes:
>> Could we get away with saying that the Unix-socket-less platforms have
>> weaker protection against mistakenly restarting the postmaster?
> Why can't we use named pipe (aka FIFO file) instead of UDS?
That's exactly what I'm talking about.
> Anothe
"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,
> "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 ..
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
> > > optiona
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 A
"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. Therefo
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(
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*, bu
> 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 car
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
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
implemente
"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
Re: BackendID and the schema search path
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 pat
"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
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 port
"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
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 soc
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
"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 attach
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.
"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
"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 pr
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
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
Although I can't tell for sure, I really don't think it's the output of the
UPDATE 0 that is causing the problem. I configured the server to log all
queries last night, and it looks to me like it (MS Access) is doing stupid
stuff. (Like issuing a select on all fields (but not *), and then issuing
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 PROTECTE
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 i
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 wo
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 secu
> -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
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
> 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'
> > > 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 ther
On Mon, May 06, 2002 at 11:24:36AM +0100, Lee Kindness wrote:
> 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. No ma
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 r
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 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
> "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 di
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 buildin
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 b
49 matches
Mail list logo
