Gokulakannan Somasundaram wrote:
> a) The current WAL architecture makes sure that the WAL Log is written
> before the actual page flush( i believe ). But you are changing that
> architecture for Visibility maps. Visibility map might get flushed out
> before the corresponding WAL gets written.
Ye
On Thu, Feb 25, 2010 at 3:16 AM, Gokulakannan Somasundaram <
gokul...@gmail.com> wrote:
>
> I haven't thought about whether this is sufficient but if it is then
>> an initial useful thing to add would be to use it for queries where we
>> have a qual that can be checked using the index key even tho
Fujii Masao wrote:
> And we need to remove the following code from XLogSend(). This code is
> useless now since the initial CopyData message is guaranteed to arrive
> at the primary before doing XLogSend().
>
>> /*
>> * Invalid position means that we have not yet received the initial
>> * CopyDa
> The WAL record of the heap insert/update/delete contains a flag
> indicating that the visibility map needs to be updated too. Thus no need
> for a separate WAL record.
>
>
Heikki,
Have you considered these cases?
a) The current WAL architecture makes sure that the WAL Log is written
befor
On Wed, Feb 24, 2010 at 7:56 AM, Simon Riggs wrote:
> On Thu, 2010-01-28 at 10:28 +0200, Heikki Linnakangas wrote:
>> Fujii Masao wrote:
>> > In relation to the functions added recently, I found an annoying problem;
>> > pg_xlogfile_name(pg_last_xlog_receive/replay_location()) might report the
>>
On Tue, Feb 23, 2010 at 4:08 PM, Heikki Linnakangas
wrote:
>> So it's not the TLI of the first record in the file, isn't it?
>
> Hmm, or is it the TLI of the last record? Not sure. Anyway, if there's a
> TLI switch in the current WAL file, curFileTLI doesn't always represent
> the TLI of the curre
On Thu, Feb 25, 2010 at 5:29 AM, Heikki Linnakangas
wrote:
> Hmm, interesting corner case. That assertion is checking that the
> streaming starting point is initialized correctly, but 0/0 is actually a
> valid value when you start streaming from the very first WAL segment.
>
> I guess we can just
Greg Smith writes:
> Tom Lane wrote:
>> The value of the HINT I think would be to make them (a) not afraid to
>> hit control-C and (b) aware of the fact that their archiver has got
>> a problem.
>>
> Agreed on both points. Patch attached that implements something similar
> to Josh's wording, tw
> I don't want that immediate NOTICE message, which sounds like a noise.
> Delaying it or changing the log level to DEBUG work for me.
Problem is that a new user won't be seeing DEBUG messages by default.
This issue is all about new user experience.
Alternatively, we could move the time of the f
On Thu, Feb 25, 2010 at 10:52 AM, Tom Lane wrote:
> The one thing I'm undecided about is whether we want the immediate
> NOTICE, as opposed to dialing down the time till the first WARNING
> to something like 5 or 10 seconds. I think the main argument for the
> latter approach would be to avoid lo
On 2/24/10 5:58 PM, Greg Smith wrote:
>
> I though about that for a minute, but didn't think pg_stop_backup is a
> common enough operation that anyone will complain that it's a little
> more verbose in its logging now. I know when I was new to this, I used
> to wonder just what it was busy doing
Tom Lane wrote:
The one thing I'm undecided about is whether we want the immediate
NOTICE, as opposed to dialing down the time till the first WARNING
to something like 5 or 10 seconds. I think the main argument for the
latter approach would be to avoid log-spam in normal operation
I though abo
On Wed, Feb 24, 2010 at 08:52:28PM -0500, Tom Lane wrote:
> Josh Berkus writes:
> > On 2/24/10 5:36 PM, Greg Smith wrote:
> >> gsmith=# select pg_stop_backup();
> >> NOTICE: pg_stop_backup cleanup done, waiting for required segments to
> >> archive
> >> WARNING: pg_stop_backup still waiting for
Josh Berkus writes:
> On 2/24/10 5:36 PM, Greg Smith wrote:
>> gsmith=# select pg_stop_backup();
>> NOTICE: pg_stop_backup cleanup done, waiting for required segments to
>> archive
>> WARNING: pg_stop_backup still waiting for all required segments to
>> archive (60 seconds elapsed)
>> HINT: Con
On 2/24/10 5:36 PM, Greg Smith wrote:
> gsmith=# select pg_stop_backup();
> NOTICE: pg_stop_backup cleanup done, waiting for required segments to
> archive
> WARNING: pg_stop_backup still waiting for all required segments to
> archive (60 seconds elapsed)
> HINT: Confirm your archive_command is
Tom Lane wrote:
The value of the HINT I think would be to make them (a) not afraid to
hit control-C and (b) aware of the fact that their archiver has got
a problem.
Agreed on both points. Patch attached that implements something similar
to Josh's wording, tweaking the original warning too.
On Thu, Feb 25, 2010 at 9:31 AM, Erik Rijkers wrote:
> On Wed, February 24, 2010 20:40, Erik Rijkers wrote:
>>
>>
>> pg_last_xlog_receive_location | pg_xlogfile_name_offset
>> ---+---
>> E2/C012AD90 | (000
Bruce Momjian wrote:
> What happened to this patch?
It was rejected because SQL standard always requires an user mapping.
I agree about the decision, too.
> ---
> Itagaki Takahiro wrote:
> > contrib/dblink in 8.4 supports
On Wed, 2010-02-24 at 19:08 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Wed, 2010-02-24 at 16:52 -0500, Tom Lane wrote:
> >> * emit a NOTICE as soon as pg_stop_backup's actual work is done and
> >> it's starting to wait for the archiver (or maybe after it's waited
> >> for a few seconds, b
Robert Haas wrote:
> I'm pretty sure it's the same as this:
> https://commitfest.postgresql.org/action/patch_view?id=263
Yes, (2) are resolved with the patch with a different implementation.
> (2) is fixed by RegisterXactCallback(AtEOXact_dblink). However, there
> might be any better solutions
On Wed, February 24, 2010 20:40, Erik Rijkers wrote:
>
>
> pg_last_xlog_receive_location | pg_xlogfile_name_offset
> ---+---
> E2/C012AD90 | (00E200C0,1224080)
> (1 row)
>
> These zero-timeline fil
On Wed, 2010-02-24 at 23:57 +, Simon Riggs wrote:
>
> > * emit a NOTICE as soon as pg_stop_backup's actual work is done and
> > it's starting to wait for the archiver (or maybe after it's waited
> > for a few seconds, but much less than the present 60).
>
> Pointless really. Nobody runs back
On Wed, Feb 24, 2010 at 14:35, Richard Huxton wrote:
> With plperl.on_init allowing the loading of modules, might there be some
> merit (and little cost) in allowing the same style of function-mapping as
> with C functions?
>
> CREATE FUNCTION add_one(integer) RETURNS integer
> AS 'DIRECTORY/f
Simon Riggs writes:
> On Wed, 2010-02-24 at 16:52 -0500, Tom Lane wrote:
>> * emit a NOTICE as soon as pg_stop_backup's actual work is done and
>> it's starting to wait for the archiver (or maybe after it's waited
>> for a few seconds, but much less than the present 60).
> Pointless really. Nobod
On Wed, 2010-02-24 at 14:20 -0800, Josh Berkus wrote:
> Since Kevin suggested this in his first post and I agreed with that in
> > the first paragraph of my first post, I think you've wasted a lot of
> > time here going in circles. 42 posts, more than a dozen people. I
> think
>
> Please tone down
On Wed, 2010-02-24 at 16:52 -0500, Tom Lane wrote:
> Before you could enter pg_abort_backup you'd have to control-C out of
> the pg_stop_backup call, and that action already accomplishes the only
> thing pg_abort_backup could do for you.
Agreed. I was responding to perceived user need.
> So what
On Wed, Feb 24, 2010 at 4:35 PM, Richard Huxton wrote:
> With plperl.on_init allowing the loading of modules, might there be some
> merit (and little cost) in allowing the same style of function-mapping as
> with C functions?
>
> CREATE FUNCTION add_one(integer) RETURNS integer
> AS 'DIRECTORY
> If you like the concept, then the next question is exactly how to phrase
> the messages. All we have at the moment is the inside-the-delay-loop
> warning:
>
> ereport(WARNING,
> (errmsg("pg_stop_backup still waiting for archive to complete (%d
> seconds elapsed)",
>
On Feb 24, 2010, at 3:24 PM, Tom Lane wrote:
> If you like the concept, then the next question is exactly how to phrase
> the messages. All we have at the moment is the inside-the-delay-loop
> warning:
>
>ereport(WARNING,
>(errmsg("pg_stop_backup still waiting for archive to com
Josh Berkus writes:
> Tom, Simon,
>> * emit a NOTICE as soon as pg_stop_backup's actual work is done and
>> it's starting to wait for the archiver (or maybe after it's waited
>> for a few seconds, but much less than the present 60).
>>
>> * extend the existing WARNING (and the NOTICE too if we el
> That's not what I said to do first. If it's possible to fix your
> archive_command, and it never returned bad "I'm saying success but I
> didn't really do the right thing" information to the server--it just
> failed--this situation is completely recoverable with no damage to the
> backup. Just
Josh Berkus wrote:
Thing is, if archive_command is failing, then the backup is useless
regardless until it's fixed. And sending the archives to /dev/null (the
fix you're essentially recommending above) doesn't make the backup any
more useful.
That's not what I said to do first. If it's possib
Tom, Simon,
> * emit a NOTICE as soon as pg_stop_backup's actual work is done and
> it's starting to wait for the archiver (or maybe after it's waited
> for a few seconds, but much less than the present 60).
>
> * extend the existing WARNING (and the NOTICE too if we elect to have
> one) with a H
Simon Riggs writes:
> Please test the following patch to see if it meets your needs and check
> the wordings used in the docs.
What exactly will that function accomplish, given the assumption that
the user already tried pg_stop_backup?
regards, tom lane
--
Sent via pgsq
On Wed, 2010-02-24 at 13:30 -0800, Josh Berkus wrote:
> So I'm seeing pg_abort_backup(), which also produces a
> markers which prevent the backup from loading, as an improvement on
> current UI.
Since Kevin suggested this in his first post and I agreed with that in
the first paragraph of my first
Josh Berkus writes:
> Thing is, if archive_command is failing, then the backup is useless
> regardless until it's fixed. And sending the archives to /dev/null (the
> fix you're essentially recommending above) doesn't make the backup any
> more useful. So I'm seeing pg_abort_backup(), which also
> I haven't thought about whether this is sufficient but if it is then
> an initial useful thing to add would be to use it for queries where we
> have a qual that can be checked using the index key even though we
> can't do a range scan. For example if you have a btree index on
> and you have a WH
> You also need to avoid scanning the same tuple twice. That's not a
> problem for VACUUM, but it is for full index scans.
>
> Heikki,
Actually the logic, which i have explained earlier is to avoid
scanning tuples twice.
Gokul.
Josh Berkus wrote:
> So I'm seeing pg_abort_backup(), which also produces a
> markers which prevent the backup from loading, as an improvement on
> current UI.
Starting with 9.0, if recovery doesn't see a end-of-backup record, it
will refuse to start up. In earlier versions we had a similar mechan
Stefan Kaltenbrunner writes:
> Simon Riggs wrote:
>> Not for 9.0, though sounds like a welcome change.
> yeah - any objections if I add it to the TODO for now?
None, it seems like a reasonable future feature.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pg
With plperl.on_init allowing the loading of modules, might there be some
merit (and little cost) in allowing the same style of function-mapping
as with C functions?
CREATE FUNCTION add_one(integer) RETURNS integer
AS 'DIRECTORY/funcs', 'add_one'
LANGUAGE C STRICT;
CREATE FUNCTION add
On Wed, Feb 24, 2010 at 8:15 PM, Richard Huxton wrote:
> If that all works, re-run the installer and you should be able to re-install
> the adminpack etc. over the top of your now working installation.
That won't work. If the installer finds the existing data directory
(which it will), it won't t
Greg,
> I expect for your particular bad situation, you can replace the
> archive_command with a corrected one, use "pg_ctl reload" to send a
> SIGHUP to make that fix active, and escape from this. That's the only
> right way out of this situation. You can't just abort a backup someone
> has ask
There is a failure report here that seems worthy of notice:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=baiji&dt=2010-02-23%2023:00:03
Everything is fine except that the session running the "triggers" test
went completely bonkers: the first few commands are okay, and then
after that eve
Simon Riggs wrote:
On Tue, 2010-02-23 at 10:00 +0100, Stefan Kaltenbrunner wrote:
While playing with SR/HS in a more complex datacenter environment I
immediatly hit the need to being able to specify the ipaddress(or
interface) that the backend(or libpq) uses to connect to the master.
There ar
I should have added that (on the slave) all pg_xlog/ files have timeline 1
like: 000100E200C0
On Wed, February 24, 2010 20:40, Erikruary 24, 2010 20:40, Er Rijkers wrote:
> I have two 9.0devel machines (*not* alpha but cvs as of 2010.02.19 22.48).
>
> One primary, one slave.
>
> In a
Heikki Linnakangas writes:
> Josh Berkus wrote:
>> OK, so we need a way out of that cycle if the user is issuing
>> pg_stop_backup because they *already know* that archive_command is
>> failing. Right now, there's no way out other than a fast shutdown,
> Sure there is. Just kill the session, Ctr
Josh Berkus wrote:
pg_stop_backup() doesn't complete until all the WAL segments needed to
restore from the backup are archived. If archive_command is failing,
that never happens.
OK, so we need a way out of that cycle if the user is issuing
pg_stop_backup because they *already know* that a
On Feb 24, 2010, at 12:47 PM, Tom Lane wrote:
>> OK, so we need a way out of that cycle if the user is issuing
>> pg_stop_backup because they *already know* that archive_command is
>> failing. Right now, there's no way out other than a fast shutdown,
>> which is a bit user-hostile.
>
> The pg_ab
Josh Berkus writes:
>> pg_stop_backup() doesn't complete until all the WAL segments needed to
>> restore from the backup are archived. If archive_command is failing,
>> that never happens.
> OK, so we need a way out of that cycle if the user is issuing
> pg_stop_backup because they *already know*
On Wed, 2010-02-24 at 11:55 -0800, Joshua D. Drake wrote:
> On Wed, 2010-02-24 at 19:02 +, Simon Riggs wrote:
> > On Wed, 2010-02-24 at 10:17 -0800, Joshua D. Drake wrote:
>
> > You make the mistake of assuming that someone that can develop has no
> > solution experience. That is exactly how I
Josh Berkus wrote:
>> pg_stop_backup() doesn't complete until all the WAL segments
>> needed to restore from the backup are archived. If
>> archive_command is failing, that never happens.
>
> OK, so we need a way out of that cycle if the user is issuing
> pg_stop_backup because they *already kn
Josh Berkus wrote:
>> pg_stop_backup() doesn't complete until all the WAL segments needed to
>> restore from the backup are archived. If archive_command is failing,
>> that never happens.
>
> OK, so we need a way out of that cycle if the user is issuing
> pg_stop_backup because they *already know*
On Wed, 2010-02-24 at 12:32 -0800, Josh Berkus wrote:
> > pg_stop_backup() doesn't complete until all the WAL segments needed to
> > restore from the backup are archived. If archive_command is failing,
> > that never happens.
>
> OK, so we need a way out of that cycle if the user is issuing
> pg_s
> pg_stop_backup() doesn't complete until all the WAL segments needed to
> restore from the backup are archived. If archive_command is failing,
> that never happens.
OK, so we need a way out of that cycle if the user is issuing
pg_stop_backup because they *already know* that archive_command is
fa
Gokulakannan Somasundaram wrote:
> OK I think, i can think of a solution to achieve fast full index scan like
> oracle.
> a) Issue ids to every block that gets created inside the index. we are
> already doing that
> b) Now before the fast full index scan starts, note down the max id that got
> issu
Greg Stark wrote:
> I tried to set up a simple master/slave setup and immediately ran into
> this assertion failure. The slave is just a cold copy of the database
> immediately after initdb. The first WAL segment hasn't been archived
> yet. It sees that the first archive fail hasn't been archived y
On Wed, Feb 24, 2010 at 8:04 PM, Gokulakannan Somasundaram
wrote:
> OK I think, i can think of a solution to achieve fast full index scan like
> oracle.
> a) Issue ids to every block that gets created inside the index. we are
> already doing that
> b) Now before the fast full index scan starts, no
Josh Berkus wrote:
> OK, can you go through the reasons why pg_stop_backup would not
> complete?
pg_stop_backup() doesn't complete until all the WAL segments needed to
restore from the backup are archived. If archive_command is failing,
that never happens.
> And why it's a problem to have it co
On 24/02/10 13:09, William wrote:
Hello Pqsql-hacker,
I have tried everything and ask many but cannot get my Installation of your
PostgreSQL 8.4.1.1 to install.
While you are having problems, take the opportunity to download 8.4.2
and work with that. That's the latest set of bugfixes.
> I f
>
>> That doesn't work because when you split an index page any sequential
>>> scan in progress will either see the same tuples twice or will miss
>>> some tuples depending on where the new page is allocated. Vacuum has a
>>> clever trick for solving this but it doesn't work for arbitrarily many
>>
On 2/24/10 11:55 AM, Joshua D. Drake wrote:
> On Wed, 2010-02-24 at 19:02 +, Simon Riggs wrote:
>> On Wed, 2010-02-24 at 10:17 -0800, Joshua D. Drake wrote:
>
>> You make the mistake of assuming that someone that can develop has no
>> solution experience. That is exactly how I fund further dev
Simon,
> If you have a concrete proposal, get off your soapbox and make one,
> based upon the technical information you've received. There are clear
> reasons why things are the way they are and those reasons will not be
> ignored, by me.
OK, can you go through the reasons why pg_stop_backup woul
On Wed, 2010-02-24 at 11:31 -0800, Josh Berkus wrote:
> > This is about what happens in production, not your laptop. The required
> > behaviour in-production is to assume that the sysadmin has configured it
> > correctly and we wait for them to fix the problem.
>
> 90% of our user base does not
On Wed, 2010-02-24 at 19:02 +, Simon Riggs wrote:
> On Wed, 2010-02-24 at 10:17 -0800, Joshua D. Drake wrote:
> You make the mistake of assuming that someone that can develop has no
> solution experience. That is exactly how I fund further development, so
> you are off base by a long way.
I n
Le 24 févr. 2010 à 18:58, Boszormenyi Zoltan a écrit :
>
> Here's the attached test code. Compile it with
>
> gcc -Wall -o nantest nantest.c -lm
>
> and run it. It tests NAN anf INFINITY values with isinf() and isnan().
> The expected output is:
>
> ==
> $ ./nantest
> computed
On Wed, Feb 24, 2010 at 2:33 PM, Bruce Momjian wrote:
> What happened to this patch?
I'm pretty sure it's the same as this:
https://commitfest.postgresql.org/action/patch_view?id=263
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
I have two 9.0devel machines (*not* alpha but cvs as of 2010.02.19 22.48).
One primary, one slave.
In an attempt to keep track of standby progression (versus primary), I ran
slave-side:
replicas=# select
pg_last_xlog_replay_location()
pg_xlogfile_name_offset(pg_l
What happened to this patch?
---
Itagaki Takahiro wrote:
> contrib/dblink in 8.4 supports a server name by CREATE SERVER for connection
> string, but it always requires an user-mapping (by CREATE USER MAPPING).
> However, I
What happened to this patch?
---
Itagaki Takahiro wrote:
>
> Merlin Moncure wrote:
>
> > Takahiro wrote:
> > > contrib/dblink seems to have no treatments for query cancels.
> > > (1) Users need to wait for completion of r
> You haven't posted a reproduceable bug, nor is this new to 9.0.
Yes, I have.
1) set up a failing archive_command on an idle database
2) do pg_start_backup
3) do pg_stop_backup
4) pg_stop_backup waits forever (or at least 5 minutes, which as long as
I've given it so far).
> This is about wh
On Wed, 2010-02-24 at 11:07 -0800, Josh Berkus wrote:
> > I haven't ignored the issue. The behaviour you are complaining about was
> > put there following complaints that it didn't wait. You're ignoring the
> > point that there hasn't been any change in this release and so your
> > comments are unf
> It might be slightly easier given the assumption that you only want to
> scan leaf tuples.
>
> But there's an additional problem I didn't think of before. Currently
> we optimize index scans by copying all relevant tuples to local memory
> so we don't need to hold an index lock for an extended ti
Gokulakannan Somasundaram wrote:
> Hmmm So whenever the update transaction changes a page, it will update
> the visibility map, but won't enter the WAL record.
> So after the crash we have a visibility map, which has false positives.
The WAL record of the heap insert/update/delete contains
> I haven't ignored the issue. The behaviour you are complaining about was
> put there following complaints that it didn't wait. You're ignoring the
> point that there hasn't been any change in this release and so your
> comments are unfounded in reality.
I've posted a reproduceable bug (pg_stop_
Missed the group
> So basically you want to have index-only scans, but you want them to
> be really slow?
>
No Robert, i just asked him to make it optional, so that the crash safe
visibility map is used only when its need is realized by the DB designer.
When there is a table with no indexes
On 2/24/10 10:40 AM, Heikki Linnakangas wrote:
> Josh Berkus wrote:
>> And, while it makes sense for smart shutdown to wait for
>> pg_stop_backup(), it does not make sense for fast shutdown to wait.
>
> Hang on, fast shutdown does *not* wait for backup to finish.
It did when I tried it. I'll tes
Missed the group...
On Thu, Feb 25, 2010 at 12:34 AM, Gokulakannan Somasundaram <
gokul...@gmail.com> wrote:
>
>
> On Thu, Feb 25, 2010 at 12:28 AM, Gokulakannan Somasundaram <
> gokul...@gmail.com> wrote:
>
>>
>> That doesn't work because when you split an index page any sequential
>>> scan in p
Simon Riggs wrote:
> Which is why, in the next paragraph, I proposed a way forwards...
Oh, sorry.
> There are 3 use cases: PITR, file-based replication and streaming
> replication. Having 3 separate sections would be less confusing since it
> would allow focused examples. A final section could be
On Wed, 2010-02-24 at 10:17 -0800, Joshua D. Drake wrote:
> Basically the reports boil down to people who are actually going to be
> dealing with this in the field. Simon with respect you have been 6 feet
> deep in code for too long on this. You need to step back and take some
> constructive feedb
On Wed, 2010-02-24 at 20:20 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > A new section inside the HA chapter would be useful, so this is on the
> > same level as "Streaming Replication". So just drop everything down one
> > level.
>
> The problem with that is that the recovery.conf op
> Yes. The visibility map doesn't need any new WAL records to be written.
>
> We probably will need to add some WAL logging to close the holes with
> crash recovery, required for relying on it for index-only-scans, but
> AFAICS only for VACUUM and probably only one WAL record for a whole
> bunch of
On Wed, Feb 24, 2010 at 1:20 PM, Heikki Linnakangas
wrote:
> Simon Riggs wrote:
>> A new section inside the HA chapter would be useful, so this is on the
>> same level as "Streaming Replication". So just drop everything down one
>> level.
>
> The problem with that is that the recovery.conf options
On Wed, 2010-02-24 at 10:07 -0800, Josh Berkus wrote:
> >
> > The behaviour to wait for pg_stop_backup() was added by user request.
> > The behaviour for shutdown to wait for pg_stop_backup() was also added
> > by user request.
>
> Your two statements above contradict each other.
No they don't.
Josh Berkus wrote:
> And, while it makes sense for smart shutdown to wait for
> pg_stop_backup(), it does not make sense for fast shutdown to wait.
Hang on, fast shutdown does *not* wait for backup to finish.
> Aside from that, the main issue is not having shutdown wait for
> pg_stop_backup; it's
On Wed, Feb 24, 2010 at 10:09 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
> > So you are essentially proposing that rather than moving the heap
> > data into the leaf tuples of the index in the index file, you will
> > move the leaf index data into the heap tuples? The pages in such a
> > IO
> Your OP was not too clear about whether you tried a smart shutdown or
> a fast shutdown, but if you meant a fast shutdown, this is apparently
> (he says without testing) a regression.
Ah, sorry. Yes, I attempted a fast shutdown.
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-ha
Simon Riggs wrote:
> A new section inside the HA chapter would be useful, so this is on the
> same level as "Streaming Replication". So just drop everything down one
> level.
The problem with that is that the recovery.conf options are also
relevant to plain-old recovery from an archive. And PITR.
Did anyone see this? This seems like a pretty grave problem in
streaming replication.
On Tue, Feb 23, 2010 at 2:46 PM, Greg Stark wrote:
> I tried to set up a simple master/slave setup and immediately ran into
> this assertion failure. The slave is just a cold copy of the database
> immediately a
On Wed, Feb 24, 2010 at 1:07 PM, Josh Berkus wrote:
> And, while it makes sense for smart shutdown to wait for
> pg_stop_backup(), it does not make sense for fast shutdown to wait.
TFM in fact says:
http://www.postgresql.org/docs/8.4/static/app-pg-ctl.html#APP-PG-CTL-DESCRIPTION
In stop mode, t
On Wed, 2010-02-24 at 10:07 -0800, Josh Berkus wrote:
> Simon,
> > Your mistake was not typoing an archive_command, it was not correctly
> > testing that what you had done was actually working. The fix is to read
> > the manual and correct the typo. Shutting down the server after failing
> > to co
On Wed, Feb 24, 2010 at 5:46 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Greg Stark wrote:
>>> That doesn't work because when you split an index page any
>>> sequential scan in progress will either see the same tuples twice
>>> or will miss some tuples depending on where the new page is
>>
Oleg, Teodor, would you look at this? I see the same behavior in 9.0.
---
Alexey Bashtanov wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4887
> Logged by: Alexey Bashtanov
> Email a
Simon,
> It's not a common setup mistake. Nothing changed in this release and
> this has never been reported before.
>
> The behaviour to wait for pg_stop_backup() was added by user request.
> The behaviour for shutdown to wait for pg_stop_backup() was also added
> by user request.
Your two stat
Rémi Zara írta:
> Le 17 févr. 2010 à 12:18, Boszormenyi Zoltan a écrit :
>
>> Is this buildfarm member for detecting bugs in the already
>> obsolete NetBSD 5.0 BETA, or what? The final 5.0 and
>> two bugfix releases are already out for a while. The owner
>> of that particular machine should upgr
On Wed, 2010-02-24 at 18:59 +0900, Fujii Masao wrote:
> On Wed, Feb 24, 2010 at 5:11 PM, Robert Haas wrote:
> > Looking at it, I think I do agree that this shouldn't be a whole
> > chapter by itself. It's not nearly as high-level a concept as the
> > chapters that surround it. But I do think it'
On Wed, 2010-02-24 at 19:30 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Major change is necessary here; this change in particular is regrettably
> > a very bad one. Please reconsider and make substantial improvements.
>
> Any suggestions?
A new section inside the HA chapter would be
"Kevin Grittner" writes:
> Greg Stark wrote:
>> That doesn't work because when you split an index page any
>> sequential scan in progress will either see the same tuples twice
>> or will miss some tuples depending on where the new page is
>> allocated. Vacuum has a clever trick for solving this b
On Wed, 2010-02-24 at 15:52 +, Greg Stark wrote:
> We can do
> better with stuff like Heikki's "grouped index tuple" and the
> visibility map which don't interfere with other features as much.
Yes, much better plan. More practical, nearly there.
--
Simon Riggs www.2ndQuadrant.com
Greg Stark wrote:
> Gokulakannan Somasundaram wrote:
>> scan through the leaf pages.
>
> That doesn't work because when you split an index page any
> sequential scan in progress will either see the same tuples twice
> or will miss some tuples depending on where the new page is
> allocated. Vac
1 - 100 of 152 matches
Mail list logo
