On Mon, Jul 16, 2018 at 04:04:12PM -0400, Alvaro Herrera wrote:
> No objection here -- incremental progress is better than none.
Thanks. I have pushed 0001 now. I have found some more work which
could be done, for which I'll spawn a new thread.
--
Michael
signature.asc
Description: PGP signatu
On 2018-Jul-16, Michael Paquier wrote:
> On Sat, Jul 14, 2018 at 03:37:56PM +0900, Michael Paquier wrote:
> > For now, I think that just moving forward with 0001, and then revisit
> > 0002 once the other 2PC patch is settled makes the most sense. On the
> > other thread, the current 2PC behavior
On Sat, Jul 14, 2018 at 03:37:56PM +0900, Michael Paquier wrote:
> For now, I think that just moving forward with 0001, and then revisit
> 0002 once the other 2PC patch is settled makes the most sense. On the
> other thread, the current 2PC behavior can create silent data loss so
> I would like to
On Sat, Jul 14, 2018 at 12:50:02AM -0400, Alvaro Herrera wrote:
> I did read them, though not in minute detail. 0002 seems to result in
> code easier to read. If there are particular places that deviate from
> the obvious patterns, I didn't notice them.
>
> In 0001 one thing I wasn't terribly in
On 2018-Jul-14, Michael Paquier wrote:
> On Fri, Jul 13, 2018 at 11:31:31AM -0400, Alvaro Herrera wrote:
> >> Mr. Robot has been complaining about this patch set, so attached is a
> >> rebased version. Thinking about it, I would tend to just merge 0001 and
> >> give up on 0002 as that may not jus
On Fri, Jul 13, 2018 at 11:31:31AM -0400, Alvaro Herrera wrote:
>> Mr. Robot has been complaining about this patch set, so attached is a
>> rebased version. Thinking about it, I would tend to just merge 0001 and
>> give up on 0002 as that may not justify future backpatch pain. Thoughts
>> are wel
On 2018-Jul-13, Michael Paquier wrote:
> Mr. Robot has been complaining about this patch set, so attached is a
> rebased version. Thinking about it, I would tend to just merge 0001 and
> give up on 0002 as that may not justify future backpatch pain. Thoughts
> are welcome.
I vote to push both.
On Mon, Jun 25, 2018 at 04:18:18PM +0900, Michael Paquier wrote:
> As this one is done, I have been looking at that this thread again.
> Peter Eisentraut has pushed as e5d11b9 something which does not need to
> worry about pluralization of error messages. So I have moved to this
> message style fo
On Sat, Jun 23, 2018 at 08:48:03AM +0900, Michael Paquier wrote:
> That's exactly why I have started this thread so as both problems are
> addressed separately:
> https://www.postgresql.org/message-id/20180622061535.gd5...@paquier.xyz
> And back-patching the errno patch while only bothering about m
On Fri, Jun 22, 2018 at 09:51:30AM -0400, Alvaro Herrera wrote:
> On 2018-Jun-22, Robert Haas wrote:
>> I think this should be split into two patches. Fixing failure to save
>> and restore errno is a different issue from cleaning up short write
>> messages. I agree that the former should be back-
On 2018-Jun-22, Robert Haas wrote:
> I think this should be split into two patches. Fixing failure to save
> and restore errno is a different issue from cleaning up short write
> messages. I agree that the former should be back-patched and the
> latter not.
Hmm, yeah, good thought, +1.
--
Álv
On Thu, Jun 21, 2018 at 2:32 AM, Michael Paquier wrote:
> Sure. I have looked at that and I am finishing with the updated version
> attached.
>
> I removed the portion about slru in the code, but I would like to add at
> least a mention about it in the commit message. The simplifications are
> a
On Wed, Jun 20, 2018 at 02:52:23PM +0200, Magnus Hagander wrote:
> On Mon, Jun 18, 2018 at 6:42 AM, Michael Paquier
> wrote:
>> Okay, so this makes two votes in favor of keeping the messages simple
>> without context, shaped like "could not read file %s", with Robert and
>> Alvaro, and two votes f
On Mon, Jun 18, 2018 at 6:42 AM, Michael Paquier
wrote:
> On Thu, Jun 14, 2018 at 09:50:33AM -0400, Robert Haas wrote:
> > On Mon, Jun 11, 2018 at 6:11 PM, Alvaro Herrera
> > wrote:
> >> I would go as far as suggesting to remove qualifiers that indicate what
> >> the file is for (such as "relati
On Thu, Jun 14, 2018 at 09:50:33AM -0400, Robert Haas wrote:
> On Mon, Jun 11, 2018 at 6:11 PM, Alvaro Herrera
> wrote:
>> I would go as far as suggesting to remove qualifiers that indicate what
>> the file is for (such as "relation mapping file"); relying on the path
>> as indicator of what's goi
On Mon, Jun 11, 2018 at 6:11 PM, Alvaro Herrera
wrote:
> I would go as far as suggesting to remove qualifiers that indicate what
> the file is for (such as "relation mapping file"); relying on the path
> as indicator of what's going wrong should be sufficient, since it's an
> error that affects in
On Tue, Jun 12, 2018 at 01:19:54PM +0900, Michael Paquier wrote:
> Agreed. I also quite like the message mentioning directly 2PC files as
> well. I think that we could gain by making all end messages more
> consistent, as the markers used and the style of each message is
> slightly different, so
On Mon, Jun 11, 2018 at 03:17:15PM -0700, Andres Freund wrote:
> On 2018-06-11 18:11:05 -0400, Alvaro Herrera wrote:
>> As for the messages, I propose to make them more regular, i.e. always
>> use the wording "could not read from file "%s": read %d, expected %zu",
>> avoiding variations such as
>>
On 2018-06-11 18:11:05 -0400, Alvaro Herrera wrote:
> As for the messages, I propose to make them more regular, i.e. always
> use the wording "could not read from file "%s": read %d, expected %zu",
> avoiding variations such as
> not enough data in file \"%s\": %d read, %d expected"
>
On 2018-Jun-11, Robbie Harwood wrote:
> It might be less confusing to just set errno if it's not set already
> (e.g., to EIO, or something). Up to you though - this is a bit of a
> niche case.
I think that would be very confusing, if we receive a report that really
is a short read but looks like
Michael Paquier writes:
> diff --git a/src/backend/access/transam/slru.c
> b/src/backend/access/transam/slru.c
> index 87942b4cca..d487347cc6 100644
> --- a/src/backend/access/transam/slru.c
> +++ b/src/backend/access/transam/slru.c
> @@ -683,6 +683,11 @@ SlruPhysicalReadPage(SlruCtl ctl, int pa
On Fri, May 25, 2018 at 01:19:58PM +0900, Kyotaro HORIGUCHI wrote:
> The case is not of an empty file. read() reads 0 bytes without
> error while lseek have told that the file has *more* data. I
> don't think that can happen. How about just commenting with
> something like the following?
Actually
At Wed, 23 May 2018 09:00:40 +0900, Michael Paquier wrote
in <2018052340.ga3...@paquier.xyz>
> On Tue, May 22, 2018 at 04:51:00PM +0900, Kyotaro HORIGUCHI wrote:
> > I see the same issue in snapbuild.c(4 places).
> >
> > | readBytes = read(fd, &ondisk, SnapBuildOnDiskConstantSize);
> > | pgs
On Tue, May 22, 2018 at 04:51:00PM +0900, Kyotaro HORIGUCHI wrote:
> I see the same issue in snapbuild.c(4 places).
>
> | readBytes = read(fd, &ondisk, SnapBuildOnDiskConstantSize);
> | pgstat_report_wait_end();
> | if (readBytes != SnapBuildOnDiskConstantSize)
> | {
> | CloseTransientFile(fd);
Hello.
At Sun, 20 May 2018 09:05:22 +0900, Michael Paquier wrote
in <2018052522.gb1...@paquier.xyz>
> Hi all,
>
> This is basically a new thread after what has been discussed for
> pg_controldata with its error handling for read():
> https://www.postgresql.org/message-id/CABUevEx8ZRV5Ut_FvP
Hi all,
This is basically a new thread after what has been discussed for
pg_controldata with its error handling for read():
https://www.postgresql.org/message-id/CABUevEx8ZRV5Ut_FvP2etXiQppx3xVzm7oOaV3AcdHxX81Yt8Q%40mail.gmail.com
While reviewing the core code, I have noticed similar weird error
26 matches
Mail list logo
