On Mon, Oct 2, 2017 at 8:13 AM, Daniel Gustafsson wrote:
> I’ve moved this to the next CF, but since this no longer applies cleanly I’ve
> reset it to Waiting for author.
Thanks Daniel for the reminder. Attached are rebased patches. This
thing rots easily...
--
Michael
> On 02 Sep 2017, at 14:17, Michael Paquier wrote:
>
> On Fri, Sep 1, 2017 at 7:17 PM, Thomas Munro
> wrote:
>> On Sat, Aug 26, 2017 at 7:32 AM, Robert Haas wrote:
>>> On Sat, Apr 8, 2017 at 10:05 AM, David Steele
On Fri, Sep 1, 2017 at 7:17 PM, Thomas Munro
wrote:
> On Sat, Aug 26, 2017 at 7:32 AM, Robert Haas wrote:
>> On Sat, Apr 8, 2017 at 10:05 AM, David Steele wrote:
>>> On 3/28/17 1:21 AM, Tsunakawa, Takayuki wrote:
On Sat, Aug 26, 2017 at 7:32 AM, Robert Haas wrote:
> On Sat, Apr 8, 2017 at 10:05 AM, David Steele wrote:
>> On 3/28/17 1:21 AM, Tsunakawa, Takayuki wrote:
>>> Thanks, marked as ready for committer, as the code is good and Alexander
>>> reported the
On Sat, Apr 8, 2017 at 10:05 AM, David Steele wrote:
> On 3/28/17 1:21 AM, Tsunakawa, Takayuki wrote:
>> From: Michael Paquier [mailto:michael.paqu...@gmail.com]
>>> Okay. I got the message, and I agree with what you say here. You are right
>>> by the way, the error messages
On 3/28/17 1:21 AM, Tsunakawa, Takayuki wrote:
> From: Michael Paquier [mailto:michael.paqu...@gmail.com]
>> Okay. I got the message, and I agree with what you say here. You are right
>> by the way, the error messages just use "two-phase file" and not "two-phase
>> STATE file", missed that
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> Okay. I got the message, and I agree with what you say here. You are right
> by the way, the error messages just use "two-phase file" and not "two-phase
> STATE file", missed that previously.
> --
Thanks, marked as ready for committer, as
On Tue, Mar 28, 2017 at 1:33 PM, Tsunakawa, Takayuki
wrote:
> I get the impression that DATA_CORRUPTED means the table data is corrupted,
> because there's an error code named INDEX_CORRUPTED.
I have interpreted that as the other way around, aka DATA_CORRUPTED
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> While I agree with that in general, we are taking about 2PC files that are
> on disk in patch 0001, so I would think that in this case
> ERRCODE_DATA_CORRUPTED is the most adapted
On Mon, Mar 27, 2017 at 11:20 PM, Tom Lane wrote:
> Alexander Korotkov writes:
>> On Mon, Mar 27, 2017 at 4:48 PM, Tom Lane wrote:
>>> Actually, the *real* problem with that coding is it lacks a SQLSTATE
>>> (errcode call). The
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
> "Tsunakawa, Takayuki" writes:
> > All other places in twophase.c and most places in other files put ereport()
> and errmsg() on separate lines. I think
On Mon, Mar 27, 2017 at 11:26 AM, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: pgsql-hackers-ow...@postgresql.org
> > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> > Moved to CF 2017-03. Both patches still apply.
>
> Sorry to be late for
Alexander Korotkov writes:
> On Mon, Mar 27, 2017 at 4:48 PM, Tom Lane wrote:
>> Actually, the *real* problem with that coding is it lacks a SQLSTATE
>> (errcode call). The only places where it's acceptable to leave that
>> out are for internal
On Mon, Mar 27, 2017 at 4:48 PM, Tom Lane wrote:
> "Tsunakawa, Takayuki" writes:
> > All other places in twophase.c and most places in other files put
> ereport() and errmsg() on separate lines. I think it would be better to
> align with
"Tsunakawa, Takayuki" writes:
> All other places in twophase.c and most places in other files put ereport()
> and errmsg() on separate lines. I think it would be better to align with
> surrounding code.
> + ereport(FATAL,
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> Moved to CF 2017-03. Both patches still apply.
Sorry to be late for reviewing this, but done now. The patch applied, make
check passed, and the code looks almost good. I could
From: David Steele [mailto:da...@pgmasters.net]
> Any idea when you'll have a chance to review?
I'll do it by early next week.
Regards
Takayuki Tsunakawa
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 12/20/16 2:54 AM, Michael Paquier wrote:
> On Sat, Dec 17, 2016 at 9:23 PM, Magnus Hagander wrote:
>> On Fri, Dec 16, 2016 at 7:08 AM, Michael Paquier
>> wrote:
>>> Looking at PrescanPreparedTransactions(), I am thinking as well that it
>>>
On Tue, Dec 20, 2016 at 4:54 PM, Michael Paquier
wrote:
> I am attaching that to next CF.
Moved to CF 2017-03. Both patches still apply.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Sat, Dec 17, 2016 at 9:23 PM, Magnus Hagander wrote:
> On Fri, Dec 16, 2016 at 7:08 AM, Michael Paquier
> wrote:
>> Looking at PrescanPreparedTransactions(), I am thinking as well that it
>> would
>> be better to get a hard failure when bumping
On Fri, Dec 16, 2016 at 7:08 AM, Michael Paquier
wrote:
> On Thu, Dec 15, 2016 at 11:25:10AM +0200, Heikki Linnakangas wrote:
> > On 12/15/2016 10:44 AM, Magnus Hagander wrote:
> > > I wonder if there might be more corner cases like this, but in this
> > > particular
On Thu, Dec 15, 2016 at 11:25:10AM +0200, Heikki Linnakangas wrote:
> On 12/15/2016 10:44 AM, Magnus Hagander wrote:
> > I wonder if there might be more corner cases like this, but in this
> > particular one it seems easy enough to just say that failing to rename
> > recovery.conf because it
On 12/15/2016 10:44 AM, Magnus Hagander wrote:
I wonder if there might be more corner cases like this, but in this
particular one it seems easy enough to just say that failing to rename
recovery.conf because it didn't exist is safe.
Yeah. It's unexpected though, so I think erroring out is
I had a system where the recovery.conf file was renamed "out of the way" at
some point, and then the system was promoted. This is obviously operator
error, but it seems like something we should handle.
What happens now is that the non-existance of recovery.conf is a FATAL
error. I wonder if it
24 matches
Mail list logo