Andres Freund writes:
> On 2015-05-08 22:08:31 -0400, Robert Haas wrote:
>> Of course, even the last one isn't totally bullet-proof. Suppose one
>> backend fails to absorb the new setting for some reason...
> I've a hard time worrying much about that one...
You should. At the very least, whate
On 2015-05-08 22:08:31 -0400, Robert Haas wrote:
> That seems a bit better. I think it's really important, if we're
> going to start to try to make fsync=off anything other than a toy,
I think it's long past that. I've seen many, many people use it during
initial data loading.
> that we document
On Fri, May 8, 2015 at 7:53 PM, Andres Freund wrote:
> On 2015-05-04 14:23:16 -0400, Robert Haas wrote:
>> On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen
>> wrote:
>> > As for the non-backpatchable 0002, I agree with Andres that it should be
>> > included in 9.5; but I take it you're still n
On 2015-05-04 14:23:16 -0400, Robert Haas wrote:
> On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen
> wrote:
> > As for the non-backpatchable 0002, I agree with Andres that it should be
> > included in 9.5; but I take it you're still not convinced?
>
> No, I'm not convinced. That patch will p
On Tue, May 5, 2015 at 6:26 AM, David Rowley wrote:
> On 5 May 2015 at 06:23, Robert Haas wrote:
>>
>> OK, committed and back-patched.
>
> There's a couple of problems with this that the windows buildfarm members
> are not happy with.
>
> The attached patch seems to work locally.
Thanks. I thin
On 5 May 2015 at 06:23, Robert Haas wrote:
>
> OK, committed and back-patched.
>
There's a couple of problems with this that the windows buildfarm members
are not happy with.
The attached patch seems to work locally.
Regards
David Rowley
fsync_win32_fix.patch
Description: Binary data
--
S
On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen wrote:
> At 2015-05-01 09:57:28 -0400, robertmh...@gmail.com wrote:
>>
>> If you don't object to this version, I'll commit it.
>
> Looks fine to me, thank you.
OK, committed and back-patched.
> As for the non-backpatchable 0002, I agree with And
At 2015-05-01 09:57:28 -0400, robertmh...@gmail.com wrote:
>
> If you don't object to this version, I'll commit it.
Looks fine to me, thank you.
As for the non-backpatchable 0002, I agree with Andres that it should be
included in 9.5; but I take it you're still not convinced? Should I add
that to
Hi,
I agree that splitting the patch into two separate ones is a good one.
On 2015-05-01 09:57:28 -0400, Robert Haas wrote:
> If you don't object to this version, I'll commit it. I believe this
> part *should* be back-patched, but Tom seemed to disagree, for reasons
> I'm not really clear on. T
On Fri, May 1, 2015 at 8:42 AM, Abhijit Menon-Sen wrote:
> At 2015-05-01 08:10:16 -0400, robertmh...@gmail.com wrote:
>> It seems to me that, at a minimum, it would be good to split those
>> controversial and definitely not-back-patchable changes into their
>> own patch.
>
> OK, split here (0002*)
At 2015-05-01 08:10:16 -0400, robertmh...@gmail.com wrote:
>
> It seems to me that, at a minimum, it would be good to split those
> controversial and definitely not-back-patchable changes into their
> own patch.
OK, split here (0002*).
> I do mind putting it into xlog.c instead of some place that
On Thu, Apr 30, 2015 at 11:29 PM, Abhijit Menon-Sen
wrote:
>> 2. I don't know why it's part of this patch.
>
> In 20150115133245.gg5...@awork2.anarazel.de, Andres explained his
> rationale as follows:
>
> «What I am thinking of is that, currently, if you start the server
> for initial loa
At 2015-04-30 16:56:17 -0700, t...@sss.pgh.pa.us wrote:
>
> As for the notion that this needs to be back-patched, I would say no.
Not even just the "fsync after crash" part? I could separate that out
from the control file changes and try to eliminate the duplication. I
think that would be worth ba
At 2015-04-30 15:37:44 -0400, robertmh...@gmail.com wrote:
>
> 1. It doesn't do that. As soon as we fsync the data directory, we
>reset the flag. That's not what "ever disabled" means to me.
Could you suggest an acceptable alternative wording? I can't immediately
think of anything better tha
Robert Haas writes:
> On Thu, Apr 30, 2015 at 6:44 PM, Alvaro Herrera
> wrote:
>> Ah, so that's not the duplicate code that I was remembering -- I think
>> it's walkdir() or something like that, which is in initdb IIRC.
> Yeah, walkdir() is there too. But if we're going to add that to the
> bac
On Thu, Apr 30, 2015 at 6:44 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Thu, Apr 30, 2015 at 6:18 PM, Alvaro Herrera
>> wrote:
>> >> Also, it seems awfully unfortunate to me that we're duplicating a
>> >> whole pile of code into xlog.c here. Maybe there's no way to avoid
>> >> the code
Robert Haas wrote:
> On Thu, Apr 30, 2015 at 6:18 PM, Alvaro Herrera
> wrote:
> >> Also, it seems awfully unfortunate to me that we're duplicating a
> >> whole pile of code into xlog.c here. Maybe there's no way to avoid
> >> the code duplication, but pre_sync_fname() seems like it'd more
> >> na
On Thu, Apr 30, 2015 at 6:18 PM, Alvaro Herrera
wrote:
>> Also, it seems awfully unfortunate to me that we're duplicating a
>> whole pile of code into xlog.c here. Maybe there's no way to avoid
>> the code duplication, but pre_sync_fname() seems like it'd more
>> naturally go in fd.c than here.
Robert Haas wrote:
> Also, it seems awfully unfortunate to me that we're duplicating a
> whole pile of code into xlog.c here. Maybe there's no way to avoid
> the code duplication, but pre_sync_fname() seems like it'd more
> naturally go in fd.c than here. I dunno where walkdir should go, but
> a
On Thu, Apr 16, 2015 at 9:24 AM, Abhijit Menon-Sen wrote:
> Here's a variation of the earlier patch that follows all links in
> PGDATA. Does this look more like what you had in mind?
I'm really confused by the additional control-file field. It is
documented as indicating whether fsync was ever d
Hi.
Here's a variation of the earlier patch that follows all links in
PGDATA. Does this look more like what you had in mind?
-- Abhijit
>From d86888b0d2f5a3a57027d26ce050a3bbb58670d3 Mon Sep 17 00:00:00 2001
From: Abhijit Menon-Sen
Date: Thu, 6 Nov 2014 00:45:56 +0530
Subject: Recursively fsync
At 2015-04-15 11:40:34 +0530, a...@2ndquadrant.com wrote:
>
> Still, thanks to the example in basebackup.c, I've got most of a patch
> that should follow any symlinks in PGDATA.
I notice that src/bin/pg_rewind/copy_fetch.c has a traverse_datadir()
function that does what we want (but it recurses i
At 2015-04-06 10:16:36 -0300, alvhe...@2ndquadrant.com wrote:
>
> Well, we have many things that can be set as symlinks; some you can
> have initdb create the links for you (initdb --xlogdir), others you
> can move manually.
Looking at sendDir() in backend/replication/basebackup.c, I notice that
t
Abhijit Menon-Sen wrote:
Hi,
> At 2015-04-03 13:32:32 -0300, alvhe...@2ndquadrant.com wrote:
> > I also noticed that walkdir() thinks it is completely agnostic on
> > what the passed action is; except that the comment at the bottom talks
> > about how fsync on directories is important, which see
Hi Álvaro.
Thanks for taking a look at the patch.
At 2015-04-03 13:32:32 -0300, alvhe...@2ndquadrant.com wrote:
>
> But then, since the name is already telling us that it's all about
> PGDATA, maybe we can remove the "recursively" part of the name?
Sure, that makes sense too. Since you and Andre
Abhijit Menon-Sen wrote:
> At 2015-01-15 14:32:45 +0100, and...@2ndquadrant.com wrote:
> Patch attached.
>
> Changes:
>
> 1. Renamed perform_fsync to fsync_recursively (otherwise it would read
>"fsync_pgdata(pg_data)")
Okay, but as far as I can tell this function is very specific to
PGDATA;
At 2015-01-15 14:32:45 +0100, and...@2ndquadrant.com wrote:
>
> What I am thinking of is that, currently, if you start the server for
> initial loading with fsync=off, and then restart it, you're open to
> data loss. So when the current config file setting is changed from off
> to on, we should fsy
On 2015-01-15 11:02:43 +0530, Abhijit Menon-Sen wrote:
> At 2015-01-14 11:59:08 +0100, and...@2ndquadrant.com wrote:
> >
> > > + if (ControlFile->state != DB_SHUTDOWNED &&
> > > + ControlFile->state != DB_SHUTDOWNED_IN_RECOVERY)
> > > + perform_fsync(data_directory);
> > > +
> >
>
At 2015-01-14 11:59:08 +0100, and...@2ndquadrant.com wrote:
>
> > + if (ControlFile->state != DB_SHUTDOWNED &&
> > + ControlFile->state != DB_SHUTDOWNED_IN_RECOVERY)
> > + perform_fsync(data_directory);
> > +
>
> a) Please think of a slightly more descriptive name than perfor
Hi,
On 2014-11-06 17:56:53 +0530, Abhijit Menon-Sen wrote:
> + /*
> + * If we need to perform crash recovery, we issue an fsync on the
> + * data directory and its contents to try to ensure that any data
> + * written before the crash are flushed to disk. Otherwise a power
> +
On 2014-10-30 14:30:28 +0530, Abhijit Menon-Sen wrote:
> Here's a proposed patch to initdb to make initdb -S fsync everything
> under pg_tblspc. It introduces a new function that calls walkdir on
> every entry under pg_tblspc. This is only one approach: I could have
> also changed walkdir to follow
At 2014-10-30 14:30:27 +0530, a...@2ndquadrant.com wrote:
>
> Here's a proposed patch to initdb to make initdb -S fsync everything
> under pg_tblspc.
Oops, I meant to include the corresponding patch to xlog.c to do the
same at startup. It's based on the initdb patch, but modified to not
use fprint
At 2014-09-29 11:54:10 +0200, and...@2ndquadrant.com wrote:
>
> On 2014-09-29 14:09:01 +0530, Abhijit Menon-Sen wrote:
> >
> > I just noticed that initdb -S ("Safely write all database files to disk
> > and exit") does (only) the following in perform_fsync:
> >
> > pre_sync_fname(pdir, true);
At 2014-09-29 12:59:09 +0200, and...@2ndquadrant.com wrote:
>
> So I'm afraid at least in a first patch it'll need to be a bit of
> duplication. Fixing initdb's code back to 9.3 and the backend all
> the way back to 9.0.
OK, thanks, I'll submit two separate patches then.
-- Abhijit
--
Sent via
On 2014-09-29 15:43:32 +0530, Abhijit Menon-Sen wrote:
> At 2014-09-29 11:54:10 +0200, and...@2ndquadrant.com wrote:
> >
> > Note that the perform_fsync() *was* ok for its original purpose in
> > initdb. At the end of initdb there's no relevant tablespaces. But if
> > used *after* pg_upgrade, that'
At 2014-09-29 11:54:10 +0200, and...@2ndquadrant.com wrote:
>
> Note that the perform_fsync() *was* ok for its original purpose in
> initdb. At the end of initdb there's no relevant tablespaces. But if
> used *after* pg_upgrade, that's not necessarily the case.
Right.
So, since I'm writing a func
On 2014-09-29 14:09:01 +0530, Abhijit Menon-Sen wrote:
> Hi.
>
> I just noticed that initdb -S ("Safely write all database files to disk
> and exit") does (only) the following in perform_fsync:
>
> pre_sync_fname(pdir, true);
> walkdir(pg_data, pre_sync_fname);
>
> fsync_fname(pdir,
Hi.
I just noticed that initdb -S ("Safely write all database files to disk
and exit") does (only) the following in perform_fsync:
pre_sync_fname(pdir, true);
walkdir(pg_data, pre_sync_fname);
fsync_fname(pdir, true);
walkdir(pg_data, fsync_fname);
walkdir() reads the directory
38 matches
Mail list logo
