Re: [HACKERS] Why format() adds double quote?

> On Wed, Jan 20, 2016 at 4:20 AM, Pavel Stehule > wrote: >>> If we would go this way, question is if we should back patch this or >>> not since the patch apparently changes the existing >>> behaviors. Comments? I would think we should not. >> >> I am sure, so we should

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 23 January 2016 at 23:04, Tom Lane wrote: > Noah Misch writes: >> On Sat, Jan 23, 2016 at 05:04:56PM -0500, Tom Lane wrote: >>> Either I missed something or there's another issue, because tern/sungazer >>> are *still* failing. This is getting annoying

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Fri, 22 Jan 2016 16:36:15 -0300 Alvaro Herrera wrote: > You're editing the expected file for the libpq-regress thingy, but you > haven't added any new lines to test the new capability. I think it'd > be good to add some there. (I already said this earlier in the >

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

On Fri, Jan 22, 2016 at 7:19 AM, Anastasia Lubennikova wrote: > > Done. I hope that my patch is close to the commit too. > Thanks for the update. I've run into this problem: create table foobar (x text, w text); create unique index foobar_pkey on foobar (x)

Re: [HACKERS] Parallel Aggregate

On Sat, Jan 23, 2016 at 12:59 PM, Haribabu Kommi wrote: > > Here I attached updated patch with additional combine function for > two stage aggregates also. A wrong combine function was added in pg_aggregate.h in the earlier patch that leading to initdb problem.

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Mon, Jan 25, 2016 at 2:34 AM, Tom Lane wrote: > Perhaps we can fix this by rewriting as > > float8 numerator = 1.0 - cos(x * RADIANS_PER_DEGREE); > return 1.0 - (numerator / one_minus_cos_60) / 2.0; > > cockatiel's compiler does recognize

Re: [HACKERS] PoC: Partial sort

Hi, Tomas! On Sat, Jan 23, 2016 at 3:07 PM, Tomas Vondra wrote: > On 10/20/2015 01:17 PM, Alexander Korotkov wrote: > >> On Fri, Oct 16, 2015 at 7:11 PM, Alexander Korotkov >> > wrote: >> >> On Sun, Jun 7, 2015

Re: [HACKERS] PoC: Partial sort

Hi! On Sat, Jan 23, 2016 at 10:07 PM, Peter Geoghegan wrote: > On Sat, Jan 23, 2016 at 4:07 AM, Tomas Vondra > wrote: > > The main thing I'm particularly interested in is how much is this coupled > > with the Sort node, and whether it's possible

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

I'm merging all your emails for sake of easier discussion. I also cut all fragments that do not require response. W dniu 22.01.2016, pią o godzinie 11∶06 +0800, użytkownik Craig Ringer napisał: > > We might also think about changing name of plugin to something > > resembling

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

On Fri, Jan 22, 2016 at 3:44 PM, Aleksander Alekseev < a.aleks...@postgrespro.ru> wrote: > This patch affects header files. By any chance didn't you forget to run > `make clean` after applying it? As we discussed above, when you > change .h files autotools doesn't rebuild dependent .c files: >

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

> > > If it didn't respond to SIGINT, that would be an issue, but otherwise > this doesn't seem much more exciting than any other way to create a > query that will run longer than you want to wait. > > regards, tom lane > It responded to SIGINT, so yeah, meh. I can see

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

On Fri, Jan 22, 2016 at 9:32 PM, Michael Paquier wrote: > On Fri, Jan 22, 2016 at 5:26 PM, Tomas Vondra > wrote: >> On 01/22/2016 06:45 AM, Michael Paquier wrote: >>> Here are some comments about your patch after a look at the code. >>>

Re: [HACKERS] Relation extension scalability

On Sat, Jan 23, 2016 at 4:28 PM, Amit Kapila wrote: > I found one more problem with patch. > > ! UnlockReleaseBuffer(buffer); > ! RecordPageWithFreeSpace(relation, BufferGetBlockNumber(buffer), > freespace); > > You can't call BufferGetBlockNumber(buffer) after releasing

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

Corey Huinker writes: > Incidentally, is there a reason behind the tendency of internal functions > to avoid parameter defaults in favor of multiple pg_proc entries? Yes: you can't specify defaults in pg_proc.h. We work around that where absolutely necessary, see the

[HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

This patch addresses a personal need: nearly every time I use generate_series for timestamps, I end up casting the result into date or the ISO string thereof. Like such: SELECT d.dt::date as dt FROM generate_series('2015-01-01'::date, '2016-01-04'::date,

Re: [HACKERS] Relation extension scalability

On Sat, Jan 23, 2016 at 12:19 PM, Amit Kapila wrote > > > Few comments about patch: > Thanks for reviewing.. > 1. > Patch is not getting compiled. > > 1>src/backend/access/heap/hio.c(480): error C2065: 'buf' : undeclared > identifier >

[HACKERS] brin_summarize_new_values error checking

In reviewing one of my patches[1], Fujii-san has pointed out that I didn't include checks for being in recovery, or for working on another backend's temporary index. I think that brin_summarize_new_values in 9.5.0 commits those same sins. In its case, I don't think those are critical, as they

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Mon, Jan 25, 2016 at 3:00 PM, Corey Huinker wrote: > This patch addresses a personal need: nearly every time I use > generate_series for timestamps, I end up casting the result into date or the > ISO string thereof. Like such: > > [...] > > One thing I discovered in

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

Michael Paquier writes: > On Mon, Jan 25, 2016 at 3:00 PM, Corey Huinker > wrote: >> One thing I discovered in doing this patch is that if you do a timestamp >> generate_series involving infinityit tries to do it. I didn't wait to >> see

Re: [HACKERS] GIN pending list clean up exposure to SQL

On Wed, Jan 20, 2016 at 6:17 AM, Fujii Masao wrote: > On Sat, Jan 16, 2016 at 7:42 AM, Julien Rouhaud > wrote: >> On 15/01/2016 22:59, Jeff Janes wrote: >>> On Sun, Jan 10, 2016 at 4:24 AM, Julien Rouhaud >>> wrote: >>

Re: [HACKERS] Releasing in September

On Fri, Jan 22, 2016 at 6:21 PM, Andres Freund wrote: > On 2016-01-22 08:50:15 -0600, Jim Nasby wrote: >> I think that's a great way to ensure we shrink the pool of reviewers when >> someone works on a patch and then it goes nowhere. > > True, it really sucks. But what's your

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Dean Rasheed writes: > If I understand correctly there were 2 separate issues at play here: > 1). On some platforms the compiler evaluates expressions like > sin(constant) and comes up with a slightly different result than a > runtime evaluation of the expression. The

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

On 2016-01-18 21:47:27 +, Tomasz Rybak wrote: > We might also think about changing name of plugin to something resembling > "logical_streaming_decoder" or even "logical_streamer" FWIW, I find those proposals unconvincing. Not that pglogical_output is grand, but "streaming decoder" or

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On 23 January 2016 at 03:32, Thom Brown wrote: > On 22 January 2016 at 19:30, Victor Wagner wrote: >> On Tue, 19 Jan 2016 14:34:54 + >> Thom Brown wrote: >> >>> >>> The segfault issue I originally reported now appears to be resolved. >>>

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On 24 January 2016 at 15:30, Thom Brown wrote: > On 23 January 2016 at 03:32, Thom Brown wrote: >> On 22 January 2016 at 19:30, Victor Wagner wrote: >>> On Tue, 19 Jan 2016 14:34:54 + >>> Thom Brown wrote: >>>

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

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested Final part of review: protocol.txt +|origin_identifier|signed

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Sun, 24 Jan 2016 15:30:22 + Thom Brown wrote: в > Okay, I've tested this again with additional logging. Again, I'm just > running "psql -p 5531 postgres", which connects to a standby. This > immediately exits psql, and the logs show: > 2016-01-24 15:04:59.886 GMT - thom

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Sun, 24 Jan 2016 15:58:10 + Thom Brown wrote: > > Output of \set variables without patch: > > HOST = '127.0.0.1' > PORT = > '5530,127.0.0.1:5531,127.0.0.1:5532,127.0.0.1:5533,127.0.0.1:5534,127.0.0.1:5535' > > And with patch: > > HOST = >

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On 24 January 2016 at 19:53, Victor Wagner wrote: > On Sun, 24 Jan 2016 15:58:10 + > Thom Brown wrote: > > >> >> Output of \set variables without patch: >> >> HOST = '127.0.0.1' >> PORT = >>

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 1/23/16 4:18 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On 1/23/16 3:05 PM, Tom Lane wrote: >>> Peter Eisentraut writes: I'm still getting a failure in float8 on OS X after commit 73193d8: > >>> Weird, because my OS X critters are all happy.

Re: [HACKERS] proposal: function parse_ident

Hi 2016-01-23 16:36 GMT+01:00 Tom Lane : > Michael Paquier writes: > > On Sat, Jan 23, 2016 at 1:25 AM, Marko Tiikkaja wrote: > > + errmsg("identifier contains disallowed chars"), > > +

Re: [HACKERS] easy way of copying regex_t

Hi all, I've been working on moving an extension that allows to move the ispell dictionaries to shared segment. It's almost complete, the last FIXME is about copying regex_t structure (stored in AFFIX). According to regex.h the structure is fairly complex and not exactly easy to understand, so

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On 24 January 2016 at 20:11, Thom Brown wrote: > On 24 January 2016 at 19:53, Victor Wagner wrote: >> On Sun, 24 Jan 2016 15:58:10 + >> Thom Brown wrote: >> >> >>> >>> Output of \set variables without patch: >>> >>> HOST = '127.0.0.1' >>>

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

On 24 January 2016 at 08:20, Tom Lane wrote: > David Rowley writes: >> On 23 January 2016 at 12:44, Tom Lane wrote: >>> * What you did to join.sql/join.out seems a bit bizarre. The existing >>> test case that you modified

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

David Rowley writes: > I've looked into why the join is not removed; since the redundant > GROUP BY columns are removed during planning, and since the outer > query is planned before the sub query, then when the join removal code > checks if the subquery can been

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

On 25 January 2016 at 10:17, Tom Lane wrote: > David Rowley writes: >> I've looked into why the join is not removed; since the redundant >> GROUP BY columns are removed during planning, and since the outer >> query is planned before the sub

Re: [HACKERS] easy way of copying regex_t

Artur Zakirov writes: > With this message I want to send some patch to your repository with > draft of a code, which allows shared_ispell to copy regex_t. Allowing ispell.c to know that much about regex internals strikes me as completely unacceptable from a modularity

Re: [HACKERS] Why format() adds double quote?

2016-01-24 8:04 GMT-02:00 Tatsuo Ishii : >> On Wed, Jan 20, 2016 at 4:20 AM, Pavel Stehule >> wrote: If we would go this way, question is if we should back patch this or not since the patch apparently changes the existing behaviors.