On Mon, 2004-07-19 at 04:31, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The way you write this makes me think you might mean you would allow: we
can start recovering in one timelines, then rollforward takes us through
all the timeline nexus points required to get us to the target
Sounds like a job for ... template0 !
Seriously, this thread would be more convincing if anyone in it betrayed
any knowledge that pg_dump wants you to start from template0 rather than
template1.
What if we made it so that template1 is always restored last? Won't
that be an improvement?
Chris
On Sun, 2004-07-18 at 23:55, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
I think what we want is a clean template without all of the extras that
template1 has.
Sounds like a job for ... template0 !
It doesn't quite work in my case as I've removed items included in
template0
On Mon, 19 Jul 2004, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
I am seeing a compile failure in current CVS from strptime():
./backend/access/transam/xlog.c:if (strptime(tok2, %Y-%m-%d %H:%M:%S, tm) ==
NULL)
BSD/OS does not have that
Bruce Momjian [EMAIL PROTECTED] writes:
I am seeing a compile failure in current CVS from strptime():
Should be fixed now. I wasn't very happy with strptime() there in
the first place, since it is inflexible about input format and
doesn't support a timezone specification. Using our own
Andrew Dunstan [EMAIL PROTECTED] writes:
How can I get a TupleDesc for the return type of a non-SR function that
returns a tuple? I'm sure it's there somewhere but I just can't see it.
What do you have available to identify the type?
If you know the type OID, then (in CVS tip) I'd recommend
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I think that we should treat the public schema specially :)
We already are to some extent, since pg_dump will dump its comment and
privileges, which it would not do for any other predefined object.
I think this is actually an implementation
Simon Riggs [EMAIL PROTECTED] writes:
Some further thinking from that base...
Perhaps timelines should be nest-numbered: (using 0 as a counter also)
0 etc is the original branch
0.1 is the first recovery off the original branch
0.2 is the second recovery off the original branch
0.1.1 is the
Rod,
I think what we want is a clean template without all of the extras that
template1 has.
We have this, it's called Template0.
Actually, KL, that would solve a lot of these duplicate object problems. What
if pg_restore used Template0 and not Template1?It wouldn't fix the drop
public
On Mon, 2004-07-19 at 12:36, Josh Berkus wrote:
Rod,
I think what we want is a clean template without all of the extras that
template1 has.
We have this, it's called Template0.
Doesn't work for me. I remove a number of things that are included by
default in template0, but yes, it's
Rod Taylor [EMAIL PROTECTED] writes:
Remove the public schema from template0, but leave it in template1.
Does not sound very workable. One of the functions of template0 is to
be a backup for the virgin state of template1, and you'd lose that.
regards, tom lane
Hi all,
I'm trying the savepoint-5.patch
Using the psql the TAB autocomplete doesn't work for savepoint and for release
commands,
also the ROLLBACK doesn't know yet the ROLLBACK TO sintax.
Attached the patch that solve these issues.
BTW, there is a way to know which savepoint are active ?
Rod,
Remove the public schema from template0, but leave it in template1. Have
pg_dump treat the public schema the same as all of the other ones.
Hmmm. No good; it wipes out the primary purpose of Template0, which is to
restore a corrupted Template1.
--
-Josh Berkus
Aglio Database
On Mon, 2004-07-19 at 13:30, Josh Berkus wrote:
Rod,
Remove the public schema from template0, but leave it in template1. Have
pg_dump treat the public schema the same as all of the other ones.
Hmmm. No good; it wipes out the primary purpose of Template0, which is to
restore a
I wrote:
I think there's really no way around the issue: somehow we've got to
keep some meta-history outside the $PGDATA area, if we want to do this
in a clean fashion.
After further thought I think we can fix this stuff by creating a
history file for each timeline. This will make recovery
On Mon, 2004-07-19 at 16:58, Tom Lane wrote:
I think there's really no way around the issue: somehow we've got to
keep some meta-history outside the $PGDATA area, if we want to do this
in a clean fashion. We could perhaps expect the archive area to store
it, but I'm a bit worried about the
On Mon, 2004-07-19 at 19:33, Tom Lane wrote:
I wrote:
I think there's really no way around the issue: somehow we've got to
keep some meta-history outside the $PGDATA area, if we want to do this
in a clean fashion.
After further thought I think we can fix this stuff by creating a
history
Simon Riggs [EMAIL PROTECTED] writes:
The crucial time is when re-running recoveries repeatedly and if we
write the manual with sufficient red ink then we'll avoid this. But
heck, not having your history file is only as bad as not having added
timelines in the first place. Not great, just more
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2004-07-19 at 19:33, Tom Lane wrote:
When doing WAL archiving a history file can be copied
off to the archive area by the existing archiver mechanism (ie, we'll
make a .ready file for it as soon as it's written).
Need to check the archive code
On Sat, 2004-07-17 at 00:57, Bruce Momjian wrote:
OK, I think I have some solid ideas and reasons for them.
Sorry for taking so long to reply...
First, I think we need server-side functions to call when we start/stop
the backup. The advantage of these server-side functions is that they
I've been having a problem with the pgstat.c localhost change since 7.4,
in that statistics gathering stopped working on my gentoo boxes. I've
not traced it back beyond getaddrinfo called in getaddrinfo_all, and
decided the quick fix was to go back and change pgstat to use 127.0.0.1
instead
Simon Riggs [EMAIL PROTECTED] writes:
I think we're heatedly agreeing again.
Yeah, I think so. I'll get started on this tomorrow.
where the default is notarget and if you specify a target, the default
target_in_timeline is latest.
I think actually the default target has to be the timeline
On Mon, 2004-07-19 at 23:15, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2004-07-19 at 19:33, Tom Lane wrote:
* When we need to do recovery, we first identify the source timeline
(either by reading the current timeline ID from pg_control, or the DBA
can tell us with a
Bruce and I had another phone chat about the problems that can ensue
if you restore a tar backup that contains old (incompletely filled)
versions of WAL segment files. While the current code will ignore them
during the recovery-from-archive run, leaving them laying around seems
awfully dangerous.
Gavin M. Roy [EMAIL PROTECTED] writes:
I've been having a problem with the pgstat.c localhost change since 7.4,
in that statistics gathering stopped working on my gentoo boxes. I've
not traced it back beyond getaddrinfo called in getaddrinfo_all, and
decided the quick fix was to go back
I have no problem resolving localhost anywhere else on the box, do you
have any suggestions on finding out if it's a misconfiguration?
Gavin
Tom Lane wrote:
Gavin M. Roy [EMAIL PROTECTED] writes:
I've been having a problem with the pgstat.c localhost change since 7.4,
in that statistics
I have been doing some re-testing with CVS HEAD from about 1 hour ago
using the simplified example posted previously.
It is quite interesting:
i) create the table as:
CREATE TABLE test0 (filler TEXT);
and COPY 100 000 rows on length 109, then recovery succeeds.
ii) create the table as:
CREATE
We already are to some extent, since pg_dump will dump its comment and
privileges, which it would not do for any other predefined object.
I think this is actually an implementation artifact rather than
something that was explicitly intended at the time, but since no one
has complained about it,
I've got a PITR set up here that's happily scp'ing WAL files across to
another machine. However, the NIC in the machine is currently stuffed,
so it gets like 50k/s :) What happens in general if you are generating
WAL file bytes faster always than they can be copied off?
Also, does the
Gavin M. Roy [EMAIL PROTECTED] writes:
I have no problem resolving localhost anywhere else on the box, do you
have any suggestions on finding out if it's a misconfiguration?
In that case maybe we have a bug to fix; but that makes me even less
eager to solve it by substituting 127.0.0.1 ...
I know it's not critical, but is it worth rewriting pg_config in C so it
works on Windows (or alternatively writing it as a .bat file for Windows)?
cheers
andrew
---(end of broadcast)---
TIP 8: explain analyze is your friend
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I've got a PITR set up here that's happily scp'ing WAL files across to
another machine. However, the NIC in the machine is currently stuffed,
so it gets like 50k/s :) What happens in general if you are generating
WAL file bytes faster
Actually, KL, that would solve a lot of these duplicate object problems. What
if pg_restore used Template0 and not Template1?It wouldn't fix the drop
public schema issue but it would solve the others.
Not sure what you mean here, but CVS pg_dump dumps like this:
CREATE DATABASE phppgadmin
If you keep falling further and further behind, eventually your pg_xlog
directory will fill the space available on its disk, and I think at that
point PG will panic and shut down because it can't create any more xlog
segments.
Hang on, are you supposed to MOVE or COPY away WAL segments?
Chris
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
If you keep falling further and further behind, eventually your pg_xlog
directory will fill the space available on its disk, and I think at that
point PG will panic and shut down because it can't create any more xlog
segments.
Hang on, are
Andrew Dunstan wrote:
I know it's not critical, but is it worth rewriting pg_config in C so it
works on Windows (or alternatively writing it as a .bat file for Windows)?
Oh, pg_config is a shell script. Yes, it should be rewritten in C.
--
Bruce Momjian|
Christopher Kings-Lynne wrote:
If you keep falling further and further behind, eventually your pg_xlog
directory will fill the space available on its disk, and I think at that
point PG will panic and shut down because it can't create any more xlog
segments.
Hang on, are you supposed to
Andrew Dunstan [EMAIL PROTECTED] writes:
I know it's not critical, but is it worth rewriting pg_config in C so it
works on Windows (or alternatively writing it as a .bat file for Windows)?
I doubt it. People can always just read the file to see what settings
are in it, and it's not like
Hang on, are you supposed to MOVE or COPY away WAL segments?
COPY. The checkpoint code will then delete or recycle the segment file,
as appropriate.
So what happens if you just move it? Postgres breaks?
Chris
---(end of broadcast)---
TIP 8: explain
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Hang on, are you supposed to MOVE or COPY away WAL segments?
COPY. The checkpoint code will then delete or recycle the segment file,
as appropriate.
So what happens if you just move it? Postgres breaks?
I don't think so, but it seems like
I don't think so, but it seems like a much less robust way to do things.
What happens if you have a failure partway through? For instance
archive machine dies and loses recent data right after you've rm'd the
source file. The recommended COPY procedure at least provides some
breathing room
Looks like someone else also just submitted the same patch, except with
a -T option to exclude tables. I will consider that version instead.
---
Andreas Joseph Krogh wrote:
[ PGP not available, raw data follows ]
Mark Kirkwood [EMAIL PROTECTED] writes:
I have been doing some re-testing with CVS HEAD from about 1 hour ago
using the simplified example posted previously.
It is quite interesting:
The problem seems to be that the computation of checkPoint.redo at
xlog.c lines 4162-4169 (all line numbers
On Mon, 2004-07-19 at 21:20, Christopher Kings-Lynne wrote:
We already are to some extent, since pg_dump will dump its comment and
privileges, which it would not do for any other predefined object.
I think this is actually an implementation artifact rather than
something that was
44 matches
Mail list logo
