I'll look into that. Thanks for pointing it out.
Kind regards,
Thomas Hallgren
Alvaro Herrera [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hackers,
I think there a bug in the GUC mechanism. The custom variables patch
added several malloc() and a strdup() call, and they are
Greg Sabino Mullane wrote:
* PREPARE OR REPLACE...
This would be an incredibly useful command since there's no
way of _checking_ in advance that a name is already used as a
prepared statement...
A check would be nice (and I've asked about it before) but it's
really not a lot of jumping through
Rather than clutter the code with the same ereport over and over again (I
count 12 malloc's in guc.c alone), I'd like something like this:
void* malloc_or_fail(int elevel, size_t sz)
{
void* result;
if(sz 1)
/*
* Make sure we have something that can be passed to free()
On Wed, Jun 23, 2004 at 03:26:49PM -0400, Tom Lane wrote:
Even if the spec doesn't help, I think a statement prepared within a
transaction should definitely be deallocated at the end of the transaction.
Uh, you do realize that Postgres does *everything* within a transaction?
Well, except
On Wed, 23 Jun 2004, Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
With our new tablespace set up, is it ever possible for someone to move
pg_largeobject to another tablespace?
Assuming that ALTER TABLE SET TABLESPACE gets in, my preferred answer is
to apply that
I have gotten no reply to my request to either move the include
functionality into the guc-file.l or remove it and just add docs for the
config location part of the patch. I now would like someone else to
take the patch and make those changes to get it applied before feature
freeze. If not, I
Thomas Hallgren [EMAIL PROTECTED] writes:
From an OO semantics point of view, I still regard Java and C# much more
elaborate than both C++ and Common Lisp. The latter lacks interfaces and
different levels of protection.
It doesn't lack interfaces. It has actual multiple inheritance. Which is
Jeroen T. Vermeulen wrote:
Well, except prepared statements apparently; I'm not sure why they are
an
exception.
When I say within a transaction as opposed to outside a transaction,
I
mean of course an explicit transaction. If you want a prepared
statement
to last throughout the session,
Thomas Hallgren [EMAIL PROTECTED] writes:
Rather than clutter the code with the same ereport over and over again (I
count 12 malloc's in guc.c alone), I'd like something like this:
The larger question is why it contains even one. In general, use of
malloc in the backend is the mark of a
On Thu, Jun 24, 2004 at 08:51:32AM -0400, Merlin Moncure wrote:
When I say within a transaction as opposed to outside a transaction,
I
mean of course an explicit transaction. If you want a prepared
statement
to last throughout the session, I'd say it stands to reason that you
create it
Greg Stark [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Thomas Hallgren [EMAIL PROTECTED] writes:
From an OO semantics point of view, I still regard Java and C# much more
elaborate than both C++ and Common Lisp. The latter lacks interfaces and
different levels of protection.
Please post this to the jdbc list.
Dave
On Sun, 2004-06-20 at 08:09, Henner Zeller wrote:
Hi,
While tracking down a query with a JDBC prepared statement, I
noticed, that the statement actually wasn't prepared but sent to the
server as 'normal' Statement. In my case, this led to a very slow
Ok, so I'm a newbie. To my defence I'll say that I made an effort to follow
the style previously used in guc.c. The unchecked mallocs I added where not
the first ;-)
So, what you are saying is that there's no need for the functions I
suggested and that a palloc using the TopMemoryContext will
Just my 2 cents here. I agree with tom that the curent behevior for the v3
protocol is the right one. I use On demand preparation. The first time a
statement is needed for a specific connection, it is prepared and the client
keep track of that (reusing the prepared statement for
On Jun 24, 2004, at 10:45 AM, Thomas Hallgren wrote:
So, what you are saying is that there's no need for the functions I
suggested and that a palloc using the TopMemoryContext will guarantee
correct behavior on out of memory?
Perhaps a section regarding proper memory management code in the
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I intend to make new archives created with 7.5 pg_dump have the fix, and
restoring pre 7.5 binary dumps will have exactly the previous
behaviour. The reason for this is that extracting the acls and owners
to the end requires scanning the
Chris,
Nothing gets silently dropped. It will cause an ERROR on creation and
then keep going, but it won't silently drop it... (unless it's a
binary dump thing...)
Silently dropped on dump, not on restore.
Anyway, pg_dump in CVS does correct dump ordering based on a topological
sort of
On Thu, Jun 24, 2004 at 05:11:48PM +0200, Cyril VELTER wrote:
Just my 2 cents here. I agree with tom that the curent behevior for the v3
protocol is the right one.I use On demand preparation. The first time a
statement is needed for a specific connection, it is prepared and the client
Josh Berkus [EMAIL PROTECTED] writes:
Right. The issue is really complex databases which were developed in 7.2 or
7.1, which is missing the pg_depends information.In that case, pg_dump
seems to get confused about dependency sorting, and a few objects with long
dependency chains simply
On Thu, Jun 24, 2004 at 04:45:31PM +0200, Thomas Hallgren wrote:
Ok, so I'm a newbie. To my defence I'll say that I made an effort to follow
the style previously used in guc.c. The unchecked mallocs I added were not
the first ;-)
Apparently Peter thought it was a good idea *not* to use palloc
Alvaro Herrera [EMAIL PROTECTED] writes:
This is why I proposed originally to keep the non-transactional behavior
for Parse messages, but transactional for SQL PREPARE. The latter can
be said to be inside the transaction and should behave like so. I think
this lowers the surprise factor.
It
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm not sure exactly why this is a good idea. After all, if the systems
runs out of memory while starting up, what can be expected later?
The issue isn't with startup, but with re-reading postgresql.conf due to
SIGHUP later on. We don't want to
Your response times improved across the board over 7.4.1.. Is that
change significant, or within the variation you see on your system?
On Wed, 2004-06-23 at 14:24, [EMAIL PROTECTED] wrote:
Hello,
Just wanted to share some data I've generated with dbt-2 using
tablespaces from a CVS export of
De : mailto:[EMAIL PROTECTED]
Emission : 24/06/2004 18:59:15
On Thu, Jun 24, 2004 at 05:11:48PM +0200, Cyril VELTER wrote:
Just my 2 cents here. I agree with tom that the curent behevior for the v3
protocol is the right one. I use On demand preparation. The first time a
statement is
I disagree. Lots of people use prepared statements for all kinds of
different reasons. A large percentage of them do not need or make
use
of explicit transactions. Having to continually rebuild the
statement
would be a hassle. The caching mechanism also seems like extra work
for
I
Greg,
You don't like Java/C#. I do. There's not much point arguing about it.
You feel that abstract classes are equivalent to interfaces provided you
have multiple inheritance, I don't since I'm in favor of a totally clean
interface/implementation separation.
Now you bring in the Java security
In the Single Unix Spec man page for syslog, I read
LOG_NOWAIT
Do not wait for child processes that may have been created during the course
of logging the message.
This option should be used by processes that enable notification of child
termination using SIGCHLD,
I intend to make new archives created with 7.5 pg_dump have the fix, and
restoring pre 7.5 binary dumps will have exactly the previous
behaviour. The reason for this is that extracting the acls and owners
to the end requires scanning the entire archive twice - not necessarily
something we
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
But...it seems kind of hacky to scan it again for owners and privs - are
you sure you want me to go that way?
If there's not a big performance penalty, sure. Being fully compatible
with existing archive files is a sufficient win to justify
Greg Sabino Mullane [EMAIL PROTECTED] writes:
I was originally unhappy with the current situation, but now I think
it is the best. Any changes will also cause a huge further headache
for driver/application writers, as we already have a released version
(and probably at least one more) with the
If there's not a big performance penalty, sure. Being fully compatible
with existing archive files is a sufficient win to justify sins much
worse than this one.
Out of interest - have you developed an opinion on the
pg_get_serial_sequence thing? Also, what's the latest I can get pg_dump
fixes
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Out of interest - have you developed an opinion on the
pg_get_serial_sequence thing?
Will apply as soon as I get a chance --- I'd intended to clean out the
patch queue today, but didn't get past Magnus' stuff.
Also, what's the latest I can
32 matches
Mail list logo
