Re: [HACKERS] dealing with extension dependencies that aren't quite 'e'

On 15 January 2016 at 14:26, Abhijit Menon-Sen wrote: > * «DROP EXTENSION ext» won't work without adding CASCADE, which is an > (admittedly relatively minor) inconvenience to users. > > * More importantly, pg_dump will dump all those trigger definitions, > which is inappropriate in this case

Re: [HACKERS] Do we need SQL-level access to amoptions functions?

On 18 January 2016 at 04:13, Tom Lane wrote: > > Does anyone know of client code that's actually doing this? > > site:github.com "ginoptions" -"pg_am.h" -"ginutil.c" -png -typedefs -vim and the same for "btreeoptions" looks promising. Nothing seems to spring out on https://searchcode.com either

Re: [HACKERS] Sequence Access Method WIP

On 1 January 2016 at 07:51, Petr Jelinek wrote: > > Other than that, this is based on the new am api by Alexander Korotkov > [1]. It extends it by adding another column called amkind to the pg_am > which can have either value "i" for index or "S" for sequence (same as > relkind in pg_class for th

Re: [HACKERS] Sequence Access Method WIP

Needs rework after the commit of https://commitfest.postgresql.org/8/336/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] extend pgbench expressions with functions

The basic operator functions also do not check for integer overflows. This is a feature. I think that they should not check for overflow, as in C, this is just int64_t arithmetic "as is". (int64_t is not an available type on Windows btw.) Possibly. I really meant "64 bits signed integers",

Re: [HACKERS] extend pgbench expressions with functions

OK, so I had an extra look at this patch and I am marking it as ready for committer. Ok. - INT64_MIN / -1 throws a core dump, and errors on HEAD. I think this should be fixed, Fabien does not. Yep. Another point about this one is that it is not related to this patch about functions. --

Re: [HACKERS] Death by regexp_replace

thanks On Fri, Jan 15, 2016 at 7:22 PM, Devrim Gündüz wrote: > Hi, > > That is the version of *repo* RPM, not PostgreSQL itself.Once you install > it, you can grab the latest version with > > yum install postgresql92-server > > Regards, Devrim > > On January 15, 2016 7:48:53 PM GMT+02:00, Robert

Re: [HACKERS] Optimizer questions

Le 18/01/2016 03:47, Bruce Momjian a écrit : > On Tue, Jan 5, 2016 at 05:55:28PM +0300, konstantin knizhnik wrote: >> Hi hackers, >> >> I want to ask two questions about PostgreSQL optimizer. >> I have the following query: >> >> SELECT o.id as id,s.id as sid,o.owner,o.creator,o.parent_id >> as di

Re: [HACKERS] exposing pg_controldata and pg_config as functions

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? pg_current_xlog_insert_location(), pg_current_xlog_location(), pg_is_xlog_replay_pause

Re: [HACKERS] More stable query plans via more predictable column statistics

On Wed, Dec 2, 2015 at 10:20 AM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Tue, Dec 1, 2015 at 7:00 PM, Tom Lane wrote: > >> "Shulgin, Oleksandr" writes: >> > This post summarizes a few weeks of research of ANALYZE statistics >> > distribution on one of our bigger production

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

Hi All, PFA patches for postgres_fdw join pushdown, taken care of all TODOs in my last mail. Here is the list of things that have been improved/added new as compared to Hanada-san's previous patch at [1]. 1. Condition handling for join Patch in [1] allowed a foreign join to be pushed down if only

Re: [HACKERS] Combining Aggregates

On 18 January 2016 at 16:44, Robert Haas wrote: > On Sun, Jan 17, 2016 at 9:26 PM, David Rowley > wrote: > > hmm, so wouldn't that mean that the transition function would need to > (for > > each input tuple): > > > > 1. Parse that StringInfo into tokens. > > 2. Create a new aggregate state objec

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On 18 January 2016 at 10:46, Ashutosh Bapat wrote: > Hi All, > PFA patches for postgres_fdw join pushdown, taken care of all TODOs in my > last mail. > > Here is the list of things that have been improved/added new as compared to > Hanada-san's previous patch at [1]. > > 1. Condition handling for

[HACKERS] Trivial fixes for some IDENTIFICATION comment lines

Hello, I've noticed that in src/backend/replication/logical/reorderbuffer.c, the IDENTIFICATION comment line is incorrect: * IDENTIFICATION * src/backend/replication/reorderbuffer.c By using a simple find+grep command I can see this is also the case for the following files: $ find src -name

Re: [HACKERS] Trivial fixes for some IDENTIFICATION comment lines

On 2016-01-18 12:52:06 +0100, Shulgin, Oleksandr wrote: > I've noticed that in src/backend/replication/logical/reorderbuffer.c, the > IDENTIFICATION comment line is incorrect: > > * IDENTIFICATION > - * src/backend/catalog/dropcmds.c > - * src/backend/replication/logicalfuncs.c > - *

[HACKERS] jsonb array-style subscription

Hi, Here is a reworked version of patch for jsonb subscription. There weren't many changes in functionality: =# create TEMP TABLE test_jsonb_subscript ( id int, test_json jsonb ); =# insert into test_jsonb_subscript values (1, '{}'), (2, '{}'); =# update test_jsonb_subscript set t

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Mon, Jan 18, 2016 at 10:54 AM, Michael Paquier wrote: > > On Sun, Jan 17, 2016 at 1:37 PM, Amit Kapila wrote: > > On Sat, Jan 16, 2016 at 6:37 PM, Michael Paquier < michael.paqu...@gmail.com> > > wrote: > >> > >> > >> > > > > So here if I understand correctly the check related to the last segm

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On 2015-12-21 16:26:25 +0900, Michael Paquier wrote: > On Sun, Dec 20, 2015 at 10:14 PM, Michael Paquier > wrote: > > Speaking of which, this patch was registered in this CF, I am moving > > it to the next as a bug fix. > > I found a stupid bug in my previous patch: when issuing XLOG_SWITCH it >

Re: [HACKERS] Combining Aggregates

On Mon, Jan 18, 2016 at 10:32 PM, David Rowley wrote: > On 18 January 2016 at 16:44, Robert Haas wrote: >> >> On Sun, Jan 17, 2016 at 9:26 PM, David Rowley >> wrote: >> > hmm, so wouldn't that mean that the transition function would need to >> > (for >> > each input tuple): >> > >> > 1. Parse th

[HACKERS] Expanded Objects and Order By

I'm starting to think this might not actually be my mistake, but be a very narrow issue w/ the expanded object code. So, I've added support for converting postgis in-memory objects into expanded outputs, and have overwritten the usual lwgeom_to_gserialized() function with one that creates an expan

Re: [HACKERS] Combining Aggregates

On Mon, Jan 18, 2016 at 6:32 AM, David Rowley wrote: >> In my tests, this seems to be slightly slower than what we're doing >> today; worst of all, it adds a handful of cycles to >> advance_transition_function() even when the aggregate is not an >> expanded object or, indeed, not even pass-by-refe

Re: [HACKERS] [PATCH] better systemd integration

Peter Eisentraut wrote: > I have written a couple of patches to improve the integration of the > postgres daemon with systemd. Great. Is anything happening with these patches, or? They've been inactive for quite a while now. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreS

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

Amit Kapila wrote: > The reason for not updating the patch related to this thread is that it is > dependent on the work for refactoring the tranches for LWLocks [1] > which is now coming towards an end, so I think it is quite reasonable > that the patch can be updated for this work during commit f

Re: [HACKERS] statistics for array types

Alexander Korotkov wrote: > The patch implementing my idea above is attached. What's the status here? Jeff, did you have a look at Alexander's version of your patch? Tomas, does this patch satisfy your concerns? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Developme

Re: [HACKERS] Optimizer questions

I am sorry for badly formatted query - I just cut&paste it from C++ client program. I have one more question to community regarding this patch. Proposed patch fix the problem particularly for SORT+LIMIT clauses. In this case evaluation of expressions which are not used in sort is alway waste of

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

Peter Geoghegan wrote: > On Fri, Dec 18, 2015 at 12:55 PM, Robert Haas wrote: > > I only see one patch version on the thread. > > I'm not going to post a revision until I thrash out the tiny issues > with Heikki. He kind of trailed off. So maybe that kills it > immediately, which is a shame. If

Re: [HACKERS] Expanded Objects and Order By

Paul Ramsey writes: > So, I've added support for converting postgis in-memory objects into > expanded outputs, and have overwritten the usual > lwgeom_to_gserialized() function with one that creates an expanded > object. I haven't done anything to actually handle expanded objects on > input, but a

Re: [HACKERS] checkpointer continuous flushing

On 2016-01-16 10:01:25 +0100, Fabien COELHO wrote: > > Hello Andres, > > >I measured it in a different number of cases, both on SSDs and spinning > >rust. I just reproduced it with: > > > >postgres-ckpt14 \ > > -D /srv/temp/pgdev-dev-800/ \ > > -c maintenance_work_mem=2GB \ > >

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Jan 18, 2016 at 1:20 PM, Michael Paquier wrote: > On Sun, Jan 17, 2016 at 11:09 PM, Masahiko Sawada > wrote: >> On Wed, Jan 13, 2016 at 1:54 AM, Alvaro Herrera wrote: >> * Confirm value of pg_stat_replication.sync_state (sync, async or potential) >> * Confirm that the data is synchronous

Re: [HACKERS] jsonb - jsonb operators

Dmitry Dolgov <9erthali...@gmail.com> writes: >> if there's any future intention to add a delete operator that removes > element/pair matches? > I think the operator (jsonb - jsonb) is logical because we have a shallow > concatenation function (something like a "union" operation), but we have > no

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 3 January 2016 at 13:26, Masahiko Sawada wrote: > On Fri, Dec 25, 2015 at 7:21 AM, Thomas Munro > wrote: >> On Fri, Dec 25, 2015 at 8:50 AM, Masahiko Sawada >> wrote: >>> On Wed, Dec 23, 2015 at 8:45 AM, Thomas Munro >>> wrote: On Wed, Dec 23, 2015 at 3:50 PM, Thomas Munro wrote:

Re: [HACKERS] Trivial fixes for some IDENTIFICATION comment lines

Andres Freund writes: > On 2016-01-18 12:52:06 +0100, Shulgin, Oleksandr wrote: >> I've noticed that in src/backend/replication/logical/reorderbuffer.c, the >> IDENTIFICATION comment line is incorrect: >> >> * IDENTIFICATION >> - *src/backend/catalog/dropcmds.c >> - *src/backend/replicati

Re: [HACKERS] Combining Aggregates

> > > # explain analyze select a%100,length(string_agg(b,',')) from ab > group > > by 1; > > QUERY PLAN > > > --- > >

Re: [HACKERS] Combining Aggregates

Robert Haas writes: > Yeah. The API contract for an expanded object took me quite a while > to puzzle out, but it seems to be this: if somebody hands you an R/W > pointer to an expanded object, you're entitled to assume that you can > "take over" that object and mutate it however you like. But t

Re: [HACKERS] Trivial fixes for some IDENTIFICATION comment lines

On Mon, Jan 18, 2016 at 12:01 PM, Tom Lane wrote: > Andres Freund writes: >> On 2016-01-18 12:52:06 +0100, Shulgin, Oleksandr wrote: >>> I've noticed that in src/backend/replication/logical/reorderbuffer.c, the >>> IDENTIFICATION comment line is incorrect: >>> >>> * IDENTIFICATION >>> - *src/

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

On 01/14/2016 12:38 AM, Michael Paquier wrote: Hi all, Beginning a new thread seems more adapted regarding $subject but that's mentioned here as well: http://www.postgresql.org/message-id/CAB7nPqQXghm_SdB5iniupz1atzMxk=95gv9a8ocdo83sxcn...@mail.gmail.com It happens based on some investigation

Re: [HACKERS] Combining Aggregates

On Mon, Jan 18, 2016 at 12:09 PM, Tom Lane wrote: > Robert Haas writes: >> Yeah. The API contract for an expanded object took me quite a while >> to puzzle out, but it seems to be this: if somebody hands you an R/W >> pointer to an expanded object, you're entitled to assume that you can >> "take

Re: [HACKERS] 2016-01 Commitfest

Two weeks into the commitfest, things have moved a bit: Needs review: 53. Waiting on Author: 20. Ready for Committer: 10. Committed: 16. Total: 99. https://commitfest.postgresql.org/8/ We have two committed patches since last report -- not a lot for a whole week. We've managed t

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Mon, Jan 18, 2016 at 11:09 AM, Alvaro Herrera wrote: > Amit Kapila wrote: > >> The reason for not updating the patch related to this thread is that it is >> dependent on the work for refactoring the tranches for LWLocks [1] >> which is now coming towards an end, so I think it is quite reasonabl

Re: [HACKERS] 2016-01 Commitfest

On Mon, Jan 18, 2016 at 11:05 PM, Alvaro Herrera wrote: > Two weeks into the commitfest, things have moved a bit: > > Needs review: 53. > Waiting on Author: 20. > Ready for Committer: 10. > Committed: 16. > Total: 99. https://commitfest.postgresql.org/8/ > > We have two committed

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

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 :-) -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreS

Re: [HACKERS] proposal: add 'waiting for replication' to pg_stat_activity.state

Andres Freund wrote: > On December 4, 2015 9:48:55 AM GMT+01:00, Craig Ringer > wrote: > >On 3 December 2015 at 22:58, Amit Kapila > >wrote: > > > >> On Thu, Dec 3, 2015 at 9:02 AM, Craig Ringer > >> wrote: > > >http://www.postgresql.org/message-id/CAA4eK1+=5Ex8-5NRr3u94=_t2p65v0kcjZ5rXddVmkx=

Re: [HACKERS] Expanded Objects and Order By

I have a size/flatten callback setup (and they are very careful not to write outside their boundaries), so that’s all OK. Since you’re not seeing anything “aha” in the error pattern, I’ll go back to the mats on memory… is there a good page on valgriding postgresql? I thought the memory manager

Re: [HACKERS] Making plpython 2 and 3 coexist a bit better

On Mon, Jan 11, 2016 at 10:44:42AM -0500, Tom Lane wrote: > Commit 803716013dc1350f installed a safeguard against loading plpython2 > and plpython3 at the same time, stating > > + It is not allowed to use PL/Python based on Python 2 and PL/Python > + based on Python 3 in the same session, beca

Re: [HACKERS] [Proposal] Table partition + join pushdown

On Tue, Dec 22, 2015 at 8:36 AM, Michael Paquier wrote: > On Fri, Nov 20, 2015 at 9:05 PM, Taiki Kondo wrote: >> I created v3 patch for this feature, and v1 patch for regression tests. >> Please find attached. >> >> [blah review and replies] >> >> Please find from attached patch. > > This new pat

Re: [HACKERS] Additional role attributes && superuser review

On Sun, Jan 17, 2016 at 6:58 PM, Stephen Frost wrote: > I'm not against that idea, though I continue to feel that there are > common sets of privileges which backup tools could leverage. > > The other issue that I'm running into, again, while considering how to > move back to ACL-based permissions

Re: [HACKERS] Making plpython 2 and 3 coexist a bit better

Bruce Momjian writes: > On Mon, Jan 11, 2016 at 10:44:42AM -0500, Tom Lane wrote: >> But it gets worse: a report today in pgsql-general points out that >> even if you have the two languages in use *in different databases*, >> pg_upgrade will fail, because pg_upgrade rather overenthusiastically >>

Re: [HACKERS] Expanded Objects and Order By

Paul Ramsey writes: > Since you’re not seeing anything “aha” in the error pattern, I’ll go > back to the mats on memory… is there a good page on valgriding postgresql? https://wiki.postgresql.org/wiki/Valgrind > I thought the memory manager papered over things so much that valgrind >

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

On Fri, Jan 15, 2016 at 2:16 PM, Tom Lane wrote: > Robert Haas writes: >> Now, I do think it's a somewhat fair complaint that if you have a >> tablespace which is totally, 100% full, recovery is difficult. You >> can probably DROP the table, but TRUNCATE might fail, and so might >> VACUUM. You

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

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 was pointed out to me > that our spinlock inline assembly is less than optimal. Attached is a > patch that addre

Re: [HACKERS] Proposal: speeding up GIN build with parallel workers

On Fri, Jan 15, 2016 at 5:38 PM, Constantin S. Pan wrote: > In current state the implementation is just a proof of concept > and it has all the configuration hardcoded, but it already works as is, > though it does not speed up the build process more than 4 times on my > configuration (12 CPUs). Th

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

On Sun, Jan 17, 2016 at 5:45 PM, Igal @ Lucee.org wrote: > UPDATE: when I ran: configure --without-zlib --enable-debug > CFLAGS="-Wno-cpp" > > I did not get an error from configure (though I get an error from "make" but > that's another issue) > > I'm not sure what I'm "losing" by passing the "no-

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:18AM -0500, 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 DWH-like (requires replans) or OLTP-like (doe

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

Robert Haas writes: > The relevant portion of config.log seems to be this: > configure:13285: gcc -o conftest.exe -Wall -Wmissing-prototypes > -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels > -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing > -fwrapv -fexcess-precis

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

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 only thing that distinguishes > on plan with parameter from another? > Checking sele

Re: [HACKERS] jsonb - jsonb operators

On Mon, 18/1/16, Tom Lane wrote: Subject: Re: [HACKERS] jsonb - jsonb operators To: "Dmitry Dolgov" <9erthali...@gmail.com> Cc: "Glyn Astill" , "Merlin Moncure" , "pgsql-hackers@postgresql.org" Date: Monday, 18 January, 2016, 16:50 Dmitry Do

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

On 1/18/2016 11:09 AM, Tom Lane wrote: Robert Haas writes: The relevant portion of config.log seems to be this: I do not think configure pays attention to mere warnings for this type of test. The real problem here seems to be the "permission denied" errors, which to me reek of broken Windows

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

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 good that's going to happen. That leaves >> me wondering exactly what the invariant is for the maps, and if it's >> oka

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

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. Thank you both for your time and expertise, Igal On 1/18/2016 11:23 AM, Igal @ Lucee.org wrote: On 1/1

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

On Mon, Jan 18, 2016 at 8:36 AM, Alvaro Herrera wrote: > If you refuse to post an updated version of the patch until Heikki > weighs in some more, and given that Heikki has (for the purposes of this > patch) completely vanished, I think we should mark this rejected. I don't refuse. I just don't w

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

Peter Geoghegan wrote: > On Mon, Jan 18, 2016 at 8:36 AM, Alvaro Herrera > wrote: > > If you refuse to post an updated version of the patch until Heikki > > weighs in some more, and given that Heikki has (for the purposes of this > > patch) completely vanished, I think we should mark this rejected

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 months ago is >> incontrovertib

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 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 (SCM), such as PCIe SS

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] 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 build

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 SSD, but their immediate

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

[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 --host=x86

[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] 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 from

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 only thing that dis

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 was pointed out to me >> that our spinlock in

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 good that's going to happen. That leaves >>> me wondering exactl

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 anti-virus software is

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 http://sourceforge.net/p/min

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 ugly. It's also pretty no

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 in

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. Hopefully

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] 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 DWH-like (requires replans) or OLTP-like (does not >> r

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? > > I know that Oracle uses syntax of this genera

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 developers, it was pointed out to me >>> that our spinlock inline assem

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 clear-cut sign that this nee

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) > > > > ! printf(_("Latest check

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 plugin separately and

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 Seltenreich > wrote: > While discussing issues with its dev

[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 t

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 >> get in the future, but clear

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? pg_current_xlog_insert_

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" (see recent hacke

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 are the closest of anyt

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 >> looks like it *should* have a neutra

[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 do

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 should be performance n

[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 w

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 the move will be Tue 19

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 >> sometimes affect performance because of ali

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 don't see anything in the pg_controldata o

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 17:20, an hour later than

  1   2   >