Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Sat, Mar 5, 2016 at 4:24 PM, Amit Langote wrote: > So, I took the Vinayak's latest patch and rewrote it a little ... > I broke it into two: > > 0001-Provide-a-way-for-utility-commands-to-report-progres.patch > 0002-Implement-progress-reporting-for-VACUUM-command.patch

Re: [HACKERS] extend pgbench expressions with functions

Attached is the fixed patch for the array method. Committed with a few tweaks, including running pgindent over some of it. Thanks. So the first set of functions is in, and the operators are executed as functions as well. Fabien, are you planning to send rebased versions of the rest? By that

Re: [HACKERS] extend pgbench expressions with functions

Committed with a few tweaks, including running pgindent over some of it. Thanks! -- Fabien. -- 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] [PROPOSAL] VACUUM Progress Checker.

On Sat, Mar 5, 2016 at 7:11 AM, Robert Haas wrote: > On Fri, Feb 26, 2016 at 3:28 AM, wrote: >> Thank you for your comments. >> Please find attached patch addressing following comments. > > I'm positive I've said this at least once before while

Re: [HACKERS] VS 2015 support in src/tools/msvc

Michael Paquier writes: > On Sat, Mar 5, 2016 at 1:41 PM, Petr Jelinek wrote: >> I vote for just using sed considering we need flex and bison anyway. > OK cool, we could go with something else than sed to generate probes.h > but that seems

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Sat, Mar 5, 2016 at 1:41 PM, Petr Jelinek wrote: > On 04/03/16 15:23, Michael Paquier wrote: >> OK, attached are a set of patches that allowed me to compile Postgres >> using VS2015, in more details: >> - 0001, as mentioned by Petr upthread, psed is removed from the core

Re: [HACKERS] Relation extension scalability

On Fri, Mar 4, 2016 at 9:59 PM, Robert Haas wrote: > > On Fri, Mar 4, 2016 at 12:06 AM, Dilip Kumar wrote: > > I have tried the approach of group extend, > > > > 1. We convert the extension lock to TryLock and if we get the lock then > > extend by

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 04/03/16 15:23, Michael Paquier wrote: OK, attached are a set of patches that allowed me to compile Postgres using VS2015, in more details: - 0001, as mentioned by Petr upthread, psed is removed from the core distribution of Perl in 5.22, so when installing ActivePerl it is not possible to

Re: [HACKERS] The plan for FDW-based sharding

On 2 March 2016 at 03:02, Bruce Momjian wrote: > On Tue, Mar 1, 2016 at 07:56:58PM +0100, Petr Jelinek wrote: > > Note that I am not saying that other discussed approaches are any > > better, I am saying that we should know approximately what we > > actually want and not just

Re: [HACKERS] The plan for FDW-based sharding

On 2 March 2016 at 00:03, Robert Haas wrote: > > True. There is an API, though, and having pluggable WAL support seems > desirable too. At the same time, I don't think we know of anyone > maintaining a non-core index AM ... and there are probably good > reasons for

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

On Fri, Mar 4, 2016 at 7:23 PM, Thom Brown wrote: > > On 4 March 2016 at 13:41, Alexander Korotkov wrote: > > > >> > >> If yes, then the only slight worry is that there will lot of repetition in > >> wait_event_type column, otherwise it is okay. > > > > > >

Re: [HACKERS] The plan for FDW-based sharding

On 28 February 2016 at 06:38, Kevin Grittner wrote: > > > For logical replay, applying in batches is actually a good thing since it > > allows parallelism. We can remove them all from the target's procarray > all > > at once to avoid intermediate states becoming visible. So

Re: [HACKERS] The plan for FDW-based sharding

On 27 February 2016 at 15:29, Konstantin Knizhnik wrote: > Two reasons: > 1. There is no ideal implementation of DTM which will fit all possible > needs and be efficient for all clusters. > 2. Even if such implementation exists, still the right way of it >

Re: [HACKERS] ExecGather() + nworkers

On Fri, Mar 4, 2016 at 11:41 PM, Robert Haas wrote: > On Fri, Mar 4, 2016 at 6:55 AM, Amit Kapila > wrote: > > On Fri, Mar 4, 2016 at 5:21 PM, Haribabu Kommi > > > wrote: > >> > >> On Fri, Mar 4, 2016 at 10:33 PM, Amit

Re: [HACKERS] The plan for FDW-based sharding

On 27 February 2016 at 11:54, Robert Haas wrote: > I could submit a patch adding > hooks to core to enable all of the things (or even just some of the > things) that EnterpriseDB has changed in Advanced Server, and that > patch would be rejected so fast it would make

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 4 March 2016 at 22:23, Michael Paquier wrote: > On Fri, Mar 4, 2016 at 3:54 PM, Michael Paquier > wrote: > > I still need to dig into that in more details. For the time being the > > patch attached is useful IMO to plug in VS 2015 with

Re: [HACKERS] The plan for FDW-based sharding

On Fri, Mar 4, 2016 at 8:27 PM, Joshua D. Drake wrote: > This does not sound like Bruce at all. Bruce is a lot of things, stubborn, > sometimes temperamental, a lot of times like you... a hot head but he does > not take credit for other people's work in my experience. On

[HACKERS] Is there a way around function search_path killing SQL function inlining?

I think the answer to this question is NO, but thought I'd ask. A lot of folks in PostGIS land are suffering from restore issues, materialized view issues etc. because we have functions such as ST_Intersects Which does _ST_Intersects AND && Since _ST_Intersects is not schema qualified,

Re: [HACKERS] JPUG wants to have a copyright notice on the translated doc

On 03/04/2016 06:01 PM, Tatsuo Ishii wrote: Considering they are BSD licensed, I am not sure what abuses could be taken? I imagine kind of an extream case: a bad guy removes "Copyright 1996-2016 The PostgreSQL Global Development Group" and replaces it with his/her copyright. Right but

Re: [HACKERS] JPUG wants to have a copyright notice on the translated doc

> On 03/04/2016 05:39 PM, Tatsuo Ishii wrote: >> JPUG (Japan PostgreSQL Users Group) would like to add a copyright >> ntice to the Japanese translated docs. >> >> http://www.postgresql.jp/document/9.5/html/ >> >> Currently "Copyright 1996-2016 The PostgreSQL Global Development >> Group" is showed

Re: [HACKERS] JPUG wants to have a copyright notice on the translated doc

On 03/04/2016 05:39 PM, Tatsuo Ishii wrote: JPUG (Japan PostgreSQL Users Group) would like to add a copyright ntice to the Japanese translated docs. http://www.postgresql.jp/document/9.5/html/ Currently "Copyright 1996-2016 The PostgreSQL Global Development Group" is showed on the translated

[HACKERS] JPUG wants to have a copyright notice on the translated doc

JPUG (Japan PostgreSQL Users Group) would like to add a copyright ntice to the Japanese translated docs. http://www.postgresql.jp/document/9.5/html/ Currently "Copyright 1996-2016 The PostgreSQL Global Development Group" is showed on the translated doc (of course in Japanese). What JPUG is

Re: [HACKERS] The plan for FDW-based sharding

On 03/04/2016 04:41 PM, Robert Haas wrote: As far as I understand it, Bruce came in near the end of that conversation and now wants to claim credit for something that doesn't really exist yet and, to the extent that it does exist, wasn't even his idea. Robert, This does not sound like Bruce

Re: [HACKERS] The plan for FDW-based sharding

On Tue, Mar 1, 2016 at 12:07 PM, Konstantin Knizhnik wrote: > In the article them used anotion "wait": > > if T.SnapshotTime>GetClockTime() > then wait until T.SnapshotTime > Originally we really do sleep here, but then we think that instead of >

Re: [HACKERS] The plan for FDW-based sharding

On Wed, Mar 2, 2016 at 1:53 PM, Josh berkus wrote: > One of the things which causes bad reactions and arguments, Bruce, is that a > lot of your posts and presentations detailing plans for the FDW approach > carry the subtext that all four of the other approaches are dead ends

Re: [HACKERS] Publish autovacuum informations

On Sat, Mar 5, 2016 at 9:21 AM, Julien Rouhaud wrote: > On 04/03/2016 23:34, Michael Paquier wrote: >> New design discussions are a little bit late for 9.6 I am afraid :( >> Perhaps we should consider this patch as returned with feedback for >> the time being? The hook

Re: [HACKERS] Publish autovacuum informations

On 04/03/2016 23:34, Michael Paquier wrote: > On Sat, Mar 5, 2016 at 6:52 AM, Julien Rouhaud > wrote: >> Very good suggestion. >> >> I think the most productive way to work on this is to start a wiki page >> to summarize what's the available information, what we should

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

On 2016-03-05 07:43:00 +0900, Michael Paquier wrote: > On Sat, Mar 5, 2016 at 7:35 AM, Andres Freund wrote: > > On 2016-03-04 14:51:50 +0900, Michael Paquier wrote: > >> On Fri, Mar 4, 2016 at 4:06 AM, Andres Freund wrote: > >> Hm. OK. I don't see any

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

On Sat, Mar 5, 2016 at 7:37 AM, Andres Freund wrote: > On 2016-03-05 07:29:35 +0900, Michael Paquier wrote: >> OK. I could produce that by tonight my time, not before unfortunately. > > I'm switching to this patch, after pushing the pending logical decoding > fixes. Probably

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

On Sat, Mar 5, 2016 at 7:35 AM, Andres Freund wrote: > On 2016-03-04 14:51:50 +0900, Michael Paquier wrote: >> On Fri, Mar 4, 2016 at 4:06 AM, Andres Freund wrote: >> > I don't think we want any stat()s here. I'd much, much rather check open >> > for

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

On 2016-03-05 07:29:35 +0900, Michael Paquier wrote: > OK. I could produce that by tonight my time, not before unfortunately. I'm switching to this patch, after pushing the pending logical decoding fixes. Probably not today, but tomorrow PST afternoon should work. > And FWIW, per the comments of

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

On 2016-03-04 14:51:50 +0900, Michael Paquier wrote: > On Fri, Mar 4, 2016 at 4:06 AM, Andres Freund wrote: > > Hi, > > Thanks for the review. > > >> +/* > >> + * rename_safe -- rename of a file, making it on-disk persistent > >> + * > >> + * This routine ensures that a

Re: [HACKERS] Publish autovacuum informations

On Sat, Mar 5, 2016 at 6:52 AM, Julien Rouhaud wrote: > Very good suggestion. > > I think the most productive way to work on this is to start a wiki page > to summarize what's the available information, what we should store and > how to represent it. > > I'll update

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

On Sat, Mar 5, 2016 at 1:23 AM, Robert Haas wrote: > On Fri, Mar 4, 2016 at 11:09 AM, Tom Lane wrote: >> Alvaro Herrera writes: >>> I would like to have a patch for this finalized today, so that we can >>> apply to master

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Sat, Mar 5, 2016 at 12:08 AM, Alvaro Herrera wrote: > Michael Paquier wrote: > >> - 0001, as mentioned by Petr upthread, psed is removed from the core >> distribution of Perl in 5.22, so when installing ActivePerl it is not >> possible to create probes.h, and the code

Re: [HACKERS] Equivalent of --enable-tap-tests in MSVC scripts

On Sat, Mar 5, 2016 at 1:16 AM, Craig Ringer wrote: > On 5 March 2016 at 00:10, Alvaro Herrera wrote: >> >> Craig Ringer wrote: >> >> > If it's the result of perltidy changing its mind about the formatting as >> > a >> > result of this change I

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Fri, Feb 26, 2016 at 3:28 AM, wrote: > Thank you for your comments. > Please find attached patch addressing following comments. > >>As I might have written upthread, transferring the whole string >>as a progress message is useless at least in this scenario. Since

Re: [HACKERS] Publish autovacuum informations

On 03/03/2016 10:54, Kyotaro HORIGUCHI wrote: > Hello, > > At Wed, 2 Mar 2016 17:48:06 -0600, Jim Nasby wrote > in <56d77bb6.6080...@bluetreble.com> >> On 3/2/16 10:48 AM, Julien Rouhaud wrote: >>> Good point, I don't see a lot of information available with this hooks

Re: [HACKERS] Performance improvement for joins where outer side is unique

I wonder why do we have two identical copies of clause_sides_match_join ... -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Robert Haas writes: > On Fri, Mar 4, 2016 at 11:17 AM, Tom Lane wrote: >> Huh? Parallel workers are read-only; what would they be doing sending >> any of these messages? > Mumble. I have no idea what's happening here. OK, after inserting a bunch of

Re: [HACKERS] Default Roles

On Mon, Feb 29, 2016 at 10:02 PM, Stephen Frost wrote: > Attached is a stripped-down version of the default roles patch which > includes only the 'pg_signal_backend' default role. This provides the > framework and structure for other default roles to be added and formally >

Re: [HACKERS] Relaxing SSL key permission checks

Christoph Berg wrote: > Re: To Tom Lane 2016-02-19 <20160219115334.gb26...@msg.df7cb.de> > > Updated patch attached. > > *Blush* I though I had compile-tested the patch, but without > --enable-openssl it wasn't built :(. > > The attached patch has successfully been included in the 9.6 Debian >

Re: [HACKERS] Typo in comment

On Fri, Mar 4, 2016 at 2:39 PM, Thomas Munro wrote: > Here is a patch to fix a typo in a comment in timestamp.c. That looks like a typo, all right. Committed. (It's "commit small patches day" for me today, in case anybody hasn't caught on to that already...) --

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

On Tue, Feb 23, 2016 at 1:18 AM, Etsuro Fujita wrote: > Thanks again for updating the patch and fixing the issues! Some comments on the latest version. I haven't reviewed the postgres_fdw changes in detail here, so this is just about the core changes. I see that

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

> > > I feel rather uneasy about simply removing the 'infinity' checks. Is there > a way to differentiate those two cases, i.e. when the generate_series is > called in target list and in the FROM part? If yes, we could do the check > only in the FROM part, which is the case that does not work (and

Re: [HACKERS][PATCH] Supporting +-Infinity values by to_timestamp(float8)

On 3/4/16, Anastasia Lubennikova wrote: > 27.02.2016 09:57, Vitaly Burovoy: >> Hello, Hackers! >> >> I worked on a patch[1] allows "EXTRACT(epoch FROM >> +-Inf::timestamp[tz])" to return "+-Inf::float8". >> There is an opposite function "to_timestamp(float8)" which

[HACKERS] Typo in comment

Hi Here is a patch to fix a typo in a comment in timestamp.c. -- Thomas Munro http://www.enterprisedb.com typo.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

On 2016-02-12 15:56:45 +0100, Andres Freund wrote: > Hi, > > > On 2016-02-10 23:26:20 -0500, Robert Haas wrote: > > I think the part about whacking around the FDW API is a little more > > potentially objectionable to others, so I want to hold off doing that > > unless a few more people chime in

Re: [HACKERS] transam README small fix

Thanks. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company > On 04 Mar 2016, at 22:14, Robert Haas wrote: > > On Tue, Mar 1, 2016 at 4:31 AM, Stas Kelvich wrote: >> Transaction function call sequence

Re: [HACKERS] transam README small fix

On Tue, Mar 1, 2016 at 4:31 AM, Stas Kelvich wrote: > Transaction function call sequence description in transam/README is slightly > outdated. Select now handled by PortalRunSelect instead of ProcessQuery. It > is also hard to follow what tabulation there means —

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

On 2/21/16 2:24 PM, Vik Fearing wrote: > On 02/21/2016 07:56 PM, Corey Huinker wrote: >> >> Other than that, the only difference is the ::date part. Is it >> really worth adding extra code just for that? I would say not. >> >> >> I would argue it belongs for the sake of completeness. > >

Re: [HACKERS] pgbench small bug fix

You're probably right, but TBH I'm pretty unsure about this whole thing. If the question is "is there a bug", then answer is yes. The progress report may disappear if thread 0 happens to stop, even of all other threads go on. Obviously it only concerns slow queries, but there is no reason why

Re: [HACKERS] Logic problem in SerializeSnapshot()

On Tue, Mar 1, 2016 at 12:34 AM, Rushabh Lathia wrote: > During the testing of parallel query (with force_parallel_mode = regress), > noticed random server crash with the below stack: > > #0 0x003fc84896d5 in memcpy () from /lib64/libc.so.6 > #1 0x00a36867

Re: [HACKERS] pgbench stats per script & other stuff

That is why the "fs" variable in process_file is declared "static", and why I wrote "some hidden awkwarness". I did want to avoid a malloc because then who would free the struct? addScript cannot to it systematically because builtins are static. Or it would have to create an on purpose struct,

Re: [HACKERS] pgbench small bug fix

Fabien COELHO wrote: > > >>Probably it is possible, but it will sure need more that one little > >>condition to be achieved... I do not think that introducing a non trivial > >>distributed election algorithm involving locks and so would be a good > >>decision for this very little matter. > >> >

Re: [HACKERS] pgbench small bug fix

Probably it is possible, but it will sure need more that one little condition to be achieved... I do not think that introducing a non trivial distributed election algorithm involving locks and so would be a good decision for this very little matter. My advice is "keep it simple". If this is a

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: > >However, this is still a bit broken -- you cannot return a stack > >variable from process_file, because the stack goes away once the > >function returns. You need to malloc it. > > That is why the "fs" variable in process_file is declared "static", and why > I wrote

Re: [HACKERS] pgbench stats per script & other stuff

*-21.patch does what you suggested above, some hidden awkwardness but much less that the previous one. Yeah, I think this is much nicer, don't you agree? Yep, I said "less awkwarness than previous", a pretty contrived way to say better:-) However, this is still a bit broken --

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

On Thu, Mar 3, 2016 at 2:48 AM, Shulgin, Oleksandr wrote: > On Wed, Mar 2, 2016 at 7:33 PM, Alvaro Herrera > wrote: >> Shulgin, Oleksandr wrote: >> >> > Alright. I'm attaching the latest version of this patch split in two >> > parts: the

Re: [HACKERS] Parallel Aggregate

On Thu, Mar 3, 2016 at 11:00 PM, David Rowley wrote: > On 17 February 2016 at 17:50, Haribabu Kommi wrote: >> Here I attached a draft patch based on previous discussions. It still needs >> better comments and optimization. > > Over in [1]

Re: [HACKERS] pgbench small bug fix

Fabien COELHO wrote: > Probably it is possible, but it will sure need more that one little > condition to be achieved... I do not think that introducing a non trivial > distributed election algorithm involving locks and so would be a good > decision for this very little matter. > > My advice is

Re: [HACKERS] pgbench stats per script & other stuff

Fabien COELHO wrote: Hi, > *-21.patch does what you suggested above, some hidden awkwardness > but much less that the previous one. Yeah, I think this is much nicer, don't you agree? However, this is still a bit broken -- you cannot return a stack variable from process_file, because the

Re: [HACKERS] ExecGather() + nworkers

On Fri, Mar 4, 2016 at 6:55 AM, Amit Kapila wrote: > On Fri, Mar 4, 2016 at 5:21 PM, Haribabu Kommi > wrote: >> >> On Fri, Mar 4, 2016 at 10:33 PM, Amit Kapila >> wrote: >> > On Fri, Mar 4, 2016 at 11:57 AM, Haribabu

[HACKERS] Re[2]: [HACKERS] Incorrect error message in InitializeSessionUserId

>On Fri, Mar 4, 2016, 5:23 +03:00 от Michael Paquier < >michael.paqu...@gmail.com >: > >> The patch adds the support of taking the role name from the role tuple >> instead of using the provided rolename variable, because it is possible >> that rolename variable is NULL if the connection is from a

Re: [HACKERS] WIP: Upper planner pathification

OK, here is a version that I think addresses all of the recent comments: * I refactored the grouping-sets stuff as suggested by Robert and David. The GroupingSetsPath code is now used *only* when there are grouping sets, otherwise what you get is a plain AGG_SORTED AggPath. This allowed removal

Re: [HACKERS] Way to check whether a particular block is on the shared_buffer?

On Thu, Mar 3, 2016 at 8:54 PM, Kouhei Kaigai wrote: > I found one other, but tiny, problem to implement SSD-to-GPU direct > data transfer feature under the PostgreSQL storage. > > Extension cannot know the raw file descriptor opened by smgr. > > I expect an extension issues

Re: [HACKERS] pgbench small bug fix

Hello Alvaro, Attached is a v3 which test integers more logically. I'm a lazy programmer who tends to minimize the number of key strokes. Well. From what I can tell this patch is Ready for Committer. I'm not a fan of this approach either. Would it be too complicated if we had a global

Re: [HACKERS] Incorrect error message in InitializeSessionUserId

On Thu, Mar 3, 2016 at 9:23 PM, Michael Paquier wrote: > On Fri, Mar 4, 2016 at 10:45 AM, Haribabu Kommi > wrote: >> On Wed, Mar 2, 2016 at 12:21 AM, Dmitriy Sarafannikov >> wrote: >>> Hi all, >>> >>> I have found

Re: [HACKERS] pgbench stats per script & other stuff

Hello Alvaro, I looked at 19.d and I think the design has gotten pretty convoluted. I think we could simplify with the following changes: struct script_t gets a new member, of type Command **, which is initially null. function process_builtin receives the complete script_t (not individual

Re: [HACKERS] psql completion for ids in multibyte string

On Fri, Mar 4, 2016 at 12:08 PM, Robert Haas wrote: > On Fri, Mar 4, 2016 at 12:02 PM, Alvaro Herrera > wrote: >> Robert Haas wrote: >>> On Wed, Mar 2, 2016 at 8:07 PM, Kyotaro HORIGUCHI >>> wrote: >>> > Hello,

Re: [HACKERS] psql completion for ids in multibyte string

Robert Haas wrote: > On Wed, Mar 2, 2016 at 8:07 PM, Kyotaro HORIGUCHI > wrote: > > Hello, thank you for the comments. > >> I think we should leave string_length as it is and use a new variable > >> for character-based length, as in the attached. > > > > Basically

Re: [HACKERS] psql completion for ids in multibyte string

On Fri, Mar 4, 2016 at 12:02 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Wed, Mar 2, 2016 at 8:07 PM, Kyotaro HORIGUCHI >> wrote: >> > Hello, thank you for the comments. >> >> I think we should leave string_length as it is and

Re: [HACKERS] raw output from copy

2016-03-04 15:54 GMT+01:00 Daniel Verite : > Corey Huinker wrote: > > > So, for me, RAW is the right solution, or at least *a* right solution. > > Questions on how to extract from a bytea column come up on a regular > basis, as in [1] [2] [3], or [4] a few days

Re: [HACKERS] psql completion for ids in multibyte string

On Wed, Mar 2, 2016 at 8:07 PM, Kyotaro HORIGUCHI wrote: > Hello, thank you for the comments. >> I think we should leave string_length as it is and use a new variable >> for character-based length, as in the attached. > > Basically agreed but I like byte_length

Re: [HACKERS] GetExistingLocalJoinPath() vs. the docs

On Wed, Mar 2, 2016 at 1:12 AM, Ashutosh Bapat wrote: >> I think that you need to take a little broader look at this section. >> At the top, it says "To use any of these functions, you need to >> include the header file foreign/foreign.h in your source file", but

Re: [HACKERS] Issue with NULLS LAST, with postgres_fdw sort pushdown

On Thu, Mar 3, 2016 at 12:08 AM, Tom Lane wrote: > Ashutosh Bapat writes: >> On Thu, Mar 3, 2016 at 7:27 AM, Michael Paquier >> wrote: >>> Per explain.c, this looks inconsistent to me. Shouldn't NULLS LAST be >>>

Re: [HACKERS] Relation extension scalability

Robert Haas writes: > This approach seems good to me, and the performance results look very > positive. The nice thing about this is that there is not a > user-configurable knob; the system automatically determines when > larger extensions are needed, which will mean that

Re: [HACKERS] Greeting for coming back, and where is PostgreSQL going

On 03/04/2016 03:20 AM, MauMau wrote: > I've been visually impaired since birth, and now I'm almost blind (can > only sense the light). I'm using screen reader software to use PCs and > smartphones. As I'm using pgindent, I'm sure the source code style > won't be bad. But I might overlook

Re: [HACKERS] Relation extension scalability

On Fri, Mar 4, 2016 at 12:06 AM, Dilip Kumar wrote: > I have tried the approach of group extend, > > 1. We convert the extension lock to TryLock and if we get the lock then > extend by one block.2. > 2. If don't get the Lock then use the Group leader concep where only one >

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

On Wed, Mar 2, 2016 at 6:41 PM, Tom Lane wrote: > Jim Nasby writes: >> On 3/2/16 4:21 PM, Peter Geoghegan wrote: >>> I think you should commit this. The chances of anyone other than you >>> and Masahiko recalling that you developed this tool in 3

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

On Fri, Mar 4, 2016 at 11:09 AM, Tom Lane wrote: > Alvaro Herrera writes: >> I would like to have a patch for this finalized today, so that we can >> apply to master before or during the weekend; with it in the tree for >> about a week we can be more

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Fri, Mar 4, 2016 at 11:17 AM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Mar 4, 2016 at 11:03 AM, Tom Lane wrote: >>> Well, that would make the function more complicated, but maybe it's a >>> better answer. On the other

Re: [HACKERS][PATCH] Supporting +-Infinity values by to_timestamp(float8)

27.02.2016 09:57, Vitaly Burovoy: Hello, Hackers! I worked on a patch[1] allows "EXTRACT(epoch FROM +-Inf::timestamp[tz])" to return "+-Inf::float8". There is an opposite function "to_timestamp(float8)" which now defined as: SELECT ('epoch'::timestamptz + $1 * '1 second'::interval) Hi, thank

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Robert Haas writes: > On Fri, Mar 4, 2016 at 11:03 AM, Tom Lane wrote: >> Well, that would make the function more complicated, but maybe it's a >> better answer. On the other hand, we know that the stats updates are >> delivered in a deterministic

Re: [HACKERS] Equivalent of --enable-tap-tests in MSVC scripts

On 5 March 2016 at 00:10, Alvaro Herrera wrote: > Craig Ringer wrote: > > > If it's the result of perltidy changing its mind about the formatting as > a > > result of this change I guess we have to eyeroll and live with it. > perltidy > > leaves the file alone as it is

Re: [HACKERS] WIP: Failover Slots

On 24 February 2016 at 18:02, Craig Ringer wrote: > I really want to focus on the first patch, timeline following for logical > slots. That part is much less invasive and is useful stand-alone. I'll move > it to a separate CF entry and post it to a separate thread as I

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Robert Haas wrote: > I'm not sure if that's actually true with parallel mode. I'm pretty > sure the earlier workers will have terminated before the later ones > start, but is that enough to guarantee that the stats collector sees > the messages in that order? Um. So if you have two queries

Re: [HACKERS] Equivalent of --enable-tap-tests in MSVC scripts

Craig Ringer wrote: > If it's the result of perltidy changing its mind about the formatting as a > result of this change I guess we have to eyeroll and live with it. perltidy > leaves the file alone as it is in the tree currently, so that be it. > > Gripe withdrawn, ready for committer IMO

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

Alvaro Herrera writes: > I would like to have a patch for this finalized today, so that we can > apply to master before or during the weekend; with it in the tree for > about a week we can be more confident and backpatch close to next > weekend, so that we see it in the

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Fri, Mar 4, 2016 at 11:03 AM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> That's what it looks like to me. I now think that the apparent >>> connection to parallel query is a mirage. The reason we've only >>> seen a few cases

Re: [HACKERS] Timeline following for logical slots

On 1 March 2016 at 21:00, Craig Ringer wrote: > Hi all > > Per discussion on the failover slots thread ( > https://commitfest.postgresql.org/9/488/) I'm splitting timeline > following for logical slots into its own separate patch. > > I've updated the logical decoding

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Fri, Mar 4, 2016 at 10:33 AM, Tom Lane wrote: > Robert Haas writes: >> Sure. If you have an idea what the right thing to do is, please go >> ahead. > > Yeah, I'll modify the patch and commit sometime later today. OK, if you're basing that on the

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Alvaro Herrera writes: > Tom Lane wrote: >> That's what it looks like to me. I now think that the apparent >> connection to parallel query is a mirage. The reason we've only >> seen a few cases so far is that the flapping test is new: it >> wad added in commit

Re: [HACKERS] syslog configurable line splitting behavior

On Sat, Feb 27, 2016 at 6:49 AM, Peter Eisentraut wrote: > Writing log messages to syslog caters to ancient syslog implementations > in two ways: > > - sequence numbers > - line splitting > > While these are arguably reasonable defaults, I would like a way to turn > them off,

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

I would like to have a patch for this finalized today, so that we can apply to master before or during the weekend; with it in the tree for about a week we can be more confident and backpatch close to next weekend, so that we see it in the next set of minor releases. Does that sound good? --

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Tom Lane wrote: > Robert Haas writes: > > Sure. If you have an idea what the right thing to do is, please go > > ahead. > > Yeah, I'll modify the patch and commit sometime later today. > > > I actually don't have a clear idea what's going on here. I > > guess it's that

Re: [HACKERS] WAL log only necessary part of 2PC GID

On 02/29/2016 08:45 AM, Pavan Deolasee wrote: Hello Hackers, The maximum size of the GID, used as a 2PC identifier is currently defined as 200 bytes (see src/backend/access/transam/twophase.c). The actual GID used by the applications though may be much smaller than that. So IMO instead of WAL

Re: [HACKERS] pg_resetxlog reference page reorganization

Hi, Peter! I've assigned myself as reviewer of this patch. On Tue, Mar 1, 2016 at 2:53 AM, Peter Eisentraut wrote: > The pg_resetxlog reference page has grown over the years into an > unnavigable jungle, so here is a patch that reorganizes it to be more in > the style of the

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

Robert Haas writes: > Sure. If you have an idea what the right thing to do is, please go > ahead. Yeah, I'll modify the patch and commit sometime later today. > I actually don't have a clear idea what's going on here. I > guess it's that the wait_for_stats() guarantees

Re: [HACKERS] pgbench small bug fix

Aleksander Alekseev wrote: > > Attached is a v3 which test integers more logically. I'm a lazy > > programmer who tends to minimize the number of key strokes. > > Well. From what I can tell this patch is Ready for Committer. I'm not a fan of this approach either. Would it be too complicated if

  1   2   >