It should be there --- in general pg_dumpall should be able to pass down
any pg_dump switch that makes sense.
Do the -S and -O switches also make sense? Should I add them?
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free space
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 ca
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 i
"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) w
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
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 wan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> It seems like we are closing in on an agreement that that is what
> should happen.
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 w
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,
sinc
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
> > 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
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
> > stat
"Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> Yes, it does lack interfaces and no, interfaces are definitely *not* a
> substitute for multiple inheritance.
I assure you that interfaces were put into Java specifically as a substitute
for full-blown multiple inheritance. The normal way to descri
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
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 elog
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
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 pallo
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 si
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 cli
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
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
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
backe
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
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 guar
[ all snipped ]
A problem with redefining the lifetime of a PREPARE'd statement
according to if it was defined within an explicitly managed transaction
or not would be with middlewares such as J2EE / EJB containers. The
container / JDBC driver performs most operations within explicitly
managed
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 s
"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 level
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> I think we're talking at cross purposes here... If the client doesn't use
> explicit transactions, as you say is common, then you're obviously not
> defining prepared statements inside explicit transactions either.
This whole discussion seems to
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
>
"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 n
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 sess
"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.
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 ca
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 t
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, ex
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() e
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 ho
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
37 matches
Mail list logo
