On Tue, 2004-06-01 at 03:13, Alvaro Herrera wrote:
> A completely different idea would be to log a "logical index creation",
> so that during normal recovery those entries are saved somewhere; after
> the rest of WAL recovery is done, the system is taken into a more normal
> post-recovery pre-usabl
On Tue, 2004-06-01 at 03:21, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I assume if someone turns on archiving in postgresql.conf, sighups the
> > > postmaster, then does a tar backup, they should be able to do archiving,
> > > no?
> >
> > I would ha
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > I'm not clear that building from WAL is really going to be that much faster.
> > A) algorithmically it's only the factor of log(n) that you're talking about.
> > and B) the WAL will have records for every write, not just the final product
On Tue, Jun 01, 2004 at 01:55:38PM -0400, Greg Stark wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
> > The big problem I see with this kind of approaches is that building an
> > index from scratch can take a huge amount of time, because you have to
> > sort the data. Building from WAL doe
Greg Stark <[EMAIL PROTECTED]> writes:
> I'm not clear that building from WAL is really going to be that much faster.
> A) algorithmically it's only the factor of log(n) that you're talking about.
> and B) the WAL will have records for every write, not just the final product,
> so it might potentia
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The big problem I see with this kind of approaches is that building an
> index from scratch can take a huge amount of time, because you have to
> sort the data. Building from WAL does not have this problem, so it can
> be much faster.
I'm not clear
On Tue, Jun 01, 2004 at 12:52:32PM -0400, Greg Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > I thought for a little bit about a magic "reconstruct the index" WAL
> > entry that would invoke the index build procedure in toto, but that
> > doesn't look like it will fly either. (Two p
Tom Lane <[EMAIL PROTECTED]> writes:
> I thought for a little bit about a magic "reconstruct the index" WAL
> entry that would invoke the index build procedure in toto, but that
> doesn't look like it will fly either. (Two problems: during crash
> recovery, you couldn't be sure that what's on di
Simon Riggs <[EMAIL PROTECTED]> writes:
> The mechanism you suggest would also break crash recovery, not just PITR
No it wouldn't.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choo
> I think an actually implementable version of this would be:
>
> 1. Don't log any index operations at all in WAL.
>
> 2. When recovering from WAL, restore all the table contents by WAL
> replay. (This would of course include the system catalog contents that
> describe the indexes.) Then sit t
On Tue, 2004-06-01 at 01:24, Tom Lane wrote:
> I was just about to commit a patch that revises the btree index build
> procedure as discussed here:
> http://archives.postgresql.org/pgsql-general/2004-05/msg00480.php
> specifically, not using shared buffers during index build and bypassing
> WAL-log
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> A completely different idea would be to log a "logical index creation",
> so that during normal recovery those entries are saved somewhere; after
> the rest of WAL recovery is done, the system is taken into a more normal
> post-recovery pre-usable state,
Gavin Sherry <[EMAIL PROTECTED]> writes:
>> So AFAICS, we've got to dump the index contents into WAL to support
>> PITR. This is a tad annoying.
> Is it possible in this case to dump the index block by block into the log
> after it has been generated?
That's what we do now, and it more or less d
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I assume if someone turns on archiving in postgresql.conf, sighups the
> > postmaster, then does a tar backup, they should be able to do archiving,
> > no?
>
> I would have zero problem with labeling the archive parameter as
> changea
On Tue, Jun 01, 2004 at 11:34:15AM +1000, Gavin Sherry wrote:
> On Mon, 31 May 2004, Tom Lane wrote:
>
> > I thought for a little bit about a magic "reconstruct the index" WAL
> > entry that would invoke the index build procedure in toto, but that
> > doesn't look like it will fly either. (Two pr
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I assume if someone turns on archiving in postgresql.conf, sighups the
> postmaster, then does a tar backup, they should be able to do archiving,
> no?
I would have zero problem with labeling the archive parameter as
changeable only at postmaster start.
Christopher Kings-Lynne wrote:
> > What I'm thinking about right now is tweaking the index-build code to
> > write to WAL only if it sees that PITR is actually in use. It would
> > have to look at the GUC variables to determine whether WAL archiving
> > is enabled. If archiving isn't turned on, t
What I'm thinking about right now is tweaking the index-build code to
write to WAL only if it sees that PITR is actually in use. It would
have to look at the GUC variables to determine whether WAL archiving
is enabled. If archiving isn't turned on, then we could assume that
rollforward from a pas
On Mon, 31 May 2004, Tom Lane wrote:
[snip]
> I thought for a little bit about a magic "reconstruct the index" WAL
> entry that would invoke the index build procedure in toto, but that
> doesn't look like it will fly either. (Two problems: during crash
> recovery, you couldn't be sure that what'
I was just about to commit a patch that revises the btree index build
procedure as discussed here:
http://archives.postgresql.org/pgsql-general/2004-05/msg00480.php
specifically, not using shared buffers during index build and bypassing
WAL-logging in favor of just fsyncing the index file before co
20 matches
Mail list logo
