On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao masao.fu...@gmail.com wrote:
Yeah, even if primary_conninfo is not given, the standby tries to invoke
walreceiver by using the another connection settings (environment variables
or defaults). This is intentional behavior, and would make the setup of
We want to teach people that Hot Standby and Streaming Replication are
two different features. However, Streaming Replication calls its main
parameter standby_mode which reminds more of Hot Standby than of
Streaming Replication.
People could also run a warm standby without streaming replication,
On Wed, Feb 10, 2010 at 12:16 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If they want to implement the warm standby using the (new) built-in
logic to keep retrying restore_command, they would set
standby_mode='on'. standby_mode='on' doesn't imply streaming replication.
On Mon, Feb 8, 2010 at 6:07 PM, David E. Wheeler da...@kineticode.com wrote:
On Feb 8, 2010, at 5:15 AM, Magnus Hagander wrote:
The text is about 180Kb. PostgreSQL takes ~40 seconds without the
patch, ~36 seconds with it, to extract the match from it. Perl takes
0.016 seconds.
Obviously we
On Wed, Feb 3, 2010 at 2:05 AM, Jeff Davis pg...@j-davis.com wrote:
Thanks, very well spotted... Actually the same is true for LISTEN... I
have reworked the patch to do the changes to listenChannels only in
the post-commit functions.
I'm worried that this creates the opposite problem: that a
On Thu, Jan 21, 2010 at 3:06 AM, Jeff Davis pg...@j-davis.com wrote:
Here's the problem as I see it:
You are writing a lot of true facts but I miss to find a real
problem... What exactly do you see as a problem?
The only time you are writing problem is in this paragraph:
However, there's
On Wed, Jan 20, 2010 at 1:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I guess Joachim is trying to provide a similar guarantee for the new
implementation, but I'm not clear on why it would require locking.
The new implementation is broadcast and ISTM it shouldn't require the
modifying
On Wed, Jan 20, 2010 at 5:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In that case I think you've way overcomplicated matters. Just deliver
the notification. We don't really care if the listener gets additional
notifications; the only really bad case would be if it failed to get an
event that
On Wed, Jan 20, 2010 at 11:08 PM, Jeff Davis pg...@j-davis.com wrote:
Yes. That is the case with the existing implementation as well, no?
We don't consider sending notifies until transaction end, so anything
that commits during the xact in which you UNLISTEN will get dropped.
Only if the
Hi Jeff,
thanks a lot for your review. I will reply to your review again in
detail but I'd like to answer your two main questions already now.
On Tue, Jan 19, 2010 at 8:08 AM, Jeff Davis pg...@j-davis.com wrote:
* AsyncCommitOrderLock
I believe this needs a re-think. What is the real purpose
The attached patch implements the idea of Heikki / Simon published in
http://archives.postgresql.org/pgsql-hackers/2009-11/msg00271.php
Since nobody objected to the idea in general, I have implemented it.
As this is not currently used anywhere it doesn't give immediate benefit, it
is however a
On Thu, Dec 31, 2009 at 6:40 PM, Simon Riggs si...@2ndquadrant.com wrote:
Building racy infrastructure when it can be avoided with a little care
still seems not to be the best path to me.
Doing that will add more complexity in an area that is hard to test
effectively. I think the risk of
On Thu, Jan 7, 2010 at 4:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
As there were so many boolean SomethingCancelPending variables I changed them
to be bitmasks and merged all of them into a single variable.
This seems like a truly horrid idea, because
On Thu, Jan 7, 2010 at 3:03 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote:
I have reworked Simon's patch a bit and attach the result.
Oh dear, this is exactly what I've been working on...
Sorry, as you have posted a first patch some days
On Thu, Jan 7, 2010 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
As far as I can think at the moment, the best you can do is throw the
elog(ERROR), and if control gets out to the error recovery block in
PostgresMain, you can force a transaction abort there. In other words,
pretty much the
On Fri, Jan 1, 2010 at 10:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
CancelRequest's behaviour currently equates to SIGINT, so
processCancelRequest() can only use SIGINT if SIGINT's behaviour remains
same.
I would recommend we make SIGINT do cancel-anything, and handle
everything else
On Fri, Jan 1, 2010 at 10:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
I would recommend we make SIGINT do cancel-anything, and handle
everything else via SIGUSR1, including CancelRequest. I'm not going to
do that; I'm going to make HS conflict resolution work, which means
putting in enough
On Thu, Dec 31, 2009 at 3:03 PM, Simon Riggs si...@2ndquadrant.com wrote:
This patch extends SIGINT to allow cancellation of transactions while
idle in both HS and normal mode. It also changes the standard message
reported on an idle transaction in aborted state to 'IDLE in
transaction
On Wed, Dec 30, 2009 at 12:28 AM, Simon Riggs si...@2ndquadrant.com wrote:
I had to write an additional function AbortAnyTransaction() which
aborts all transactions and subtransactions and leaves the transaction
in the aborted state, is there an existing function to do this?
On Tue, Dec 29, 2009 at 4:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This seems like a fairly bad idea. One of the intended use-cases is to
be able to manually kill -INT a misbehaving backend. Assuming that
there will be valid info about the signal in shared memory will break
that.
I never
On Sun, Dec 27, 2009 at 10:42 PM, Simon Riggs si...@2ndquadrant.com wrote:
Thanks for the report. I'll see about a fix.
In the end we are about to use SIGINT for two use cases:
- cancel an idle transaction
- cancel a running query
Previously a backend that was DoingCommandRead == true didn't
On Sun, Dec 6, 2009 at 4:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We are using NOTICE, not NOTIFY, assuming that we use anything at all
(which I still regard as unnecessary). Please stop injecting confusion
into the discussion.
Attached is a minimal POC patch that allows to cancel an idle
Hi Jeff,
the current patch suffers from what Heikki recently spotted: If one
backend is putting notifications in the queue and meanwhile another
backend executes LISTEN and commits, then this listening backend
committed earlier and is supposed to receive the notifications of the
notifying backend
On Fri, Nov 20, 2009 at 7:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Note that we don't preserve notifications when the database restarts.
But 2PC can cope with restarts. How would that fit together?
The notifications are written to the state file at prepare. They can
On Thu, Nov 19, 2009 at 4:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
There will now be a nonzero chance
of transactions failing at commit because of queue full. If the
chance is large this will be an issue. (Is it sane to wait for
the queue to be drained?)
Exactly. The whole idea of putting
On Thu, Nov 19, 2009 at 1:51 PM, Andreas 'ads' Scherbaum
adsm...@wars-nicht.de wrote:
And in addition i don't like the idea of having the sender sitting
around until there's room for more messages in the queue, because some
very old backends didn't remove the stuff from the same.
The only
On Thu, Nov 19, 2009 at 6:55 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, ignoring 2PC for a moment, I think the patch suffers from a little
race condition:
Session 1: BEGIN;
Session 1: INSERT INTO foo ..;
Session 1: NOTIFY 'foo';
Session 1: COMMIT -- commit begins
On Thu, Nov 19, 2009 at 1:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
4) Allow readers to read uncommitted notifications as well.
The question that strikes me here is one of timing --- apparently,
readers will now have to check the queue *without* having
On Sat, Nov 14, 2009 at 11:06 PM, Merlin Moncure mmonc...@gmail.com wrote:
The old method (measured on a 4 core high performance server) has
severe scaling issues due to table bloat (we knew that):
./pgbench -c 10 -t 1000 -n -b listen.sql -f notify.sql
run #1 tps = 1364.948079 (including
We still need to decide what to do with queue full situations in the proposed
listen/notify implementation. I have a new version of the patch to allow for a
variable payload size. However, the whole notification must fit into one page so
the payload needs to be less than 8K.
I have also added the
Unfortunately with all that payload-length discussion, the other part
of my email regarding ACID compliant behavior got completely lost. I
would appreciate some input on that part also...
Thanks,
Joachim
On Thu, Nov 12, 2009 at 12:17 PM, Joachim Wieland j...@mcknight.de wrote:
On Thu, Nov 12
On Thu, Nov 12, 2009 at 2:12 AM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Does it cope with the case where a trigger is doing NOTIFY, and you do
a whole-table update, therefore dumping potentially millions of
notifications in at once?
(for example a rare maintenance operation on a
On Thu, Nov 12, 2009 at 4:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
One possible solution would be to write to the queue before committing
and adding the TransactionID. Then other backends can check if our
TransactionID has successfully committed or not. Not sure if this is
worth the overhead
On Thu, Nov 12, 2009 at 3:30 PM, Merlin Moncure mmonc...@gmail.com wrote:
Couple of questions:
*) is BLCKSZ a hard requirement, that is, coming from the slru
implementation, or can QUEUE_PAGESIZE be bumped independently of block
size.
It's the size of slru's pages.
*) why not make the
On Thu, Nov 12, 2009 at 1:04 AM, Andrew Chernow a...@esilo.com wrote:
I think a bsearch would be needed. Very busy servers that make heavy use of
notifies would be quite a penalty.
In such an environment, how many relations/channels is a backend
typically listening to?
Do you have average /
Hi,
the attached patch addresses the performance issues of the
authorization related views from information_schema (BUG #4596). It
implements what Tom suggests in
http://archives.postgresql.org/pgsql-bugs/2008-12/msg00144.php
In the cases that I have tested both the new and the old view return
Hi all,
this is a reply to the following post:
http://archives.postgresql.org/message-id/7867.1219793...@sss.pgh.pa.us
which is also a TODO item:
[E] Incomplete itemRevise the src/timezone/tznames abbreviation files:
* to add missing abbreviations
* to find abbreviations that can be
On Thu, Jun 14, 2007 at 08:17:05AM -0400, Andrew Dunstan wrote:
Maybe it uses a different CVS or something. Who knows? Aren't our diffs
supposed to be done ignoring whitespace?
pg_init() in pg_regress_ecpg.c has:
/* no reason to set -w for ecpg checks, except for when on windows */
On Thu, May 17, 2007 at 10:14:45PM +0200, Magnus Hagander wrote:
IIRC, Joachim had started working on the ecpg part. (Which is one of the
reasons I haven't looked at it myself yet)
Joachim, did you ever get anywhere with that?
I have ecpg tests somehow running under msvc but there are still
On Wed, Feb 28, 2007 at 12:56:13PM -0500, Tom Lane wrote:
It hasn't ever made it onto the TODO list, which means there's not a
consensus that we need it.
Such a patch could improve the acceptance of PostgreSQL in shared hosting
environments. Note that a database without quotas can be filled up
On Fri, Jan 26, 2007 at 10:10:20PM +0100, Magnus Hagander wrote:
I would like to build pg on VC2005. How do I use pthreads that is
mentioned in the README file. Do I need the DLL? Sources? LIB?
Where do I install or copy them..
Err, pthreads is a threads library for Unix, I don't think
I'm working again on the patch for making guc variables fall back to their
default value if they get removed (or commented) in the configuration file.
There is still an issue with custom variables that needs discussion.
Remember that for regular variables we have the following semantics:
BEGIN;
On Fri, Jan 12, 2007 at 01:45:10AM +0100, Chris Mair wrote:
I just wanted to mention that the latest release of OpenBSD i386
(4.0) is still broken too. So the ecpg-check failure would apply to
(at least) to 3.8, 4.0, and likely 3.9.
ok, but then we have some hosts in the buildfarm that run the
On Thu, Jan 11, 2007 at 08:41:24AM +0100, Michael Meskes wrote:
While I'm whining ... we really need some support in the ecpg regression
tests for platform-specific diffs, so that the consistent ECPG-check
failures in buildfarm can go away.
Hmm, I thought there was. Joachim, could you
On Thu, Jan 11, 2007 at 09:59:14PM +0100, Magnus Hagander wrote:
.. appears to have killed win32. It did kill my manual MSVC builds, but
it also seems to have killed win32 buildfarm members yak and snake:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=yakdt=2007-01-11%2020:32:11
On Thu, Jan 11, 2007 at 01:15:56PM +0100, Magnus Hagander wrote:
Can't comment on that one, since I just noticed it existed. How similar
was this one to the standard regression tests? Those were moved into a
C executable so they'd run on a Windows system without a shell, could
the same be done
On Fri, Dec 15, 2006 at 11:37:56AM -0500, Tom Lane wrote:
Joachim Wieland [EMAIL PROTECTED] writes:
Appended is a patch that adds JST and JDT into Asia.txt and the Default set.
Um ... is there a JDT? Last I heard, Japan does not observe daylight
time. I don't see a JDT in the old PG set
On Sat, Dec 16, 2006 at 10:26:52AM -0500, Tom Lane wrote:
Joachim Wieland [EMAIL PROTECTED] writes:
True... Actually I wonder how I have to read the zic files in this case.
It says:
RuleJapan 1948only- May Sun=1 2:001:00
D
RuleJapan 1948
On Sat, Dec 16, 2006 at 12:52:12PM -0500, Brian Hurt wrote:
Joachim Wieland wrote:
Yes, I completely agree that JDT should not be included. I just wanted to
understand how those lines show that JST is still in active use. As far as
I
understand it, it says that JST was observed from 1948
On Fri, Dec 15, 2006 at 10:17:20AM -0500, Tom Lane wrote:
However, I encounter the problem of timestamp.:-(
Was anyone recognizing this problem?
The list of accepted timezones is now configurable, check through the
docs how to find the list and set it the way you want.
Yeah, but why the
There have been several reports that people could not vacuum any more or
observed strange locks even after server restart. The reason was that they
still had uncommitted prepared transactions around.
I wonder if it could help to change the log level from
ereport(LOG,
Current beta seems to have the 2006k version of the zic database. The current
zic database is version 2006n however. Since this update does not include
source code but just data files I would vote to do the update in beta, what
do others think?
One prominent update concerns Brazil which changes
On Wed, Oct 04, 2006 at 06:15:31AM -0400, Bruce Momjian wrote:
Michael Meskes wrote:
Is there a way to make pgindent skip a directory? It seems it has
changed all expected file in ecpg's regression suite. So we see a lot of
differences now.
Sure a directory can be skipped. I am confused
On Tue, Oct 03, 2006 at 12:27:47AM -0700, Jeremy Drake wrote:
On Tue, 3 Oct 2006, Magnus Hagander wrote:
Funky.
Can you try having it run the dumpbin command into a tempfile, and then
open-and-read that tempfile, to see if that makes a difference?
(Assuming you know enough perl to do
... FAILED (log, output)
testing pgtypeslib/num_test.pgc... FAILED (output)
testing pgtypeslib/num_test2.pgc ... FAILED (output)
All should be fine now. I tested successfully with both cygwin and MinGW.
Joachim
--
Joachim Wieland
ecpg-check manually? Which test hangs?
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
GPG key available
---(end of broadcast)---
TIP 6: explain
from the view
completely or add another boolean column has_leapsecs or similar?
Removing them seems not to be the right idea because you can say:
select now() at time zone 'Mideast/Riyadh87';
Joachim
--
Joachim Wieland [EMAIL PROTECTED
On Mon, Sep 18, 2006 at 01:13:45PM +0200, Peter Eisentraut wrote:
Joachim Wieland is in the process of reworking the original feature patch
(resetting commented out parameters) in a much more compact form. But it
turns out that there are a couple of very tricky situations involving custom
docs ... we should probably
remove both of those in favor of recommending people look at the
views.
I did the basic documentation work in catalogs.sgml for these views,
but Appendix B still needs an update. Joachim, you were going to do
that, right?
Thats right.
Joachim
--
Joachim Wieland
as the table is concerned, I think we agreed on removing the list
(that has been inaccurate since long anyway) and tell people to check out
the system view.
Joachim
--
Joachim Wieland [EMAIL PROTECTED
to `#line 1 sql3types.h' as well but I think this is
acceptable.
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
GPG key available
Index: pg_regress.sh
it is in. Doesn't the backend
regression test (using psql) suffer from the same problem with libpq?
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
GPG key available
---(end
directorymake[4]: *** [all] Error 2
You don't have ecpg/test/connect/ ?
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/connect/
Joachim
--
Joachim Wieland [EMAIL PROTECTED
...).
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
GPG key available
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
to select what test should be run? Maybe no tcp
connections by default but with an additional make-target checktcp?
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
GPG key available
On Tue, Jul 25, 2006 at 10:37:20PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I'll take a whack at that patch this evening PDT or tomorrow evening
at the latest. We're too late in the cycle to go over this, but maybe
we can figure out a way to have this data read from
Hi,
what do people think about this TODO item:
o Merge hardwired timezone names with the TZ database; allow either
kind everywhere a TZ name is currently taken
I think it is kind of done. The hardwired timezone names are no longer
hardwired and the America/New_York syntax is
On Mon, Jul 24, 2006 at 07:09:17PM +0200, Peter Eisentraut wrote:
Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost:
#2: That variable can *not* be changed by a reload.
Notice-level message is sent to the log notifying the admin that the
change requested could not be performed.
On Mon, Jul 24, 2006 at 10:55:47AM -0400, Stephen Frost wrote:
#2: That variable can *not* be changed by a reload.
Notice-level message is sent to the log notifying the admin that the
change requested could not be performed. This change could be
either a revert to reset-value
Giampaolo,
On Sun, Jun 18, 2006 at 01:26:21AM +0200, Giampaolo Tomassoni wrote:
Or... Can I put a custom variable in pgsql.conf?
Like that you mean?
custom_variable_classes = 'identify'# list of custom variable classnames
identify.id = 42
template1=# show identify.id;
I looked into the timezone specifications and basically extracted a list of
existing offsets from the zic database.
My proposed format for the timezone files is something like this:
HADT -32400 D # Hawaii-Aleutain Daylight Time
# (America/Adak)
HAST -36000#
Can someone please explain why in include/utils/datetime.h (struct datetkn)
there is a check for _AIX that either initializes a char* pointer or a char
array? Is there any advantage of a char-array except for warnings of some
compilers if the initilization string is too long?
Apart from that I
Martijn,
On Fri, May 26, 2006 at 03:03:15PM +0200, Martijn van Oosterhout wrote:
I think you may be thinking of yet a separate TODO item, which is to
be able to use the zic timezone names in timestamptz input, viz
'2006-05-24 21:11 Americas/New_York'::timestamptz
But names like 'IST'
I'd like to know what exactly is to be done for this TODO-item
o Allow customization of the known set of TZ names (generalize the
present australian_timezones hack)
The most recent mail in the archives about this subject seems to be:
a server restarted.
Does anybody work on it?
I have a patch that seems to work, it could need some more testing however.
I'll send it to you per PM.
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
C/ Usandizaga 12 1°B
The documentation for the .pgpass file seems to be incorrect with respect to
unix domain sockets.
There's also a user comment saying that:
http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html
The documentation suggests that the hostname part of .pgpass can be set to
localhost to
to the configuration re-read at SIGHUP?
Right, and it is something we have needed to fix for a while.
I'm working on this one.
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
C/ Usandizaga 12 1°B ICQ: 37225940
20002 Donostia
dependencies
- SET DEFAULT forbidden, issues a hint to DROP DEFAULT first
Is it also desired to convert an int column to a serial column?
(moving to -hackers)
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
C/ Usandizaga 12 1°B
On Mon, Jan 30, 2006 at 05:10:03PM -0500, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Joachim Wieland wrote:
I wonder if there is a policy on when schema-qualified names should
be used in ereport/elog messages.
If it's not too hard to do, I would add the schema name
On Tue, Jan 31, 2006 at 01:46:42PM -0500, Tom Lane wrote:
The direction that we ought to be going in is to add separate fields to
error reports that contain just the names of the relevant objects (without
any other decoration). This is needed anyway to allow client-side
programs to extract
I wonder if there is a policy on when schema-qualified names should be used
in ereport/elog messages.
At the moment this doesn't seem to be consistent, even within the same
command:
template1=# VACUUM verbose t;
INFO: vacuuming public.t
[...]
template1=# VACUUM verbose tv;
WARNING: skipping
on at the moment. So it
might get more concise but we'll have to play around with it to see what is
useful and what isn't.
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
C/ Usandizaga 12 1°B ICQ: 37225940
20002
to be mirrored and should be recreated on every webserver? We might need
one copy for the last version of every major release as well as one for
cvs. The latter should get updated regularly of course but I figure it would
be sufficient to do that once a week...
Joachim
--
Joachim Wieland
header and footer as well. The
postgresql logo on top would be nice but the navigation menu on the left has
to be sacrificed for more space.
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
C/ Usandizaga 12 1°B ICQ
to easily check
what is where defined and how... What do you think?
doxygen can also produce a pdf but I haven't succeeded in doing that so far,
pdflatex keeps bailing out. Has anybody else succeeded building this yet?
Joachim
--
Joachim Wieland
some de facto rules about comments to get most
of the matches: For example a comment starting on column 0 of the line is
probably one you're looking for vs. one that has some whitespace at the
beginning is not.
Of course this would still need manual review for every file.
Joachim
--
Joachim
The TODO list contains some items concerning the CIDR/INET datatype.
* %Prevent INET cast to CIDR if the unmasked bits are not zero, or
zero the bits
I added a function for this cast (which zeroes the bits) but then the
opr_sanity regression test failed because there is a cast from INET - CIDR
On Sat, Jan 07, 2006 at 12:50:23PM -0500, Tom Lane wrote:
Joachim Wieland [EMAIL PROTECTED] writes:
Actually both types are not binary compatible, since they have a
type component that is either 0 or 1, depending on whether it is of type
INET or CIDR.
The whole question
Hi,
there's a topic that comes up from time to time on the lists, the problem
that pgsql functions get planned only once and thereafter the same query
plan is used until server shutdown or explicit recreation of the function.
I'd like to implement a way of automatic function replanning. I can
Hi,
I have a 7.4.3 installation where a small plperl function seems to have
side-effects. In the example below I run an ordinary SELECT first, nothing
special with the table. Thereafter I call the plperl function and then I
rerun the SELECT query. This time it doesn't return the expected result.
On Tue, Nov 23, 2004 at 10:33:50AM -0500, Tom Lane wrote:
We do need to do something about the fact that EXECUTE can't access
plpgsql variables, though I'm afraid that fixing that is going to
require a rather complete overhaul of plpgsql :-(. But it needs one
anyway.
Why do you think that it
Hi,
this query makes postmaster (beta4) die with signal 11:
(echo CREATE TABLE footest(;
for i in `seq 0 66000`; do
echo col$i int NOT NULL,;
done;
echo PRIMARY KEY(col0));) | psql test
ERROR: tables can have at most 1600 columns
LOG: server process (PID 2140)
On Sat, Nov 06, 2004 at 07:17:29PM +, Simon Riggs wrote:
Once you have brought up a database in timeline N+1, you can't use it as
the base to recover to a point in timeline N because the data file
contents cannot be trusted to be identical to the way they were in
timeline N.
You
Hi,
On Sat, Nov 06, 2004 at 11:13:34AM +, Simon Riggs wrote:
The timeline code only comes into effect when you request an archive
recovery. If you do not, it has no way of knowing it should have.
Ok. However these details should be added to the docs as well.
At least a short warning should
Hi there,
I just wanted to try the PITR feature in beta and got it working somehow.
However I think the docs on this point are still not sufficient enough.
We have to assume that people will have a closer look at the backup/recovery
documentation as soon as 8.0 ships, because we're kinda heavily
Simon,
thanks for that quick and detailed answer.
On Fri, Nov 05, 2004 at 05:42:01PM +0100, [EMAIL PROTECTED] wrote:
The sample file gives additional information, just as occurs with
pg_hba.conf. I don't see any need to replicate the sample file in the
docs, do you?
Well, maybe one could add
Hi,
On Fri, Nov 05, 2004 at 10:26:55PM +, Simon Riggs wrote:
That is exactly the situation Timelines are designed to avoid. This
should not have happened. What leads you to think it has? My guess is
that it has not. If it has, its a bug.
Hmm. I did the following:
- I recovered to one
101 - 197 of 197 matches
Mail list logo
