s will need to turn fsync off
as of 11.2
On Tue, Feb 19, 2019 at 5:16 PM James Sewell wrote:
>> Here's a starter patch that shows one of the approaches discussed. It
>> gets WSL users to a better place than they were before, by suppressing
>> further warnings after the fir
>> > Great. Thanks for testing, and for the fix! Well that all sounds
>> > like good news: it corrects the behaviour from 11.2, and also improves
>> > on the previous behaviour which I'd have accepted as a bug if anyone
>> > had reported it. So the next problem is that we don't have a
>> > conse
Sounds good to me. Thank you!
On Fri, Feb 22, 2019 at 11:47 AM Thomas Munro
wrote:
> On Tue, Feb 19, 2019 at 5:31 PM Thomas Munro
> wrote:
> > On Tue, Feb 19, 2019 at 5:16 PM James Sewell
> wrote:
> > >> Here's a starter patch that shows one of the approaches discussed. It
> > >> gets WSL use
On Tue, Feb 19, 2019 at 5:31 PM Thomas Munro wrote:
> On Tue, Feb 19, 2019 at 5:16 PM James Sewell
> wrote:
> >> Here's a starter patch that shows one of the approaches discussed. It
> >> gets WSL users to a better place than they were before, by suppressing
> >> further warnings after the firs
On Tue, Feb 19, 2019 at 5:16 PM James Sewell wrote:
>> Here's a starter patch that shows one of the approaches discussed. It
>> gets WSL users to a better place than they were before, by suppressing
>> further warnings after the first one.
>
> This wasn't quite right, updated to check erro for EN
> Here's a starter patch that shows one of the approaches discussed. It
> gets WSL users to a better place than they were before, by suppressing
> further warnings after the first one.
>
This wasn't quite right, updated to check erro for ENOSYS (not rc)
This compiles and stops the panic on WSL (
> What do you mean by "not being included by #ifdef blocks"? The only
> guard in issue_xlog_fsync() is #ifdef HAVE_FDATASYNC, which ought to be
> independent of any includes? I can see how this'd go wrong if configure
> did *not* detect fdatasync, because then
>
And now this looks like it works a
Hi,
On 2019-02-19 11:50:36 +1100, James Sewell wrote:
> >
> > Right, the first step would be for a WSL user to figure out what's
> > wrong with builds on the WSL and show us how to fix it; I heard
> > through the grapevine that if you try it, initdb doesn't work (it must
> > be something pretty su
>
> Right, the first step would be for a WSL user to figure out what's
> wrong with builds on the WSL and show us how to fix it; I heard
> through the grapevine that if you try it, initdb doesn't work (it must
> be something pretty subtle in the configure phase or something like
> that, since the U
On Tue, Feb 19, 2019 at 6:01 AM Andres Freund wrote:
> On 2019-02-18 10:33:50 -0500, Ravi Krishna wrote:
> > Are there any plans to support PG on WSL ? Just curious.
Hi Ravi,
I definitely want to fix this particular issue for 11.3.
> I think if somebody wanted to start investing efforts to imp
On 2019-02-18 10:33:50 -0500, Ravi Krishna wrote:
> Are there any plans to support PG on WSL ? Just curious.
I think if somebody wanted to start investing efforts to improve testing
of that setup, and then fix the resulting issues, nobody would seriously
object. But also most people working on PG
Are there any plans to support PG on WSL ? Just curious.
On Mon, Feb 18, 2019 at 2:19 PM Michael Paquier wrote:
> On Sun, Feb 17, 2019 at 10:54:54AM -0800, Andres Freund wrote:
> > On 2019-02-17 23:29:09 +1300, Thomas Munro wrote:
> >> Hmm. Well, at least ENOSPC should be treated the same way as EIO.
> >> Here's an experiment that seems to confirm some
On Sun, Feb 17, 2019 at 10:54:54AM -0800, Andres Freund wrote:
> On 2019-02-17 23:29:09 +1300, Thomas Munro wrote:
>> Hmm. Well, at least ENOSPC should be treated the same way as EIO.
>> Here's an experiment that seems to confirm some speculations about NFS
>> on Linux from the earlier threads:
>
Hi,
On 2019-02-17 23:29:09 +1300, Thomas Munro wrote:
> Hmm. Well, at least ENOSPC should be treated the same way as EIO.
> Here's an experiment that seems to confirm some speculations about NFS
> on Linux from the earlier threads:
I wish we'd' a good way to have test scripts in the tree for som
If this one appears in the list, then it means the problem is with AOL.
On Sun, Feb 17, 2019 at 4:56 AM Tom Lane wrote:
> Thomas Munro writes:
> >>> Really? The specification says that it starts I/O, not that it waits
> >>> around for any to finish.
>
> > Right, there was some discussion of that, and I didn't (and still
> > don't) think it'd be wise to rely on undoc
Thomas Munro writes:
>>> Really? The specification says that it starts I/O, not that it waits
>>> around for any to finish.
> Right, there was some discussion of that, and I didn't (and still
> don't) think it'd be wise to rely on undocumented knowledge about
> which flags can eat errors based o
On Fri, Feb 15, 2019 at 1:34 AM Bruce Klein wrote:
>
> If you are running Postgres inside Microsoft WSL
>
https://docs.microsoft.com/en-us/windows/wsl/faq
Who is WSL for?
This is primarily a tool for developers ...
---
One problem with WSL is that the I/O performance is not
On 2/15/19 4:04 PM, Bruce Klein wrote:
[snip]
I'm glad Microsoft is trying though
If Steve "Linux is a cancer" Ballmer were dead, he's be spinning in his grave...
--
Angular momentum makes the world go 'round.
> I guess the OP is reporting about a .deb that was built on a real Linux
system
Yes, I (OP) installed via:
% wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc |
sudo apt-key add -
% sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/
$(lsb_release -sc)-pgdg main
On Sat, Feb 16, 2019 at 6:50 AM Andres Freund wrote:
> On February 15, 2019 9:44:50 AM PST, Tom Lane wrote:
> >Andres Freund writes:
> >> On February 15, 2019 9:13:10 AM PST, Tom Lane
> >wrote:
> >>> I'm of the opinion that we shouldn't be panicking for
> >sync_file_range
> >>> failure, period.
On February 15, 2019 9:44:50 AM PST, Tom Lane wrote:
>Andres Freund writes:
>> On February 15, 2019 9:13:10 AM PST, Tom Lane
>wrote:
>>> I'm of the opinion that we shouldn't be panicking for
>sync_file_range
>>> failure, period.
>
>> With some flags it's strictly required, it does"eat"errors
Andres Freund writes:
> On February 15, 2019 9:13:10 AM PST, Tom Lane wrote:
>> I'm of the opinion that we shouldn't be panicking for sync_file_range
>> failure, period.
> With some flags it's strictly required, it does"eat"errors depending on the
> flags. So I'm not sure I understand?
Really
On February 15, 2019 9:13:10 AM PST, Tom Lane wrote:
>Andres Freund writes:
>> I suspect that's because WSL has an empty implementation of
>> sync_file_range(), i.e. it unconditionally returns ENOSYS. But as
>> configure detects it, we still emit calls for it. I guess we ought
>to
>> except E
Andres Freund writes:
> I suspect that's because WSL has an empty implementation of
> sync_file_range(), i.e. it unconditionally returns ENOSYS. But as
> configure detects it, we still emit calls for it. I guess we ought to
> except ENOSYS for the cases where we do panic-on-fsync-failure?
I'm of
Hi,
On 2019-02-14 19:48:05 -0500, Tom Lane wrote:
> Bruce Klein writes:
> > If you are running Postgres inside Microsoft WSL (at least on Ubuntu, maybe
> > on others too), and just picked up a software update to version 11.2, you
> > will need to go into your /etc/postgresql.conf file and set fsy
On Fri, Feb 15, 2019 at 5:29 PM Tom Lane wrote:
> Thomas Munro writes:
> >> On Fri, Feb 15, 2019 at 2:56 PM Bruce Klein wrote:
> >>> In 11.1 did you see the message "WARNING: could not flush dirty data:
> >>> Function not implemented"
> >> Yes
>
> > Here is a place where people go to complain a
Thomas Munro writes:
>> On Fri, Feb 15, 2019 at 2:56 PM Bruce Klein wrote:
>>> In 11.1 did you see the message "WARNING: could not flush dirty data:
>>> Function not implemented"
>> Yes
> Here is a place where people go to complain about that:
> https://github.com/Microsoft/WSL/issues/645
> I s
On Fri, Feb 15, 2019 at 3:56 PM Thomas Munro
wrote:
> On Fri, Feb 15, 2019 at 2:56 PM Bruce Klein wrote:
> > > In 11.1 did you see the message "WARNING: could not flush dirty data:
> > > Function not implemented"
> > Yes
>
> I wonder if this is coming from sync_file_range(), which is not
> impl
On Fri, Feb 15, 2019 at 2:56 PM Bruce Klein wrote:
> > In 11.1 did you see the message "WARNING: could not flush dirty data:
> > Function not implemented"
> Yes
I wonder if this is coming from sync_file_range(), which is not
implemented on WSL according to random intergoogling, but probably
app
> In 11.1 did you see the message "WARNING: could not flush dirty data:
Function not implemented"
Yes
re: the discussions of O/S and filesystem in that thread:
I am not qualified to describe the implementation of WSL but I believe it
is neither pure Ubuntu running on metal, nor a virtual machine
Thanks Tom I feel like I'm in a little over my head here but I'll try to
help as I can.
With fsync off, everything appears to run as it did before on 11.1.
With fsync default/on, the problem is easily reproducible by trying to
create a database. I believe the very first time I saw it it was with
Bruce Klein writes:
> If you are running Postgres inside Microsoft WSL (at least on Ubuntu, maybe
> on others too), and just picked up a software update to version 11.2, you
> will need to go into your /etc/postgresql.conf file and set fsync=off.
Hm. Probably this is some unexpected problem with
Just in case this helps the next person who can't figure out why their
postgres server won't start today:
If you are running Postgres inside Microsoft WSL (at least on Ubuntu, maybe
on others too), and just picked up a software update to version 11.2, you
will need to go into your /etc/postgresql.
35 matches
Mail list logo
