Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Mon, Jan 18, 2016 at 5:01 AM, Dean Rasheed wrote: > On 30 November 2015 at 14:11, Tom Lane wrote: >> FWIW, I think that probably the best course of action is to go ahead >> and install POSIX-compliant error checking in the existing functions >>

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

On Thu, Jan 7, 2016 at 5:36 PM, Kyotaro HORIGUCHI wrote: > Finally, PsqlScanState has four callback funcions and all pgbench > needs to do to use it is setting NULL to all of them and link the > object file in psql directory. No link switch/ifdef are necessary.

Re: [HACKERS] jsonb array-style subscription

On Mon, Jan 18, 2016 at 9:32 PM, Dmitry Dolgov <9erthali...@gmail.com> wrote: > I've cleaned up the code, created a separate JsonbRef node (and there are a > lot of small changes because of that), abandoned an idea of "deep nesting" > of assignments (because it doesn't relate to jsonb

Re: [HACKERS] silent data loss with ext4 / all current versions

On Tue, Jan 19, 2016 at 3:58 PM, Tomas Vondra wrote: > > > On 01/19/2016 07:44 AM, Michael Paquier wrote: >> >> On Wed, Dec 2, 2015 at 3:24 PM, Michael Paquier >> wrote: >>> >>> On Wed, Dec 2, 2015 at 3:23 PM, Michael Paquier >>>

Re: [HACKERS] silent data loss with ext4 / all current versions

On 01/19/2016 08:03 AM, Michael Paquier wrote: On Tue, Jan 19, 2016 at 3:58 PM, Tomas Vondra wrote: ... Tomas, I am planning to have a look at that, because it seems to be important. In case it becomes lost on my radar, do you mind if I add it to the 2016-03

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Mon, Jan 18, 2016 at 11:56 AM, Alvaro Herrera wrote: >> That's because I believe this is quite broken, as already pointed out. > > I think I like your approach better. That makes things far simpler, then. >> Your premise here is that what Heikki said in passing

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

> diff --git a/src/pl/plpgsql/src/pl_comp.c b/src/pl/plpgsql/src/pl_comp.c > new file mode 100644 > index 1ae4bb7..c819517 > *** a/src/pl/plpgsql/src/pl_comp.c > --- b/src/pl/plpgsql/src/pl_comp.c > *** plpgsql_parse_tripword(char *word1, char > *** 1617,1622 > --- 1617,1677

Re: [HACKERS] exposing pg_controldata and pg_config as functions

* Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Jan 18, 2016 at 4:43 AM, Andres Freund wrote: > > Meh, that seems pretty far into pseudo security arguments. > > Yeah, I really don't see anything in the pg_controldata output that > looks sensitive. The WAL locations

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

On Mon, Jan 18, 2016 at 2:14 PM, Kevin Grittner wrote: >> You get just as much churn by changing code elsewhere, which >> often causes code movement and alignment changes. > > It's hard to understand quite what you're saying there. If you're > saying that code changes that

Re: [HACKERS] system mingw not recognized

It looks like the docs are indeed wrong. According to http://sourceforge.net/p/mingw-w64/wiki2/TypeTriplets/ it should be x86_64-w64-mingw32 So in summary, the docs at http://www.postgresql.org/docs/current/static/installation-platform-notes.html#INSTALLATION-NOTES-MINGW should be updated

Re: [HACKERS] Cannot find a working 64-bit integer type

On Mon, Jan 18, 2016 at 2:42 PM, Igal @ Lucee.org wrote: > It looks like Tom is correct. > > I added the directory tree to an exclude list of Microsoft Security > Essentials and > ran `configure` without any flags and it completed successfully this time. Cool. Man, Windows

Re: [HACKERS] system mingw not recognized

On 01/18/2016 04:11 PM, Igal @ Lucee.org wrote: I posted the error in the docs to pgsql-d...@postgresql.org If it's possible to update it myself via git, or if it should be reported elsewhere -- please advise. 1. Please don't top-post on the PostgreSQL lists. See

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 01/18/2016 01:47 PM, Bruce Momjian wrote: > On Sun, Jan 17, 2016 at 02:24:46PM -0800, Joe Conway wrote: >> On 01/16/2016 06:02 AM, Michael Paquier wrote: >>> On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway wrote: 1) Change NextXID output format from "%u/%u" to "%u:%u"

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Mon, Jan 18, 2016 at 4:43 AM, Andres Freund wrote: > On 2016-01-18 10:18:34 +0900, Michael Paquier wrote: >> We are trying to hide away from non-superusers WAL-related information >> in system views and system function, that's my point to do the same >> here. > > We are?

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

On Mon, Jan 18, 2016 at 3:47 PM, Andres Freund wrote: > On January 18, 2016 10:42:42 PM GMT+01:00, Kevin Grittner > wrote: >> I took a look at this and agree that the shorter, simpler code >> proposed in this patch should make no *logical* difference, and

[HACKERS] Re: [JDBC] 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

Robert Haas wrote: > This isn't the first complaint about this mechanism that we've gotten, > and it won't be the last. Way too many of our users are way more > aware than they should be that the threshold here is five rather than > any other number, which to me is a clear-cut sign that this

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

On 2016-01-18 16:56:22 -0600, Kevin Grittner wrote: > On Mon, Jan 18, 2016 at 4:50 PM, Andres Freund wrote: > > > Now I'm equally unconvinced that it's worthwhile to do anything > > here. I just don't think benchmarking plays a role either way. > > Well, that would be the

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

On Mon, Jan 18, 2016 at 3:04 PM, Andres Freund wrote: > On January 18, 2016 7:27:59 PM GMT+01:00, Robert Haas > wrote: >> On Sun, Jan 17, 2016 at 6:38 AM, Andreas Seltenreich >> wrote: >>> While discussing issues with its

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On January 18, 2016 11:10:35 PM GMT+01:00, Stephen Frost wrote: >* Robert Haas (robertmh...@gmail.com) wrote: >> On Mon, Jan 18, 2016 at 4:43 AM, Andres Freund >wrote: >> > Meh, that seems pretty far into pseudo security arguments. >> >> Yeah, I really

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

FWIW the reason I read through this patch is that I wondered if there was anything in common with this other patch https://commitfest.postgresql.org/8/459/ -- and the answer seems to be "no". What that patch does is add a new construct TYPE(1+1) which in this case returns "int4"; I guess if we

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

On Mon, Jan 18, 2016 at 02:14:11PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > I never understood why we don't just keep the selectivity estimates of > > previous plans and just reuse the plan if the selectivity estimates are > > similar. Isn't parameter selectivity the

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

On January 18, 2016 7:27:59 PM GMT+01:00, Robert Haas wrote: >On Sun, Jan 17, 2016 at 6:38 AM, Andreas Seltenreich > wrote: >> I'm currently experimenting with just-in-time compilation using >libfirm. >> While discussing issues with its developers, it

Re: [HACKERS] system mingw not recognized

I posted the error in the docs to pgsql-d...@postgresql.org If it's possible to update it myself via git, or if it should be reported elsewhere -- please advise. On 1/18/2016 12:59 PM, Igal @ Lucee.org wrote: It looks like the docs are indeed wrong. According to

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

On Wed, Jan 13, 2016 at 10:47 AM, Tom Lane wrote: > Vladimir Sitnikov writes: >> Note: I state that mixing "kinds" of bind values is a bad application >> design anyway. In other words, application developer should understand >> if a query is

[HACKERS] Re: pglogical_output - a general purpose logical decoding output plugin

I just quickly went through patch v5. It's rather big patch, on (or beyond) my knowledge of PostgreSQL to perform high-quality review. But during this week I'll try to send reviews of parts of the code, as going through it in one sitting seems impossible. One proposed change - update copyright

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On Mon, Jan 18, 2016 at 4:35 PM, Pavel Stehule wrote: >> I know that Oracle uses syntax of this general type, but I've always >> found it ugly. It's also pretty non-extensible. You could want >> similar things for range types and any other container types we might >>

[HACKERS] Random inconsistencies in GiST support function declarations

I was idly trying to improve the just-added index AM amvalidate() functions by having them verify the expected signatures (argument and result types) of opclass support functions. opr_sanity currently does this for btree, hash, and spgist functions, but not for other cases; it'd be useful IMO if

Re: [HACKERS] jsonb - jsonb operators

On 1/15/16, Glyn Astill wrote: > Hi all, > > I was just looking through the new jsonb operators in the 9.5 release, and > was wondering if there's any future intention to add a delete operator that > removes element/pair matches? I.e. some sort of top-level "jsonb -

Re: [HACKERS] Removing service-related code in pg_ctl for Cygwin

On 01/18/2016 12:38 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: I think we can be a bit more adventurous and remove all the Cygwin-specific code. See attached patch, which builds fine on buildfarm cockatiel. Hopefully you also tested that it builds under MSVC :-) Why would I? This

[HACKERS] source files without copyright notices

I never noticed before, but today I came across a header file without any copyright notice at all. Turns out there are quite a few: grep -riL Copyright src/* --include=*.c --include=*.h Shouldn't at least some of these get a copyright? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On Mon, Jan 18, 2016 at 3:51 PM, Alvaro Herrera wrote: > BTW are we all agreed that enabling > foo%ARRAYTYPE > and > foo%ELEMENTYPE > in plpgsql's DECLARE section is what we want for this? I know that Oracle uses syntax of this general type, but I've always found it

Re: [HACKERS] Removing service-related code in pg_ctl for Cygwin

On 01/18/2016 03:46 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: On 01/18/2016 12:38 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: I think we can be a bit more adventurous and remove all the Cygwin-specific code. See attached patch, which builds fine on buildfarm cockatiel.

Re: [HACKERS] Buildfarm server move

Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Andrew Dunstan writes: > > Tomorrow, January 18th, at 4.00 pm US East Coast time (UT - 5.0) we will > > be moving the buildfarm server from its current home at CommandPrompt, > > Um, this message is postmarked 18 Jan

Re: [HACKERS] Buildfarm server move

On 01/18/2016 05:20 PM, Andrew Dunstan wrote: People, Apologies for the late notice. Tomorrow, January 18th, at 4.00 pm US East Coast time (UT - 5.0) we will be moving the buildfarm server from its current home at CommandPrompt, where we have been ever since we started, to a machine that

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

On Mon, Jan 18, 2016 at 2:26 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Jan 15, 2016 at 2:16 PM, Tom Lane wrote: >>> Presumably the hope would be that VACUUM would truncate off some of the >>> heap, else there's not much

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

2016-01-18 22:21 GMT+01:00 Robert Haas : > On Mon, Jan 18, 2016 at 3:51 PM, Alvaro Herrera > wrote: > > BTW are we all agreed that enabling > > foo%ARRAYTYPE > > and > > foo%ELEMENTYPE > > in plpgsql's DECLARE section is what we want for this?

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

Robert Haas writes: > This isn't the first complaint about this mechanism that we've gotten, > and it won't be the last. Way too many of our users are way more > aware than they should be that the threshold here is five rather than > any other number, which to me is a

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

On Mon, Jan 18, 2016 at 4:24 PM, Peter Geoghegan wrote: > On Mon, Jan 18, 2016 at 2:14 PM, Kevin Grittner wrote: >> It's hard to understand quite what you're saying there. If you're >> saying that code changes that should be performance neutral can >>

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

On 2016-01-18 16:14:05 -0600, Kevin Grittner wrote: > Unconvinced that we should do performance testing on a proposed > performance patch before accepting it I'm unconvinced that it makes sense to view this as a performance patch. And unconvinced that you can sanely measure it. The lock prefix is

Re: [HACKERS] Interesting read on SCM upending software and hardware architecture

On Mon, Jan 18, 2016 at 1:44 AM, David Fetter wrote: > On Sun, Jan 17, 2016 at 11:13:33PM -0500, Bruce Momjian wrote: >> On Thu, Jan 7, 2016 at 02:30:06PM -0600, Jim Nasby wrote: >> > https://queue.acm.org/detail.cfm?id=2874238 discusses how modern >> > Storage Class Memory

Re: [HACKERS] Interesting read on SCM upending software and hardware architecture

On Mon, Jan 18, 2016 at 12:31 PM, Robert Haas wrote: > People keep predicting the death of spinning media, but I think > it's not happening to anywhere near as fast as that people think. > Yes, I'm writing this on a laptop with an SSD, and my personal laptop > also has an

Re: [HACKERS] Removing service-related code in pg_ctl for Cygwin

Andrew Dunstan wrote: > > > On 01/18/2016 12:38 PM, Alvaro Herrera wrote: > >Andrew Dunstan wrote: > > > >>I think we can be a bit more adventurous and remove all the Cygwin-specific > >>code. See attached patch, which builds fine on buildfarm cockatiel. > >Hopefully you also tested that it

[HACKERS] system mingw not recognized

Per the docs at http://www.postgresql.org/docs/current/static/installation-platform-notes.html#INSTALLATION-NOTES-MINGW "To build 64 bit binaries using MinGW ... and run configure with the --host=x86_64-w64-mingw option" But when I try to run: $ ~/sources/postgresql-9.5.0/configure

Re: [HACKERS] Tsvector editing functions

So, Tomas, Teodor, did you like this new version of the patch? Stas Kelvich wrote: > > 7) Some of the functions use intexterm that does not match the function > > name. I see two such cases - to_tsvector and setweight. Is there a > > reason for that? > > Because sgml compiler wants unique

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Sun, Jan 17, 2016 at 02:24:46PM -0800, Joe Conway wrote: > On 01/16/2016 06:02 AM, Michael Paquier wrote: > > On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway wrote: > >> 1) Change NextXID output format from "%u/%u" to "%u:%u" > >>(see recent hackers thread) > > > > !

Re: [HACKERS] pglogical_output - a general purpose logical decoding output plugin

W dniu 07.01.2016, czw o godzinie 15∶50 +0800, użytkownik Craig Ringer napisał: > On 7 January 2016 at 01:17, Peter Eisentraut wrote: > > On 12/22/15 4:55 AM, Craig Ringer wrote: > > > I'm a touch frustrated by that, as a large part of the point of > > > submitting the output

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

On January 18, 2016 10:42:42 PM GMT+01:00, Kevin Grittner wrote: >On Mon, Jan 18, 2016 at 3:04 PM, Andres Freund >wrote: >> On January 18, 2016 7:27:59 PM GMT+01:00, Robert Haas > wrote: >>> On Sun, Jan 17, 2016 at 6:38 AM, Andreas

[HACKERS] Buildfarm server move

People, Apologies for the late notice. Tomorrow, January 18th, at 4.00 pm US East Coast time (UT - 5.0) we will be moving the buildfarm server from its current home at CommandPrompt, where we have been ever since we started, to a machine that is part of the standard core infrastructure. In

Re: [HACKERS] Buildfarm server move

Andrew Dunstan writes: > Tomorrow, January 18th, at 4.00 pm US East Coast time (UT - 5.0) we will > be moving the buildfarm server from its current home at CommandPrompt, Um, this message is postmarked 18 Jan 17:20, an hour later than the stated move time. Did you mean

<    1   2