Re: [HACKERS] Function and view to retrieve WAL receiver status

On Fri, Jan 8, 2016 at 4:38 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Thu, Jan 7, 2016 at 1:57 PM, Haribabu Kommi >> wrote: >> > On Wed, Jan 6, 2016 at 8:00 PM, Michael Paquier >> > wrote: >> >> On

Re: [HACKERS] Re: [COMMITTERS] pgsql: Windows: Make pg_ctl reliably detect service status

Tom Lane wrote: > Alvaro Herrera writes: > > I confirmed that adding that line makes the new file get compiled. I > > also noticed these warnings when compiling it: > > > In file included from > > /usr/lib/gcc/x86_64-w64-mingw32/4.9-win32/include/stdarg.h:1:0, > >

Re: [HACKERS] Very confusing installcheck behavior with PGXS

On Jan 7, 2016, at 11:20 AM, Jim Nasby wrote: >>> Also worth noting: the only reason I'm using pg_regress is it's the easiest >>> way to get a test cluster. If not for that, I'd just use pg_prove since I'm >>> already using pgTap. >> >> In 9.5 you might want to "use

Re: [HACKERS] Very confusing installcheck behavior with PGXS

David E. Wheeler wrote: > On Jan 7, 2016, at 11:20 AM, Jim Nasby wrote: > > >>> Also worth noting: the only reason I'm using pg_regress is it's the > >>> easiest > >>> way to get a test cluster. If not for that, I'd just use pg_prove since > >>> I'm > >>> already

Re: [HACKERS] Proposal: Generic WAL logical messages

On 2016-01-07 17:22, Simon Riggs wrote: * You call them "logical messages" here, but standby messages in code. But they only apply to logical decoding, so "logical message" seems a better name. Can we avoid calling them "messages" cos that will get confusing. Yes it's slightly confusing, the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Windows: Make pg_ctl reliably detect service status

On Fri, Jan 8, 2016 at 8:38 AM, Alvaro Herrera wrote: > Tom Lane wrote: >> Alvaro Herrera writes: >> > I confirmed that adding that line makes the new file get compiled. I >> > also noticed these warnings when compiling it: >> >> > In file

[HACKERS] BEGINNER HACKERS: array_remove(anyarray, anyarray)

On 12/10/15 6:25 PM, Jim Nasby wrote: Recently I had need of removing occurrences of a number of values from an array. Obviously I could have nested array_remove() call or wrapped the whole thing in a SELECT unnest(), but that seems rather silly and inefficient. Any one have objections to

Re: [HACKERS] pg_conversion seems rather strangely defined

On Wed, Jan 06, 2016 at 11:56:14PM -0500, Tom Lane wrote: > Noah Misch writes: > > On Tue, Jan 05, 2016 at 01:46:51PM -0500, Tom Lane wrote: > >> I do not see a lot of point in the namespacing of encoding conversions > >> either. Does anyone really need or use

Re: [HACKERS] Relation extension scalability

On 2016-01-07 16:48:53 +0530, Amit Kapila wrote: > What I could understand from above e-mail is that Dilip has tried to > extend relation multiple-pages-at-a-time and observed that it gives > comparable or better performance as compare to Andres's idea of > lock-free extension and it doesn't

Re: [HACKERS] checkpointer continuous flushing

Hello, I read your patch and I know what I want to try to have a small and simple fix. I must admit that I have not really understood in which condition the checkpointer would decide to close a file, but that does not mean that the potential issue should not be addressed. There's a trivial

Re: [HACKERS] pglogical - logical replication contrib module

... and this is why we don't post while jetlagged and tired. The patch on the prior mail is the output plugin. Wrong thread, wrong filename. It's the output plugin update needed for the pglogical downstream in this thread. Corrected post of v5 output plugin here:

Re: [HACKERS] checkpointer continuous flushing

On 2016-01-07 11:27:13 +0100, Fabien COELHO wrote: > I read your patch and I know what I want to try to have a small and simple > fix. I must admit that I have not really understood in which condition the > checkpointer would decide to close a file, but that does not mean that the > potential

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

On Wed, Jan 6, 2016 at 3:02 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > > Please find attached a POC patch, using \errverbose for the command name. > Unfortunately, I didn't see a good way to contain the change in psql only > and had to change libpq, adding new interface

Re: [HACKERS] Add numeric_trim(numeric)

2016-01-07 8:12 GMT+01:00 Pavel Stehule : > > > 2016-01-07 1:11 GMT+01:00 Tom Lane : > >> Dean Rasheed writes: >> > On 6 January 2016 at 20:09, Robert Haas wrote: >> >> On Wed, Jan 6, 2016 at 10:21 AM,

Re: [HACKERS] Add numeric_trim(numeric)

On 6 January 2016 at 15:21, Dean Rasheed wrote: > Actually I found the implementation a little confusing, partly because > the first comment doesn't really match the line of code that follows > it, and partly because of the complexity of the loop, the macros and >

Re: [HACKERS] extend pgbench expressions with functions

Hello Michaël, Based on that all the final results of a \set command will have an integer format, still after going through this patch, allowing double as return type for nested function calls (first time "nested" is written on this thread) is actually really useful, and that's what makes

Re: [HACKERS] parallel joins, and better parallel explain

On Wed, Jan 6, 2016 at 10:29 PM, Robert Haas wrote: > On Mon, Jan 4, 2016 at 8:52 PM, Dilip Kumar wrote: > > One strange behaviour, after increasing number of processor for VM, > > max_parallel_degree=0; is also performing better. > > So, you went

Re: [HACKERS] Add numeric_trim(numeric)

On 7 January 2016 at 00:11, Tom Lane wrote: > A different approach is that I'm not real sure why we want a function > that returns a modified numeric value at all. To the extent I understood > Marko's original use case, it seems like what you'd invariably do with the > result

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

+1 to both the feature and the concept of how it's implemented. Haven't looked at the code though. This feature would be very useful for us at Trustly. This would mean we got get rid of an entire system component in our architecture (=memcached) which we only use to write data which must be

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On 2016/01/06 20:37, Thom Brown wrote: On 25 December 2015 at 10:00, Etsuro Fujita wrote: Attached is an updated version of the patch, which is still WIP, but I'd be happy if I could get any feedback. I've run into an issue: *# UPDATE master_customers SET id =

Re: [HACKERS] Proposal: Generic WAL logical messages

> Process-wise, I don't understand why is Andres mentioned as co-author. > Did he actually wrote part of the patch, or advised on the design? > Who is reviewing the patch? It's extracted & extended from BDR, where I added that feature (to implement distributed locking). -- Sent via

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On 2016/01/06 18:58, Rushabh Lathia wrote: I started looking at updated patch and its definitely iked the new approach. Thanks for the review! With the initial look and test overall things looking great, I am still reviewing the code changes but here are few early doubts/questions: .)

Re: [HACKERS] Improved tab completion for FDW DDL

Andreas Karlsson writes: > On 01/04/2016 01:09 AM, David Fetter wrote: >> On Wed, Dec 30, 2015 at 01:21:06PM +0100, Andreas Karlsson wrote: >>> Another completion which is currently missing but I am not sure if we should >>> add or not is completing "ALTER|CREATE|DROP USER"

Re: [HACKERS] Very confusing installcheck behavior with PGXS

On 1/7/16 8:47 AM, Tom Lane wrote: Jim Nasby writes: However, if I do this: mv test/sql/acl_type.sql test/sql/acl.sql mv test/expected/acl_type.out test/expected/acl.out And change acl_type to acl in that pg_regress command:

Re: [HACKERS] checkpointer continuous flushing

Hello Andres, I thought of adding a pointer to the current flush structure at the vfd level, so that on closing a file with a flush in progress the flush can be done and the structure properly cleaned up, hence later the checkpointer would see a clean thing and be able to skip it instead of

Re: [HACKERS] Very confusing installcheck behavior with PGXS

Jim Nasby writes: > On 1/7/16 8:47 AM, Tom Lane wrote: >> That's pretty hard to believe. There's nothing in pg_regress that looks >> in places other than the given --inputdir. > Actually, I think it does... from pg_regress_main.c: > /* >* Look for files

Re: [HACKERS] checkpointer continuous flushing

On 2016-01-07 16:05:32 +0100, Fabien COELHO wrote: > >But I'm inclined to go a different way: I think it's a mistake to do > >flusing based on a single file. It seems better to track a fixed number of > >outstanding 'block flushes', independent of the file. Whenever the number > >of outstanding

Re: [HACKERS] Proposal: BSD Authentication support

This sounds like a sensible thing to me. I'm actually surprised, it sounds like something we would have already seen. Do some people just use PAM on OpenBSD? Are both supported? You should add the patch to https://commitfest.postgresql.org to ensure it doesn't slip through the cracks. It's too

Re: [HACKERS] checkpointer continuous flushing

On 2016-01-07 13:07:33 +0100, Fabien COELHO wrote: > > >>Yes, I'm planning to try to do the minimum possible damage to the current > >>API to fix the issue. > > > >What's your thought there? Afaics it's infeasible to do the flushing tat > >the fd.c level. > > I thought of adding a pointer to the

Re: [HACKERS] Very confusing installcheck behavior with PGXS

On 1/6/16 11:54 AM, Tom Lane wrote: Robert Haas writes: On Sun, Jan 3, 2016 at 5:22 PM, Jim Nasby wrote: The rule that gets executed if you do `make installcheck` with something using PGXS is pgxs.mk:$(pg_regress_installcheck)

Re: [HACKERS] Very confusing installcheck behavior with PGXS

On 1/7/16 9:12 AM, Tom Lane wrote: Jim Nasby writes: On 1/7/16 8:47 AM, Tom Lane wrote: That's pretty hard to believe. There's nothing in pg_regress that looks in places other than the given --inputdir. Actually, I think it does... from pg_regress_main.c:

Re: [HACKERS] pg_conversion seems rather strangely defined

Tatsuo Ishii writes: >> It would only be important to be able to do it like that if different >> users of the same database had conflicting ideas about what was the >> correct conversion between client and database encodings. I submit >> that that's somewhere around epsilon

Re: [HACKERS] Proposal: BSD Authentication support

There's a port for PAM, but we would prefer to use BSD Auth as its quite a lot cleaner and is standard on OpenBSD. I've attached an updated patch that includes documentation. It has been tested against OpenBSD 5.8. I'll add this thread to the commitfest. On 07/01/16 23:26, Greg Stark wrote:

Re: [HACKERS] pg_conversion seems rather strangely defined

> It would only be important to be able to do it like that if different > users of the same database had conflicting ideas about what was the > correct conversion between client and database encodings. I submit > that that's somewhere around epsilon probability, considering we have > not even

Re: [HACKERS] Generalizing SortSupport for text to work with char(n), bytea, and alternative opclasses

Peter Geoghegan wrote: > We lack SortSupport for many character-like-type cases. In full, the > cases within the core system are: You're stealthily introducing a new abstraction called "string", including a typedef and DatumGetString support macros. Is that really necessary? Shouldn't it be

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

I didn't receive a response on the bugs mailing list for the following bug, so I was hoping we could triage to someone with more familiarity with Postgres internals than I to fix. This ticket seems like folks who are invested in logical decoding. The attached script is a simple workload that

Re: [HACKERS] Multi-tenancy with RLS

Joe Conway writes: > On 01/06/2016 12:15 PM, Robert Haas wrote: >> Is any committer thinking about taking a serious look at this patch series? >> >> I ask because (1) it seems like it could be nice to have but (2) it >> frightens me terribly. We are generally very sparing

Re: [HACKERS] Very confusing installcheck behavior with PGXS

Jim Nasby writes: > On 1/7/16 9:12 AM, Tom Lane wrote: >> (I'm also wondering how convert_sourcefiles() works at all in a vpath >> build, considering that I don't see it doing anything like this ...) > It's only looking at outputdir, which I suspect is never ambiguous.

Re: [HACKERS] Very confusing installcheck behavior with PGXS

On 1/7/16 9:56 AM, Tom Lane wrote: Jim Nasby writes: On 1/7/16 9:12 AM, Tom Lane wrote: (I'm also wondering how convert_sourcefiles() works at all in a vpath build, considering that I don't see it doing anything like this ...) It's only looking at outputdir, which

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 01/06/2016 04:18 PM, Greg Stark wrote: On Wed, Jan 6, 2016 at 11:42 PM, Jim Nasby wrote: Right. Personally, I feel the TODO has pretty much outlived it's usefulness. An issue tracker would make maintaining items like this a lot more reasonable, but it certainly

Re: [HACKERS] Multi-tenancy with RLS

On 01/06/2016 12:15 PM, Robert Haas wrote: > On Tue, Jan 5, 2016 at 11:07 PM, Haribabu Kommi > wrote: >> May be you missed to apply the 3_shared_catalog_tenancy_v4 path, >> because 4_database_catalog_tenancy_v5 patch depends on it. >> >> Here I attached all the patches

Re: [HACKERS] pg_conversion seems rather strangely defined

Noah Misch writes: > On Wed, Jan 06, 2016 at 11:56:14PM -0500, Tom Lane wrote: >> Moreover, we have precedent both for this approach being a bad idea >> and for us changing it without many complaints. We used to have >> search-path-dependent lookup of default index operator

Re: [HACKERS] Weighted Stats

On Mon, Dec 21, 2015 at 1:50 PM, David Fetter wrote: > On Sun, Dec 20, 2015 at 06:13:33PM -0600, Jim Nasby wrote: >> On 11/2/15 5:46 PM, David Fetter wrote: >> >I'd like to add weighted statistics to PostgreSQL >> >> Anything happen with this? If community isn't interested, ISTM

Re: [HACKERS] proposal: PL/Pythonu - function ereport

shellOn Thu, Dec 31, 2015 at 11:37 AM, Pavel Stehule wrote: > here is new version. And here's a new review, sorry for the delay. > Now I use a common ancestor "plpy.BaseError" for plpy builtin classes. So > plpy.SPIError isn't descendant of plpy.Error and then there are

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-08 7:31 GMT+01:00 Catalin Iacob : > shellOn Thu, Dec 31, 2015 at 11:37 AM, Pavel Stehule > wrote: > > here is new version. > > And here's a new review, sorry for the delay. > > > Now I use a common ancestor "plpy.BaseError" for plpy

[HACKERS] Duplicate 'use' for TestLib in 001_ssltests.pl

Hello, I noticed that 001_ssltests.pl uselessly (perhaps) imports TestLib twice. Is this intentional? The following change made no differences. diff --git a/src/test/ssl/t/001_ssltests.pl b/src/test/ssl/t/001_ssltests.pl index 9ce0cf3..cd38e45 100644 --- a/src/test/ssl/t/001_ssltests.pl +++

Re: [HACKERS] Duplicate 'use' for TestLib in 001_ssltests.pl

On Fri, Jan 8, 2016 at 8:37 AM, Michael Paquier wrote: > On Fri, Jan 8, 2016 at 4:16 PM, Kyotaro HORIGUCHI > wrote: > > Hello, I noticed that 001_ssltests.pl uselessly (perhaps) imports > > TestLib twice. Is this intentional? The

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

Hello, At Mon, 4 Jan 2016 15:29:34 +0900, Michael Paquier wrote in

[HACKERS] Comment typo in port/atomics/arch-x86.h

Hi, I found a typo in arch-x86.h. The attached patch fixes a typo: s/468/486/g Best regards, Tatsuro Yamada *** a/src/include/port/atomics/arch-x86.h --- b/src/include/port/atomics/arch-x86.h *** *** 67,73 typedef struct pg_atomic_uint32 /* * It's too complicated to

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

On Fri, Jan 8, 2016 at 1:53 PM, Kyotaro HORIGUCHI wrote: > Hello, > > At Mon, 4 Jan 2016 15:29:34 +0900, Michael Paquier > wrote in >

Re: [HACKERS] Bug in MergeAttributesIntoExisting() function.

>On Monday, 4 January 2016 8:24 PM, Tom Lane wrote: >Either way, however, the way you declared c2, it has an independent >local definition of all four columns, and so they should not go away >even if the parent's columns go away. This is exactly the purpose >that attislocal

Re: [HACKERS] Comment typo in port/atomics/arch-x86.h

On Fri, Jan 8, 2016 at 7:37 AM, Tatsuro Yamada wrote: > Hi, > > I found a typo in arch-x86.h. > The attached patch fixes a typo: s/468/486/g > > Applied, thanks. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Generalizing SortSupport for text to work with char(n), bytea, and alternative opclasses

On Thu, Jan 7, 2016 at 7:41 AM, Alvaro Herrera wrote: > You're stealthily introducing a new abstraction called "string", > including a typedef and DatumGetString support macros. Is that really > necessary? Shouldn't it be discussed specifically? I don't necessarily >

Odd behavior in foreign table modification (Was: Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW)

On 2016/01/07 21:50, Etsuro Fujita wrote: On 2016/01/06 20:37, Thom Brown wrote: On 25 December 2015 at 10:00, Etsuro Fujita wrote: Attached is an updated version of the patch, which is still WIP, but I'd be happy if I could get any feedback. I've run into an

Re: [HACKERS] Duplicate 'use' for TestLib in 001_ssltests.pl

On Fri, Jan 8, 2016 at 4:16 PM, Kyotaro HORIGUCHI wrote: > Hello, I noticed that 001_ssltests.pl uselessly (perhaps) imports > TestLib twice. Is this intentional? The following change made no > differences. > > > diff --git a/src/test/ssl/t/001_ssltests.pl

Re: [HACKERS] checkpointer continuous flushing

Hello Andres, One of the point of aggregating flushes is that the range flush call cost is significant, as shown by preliminary tests I did, probably up in the thread, so it makes sense to limit this cost, hence the aggregation. These removed some performation regression I had in some cases.

Re: [HACKERS] Re: [COMMITTERS] pgsql: Windows: Make pg_ctl reliably detect service status

Alvaro Herrera wrote: > Alvaro Herrera wrote: > > Windows: Make pg_ctl reliably detect service status > > > > pg_ctl is using isatty() to verify whether the process is running in a > > terminal, and if not it sends its output to Windows' Event Log ... which > > does the wrong thing when the

Re: [HACKERS] checkpointer continuous flushing

On 2016-01-07 21:08:10 +0100, Fabien COELHO wrote: > Hmmm. What I understood is that the workloads that have some performance > regressions (regressions that I have *not* seen in the many tests I ran) are > not due to checkpointer IOs, but rather in settings where most of the writes > is done by

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 1/7/16 1:49 PM, Josh Berkus wrote: Yeah, we could also get rid of this conversation: "Here's a patch for X, which is on the TODO list" "Oh, we've obsolesced that, that was added to the TODO before we had Y" ... by auto-closing TODO items at a certain age. Even if not auto-closed at least

Re: [HACKERS] Very confusing installcheck behavior with PGXS

Jim Nasby writes: > If we want to keep input/ and output/ inside pg_regress then I think > what needs to happen in a vpath build is to first create $vpath/sql and > $vpath/expected, copy anything from $(uh... source?)/sql and /expected > there, and then process /input

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Wed, Jan 6, 2016 at 4:18 PM, Greg Stark wrote: > On Wed, Jan 6, 2016 at 11:42 PM, Jim Nasby wrote: >> Right. Personally, I feel the TODO has pretty much outlived it's usefulness. >> An issue tracker would make maintaining items like this a lot more >>

Re: [HACKERS] Very confusing installcheck behavior with PGXS

Jim Nasby wrote: > Also worth noting: the only reason I'm using pg_regress is it's the easiest > way to get a test cluster. If not for that, I'd just use pg_prove since I'm > already using pgTap. In 9.5 you might want to "use PostgresNode" which allows you to initdb and such. -- Álvaro Herrera

Re: [HACKERS] Very confusing installcheck behavior with PGXS

On 1/7/16 1:04 PM, Alvaro Herrera wrote: Jim Nasby wrote: Also worth noting: the only reason I'm using pg_regress is it's the easiest way to get a test cluster. If not for that, I'd just use pg_prove since I'm already using pgTap. In 9.5 you might want to "use PostgresNode" which allows you

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 01/07/2016 10:30 AM, Jeff Janes wrote: > I don't completely agree with that. I have often wanted to know when > a specific item was added to the TODO page, and/or its individual edit > history. With only a unified history of the entire TODO page, and > with no wiki equivalent of "git blame",

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

On 2016-01-07 09:28:29 -0800, Jarred Ward wrote: > I didn't receive a response on the bugs mailing list for the following bug, > so I was hoping we could triage to someone with more familiarity with > Postgres internals than I to fix. Please don't post to unrelated threads, that just confuses

Re: [HACKERS] Very confusing installcheck behavior with PGXS

On 1/7/16 12:12 PM, Tom Lane wrote: I'm not really concerned about the current behavior of putting transformed input/output files into sql/ and expected/. Only experts are likely to be creating files requiring transformation at all (and even the experts prefer to avoid that, because they're a

Re: [HACKERS] Re: [COMMITTERS] pgsql: Windows: Make pg_ctl reliably detect service status

Alvaro Herrera wrote: > Alvaro Herrera wrote: > > Alvaro Herrera wrote: > > > Windows: Make pg_ctl reliably detect service status > > > > > > pg_ctl is using isatty() to verify whether the process is running in a > > > terminal, and if not it sends its output to Windows' Event Log ... which > > >

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 01/07/2016 12:32 PM, Jim Nasby wrote: On 1/7/16 1:49 PM, Josh Berkus wrote: Yeah, we could also get rid of this conversation: "Here's a patch for X, which is on the TODO list" "Oh, we've obsolesced that, that was added to the TODO before we had Y" ... by auto-closing TODO items at a

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

On 7 January 2016 at 06:36, Jeff Janes wrote: > On Tue, Jan 5, 2016 at 11:55 PM, David Rowley > wrote: > > create table ab (a int,b int); > > insert into ab select x,y from generate_series(1,20) x(x), > > generate_series(10,1,-1) y(y); > >

Re: [HACKERS] checkpointer continuous flushing

Hello Andres, Hmmm. What I understood is that the workloads that have some performance regressions (regressions that I have *not* seen in the many tests I ran) are not due to checkpointer IOs, but rather in settings where most of the writes is done by backends or bgwriter. As far as I can

Re: [HACKERS] Re: [COMMITTERS] pgsql: Windows: Make pg_ctl reliably detect service status

Alvaro Herrera writes: > I confirmed that adding that line makes the new file get compiled. I > also noticed these warnings when compiling it: > In file included from > /usr/lib/gcc/x86_64-w64-mingw32/4.9-win32/include/stdarg.h:1:0, > from