need be. Maybe Szucs hasn't found one this time, but there is
a possibility and many people don't have a long time to decide with a
production system looking unstable.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3: if posting/r
ost
at the same time.
...but you shouldn't use locking as a queuing mechanism.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Mon, 2005-05-09 at 15:18 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2005-05-09 at 12:21 -0500, Kris Kiger wrote:
> >> Quick question. I lock a table, call it table X, and then issue two
> >> updates on that table. The two
This is the same error that was also reported on GENERAL recently on
8.0.1.
I'm suspicious of a more subtle intermittent error. We have no
information about what the magic values are, only that they are not
correct. Should we increase the information returned for that error?
That might show
On Thu, 2005-06-16 at 08:25 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I'm suspicious of a more subtle intermittent error.
>
> Yeah, I am too, but so far none of the reporters have been cooperative
> about providing more information :-(
>
ing it. Is this by design?
That was the bit I didn't. Fix partially implemented and I am to submit
for 8.1, godspeed my typing fingers. There's a simple workaround if you
have a low transaction rate system: load up enough data to trip into the
next xlog.
Best Reg
a little strange?
pg 7.4.6
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Tue, 2005-07-26 at 23:22 +0100, Simon Riggs wrote:
> If I have a system that writes out one WAL file every 5 minutes, and I
> have these settings:
>
> checkpoint_timeout = 3329
> checkpoint_segments = 1000
> (parameters checked as valid via pg_settings)
>
> How many WA
_xlog. This is where the archiver
checks to see for notifications of filled WAL files, then clears the
notification afterwards. Only filled WAL filenames are shown.
Don't touch the files or you might interfere with the archiver's
activities.
Best Regards, Simon Riggs
-
On Fri, 2005-09-30 at 09:29 -0700, Jeff Frost wrote:
> On Fri, 30 Sep 2005, Simon Riggs wrote:
>
> > You don't say why you need to know?
>
> Not sure why Kris needs to know, but I need to know for PITR and keeping the
> latest WAL file saved by a script which runs ever
On Sat, 2005-10-01 at 21:43 -0700, Jeff Frost wrote:
> On Fri, 30 Sep 2005, Simon Riggs wrote:
>
> > If I follow your example, yes. But that assumes there is only one
> > timeline's WAL files in your pg_xlog. It could get more complex in that
> > situation becau
the last year.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
or
and at what thresholds, which is dependant on the system, its
availability goals, security intolerance etc - most of which is a
business issue not a technical one.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Mon, 2005-10-03 at 20:00 -0700, Jeff Frost wrote:
> On Sun, 2 Oct 2005, Simon Riggs wrote:
>
> > Probably the best idea is to backup the last WAL file for each timeline
> > seen. Keep track of that, so when the current file changes you'll know
> > which timelin
n used on both servers to refer to separate transactions, so
there can be no automated way of resolving the data. It has to be done
using business domain knowledge rather than log data.
All of that's no different from any other RDBMS, as I'm sure you know.
Best Regards, Simon Riggs
partitions.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
it doesn't provide the other pieces of the puzzle.
It doesn't do replication itself, so there's no performance aspect to
it, AFAIK.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore yo
gt;
> Now, that looks like a nice plan (I guess).
>
> My question: Are my partitions constructed in such a way that prevents
> the planner from picking better plans? Or is that
> the way things stand right now?
No and No. Partitions can use indexes, but the
ine, then *while postmaster is
shutdown* copy the entire data directory across to the smaller machine.
>From there you can edit the postgresql.conf and startup.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Have you searche
he backup files don't be deleted ?
> >
> > thanks a lot in advance ...
> >
Take a look in the PGDATA/pg_xlog/archive_status directory.
If the files all say ".ready" then your archive_command is not working
correctly for some reason.
Try running it manually to copy one of the files away.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
se up to
> the last archived WAL file if the db server fails?
No.
pg_dump only copies the data, not the current state of the database.
> If so, how? Is it just a matter of restoring the database then copying
> the archived WAL files into the xlog dir and creating a recovery.conf
> f
On Fri, 2005-12-23 at 10:09 +1300, Mike C wrote:
> On 12/22/05, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-12-13 at 11:18 +1300, Mike C wrote:
> > All the documentation I've seen for PITR points to having to
> do a file
>
should be looking at backup designs that do not require you to dump
the complete database each time. That way your backup and recovery times
increase linearly.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
thing unlike PITR where you can choose any point in time to
> recover to.
Why not use SAN Snapshots *and* PITR? They play nicely.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
ony.
pgcluster implements something similar to Oracle RAC, but I have not
seen a production installation of this, though this may exist in Japan?
pgpool can be used to load balance across multiple servers, if that was
your requirement for RAC.
Best Regards, Simon Riggs
---
probably
overall a smaller system and one less prone to bugs in the data update
processes.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
On Sun, 2006-02-12 at 11:47 +0100, [EMAIL PROTECTED] wrote:
> How Can I do that ?
This is on my todo list for 8.2, but not yet at the top.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ign
tion.
There should be no recovery_target* settings.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
On Thu, 2006-02-23 at 16:18 +, Andy Shellam wrote:
> Cheers for the idea Simon, now to get coding...!
S'OK ... it was designed that way from the start.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3: Have you che
he documented caveats there are no design
limitations...but I would restart from a base backup weekly, to be sure.
It's all about certainty after all.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 6: explain analyze is your friend
useful than manual failover, so is
not quite the magic bullet it may appear.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
t a month ago on -general but without much response.
> When I connect to postgres from PHP or Python or using just psql, I can
> see full SELECT querries logged, with the actuall values for the
> parameters.
Those interfaces do not use prepared statements, so are not logged in
the same way.
B
On Fri, 2006-03-03 at 12:03 -0600, Thomas F. O'Connell wrote:
> On Mar 3, 2006, at 11:54 AM, Simon Riggs wrote:
>
> > On Thu, 2006-03-02 at 16:38 -0600, Thomas F. O'Connell wrote:
> >> Ideally, I'd be able to take a base backup of a production system,
>
progress with interest.
The reason you've got excellent support is because of the detailed
postings you've made, together with responses to all replies. Doing all
your homework before posting is essential; unfortunately many people
don't do this and then leave disappointe
On Tue, 2006-03-14 at 16:41 -0600, Thomas F. O'Connell wrote:
> On Mar 4, 2006, at 3:56 AM, Simon Riggs wrote:
>
> > On Fri, 2006-03-03 at 12:03 -0600, Thomas F. O'Connell wrote:
> >> On Mar 3, 2006, at 11:54 AM, Simon Riggs wrote:
> >>
> >>> On
ed up again.
This will be slower, but has less risk if you are unsure of the process.
I'd suggest you follow your own procedure on a test box without step
(4), so you can check you've done it right before you stop oldhost for
good. Once you are happy with that, go for it in live.
Be
the whole database in one go.
You can copy only changed data out of the tables using your knowledge of
the mail store. That way you'll not need to have such a long running
backup and it won't be so large either. You can then reassemble the
pieces later into a new table in case of recov
ent on the appropriate page of the annotated docs?
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
in to make the retry period elongate, but you'd
need to put a reasonable case for how that would increase robustness.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 9: In versions below 8.0, t
On Mon, 2006-05-15 at 14:29 -0700, Jeff Frost wrote:
> On Mon, 15 May 2006, Simon Riggs wrote:
>
> > On Mon, 2006-05-15 at 09:28 -0700, Jeff Frost wrote:
> >> I've run into a problem with a PITR setup at a client. The problem is that
> >> whenever the CIFS NAS
5 02:06:05 db3 crond(pam_unix)[14517]: session closed for user postgres
> May 15 02:06:24 db3 postgres[14582]: [1-1] LOG: autovacuum: processing
> database "template1"
> May 15 02:06:43 db3 postgres[22009]: [4913-1] LOG: archived transaction log
> file "00010016009
On Wed, 2006-05-17 at 00:36 -0400, Tom Lane wrote:
> Jeff Frost <[EMAIL PROTECTED]> writes:
> > On Tue, 16 May 2006, Simon Riggs wrote:
> >> Whatever happened between 02:08 and 02:14 seems important.
>
> > I have the logs and after reviewing /var/log/messages fo
On Wed, 2006-05-17 at 10:01 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > You'll have to explain a little more. I checked the archives...
>
> I was thinking of
> http://archives.postgresql.org/pgsql-hackers/2004-01/msg00530.php
&g
Seems bad.
Seems so.
Can you post the full test, plus full execution log.
[You don't need to "cat" you could just do "ls" instead FWIW]
Are you doing *anything* with pg_xlog directory or below? I understand
your saying No to that question
0001007F.done already
exists?
Are there two postmasters running (at all)?
Is there somehow an archiver process running from a previously shutdown
postmaster (somehow)?
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadca
actually, nevermind: we have explained the failures you were seeing
> in the test setup, but a multiple-active-archiver situation still
> doesn't explain the original situation of incoming connections getting
> blocked.
Agreed.
--
Simon Riggs
EnterpriseDB http://w
l individually
> and
> started postmaster again).
Thats good.
> Now I can run my same pg_bench, or do you guys
> have any other suggestions on attempting to reproduce the problem?
No. We're back on track to try to reproduce the original error.
On Sun, 2006-05-21 at 14:16 -0700, Jeff Frost wrote:
> On Fri, 19 May 2006, Simon Riggs wrote:
>
> >> Now I can run my same pg_bench, or do you guys
> >> have any other suggestions on attempting to reproduce the problem?
> >
> > No. We're back on tra
tgres: archiver process
> postgres 20573 1 0 May17 ?00:00:00 postgres: archiver process
> postgres 23817 23810 0 May17 pts/11 00:00:00 postgres: archiver process
>
> 23810 is the running postmaster:
>
> postgres 23810 1 0 May17 pts/11 00:03:01
> /usr/loc
On Fri, 2006-05-19 at 08:23 -0700, Jeff Frost wrote:
> On Fri, 19 May 2006, Simon Riggs wrote:
>
> > On Thu, 2006-05-18 at 10:08 -0700, Jeff Frost wrote:
> >
> >> May 18 08:00:18 discord postgres[20228]: [129-1] LOG: archived
> >> transaction log file "
If you quit psql, then the server may not realise you have disconnected.
You need to issue a cancel, so that can be communicated to the server so
it knows to quit.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)
s the approved way and quicker than re-creating the indexes.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe
and
> remove all previous un-needed WAL files from the archive.
Is this any help?
http://archives.postgresql.org/pgsql-patches/2006-05/msg00229.php
If so, I'll see about updating it so it can get backpatched to 8.0 and
8.1 also.
--
Simon Riggs
EnterpriseDB http:
ss-datatype comparisons in CHECK
constraints.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
ves.postgresql.org/pgsql-committers/2006-06/msg00305.php
I notice it isn't mentioned in the 8.1.5 release notes. You should
upgrade.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
On Fri, 2006-12-01 at 15:15 +0530, Rajesh Kumar Mallah wrote:
> I think the gap is genuine.
I think you need to take a look at the EnterpriseDB Debugger.
It solves the problem, so I suggest you take a look.
Open Source versions are available, AFAIK.
--
Simon Ri
wn.
The idea that you'd need a checking tool comes from not trusting your
database. The PostgreSQL way is to ensure you don't lose that trust
because there are no short-cuts and leaps of faith taken to make the
database go faster.
--
Simon Riggs
Enterp
(bid) REFERENCES branches(bid)
"accounts_bid_fkey2" FOREIGN KEY (bid) REFERENCES branches(bid)
"accounts_bid_fkey3" FOREIGN KEY (bid) REFERENCES branches(bid)
"accounts_bid_fkey4" FOREIGN KEY (bid) REFERENCES branches(bid)
--
Simon Riggs
upport "incremental"
backup, i.e. only what has changed since last backup, nor will it when
PITR is implemented...thats something different again]
Best Regards, Simon Riggs, 2ndQuadrant
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
LOG, "backend: written %s", rlogpath );
+
+ elog(LOG, "postmaster: WAKEN_ARCHIVER received, sending SIGUSR1 to
archiver");
+ elog(LOG, "chkpt: archiving done for log file %s",
+ xlog);
+
On Wed, 2004-06-30 at 15:58, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
Thanks very much for your comments.
> > Simon Riggs wrote:
> >> + elog(WARNING, "could not set notify for archiver to read log file
> >> %u, segment %u",
>
&
nting or I've missed
> > > something or are there workarounds?
This might be something you could do...
Best regards, Simon Riggs
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
), so please have a look at
[PATCHES] and try it out.
Many thanks,
Simon Riggs
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
a test document with numbered tests...
Best regards, Simon Riggs
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Wed, 2004-07-14 at 16:55, [EMAIL PROTECTED] wrote:
> On 14 Jul, Simon Riggs wrote:
> > PITR Patch v5_1 just posted has Point in Time Recovery working
> >
> > Still some rough edgesbut we really need some testers now to give
> > this a try and let me know wha
>rd_istemp;
>
>
Yes, I discovered that myself.
The fix is included in pitr_v5_2.patch...
Your patch follows the right thinking and looks like it would have
worked...
- XLogArchiveMode carries the main bool value for mode on/off
- XLogArchiveDest might also be used, though best
ossible.
>
Not read whole chain of conversation...but this idea came up before and
was rejected then. I agree with the 3 objections to that thought above.
There's already enough copies of full xlogs around to worry about.
If you need more granularity, reduce size of xlog files
(T
ces recovery whether it was or not. On that basis, this may work, but
is yet untested. I didn't mention this because it might interfere with
getting hot backup to work...
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Fri, 2004-07-23 at 01:05, Mark Kirkwood wrote:
> I have tested the "cold" backup - and retested my previous scenarios
> using "hot" backup (just to be sure) . They all work AFAICS!
> cheers
Yes, I'll drink to that! Thanks for you
ave the
> normal running load of PG.
>
Check the PostgreSQL manual pages entitled "Monitoring Database
Activity". In light of the above comments, you will find this useful,
but not the answer to your problems.
Best Regards, Simon Riggs
---(end of broadca
ut maintenance.
For most applications, you should be running VACUUM FULL at least monthly,
since any more than that is effectively the same thing as "never", as your
case shows.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 2:
is exactly what PITR does in v8.0,
now in beta.
Best Regards,
Simon Riggs
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Bruce Momjian
> Sent: 05 October 2004 02:59
> To: Dan Hrabarchuk
> Cc: [EMAIL PROTECTED]
> Subject: Re: [ADM
what it does - just wanted to check that people really used it.
I always felt I did that as a precaution rather than for good reason.
OK - 8.1 it is then,
Best Regards
Simon Riggs
---(end of broadcast)---
TIP 8: explain analyze is your friend
eporting this as a bug for 8.0? It's not on the bug list...
Do we consider that to be desirable or not?
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
ver returns from...so it just hangs.
[Just so we're all clear: we're talking about Gaetano's script, not the
PostgreSQL archver. The postgresql archiver doesn't do it that way, so
it never misses one.]
--
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
XPLAIN ANALYZE will show you whether this is the case. It seems likely
that the estimated cardinality of certain joins is incorrect.
--
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an inde
cess problem" is one big reason PostgreSQL is well supported, and
will continue to be so. Microsoft are responding by making SQL Server
2005 free for use on one CPU... as if that helps.
--
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
s are important in knowing what might be causing your
problem.
There is much good advice available already and the manuals are good
too...
--
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
take a
long time to fill?
Please give a blow-by-blow time/event description, so we can understand
what the issue is and where the window of exposure is that you can see.
Best regards, Simon Riggs
---(end of broadcast)---
TIP 6: Have you s
tter still, try it and see for yourself. About 3 times, so you're
certain you understand how it works before you begin using it and
relying on it.
The xlog filenames are prefixed by the timelineId, which prevents the
server from becoming confused about the files.
Best regards,
sets this value independently for sets
of users (is there?)
I'm also having similar problems with log_min_statement_duration not
working at all.
Any ideas? Thanks,
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 5: Have you checke
> From: Tom Lane
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On top of a confusing day, I now have this:
> > I set log_duration = true in a postgresql.conf file.
> > I startup and test, local users connected via psql:
> working, no problem.
>
>Simon Riggs
> > From: Tom Lane
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > > On top of a confusing day, I now have this:
> > > I set log_duration = true in a postgresql.conf file.
> > > I startup and test, local users connected
>Tom Lane
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Further update on this:
>
> > We've isolated this issue to JDBC client access.
>
> Ah-hah, now it makes sense. I believe the JDBC driver always uses
> extended query protocol (parse/bind/e
s, so in those cases the timing error
becomes noticeable. You're not the first to observe this, though only by
about a month.
I'm considering options for the next release, since major change seems
to be required to the basic xlog handling mechanisms.
Best Regards, Simon Riggs
On Thu, 2005-03-31 at 23:46 -0500, Jason DiCioccio wrote:
> Simon,
>
> On Mar 31, 2005 7:29 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> >
> > In retrospect, there is a slight timing error between end backup and
> > archival of next WAL log. The first-rel
On Fri, 2005-04-01 at 01:29 +0100, Simon Riggs wrote:
> I'm considering options for the next release, since major change seems
> to be required to the basic xlog handling mechanisms.
Hmmm. I've thought about what to do here, I'll detail a proposal on
HACKERS over next few
On Sat, 2005-04-09 at 19:29 -0300, [EMAIL PROTECTED] wrote:
> Please,
> how do I identify a id timeline on a transaction log file?
>
> Thanks.
First 8 characters of the filename show the timeline id in hex.
Best Regards, Simon Riggs
---(end
e following select statement,
>
> select pg_class.oid, pg_trigger.tgrelid from pg_trigger left join pg_class
> on pg_trigger.tgrelid=pg_class.oid;
>From the error message it appears you have a data type called "trigger",
which appears to be invalidated.
--
Simon Riggs
ried to supply a wrong login password, and the login failure was
> successfully logged). Has anyone experienced similar issue?
Yes, its not very easy to determine if it is working, and if it is, what
it has done.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---
On Fri, 2007-01-05 at 12:59 -0600, Ben K. wrote:
> 2. sql dump and PITR
>
> Is it possible to use the PITR method with SQL dump? (pg_start_backup ->
> sql dump -> pg_stop_backup) I guess not, but just want to make sure.
>
No, because there is no reason or benefi
t. So there's nothing to
stop you doing a recovery on a development machine up to a certain
point, then dumping the deleted data using pg_dump and re-loading it
into the live server. Then erasing the dev recovered database.
--
Simon Riggs
EnterpriseDB http://www.enterpri
On Tue, 2007-01-09 at 08:37 -0600, Ben K. wrote:
> On Mon, 8 Jan 2007, Simon Riggs wrote:
>
> > There is a log analysis tool on pgfoundry that does something similar.
>
> > You can already stop recovery at a certain point. So there's nothing to
> > stop you d
the cluster on a second server to your specific point in
> time, and restore that copy of the database in question to your primary
> server.
I'll take that as a request for a TODO item, for 8.4
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---
very well at all, since many records depend upon
previous data changes, so could quickly end in further errors.
What would you suggest?
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
s/8.2/static/warm-standby.html
If you want to do (a) or (b) you've mistakenly read both parts of the
manual and if you want to do (c) then you need two servers, not just
one.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
--
the point-in-time it has
stopped at sounds blindingly obvious in retrospect.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
t; of WAL. But in this case it looks more like corrupt data ...
Tom,
I think there is a problem here. If we stop before the end of logs we
should be incrementing the timeline id.
I'm not going to think about it right now, but I'll think on that next
week. Not the most likely
On Fri, 2007-03-30 at 12:40 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > I think there is a problem here. If we stop before the end of logs we
> > should be incrementing the timeline id.
>
> There is no good reason here to think tha
h 8.2 also, though isn't available
as part of the 8.2 distribution. The README will contain information for
both 8.2 and 8.3 releases, since there will be one minor difference.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of bro
1 - 100 of 225 matches
Mail list logo
