On Mon, May 21, 2018 at 4:36 PM, Tom Lane wrote:
> ... and, while we're thinking about this, how can we prevent the reverse
> problem of using strerror(errno) where you should have used %m? That
> is evidently not academic either, cf 81256cd.
>
> I am wondering whether the elog/ereport macros can
On Fri, May 11, 2018 at 12:27 AM, Robert Haas wrote:
> On Tue, Feb 27, 2018 at 2:21 AM, Masahiko Sawada
> wrote:
>> I might be missing your point. As for API breaking, this patch doesn't
>> break any existing FDWs. All new APIs I proposed are dedicated to 2PC.
>> In other words, FDWs that work t
On 18 May 2018 at 00:44, Andres Freund wrote:
> Hi,
>
> On 2018-05-10 09:50:03 +0800, Craig Ringer wrote:
> > while ((src = (RewriteMappingFile *) hash_seq_search(&seq_status))
> != NULL)
> > {
> > if (FileSync(src->vfd, WAIT_EVENT_LOGICAL_REWRITE_SYNC)
> != 0)
> > -
On Sat, May 19, 2018 at 6:31 AM, Stephen Frost wrote:
> Greetings,
>
> * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
>> At 2018-05-18 20:27:57 -0400, sfr...@snowman.net wrote:
>> >
>> > I don't agree with the general notion that we can't have a function
>> > which handles the complicated bits
On Sat, May 19, 2018 at 12:51 AM, Robert Haas wrote:
> On Thu, May 17, 2018 at 4:10 PM, Peter Eisentraut
> wrote:
>> I think I have made a mistake here. I was reading in between the lines
>> of a competitor's documentation that they have functions and procedures
>> in different name spaces, whic
... and, while we're thinking about this, how can we prevent the reverse
problem of using strerror(errno) where you should have used %m? That
is evidently not academic either, cf 81256cd.
I am wondering whether the elog/ereport macros can locally define some
version of "errno" that would cause a
Thomas Munro writes:
> I tried this on macOS and FreeBSD using GCC and Clang: both accept
> printf("%m") without warning and then just print out "m". It'll be
> interesting to see if the NetBSD patch/idea travels further or some
> other solution can be found. I've raised this on the freebsd-hack
On Mon, May 21, 2018 at 12:30 PM, Tom Lane wrote:
> For amusement's sake, I was playing around with NetBSD-current (9-to-be)
> today, and tried to compile Postgres on it. It works OK --- and I can
> even confirm that our new code for using ARM v8 CRC instructions works
Excellent news.
> there -
From: Masahiko Sawada [mailto:sawada.m...@gmail.com]
> Regarding to API design, should we use 2PC for a distributed
> transaction if both two or more 2PC-capable foreign servers and
> 2PC-non-capable foreign server are involved with it? Or should we end
> up with an error? the 2PC-non-capable serv
Hi all,
The kerberos test suite mentions the package list to use on a set of
distributions, which is very useful. However we don't do the same for
ldap. Something like the attached would be adapted then to help setting
up a test environment?
I have at hand only a Debian installation, and I have
On Tue, Apr 10, 2018 at 11:11 PM, David Steele wrote:
> On 4/10/18 6:14 AM, Masahiko Sawada wrote:
>> On Fri, Mar 30, 2018 at 5:37 AM, Fujii Masao wrote:
>>> On Wed, Jan 17, 2018 at 2:16 AM, Simon Riggs wrote:
On 16 January 2018 at 06:21, Michael Paquier
wrote:
> On Tue, Jan 16,
> "Stephen" == Stephen Frost writes:
Stephen> Just to be clear, based on what I saw on IRC, this
Stephen> specifically came out of someone complaining that it didn't
Stephen> work and caused difficulty for them.
Specifically, as I said at the start, it's from bug #15200, see
http://postgr
For amusement's sake, I was playing around with NetBSD-current (9-to-be)
today, and tried to compile Postgres on it. It works OK --- and I can
even confirm that our new code for using ARM v8 CRC instructions works
there --- but I got a boatload of compile warnings like this:
latch.c:1180:4: war
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> Whether or not Andrew's patch is formally classified as a bug fix is
> subjective. I'm inclined to accept it as a bug fix, but I also think
> that it shouldn't matter very much. The practical implication is that
> I don't think it's completely o
"David G. Johnston" writes:
> The risk here is significantly reduced since the existing user-visible
> behavior is an error which presumably no one is relying upon. Between that
> and being able to conform to the standard syntax for a long-standing
> feature I would say the benefit outweighs the
On Sun, May 20, 2018 at 1:13 PM, Peter Geoghegan wrote:
> There have been
> cases where we chose to not back-patch an unambiguous bug fix even
> though it was clear that incorrect user-visible behavior remained.
>
The risk here is significantly reduced since the existing user-visible
behavior i
On Sat, May 19, 2018 at 4:41 PM, Tom Lane wrote:
> It may be that this fix is simple and safe enough that the risk/reward
> tradeoff favors back-patching, but I think you have to argue it as a
> favorable tradeoff rather than just saying "this isn't per standard".
> Consider: if Andrew had complet
On Sun, May 20, 2018 at 01:39:27AM +0100, Andrew Gierth wrote:
> > "Tom" == Tom Lane writes:
>
> >> I'm +1 for backpatching it. It may be operating as designed by
> >> PeterE ten years ago, but it's not operating as designed by the SQL
> >> standard.
>
> Tom> By that argument, *anyplace*
On 20/05/18 05:25, Andrew Gierth wrote:
> +select_fetch_first_value:
> + c_expr
> { $$ = $1; }
> + | '+' I_or_F_const
> + { $$ = (Node *) makeSimpleA_Expr(AEXPR_OP,
On 20/05/18 01:41, Tom Lane wrote:
> Vik Fearing writes:
>> On 20/05/18 00:57, Tom Lane wrote:
>> I'm +1 for backpatching it. It may be operating as designed by PeterE
>> ten years ago, but it's not operating as designed by the SQL standard.
>
> By that argument, *anyplace* where we're missing a
20 matches
Mail list logo
