Tom Lane wrote:
> I doubt it. People can always just read the file to see what
> settings are in it, and it's not like nonexperts are going to have a
> variety of different configurations that we're gonna have to ask them
> about. (Even in the Unix world, pg_config is not really needed when
> most
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 ex
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 numbe
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 ]
> -BEGI
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 betwee
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
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
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 no
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 sup
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| http:
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
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
-
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
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
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
"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'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 archive
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, it'
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 TA
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
"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
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.
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 tel
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 and if you specify a target, the default
> target_in_timeline is .
I think actually the default target has to be the timeline ID found in
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 of
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
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 archiv
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
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
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
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 recover
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
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 Solutio
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 ?
Regards
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
--
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
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
publi
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
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 art
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 recommen
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 datet
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
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
templat
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 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 th
45 matches
Mail list logo
