Mark Wong wrote:
I have some initial results using 8.0beta5 with our OLTP workload.
Off the bat I see about a 23% improvement in overall throughput. The
most significant thing I've noticed was in the oprofile report where
FunctionCall2 and hash_seq_search have moved down the profile a bit.
Also,
On Tue, 2004-11-30 at 17:54 +1100, Johan Wehtje wrote:
> I am getting the error "Column n.nsptablespace does not exist" in my
> application when I connect using my Administrative tool. This only
> happens with Version 8, but it does crash my application, does anyone
> have any ideas ?
You need
On Tue, 2004-11-30 at 04:35, Tom Lane wrote:
> Mark Wong <[EMAIL PROTECTED]> writes:
> > I have some initial results using 8.0beta5 with our OLTP workload.
> > Off the bat I see about a 23% improvement in overall throughput.
>
> Between beta4 and beta5? That's astonishing. We didn't really do ve
Mark Wong <[EMAIL PROTECTED]> writes:
> I have some initial results using 8.0beta5 with our OLTP workload.
> http://www.osdl.org/projects/dbt2dev/results/dev4-010/199/
> throughput: 4076.97
Do people really only look at the "throughput" numbers? Looking at those
graphs it seems that w
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The advantage of having it in COPY is that it can be done serverside direct
> from the file system. For massive bulk loads that might be a plus, although I
> don't know what the protocol+socket overhead is.
Actually even if you use client-side COPY i
Oops! [EMAIL PROTECTED] (Bruce Momjian) was seen spray-painting on a wall:
> That could be part of auto-vacuum. Vacuum itself would still
> sequential scan, I think. The idea is to easily grab expire tuples
> when they are most cheaply found.
The nifty handling of this would be to introduce "VAC
Robert Treat <[EMAIL PROTECTED]> writes:
> don't we normally announce if initdb is required on new beta releases? We
> should.
It was sloppy that we didn't do that for beta5, and I apologize for it.
One problem is that we don't have a defined place for per-beta-version
release notes. The curr
Mark Wong <[EMAIL PROTECTED]> writes:
> I have some initial results using 8.0beta5 with our OLTP workload.
> Off the bat I see about a 23% improvement in overall throughput.
Between beta4 and beta5? That's astonishing. We didn't really do very
much that was performance-focused. Digging in the C
Tom Lane wrote:
Kris Jurka <[EMAIL PROTECTED]> writes:
Endlessly extending the COPY command doesn't seem like a winning
proposition to me and I think if we aren't comfortable telling every user
to write a script to pre/post-process the data we should instead provide a
bulk loader/unloader th
On Monday 29 November 2004 16:48, Dave Cramer wrote:
> Hi,
>
> Mike Aubury is considering porting Aubit 4GL
> http://www.aubit.com/index.php?page=Products/Aubit4gl to native
> postgresql.
>
> If this is of interest to you please respond. He is trying to measure
> the level of interest.
An unname
On 11/29/2004 10:43 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
I don't agree that the right cure is to execute each and every statement
itself as a subtransaction. What we ought to do is to define a wrapper
for the catch Tcl command, that creates a subtransaction and executes
the
Tom Lane wrote:
> Kris Jurka <[EMAIL PROTECTED]> writes:
> > Endlessly extending the COPY command doesn't seem like a winning
> > proposition to me and I think if we aren't comfortable telling every user
> > to write a script to pre/post-process the data we should instead provide a
> > bulk load
On Monday 29 November 2004 02:58, Christopher Kings-Lynne wrote:
> > Hmm. This error is not coming from "a line of the copy", it is occurring
> > because the COPY command itself fails, and so the server never tells
> > psql to shift into COPY mode. I'm not sure that a reasonable fix for
> > this
Jan Wieck <[EMAIL PROTECTED]> writes:
> I don't agree that the right cure is to execute each and every statement
> itself as a subtransaction. What we ought to do is to define a wrapper
> for the catch Tcl command, that creates a subtransaction and executes
> the code within during that.
What I
Kris Jurka <[EMAIL PROTECTED]> writes:
> Endlessly extending the COPY command doesn't seem like a winning
> proposition to me and I think if we aren't comfortable telling every user
> to write a script to pre/post-process the data we should instead provide a
> bulk loader/unloader that transform
Kris Jurka wrote:
>
>
> On Mon, 29 Nov 2004, Andrew Dunstan wrote:
>
> > Longer term I'd like to be able to have a command parameter that
> > specifies certain fields as multiline and for those relax the line end
> > matching restriction (and for others forbid multiline altogether). That
> >
Matthew T. O'Connor wrote:
> Bruce Momjian wrote:
>
> >Matthew T. O'Connor wrote:
> >
> >
> >>Bruce Momjian wrote:
> >>
> >>
> >>>I have added an auto-vacuum TODO item:
> >>>
> >>>* Auto-vacuum
> >>> o Move into the backend code
> >>> o Scan the buffer cache to find free space or
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Bruce Momjian wrote:
I have added an auto-vacuum TODO item:
* Auto-vacuum
o Move into the backend code
o Scan the buffer cache to find free space or use background writer
o Use free-space map information to guide refilling
Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Gavin Sherry wrote:
> > On Mon, 29 Nov 2004, Marc G. Fournier wrote:
> >
> > >
> > > If there were a comp.databases.postgresql.hackers newsgroup created and
> > > carried by all the news servers ... would you move to using it vs using
> > > the mailing
On Monday 29 November 2004 11:03, Andreas Pflug wrote:
> Christopher Kings-Lynne wrote:
> >>> Sorry Chris - obviously the pgAdmin team are just a bit crazier than
> >>> your lot :-)
> >>
> >> And a little faster fixing it :-)
> >
> > I didn't even see it go through. Which is weird because I normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> If there were a comp.databases.postgresql.hackers newsgroup created and
> carried by all the news servers ... would you move to using it vs using
> the mailing lists?
No, but I might use it from time to time. Although I abandoned newsgroups a
On Mon, 2004-11-29 at 15:03 -0400, Marc G. Fournier wrote:
> If there were a comp.databases.postgresql.hackers newsgroup created and
> carried by all the news servers ... would you move to using it vs using
> the mailing lists?
Is there a reliable, fast, public news server out there which would
Mark Wong wrote:
> I have some initial results using 8.0beta5 with our OLTP workload.
> Off the bat I see about a 23% improvement in overall throughput. The
> most significant thing I've noticed was in the oprofile report where
> FunctionCall2 and hash_seq_search have moved down the profile a bit.
On Mon, 29 Nov 2004, Bruce Momjian wrote:
Gavin Sherry wrote:
On Mon, 29 Nov 2004, Marc G. Fournier wrote:
If there were a comp.databases.postgresql.hackers newsgroup created and
carried by all the news servers ... would you move to using it vs using
the mailing lists?
The USENET community seems to
That would be something good for 8.1 so I will keep your email.
This has been saved for the 8.1 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Gevik Babakhani wrote:
> Dear People,
>
> Hereby a propo
Matthew T. O'Connor wrote:
> Bruce Momjian wrote:
>
> >I have added an auto-vacuum TODO item:
> >
> >* Auto-vacuum
> >o Move into the backend code
> >o Scan the buffer cache to find free space or use background writer
> >o Use free-space map information to guide refilling
>
Gavin Sherry wrote:
> On Mon, 29 Nov 2004, Marc G. Fournier wrote:
>
> >
> > If there were a comp.databases.postgresql.hackers newsgroup created and
> > carried by all the news servers ... would you move to using it vs using
> > the mailing lists?
> >
> > The USENET community seems to think that t
[EMAIL PROTECTED] ("Gevik Babakhani") writes:
>Maybe it is me but, I am trying to send a posting regarding a solution
>proposal for a TODO item.
>My posting has a .tgz attachment but it seems that it never arives at
>hackers list!
>This is very frustrating. I even ask Bruce for help.
how big is
On 11/19/2004 7:54 PM, Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
My approach with PL/Java is a bit different. While each SPI call is
using a try/catch they are not using a subtransaction. The catch will
however set a flag that will ensure two things:
1. No more calls can be mad
On Mon, 29 Nov 2004, Andrew Dunstan wrote:
> Longer term I'd like to be able to have a command parameter that
> specifies certain fields as multiline and for those relax the line end
> matching restriction (and for others forbid multiline altogether). That
> would be a TODO for 8.1 though, al
I have some initial results using 8.0beta5 with our OLTP workload.
Off the bat I see about a 23% improvement in overall throughput. The
most significant thing I've noticed was in the oprofile report where
FunctionCall2 and hash_seq_search have moved down the profile a bit.
Also, I have libc with
I just finished doing a brief evaluation of informix-4gl. I was going to
do some non-4gl work for a company that uses 4gl extensively, so I just
wanted to get an idea where they were coming from.
I am interested in that PostgreSQL port, but right now it's just
academic.
Regards,
Jeff Davi
On Mon, 29 Nov 2004, Marc G. Fournier wrote:
>
> If there were a comp.databases.postgresql.hackers newsgroup created and
> carried by all the news servers ... would you move to using it vs using
> the mailing lists?
>
> The USENET community seems to think that there would be a mass exodus from
> t
On Mon, 2004-11-29 at 15:03 -0400, Marc G. Fournier wrote:
> If there were a comp.databases.postgresql.hackers newsgroup created and
> carried by all the news servers ... would you move to using it vs using
> the mailing lists?
No.
-Neil
---(end of broadcast)-
On Mon, 2004-11-29 at 15:37, Tom Lane wrote:
> "Zeugswetter Andreas DAZ SD" <[EMAIL PROTECTED]> writes:
> > Tom wrote:
> >>> But I am used to applications
> >>> that prepare a query and hold the plan for days or weeks. If you happen
> >>> to
> >>> create the plan when the table is by chance empty
Hi,
Mike Aubury is considering porting Aubit 4GL
http://www.aubit.com/index.php?page=Products/Aubit4gl to native
postgresql.
If this is of interest to you please respond. He is trying to measure
the level of interest.
--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561
-
Dear People,
Hereby a proposal for the TODO item "Clients: Have psql show current values
for a sequences".
I have added a new slash command to psql client "\sq" for showing the last
values of the
existing sequences in the public schema. The code is only tested on rh9.
The new files are sequence_
Marc G. Fournier wrote:
> If there were a comp.databases.postgresql.hackers newsgroup created
> and carried by all the news servers ... would you move to using it vs
> using the mailing lists?
No.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of br
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Mon, 29 Nov 2004, Marc G. Fournier wrote:
If there were a comp.databases.postgresql.hackers newsgroup created and
carried by all the news servers ... would you move to using it vs using the
mailing lists?
No. Using mailing lists is what I prefe
The WWW folks just put up a survey asking:
"If there was an official newsgroup for postgresql, would you switch to
using Usenet from using the mailing lists?"
The Poll can be found at http://www.postgresql.org ... we're curious as to
what sort of interest there is by the 'General Users' ...
As
Marc G. Fournier wrote:
The USENET community seems to think that there would be a mass exodus
from the lists to usenet ... based on past discussions concerning moving
some stuff out of email to stuff like bug trackers, I don't believe this
to be the case, but am curious what the opinion of other
Maybe it is me but, I am trying to send a posting regarding a solution
proposal for a TODO item.
My posting has a .tgz attachment but it seems that it never arives at
hackers list!
This is very frustrating. I even ask Bruce for help.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMA
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> If there were a comp.databases.postgresql.hackers newsgroup created and
> carried by all the news servers ... would you move to using it vs using the
> mailing lists?
>
> The USENET community seems to think that there would be a mass exodus from th
On Mon, 29 Nov 2004, Gevik Babakhani wrote:
I was wondering if there is a better solution than mailing lists.
My experience is that mailing lists are somewat combersome to use.
Especially when your postings do not arrive!
When they don't arrive? *raised eyebrow* You having a problem? :(
I don't kn
Didn't know that existed...
Ack ... its never been 'hidden', but its also never been fully
advertised either ...
To be fair, I didn't know it existed until the whole usenet thing popped
up either.
Sincerely,
Joshua D. Drake
I'm tempted to write a 'monthly FAQ' that gets posted that talks about
I was wondering if there is a better solution than mailing lists.
My experience is that mailing lists are somewat combersome to use.
Especially when your postings do not arrive!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc G. Fournier
Sent: Monda
On Mon, 29 Nov 2004, Rod Taylor wrote:
Is there a reliable, fast, public news server out there which would
carry it at reasonable speed (my ISP updates their groups nightly --
completely useless).
news.postgresql.org?
Didn't know that existed...
Ack ... its never been 'hidden', but its also never b
Bruce Momjian wrote:
I have added an auto-vacuum TODO item:
* Auto-vacuum
o Move into the backend code
o Scan the buffer cache to find free space or use background writer
o Use free-space map information to guide refilling
I'm not sure what you mean exactly by "Scan the buffer
> > Is there a reliable, fast, public news server out there which would
> > carry it at reasonable speed (my ISP updates their groups nightly --
> > completely useless).
>
> news.postgresql.org?
Didn't know that existed...
---(end of broadcast)---
Hello Russell,
Russell Smith wrote:
I am doing serious thinking about the implementation of Auto Vacuum as part of
the backend, Not using libpq, but classing internal functions directly.
It appears to me that calling internal functions directly is a better
implementation than using the external l
On Mon, 29 Nov 2004, Rod Taylor wrote:
On Mon, 2004-11-29 at 15:03 -0400, Marc G. Fournier wrote:
If there were a comp.databases.postgresql.hackers newsgroup created and
carried by all the news servers ... would you move to using it vs using
the mailing lists?
Is there a reliable, fast, public news
On Mon, Nov 29, 2004 at 07:35:41AM -0500, Jim Seymour wrote:
>
> Chris Green <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, Nov 28, 2004 at 07:34:28PM -0400, Marc G. Fournier wrote:
> > >
> > > What is the general opinion of this? I'd like to implement it, but not
> > > so
> > > much so that I'm
On Sun, Nov 28, 2004 at 07:34:28PM -0400, Marc G. Fournier wrote:
>
> What is the general opinion of this? I'd like to implement it, but not so
> much so that I'm going to beat my head against a brick wall on it ...
>
Personally I'm against it because it means that I'll often get two
replies wh
Bruce Momjian wrote:
Should I add a TODO to warn if FSM values are too small? Is that doable?
It sounds like it should be, and it would be a valuable pointer to
people, so yep.
Any idea who'd be interested in claiming it?
Regards and best wishes,
Justin Clift
---(end of b
Marc G. Fournier wrote:
If there were a comp.databases.postgresql.hackers newsgroup created and
carried by all the news servers ... would you move to using it vs using
the mailing lists?
No.
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 2: yo
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> If there were a comp.databases.postgresql.hackers newsgroup created and
> carried by all the news servers ... would you move to using it vs using
> the mailing lists?
No. I abandoned Usenet years ago.
regards, tom lane
-
Marc G. Fournier wrote:
If there were a comp.databases.postgresql.hackers newsgroup created and
carried by all the news servers ... would you move to using it vs using
the mailing lists?
Heck no. I have no desire to use USENET.
Sincerely,
Joshua D. Drake
The USENET community seems to think that
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
If there were a comp.databases.postgresql.hackers newsgroup created and
carried by all the news servers ... would you move to using it vs using
the mailing lists?
The USENET community seems to think that there would be a mass exodus from
the lists to usenet ... based on past discussions concern
Tom Lane <[EMAIL PROTECTED]> writes:
> Nonsense. You're assuming incremental changes (ie, only a small
> fractional change in table size), but we are getting killed by
> non-incremental cases. If the plan cost estimates are such that a small
> fractional change in table size will cause the plann
Simon Riggs <[EMAIL PROTECTED]> writes:
> Greg's additional request might be worded:
>
> * Allow a warm standby system to also allow read-only queries
Others have also asked in the past for a mode where a database could be run
off read-only media like a CD-ROM. I would phrase it more like
Joe Conway <[EMAIL PROTECTED]> writes:
> Problem is that a polymorphic SRF cannot (currently at least) both
> accept and return type anyarray.
Beyond that, would the proposed function really be SQL-compliant other
than this one point? I had the idea that UNNEST required some
fundamental changes
Tom,
Here's an attempt to do some major rethinking and solve all open issues
(and of course creating some new ones).
The idea is based on use of normal tables with a bytea column that
stores one LO-page per row (henceforth referred to as LO-page tables).
Several such tables can be used in order
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I'm unsure why you feel you need a knob to defeat this.
> Simply put because the optimizer isn't infallible.
And one of the main reasons that it's fallible is because it sometimes
uses grossly obsolete statistics. W
Bruce Momjian wrote:
I assume this is not something for our PostgreSQL CVS, even the later
SRF implementation.
I agree with that assessment, at least in its present state. For example:
regression=# select * from unnest(array[[1,2,3],[4,5,6]]);
unnest
1
2
3
4
Tom Lane <[EMAIL PROTECTED]> writes:
> I'm unsure why you feel you need a knob to defeat this. The only time
> when the plan would change from what you think of as the hand-tuned
> case is when the physical table size is greatly different from what it
> was when you analyzed. The entire point o
Simon Riggs <[EMAIL PROTECTED]> writes:
> The SQL window functions seem to require an ordering for most of their
> operations.
AFAICS, the entire concept of a "window" implies the input is ordered
in some way; what operations would they provide that don't require this?
> It is possible that that
Simon Riggs wrote:
> On Mon, 2004-11-29 at 13:10, Bruce Momjian wrote:
>
>>Or TODO maybe worded as:
>>
>>* Allow the PITR process to be debugged and data examined
>>
>
>
> Yes, thats good for me...
>
> Greg's additional request might be worded:
>
>* Allow a warm standby system to also
Tom Lane <[EMAIL PROTECTED]> writes:
> Disable tab completion, or don't paste tabs. I don't think psql can be
> expected to recognize that a tab is coming from pasted input.
Hm, this also bother me all the time. It doesn't sound like it would be very
hard to detect pasted tabs actually. Two opti
"Zeugswetter Andreas DAZ SD" <[EMAIL PROTECTED]> writes:
> I think I recall that lseek may have a negative effect on some OS's
> readahead calculations (probably only systems that cannot handle an
> lseek to the next page eighter) ? Do you think we should cache the
> last value to avoid the syscall
>> This is not true in my case, since I only "update statistics"/analyze
>> when the tables have representative content (i.e. not empty).
>
> I'm unsure why you feel you need a knob to defeat this. The only time
> when the plan would change from what you think of as the hand-tuned
> case is when
Christopher Kings-Lynne wrote:
Sorry Chris - obviously the pgAdmin team are just a bit crazier than
your lot :-)
And a little faster fixing it :-)
I didn't even see it go through. Which is weird because I normally
notice that kind of thing...
Same with us. It's probably the result of the 100+m
Hi
I would like to test, how storing one biggish (~450 bytes bytea) column
into toast table would affect my applications performance.
is there a way to set the values used for this using some SET variable
or some column in system tables.
or is my only option to build a custom version of server w
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Also, can you explain why we can't read across a newline to the next
> quote? Is it a problem with the way our code is structured or is it a
> logical problem?
It's a structural issue in the sense that we separate the act of
dividing the input into rows
"Zeugswetter Andreas DAZ SD" <[EMAIL PROTECTED]> writes:
> Tom wrote:
>>> But I am used to applications
>>> that prepare a query and hold the plan for days or weeks. If you happen to
>>> create the plan when the table is by chance empty you lost.
>>
>> You lose in either case, since this proposal
An example of a window function is RANK or a moving AVG, though also
include ROW_NUMBER or CUME_DIST. They are a different kind of aggregate
introduced by/included in SQL:2003, which require a "sliding window" of
rows.
The SQL window functions seem to require an ordering for most of their
operatio
Sorry Chris - obviously the pgAdmin team are just a bit crazier than
your lot :-)
And a little faster fixing it :-)
I didn't even see it go through. Which is weird because I normally
notice that kind of thing...
Chris
---(end of broadcast)---
TIP
Bruce Momjian wrote:
Also, can you explain why we can't read across a newline to the next
quote? Is it a problem with the way our code is structured or is it a
logical problem? Someone mentioned multibyte encodings but I don't
understand how that applies here.
In a CSV file, each line is a re
On Mon, 2004-11-29 at 13:10, Bruce Momjian wrote:
> Or TODO maybe worded as:
>
> * Allow the PITR process to be debugged and data examined
>
Yes, thats good for me...
Greg's additional request might be worded:
* Allow a warm standby system to also allow read-only queries
Thanks
Bruce Momjian wrote:
Andrew Dunstan wrote:
OK, then should we disallow dumping out data in CVS format that we can't
load? Seems like the least we should do for 8.0.
As Tom rightly points out, having data make the round trip was not the
goal of the exercise. Excel, for example, has no
Bruce Momjian wrote:
> Andrew Dunstan wrote:
> > >OK, then should we disallow dumping out data in CVS format that we can't
> > >load? Seems like the least we should do for 8.0.
> > >
> > >
> > >
> >
> > As Tom rightly points out, having data make the round trip was not the
> > goal of the exer
Andrew Dunstan wrote:
> >OK, then should we disallow dumping out data in CVS format that we can't
> >load? Seems like the least we should do for 8.0.
> >
> >
> >
>
> As Tom rightly points out, having data make the round trip was not the
> goal of the exercise. Excel, for example, has no troubl
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Which we do not have, because pg_dump doesn't use CSV. I do not think
this is a must-fix, especially not if the proposed fix introduces
inconsistencies elsewhere.
Sure, pg_dump d
Justin Clift wrote:
> Bruce Momjian wrote:
> > Should I add a TODO to warn if FSM values are too small? Is that doable?
>
> It sounds like it should be, and it would be a valuable pointer to
> people, so yep.
>
> Any idea who'd be interested in claiming it?
Turns out it was already on the TODO
Or TODO maybe worded as:
* Allow the PITR process to be debugged and data examined
---
Simon Riggs wrote:
> On Mon, 2004-11-29 at 02:20, Bruce Momjian wrote:
>
> > Is this a TODO?
>
> Yes, but don't hold your bre
OK, how would it be worded?
* Allow PITR recovery to a read-only server
---
Simon Riggs wrote:
> On Mon, 2004-11-29 at 02:20, Bruce Momjian wrote:
>
> > Is this a TODO?
>
> Yes, but don't hold your breath on that
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Which we do not have, because pg_dump doesn't use CSV. I do not think
> >> this is a must-fix, especially not if the proposed fix introduces
> >> inconsistencies elsewhere.
>
> > Sure, pg_dump doesn't use it but
Chris Green <[EMAIL PROTECTED]> wrote:
>
> On Sun, Nov 28, 2004 at 07:34:28PM -0400, Marc G. Fournier wrote:
> >
> > What is the general opinion of this? I'd like to implement it, but not so
> > much so that I'm going to beat my head against a brick wall on it ...
> >
> Personally I'm against
>> One possibility: vacuum already knows how many tuples it removed. We
>> could set reltuples equal to, say, the mean of the number-of-tuples-
>> after-vacuuming and the number-of-tuples-before. In a steady state
>> situation this would represent a fairly reasonable choice. In cases
>> where t
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED] on behalf of Christopher Kings-Lynne
Sent: Sun 11/28/2004 2:57 PM
To: Roland Volkmann
Cc: PostgreSQL Developers
Subject: Re: [HACKERS] Error: column "nsptablespace" does not exist
No other applications will be broken because no
On Mon, 2004-11-29 at 02:20, Bruce Momjian wrote:
> Is this a TODO?
Yes, but don't hold your breath on that feature.
Gavin and I were discussing briefly a design that would allow something
similar to this. The design would allow the user to stop/start recovery
and turn a debug trace on/off, in a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Which we do not have, because pg_dump doesn't use CSV. I do not think
>> this is a must-fix, especially not if the proposed fix introduces
>> inconsistencies elsewhere.
> Sure, pg_dump doesn't use it but COPY should be able to load an
92 matches
Mail list logo
