The pg_dump fix in 8.0 that stops the destruction of existing users in
the target database via DELETE FROM pg_shadow WHERE usesysid (...
would be great!
regards
Mark
Tom Lane wrote:
Comments anyone? Backpatches for other bugs?
---(end of
Sorry - I meant pg_dump*all* rather than pg_dump.
Mark Kirkwood wrote:
The pg_dump fix in 8.0 that stops the destruction of existing users in
the target database via DELETE FROM pg_shadow WHERE usesysid (...
would be great!
regards
Mark
Tom Lane wrote:
Comments anyone? Backpatches for other
Robert,
Are you planning to use Intel's C compiler in production?
We tried that some time ago and corrupted our database cluster almost
instantly (for some reason we have not investigated any further).
I highly recommend to do some stress testing to see if everything works
nicely.
I'd be pleased
Dear Peter,
Am Dienstag, 10. August 2004 17:55 schrieb Fabien COELHO:
(1) all makefiles in contrib include directly src/Makefile.global which
is generated by configure, although it is already included by the
src/makefiles/pgxs.mk makefile anyway, so it seems to me that it
is
Philip Warner said:
At 12:15 PM 12/08/2004, Tom Lane wrote:
You might need to bite the bullet and implement a flex
lexer.
I'd like to avoid this if I can; AFAICT, for statement detection on
pg_restore, I can require white space before the $tag. Since I also
skip over all quoted text, the
In article [EMAIL PROTECTED],
Stephan Szabo [EMAIL PROTECTED] writes:
Right, the reason it's important is that there are some things now that
are potentially tied together. If you have table A with rows A1,...,An and
table B with rows B1,...,Bm and the delete join condition gives the two
With help from Christopher I've made some other tests.
Neither 7.4 nor 7.5/8.0 pg_dump are able to detect the
error. Here is a summary:
The produced dump creates a SEQUENCE SET call with no
corresponding SEQUENCE or TABLE SCHEMA creating the
sequence. No Error or warning is issued at dump time,
Hi Tom,
Just re-installed a new version of Postgres 7.3.4 on a *clean* version
of Mandrake 9.2, which seemed to work well. The reference to the
xlateSqlType symbol is gone from plpgsql.so.
All postgres packages installed came from the original Mandrake 9.2 CD.
After a little search plpgsql.so
Andrew Dunstan [EMAIL PROTECTED] writes:
I had a thought that might short-circuit this - do we even need pg_dump to
use dollar quoting for non-text output, such as is required by pg_restore?
That's a possibility, but I'd rather work around it by finding a way for
pg_restore not to need to parse
Kenneth Marshall [EMAIL PROTECTED] writes:
Would it be possible to use a latch + version number in
this case to minimize this problem by allowing all but the checkpoint to
perform a read-only action on the latch?
How would a read-only action work to block out the checkpoint?
More generally,
Kenneth Marshall [EMAIL PROTECTED] writes:
On Thu, Aug 12, 2004 at 09:58:56AM -0400, Tom Lane wrote:
How would a read-only action work to block out the checkpoint?
The latch+version number is use by the checkpoint process. The
other processes can do a read of the latch to determine if it has
Dear Hans,
Robert,
Are you planning to use Intel's C compiler in production?
We tried that some time ago and corrupted our database cluster almost
instantly (for some reason we have not investigated any further).
I highly recommend to do some stress testing to see if everything works
OK, I added this TODO:
* Allow finer control over the caching of prepared query plans
Currently, queries prepared via the libpq API are planned on first
execute using the supplied parameters --- allow SQL PREPARE to do the
same. Also, allow control over replanning prepared queries
At 11:42 PM 12/08/2004, Tom Lane wrote:
That's a possibility, but I'd rather work around it by finding a way for
pg_restore not to need to parse the dollar-quoted literal in the first
place.
Two possibilities:
1) Parse the tags (I have the code working): it's not that hard, the only
trick bit
OK, everything for pg_dump TODO I can think of:
pg_dump/pg_dumpall/pg_restore
* Add dumping of comments on composite type columns
* Add dumping of comments on index columns
* Replace crude DELETE FROM way of dumping cleaning of users and groups
with separate DROP commands
* Add dumping and
I think we should add another column to this table:
http://developer.postgresql.org/docs/postgres/errcodes-appendix.html
And explicitly list out all the exception names.
I think that would be clearer and easier than having a paragraph they
need to read that says 'just use underscores'...
Also, I
And I forgot to add:
* Allow dumping/restoring of any number of specific objects and types
Chris
Christopher Kings-Lynne wrote:
OK, everything for pg_dump TODO I can think of:
pg_dump/pg_dumpall/pg_restore
* Add dumping of comments on composite type columns
* Add dumping of comments on index
On Tuesday 10 August 2004 22:13, Christopher Kings-Lynne wrote:
What I mean here is that I think it would be in our best interests to
define the syntax for any new operation to be as easily guessed as
possible. I believe that ALTER INDEX would be more easily guessed by
more people as the
Added to TODO:
o Add ALTER INDEX that works just like ALTER TABLE already does
on an index
---
Robert Treat wrote:
On Tuesday 10 August 2004 22:13, Christopher Kings-Lynne wrote:
What I mean here is
Do you want any of these added to the TODO?
---
Christopher Kings-Lynne wrote:
And I forgot to add:
* Allow dumping/restoring of any number of specific objects and types
Chris
Christopher Kings-Lynne wrote:
Yep, a whole section for pg_dump features and bugs would be nice.
Bruce Momjian wrote:
Do you want any of these added to the TODO?
---
Christopher Kings-Lynne wrote:
And I forgot to add:
* Allow dumping/restoring of any number
Christopher Kings-Lynne wrote:
OK, everything for pg_dump TODO I can think of:
[snip]
* Export to other database (eg. Oracle, MySQL and DB2) formats
This strikes me as a can of worms, or to mix metaphors a bit, a rathole
from which we might never emerge.
I did have a thought the other day -
Did we resolve this?
---
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Maybe we could avoid removing it until the next checkpoint? Or is that
not enough. Maybe it could stay there forever :/
Where are we on this?
---
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Yeah, those are all bug fixes and okay for post-beta I think. But which
two tablespace failures are you thinking of exactly?
That should make exporting to other DBs a lot easier. Of course, that
could be cutting our own throat too ...
It won't make any difference to anything. You can already dump in
INSERT format.
Being able to export to other dbs will get us _more_ users, not less.
Chris
The other tablespace problem is if you drop a tablespace that schema in
another db uses, it's broken still I think.
Chris
Bruce Momjian wrote:
Where are we on this?
---
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL
Bruce Momjian [EMAIL PROTECTED] writes:
Did we resolve this?
No, it's an open issue.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
That should make exporting to other DBs a lot easier. Of course, that
could be cutting our own throat too ...
It won't make any difference to anything. You can already dump in
INSERT format.
And anyway, the DDL peculiarities would be the
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
That should make exporting to other DBs a lot easier. Of course, that
could be cutting our own throat too ...
It won't make any difference to anything. You can already dump in
INSERT format.
And anyway, the DDL
On Fri, 13 Aug 2004, Bruce Momjian wrote:
Where are we on this?
---
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Yeah, those are all bug fixes and okay for post-beta I think. But which
two
hackers,
here's another bunch of message strings translated into sk_SK.
Cheers
Zoltan
pg_dump-sk.po.bz2
Description: BZip2 compressed data
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
31 matches
Mail list logo
