[HACKERS] Compiler warning in pg_am changes

Hi, I've attached a small patch to fix new compiler warning which is new as of 65c5fcd3 -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services amcostestimate_cast.patch Description: Binary data -- Sent via pgsql-hackers

Re: [HACKERS] extend pgbench expressions with functions

On Mon, Jan 18, 2016 at 10:07 AM, Michael Paquier wrote: > On Sun, Jan 17, 2016 at 3:10 AM, Fabien COELHO wrote: >> I put the function evaluation in a function in the attached version. > > Thanks, this makes the code a bit clearer. OK, so I had an

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

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 synchronously replicated to multiple > standbys in

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

On Sun, Jan 17, 2016 at 1:37 PM, Amit Kapila wrote: > On Sat, Jan 16, 2016 at 6:37 PM, Michael Paquier > wrote: >> >> On Sat, Jan 16, 2016 at 9:07 PM, Amit Kapila >> wrote: >> > On Sat, Jan 16, 2016 at 5:08 PM, Michael

Re: [HACKERS] Limit and inherited tables

On Fri, Jan 15, 2016 at 9:47 PM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > This example is lacking indexes on the child tables, which is >> why the plan shown is about as good as you're going to get. >> The contents of foo1 and foo2 have to be read in entirety in any >> case,

Re: [HACKERS] PGCon 2016 call for papers

Sorry ^^ 2016-01-18 (월), 16:10 +0900, Michael Paquier: > On Mon, Jan 18, 2016 at 3:29 PM, Ioseph Kim wrote: > > What can I do for next step? > > (pgsql-hackers is not the right place to ask that, it is a mailing > list dedicated to the development and discussion of new

Re: [HACKERS] Compiler warning in pg_am changes

David Rowley writes: > I've attached a small patch to fix new compiler warning which is new as of > 65c5fcd3 Pushed, thanks. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] make error - libpqdll.def No such file or directory

p.s. -- On 1/17/2016 3:24 PM, Igal @ Lucee.org wrote: When running make I encounter the following error: gcc.exe: error: libpqdll.def: No such file or directory /home/Admin/sources/postgresql-9.5.0/src/Makefile.shlib:393: recipe for target 'libpq.dll' failed make[3]: *** [libpq.dll] Error 1

Re: [HACKERS] PGCon 2016 call for papers

On Mon, Jan 18, 2016 at 3:29 PM, Ioseph Kim wrote: > What can I do for next step? (pgsql-hackers is not the right place to ask that, it is a mailing list dedicated to the development and discussion of new features) Follow the flow here:

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

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 SSD and NVDIMMs are > completely upending every assumption made about storage. To put this > in perspective, you can now see

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

At 2016-01-16 12:18:53 -0500, robertmh...@gmail.com wrote: > > This seems like one manifestation of the more general problem that we > don't have any real idea what objects a function definition depends > on. Yes. I'm proposing to address a part of that problem by allowing extension dependencies

Re: [HACKERS] WIP: Rework access method interface

On Sat, Jan 16, 2016 at 12:32 PM, Tom Lane wrote: > Then we're going to end up with option A; and I suspect that we'll never > bother with factoring out any common code, because it won't be worth the > notational trouble if it involves common code that's in a different file >

Re: [HACKERS] pglogical - logical replication contrib module

On 17 January 2016 at 14:46, leo wrote: > I also run into same problem and waiting for bug fix. > please update if new patch has published. > > There's a point release coming soon that'll incorporate these fixes and a number of others. It'll be posted here in a few days.

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

On Thu, Dec 31, 2015 at 10:47 AM, Haribabu Kommi wrote: > On Wed, Dec 30, 2015 at 9:48 PM, Shulgin, Oleksandr > wrote: >> On Wed, Dec 30, 2015 at 4:31 AM, Haribabu Kommi >> wrote: >>> >>> >>> Adding quotes to

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

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 SSD and NVDIMMs are > > completely upending every assumption

Re: [HACKERS] Combining Aggregates

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 object. > 3. Populate the new aggregate

Re: [HACKERS] jsonb - jsonb operators

> 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 nothing like "set difference" and "intersection"

Re: [HACKERS] PGCon 2016 call for papers

Hello, I want to speak a proposal on PGCon 2016. Currently I wrote only title of contents. Main title is "PostgreSQL in Korea". That proposal contains * Short history of PostgreSQL in Korea (status of korean user group and theses works) * kt (korea telecom) report (for

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

On Wed, Jan 6, 2016 at 12:29:14PM -0500, Robert Haas wrote: > The point is that with the GRANT EXECUTE ON FUNCTION proposal, authors > of monitoring tools enjoy various really noteworthy advantages. They > can have monitoring roles which have *exactly* the privileges that > their tool needs, not

Re: [HACKERS] ToDo list update for BRIN indexes

On Mon, Dec 21, 2015 at 07:54:43AM -0500, Robert Haas wrote: > On Thu, Jul 9, 2015 at 4:49 PM, Jeff Janes wrote: > > Is there anything in the below section which has been been implemented or > > rendered irrelevant by BRIN indexes? > > > >

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

On Fri, Jan 15, 2016 at 11:16 AM, Tom Lane wrote: > I believe that there would be ramifications for some of the index AMs > too. For example, if left to its own devices GIN would consider VACUUM > to include flushing its pending-list pages, which more than likely will >

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

On Fri, Jan 15, 2016 at 3:29 PM, Peter Geoghegan wrote: > On Fri, Jan 15, 2016 at 2:38 PM, Constantin S. Pan wrote: >> I have a draft implementation which divides the whole process between >> N parallel workers, see the patch attached. Instead of a full scan of

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

There is some text in indexam.sgml currently that says [ index AMs' amoptions functions ] should be correctly declared as taking text[] and bool and returning bytea. This provision allows client code to execute amoptions to test validity of options settings. In the pending AM

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

On Sun, Jan 17, 2016 at 12:03 PM, Jeff Janes wrote: > I think it would take a lot of changes to tuple sort to make this be a > almost-always win. > > In the general case each GIN key occurs in many tuples, and the > in-memory rbtree is good at compressing the tid list for

Re: [HACKERS]WIP: Covering + unique indexes.

On 14 January 2016 at 08:24, David Rowley wrote: > I will try to review the omit_opclass_4.0.patch soon. > Hi, as promised, here's my review of the omit_opclass_4.0.patch patch. The following comment needs to be updated: * indexkeys[], indexcollations[],

Re: [HACKERS] exposing pg_controldata and pg_config as functions

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 checkpoint's NextXID: %u/%u\n"), >

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

* Bruce Momjian (br...@momjian.us) wrote: > On Mon, Jan 4, 2016 at 12:55:16PM -0500, Stephen Frost wrote: > > I'd like to be able to include, in both of those, a simple set of > > instructions for granting the necessary rights to the user who is > > running those processes. A set of rights which

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

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-cpp" compiler flag? also, the thread I mentioned in the previous

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

* Bruce Momjian (br...@momjian.us) wrote: > On Sun, Jan 17, 2016 at 01:49:19PM -0500, Stephen Frost wrote: > > * Bruce Momjian (br...@momjian.us) wrote: > > > > pgbackrest: > > > > > > > > To run pgbackrest as a non-superuser and not the 'postgres' system > > > > user, grant the pg_backup

Re: [HACKERS] Proposal: Trigonometric functions in degrees

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 > too. POSIX:2008 is quite clear about this: > > : An application wishing to check for

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

On Mon, Jan 4, 2016 at 12:55:16PM -0500, Stephen Frost wrote: > I'd like to be able to include, in both of those, a simple set of > instructions for granting the necessary rights to the user who is > running those processes. A set of rights which an administrator can go > look up and easily read

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

On Fri, 15 Jan 2016 15:29:51 -0800 Peter Geoghegan wrote: > On Fri, Jan 15, 2016 at 2:38 PM, Constantin S. Pan > wrote: > Even without parallelism, wouldn't it be better if GIN indexes were > built using tuplesort? I know way way less about the gin am than the

Re: [HACKERS] dblink: add polymorphic functions.

On 01/08/2016 07:31 AM, Tom Lane wrote: > Alvaro Herrera writes: >> So, is this going anywhere? > > Oh, sorry, was I on the hook to review that? > > [ quick look... ] This doesn't seem like it responds to my criticism > above. I think what we want is that for every

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 01/16/2016 06:07 AM, Michael Paquier wrote: > On Sun, Dec 27, 2015 at 5:39 AM, Joe Conway wrote: >> First installment -- pg_config function/view as a separate patch, >> rebased to current master. > > Documentation would be good to have. I'm definitely happy to write the

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

On Sun, Jan 17, 2016 at 01:49:19PM -0500, Stephen Frost wrote: > * Bruce Momjian (br...@momjian.us) wrote: > > > pgbackrest: > > > > > > To run pgbackrest as a non-superuser and not the 'postgres' system > > > user, grant the pg_backup role to the backrest user and ensure the > > > backrest

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

Hi, I'm trying to build Postgres with GCC 5.3.0 on Windows (a-la MinGW-64) and when I ran "configure" I received the following error: "configure: error: Cannot find a working 64-bit integer type." The config.log file can be seen at

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Sun, Jan 17, 2016 at 8:48 AM, Andres Freund wrote: > On January 17, 2016 12:46:36 AM GMT+01:00, Michael Paquier > wrote: > , but we surely do not want to give away >>checkpoint and recovery information. > > Why is that? A lot of that information

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

On Sun, Jan 17, 2016 at 01:57:22PM -0500, Stephen Frost wrote: > Right, we also check in the backend on startup for certain permissions. > I don't recall offhand if that's forced to 700 or if we allow 750. > > > > I don't recall offhand if that means we'd have to make changes to allow > > > that,

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

On Sun, Jan 17, 2016 at 06:58:25PM -0500, 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

Re: [HACKERS] Combining Aggregates

On Sat, Jan 16, 2016 at 12:00 PM, David Rowley wrote: > On 16 January 2016 at 03:03, Robert Haas wrote: >> >> On Tue, Dec 29, 2015 at 7:39 PM, David Rowley >> wrote: >> >> No, the idea I had in mind was to allow

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 01/16/2016 06:02 AM, Michael Paquier wrote: > On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway wrote: >> 3) Adds new functions, more or less in line with previous discussions: >>* pg_checkpoint_state() >>* pg_controldata_state() >>* pg_recovery_state() >>*

[HACKERS] make error - libpqdll.def No such file or directory

When running make I encounter the following error: gcc.exe: error: libpqdll.def: No such file or directory /home/Admin/sources/postgresql-9.5.0/src/Makefile.shlib:393: recipe for target 'libpq.dll' failed make[3]: *** [libpq.dll] Error 1 make[3]: Leaving directory

Re: [HACKERS] WIP: Rework access method interface

Alexander Korotkov writes: > [ aminterface-13.patch ] I've committed this after some rather significant rework, not all of it cosmetic in nature. For example, the patch fell over under CLOBBER_CACHE_ALWAYS (planner failing to copy data out of relcache entries that

Re: [HACKERS] extend pgbench expressions with functions

On Sun, Jan 17, 2016 at 3:10 AM, Fabien COELHO wrote: >> With this example: >> \set cid debug(sqrt(-1)) >> I get that: >> debug(script=0,command=1): double nan >> An error would be more logical, no? > > > If "sqrt(-1)" as a double is Nan for the computer, I'm fine with that.

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

* Bruce Momjian (br...@momjian.us) wrote: > On Wed, Jan 6, 2016 at 12:29:14PM -0500, Robert Haas wrote: > > The point is that with the GRANT EXECUTE ON FUNCTION proposal, authors > > of monitoring tools enjoy various really noteworthy advantages. They > > can have monitoring roles which have

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

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Sun, Jan 17, 2016 at 01:57:22PM -0500, Stephen Frost wrote: > > Right, we also check in the backend on startup for certain permissions. > > I don't recall offhand if that's forced to 700 or if we allow 750. > > > > > > I don't recall offhand

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

* Bruce Momjian (br...@momjian.us) wrote: > On Sun, Jan 17, 2016 at 06:58:25PM -0500, 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,

Re: [HACKERS] pgsql: Further tweaking of print_aligned_vertical().

On Mon, Jan 4, 2016 at 01:18:02PM -0500, Tom Lane wrote: > Greg Stark writes: > > I used plenty of images I pulled off the net without regard for > > copyright so I hesitated to put it up. I suppose that's par for the > > course with these kinds of presentations. In any case it

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

On Sun, Jan 17, 2016 at 09:10:23PM -0500, Stephen Frost wrote: > > While the group owner of the directory is a distributions question, the > > permissions are usually a backup-method-specific requirement. I can see > > us creating an SQL function that opens up group permissions on the data > >

Re: [HACKERS] Combining Aggregates

On 18 January 2016 at 14:36, Haribabu Kommi wrote: > On Sat, Jan 16, 2016 at 12:00 PM, David Rowley > wrote: > > On 16 January 2016 at 03:03, Robert Haas wrote: > >> > >> On Tue, Dec 29, 2015 at 7:39 PM, David

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

On Sun, Jan 17, 2016 at 09:23:14PM -0500, Stephen Frost wrote: > > > Group ownership and permissions aren't a backup-method-specific > > > requirement either, in my view. I'm happy to chat with Marco (who has > > > said he would be weighing in on this thread when he is able to) > > > regarding

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

* Bruce Momjian (br...@momjian.us) wrote: > On Sun, Jan 17, 2016 at 09:23:14PM -0500, Stephen Frost wrote: > > > > Group ownership and permissions aren't a backup-method-specific > > > > requirement either, in my view. I'm happy to chat with Marco (who has > > > > said he would be weighing in on

Re: [HACKERS] Optimizer questions

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

Re: [HACKERS] Freeze avoidance of very large table.

On Wed, Jan 13, 2016 at 12:16 AM, Masahiko Sawada wrote: > On Mon, Dec 28, 2015 at 6:38 PM, Masahiko Sawada > wrote: >> On Mon, Dec 21, 2015 at 11:54 PM, Robert Haas wrote: >>> On Mon, Dec 21, 2015 at 3:27 AM, Kyotaro

[HACKERS] Log operating system user connecting via unix socket

Greetings, gentlemen. Here in my work, we have about 100 PostgreSQL machines and about 20 users with superuser privileges. This group of 20 people change constantly, so it's cumbersome create a role for each. Instead, we map all of then in pg_ident.conf. The problem is: with current postgres

Re: [HACKERS] Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?

Coming in late here, but I always thought the fact that the FPW happen mostly at the start of the checkpoint, and the checkpoint writes/fsyncs happen mostly in the first half of the checkpoint period was always suboptimal, i.e. it would be nice of one of these was more active in the second half

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

Hi, 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 addresses this. , | Remove the LOCK prefix from the XCHG

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

On Wed, Jan 13, 2016 at 1:54 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Fri, Jan 8, 2016 at 1:53 PM, Kyotaro HORIGUCHI >> wrote: >> > Hello, >> > >> > At Mon, 4 Jan 2016 15:29:34 +0900, Michael Paquier >> >

Re: [HACKERS] Log operating system user connecting via unix socket

José, * José Arthur Benetasso Villanova (jose.art...@gmail.com) wrote: > Here in my work, we have about 100 PostgreSQL machines and about 20 users > with superuser privileges. Sounds pretty common. What kind of superuser rights are they using? What is the minimum set of rights that are required

Re: [HACKERS] WIP: Rework access method interface

Amit Kapila writes: > Shouldn't we try to move amhandler function as well along with > amvalidate? I think moving each am's handler and validate into > am specific new file can make this arrangement closer to what > we have for PL's (ex. we have plpgsql_validator and

Re: [HACKERS] Log operating system user connecting via unix socket

Stephen Frost writes: > What I think we really want here is logging of the general 'system > user' for all auth methods instead of only for the 'peer' method. Well, we don't really know that except in a small subset of auth methods. I agree that when we do know it, it's

Re: [HACKERS] Log operating system user connecting via unix socket

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > What I think we really want here is logging of the general 'system > > user' for all auth methods instead of only for the 'peer' method. > > Well, we don't really know that except in a small subset of