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

Hello, Sorry for long, hard-to-read writings in advance.. At Thu, 3 Mar 2016 23:30:49 +0900, Masahiko Sawada wrote in > Hi, > > Thank you so much for reviewing this patch! > > All review comments regarding document and comment are fixed. > Attached latest v14 patch. > > > This accepts 'abc^

Re: [HACKERS] pgbench small bug fix

> 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscripti

Re: [HACKERS] raw output from copy

Hi Pavel 27/02/16 10:26, Pavel Stehule пишет: Hi 2015-08-06 10:37 GMT+02:00 Pavel Stehule >: Hi, Psql based implementation needs new infrastructure (more than few lines) Missing: * binary mode support * parametrized query support,

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

On Fri, Mar 4, 2016 at 7:05 AM, Amit Kapila wrote: > > I think the wait event types should be documented - and the wait > > events too, perhaps. > > > > As discussed upthread, I have added documentation for all the possible > wait events and an example. Some of the LWLocks like AsyncQueueLock an

Re: [HACKERS] WIP: Upper planner pathification

Hi, On 03/03/2016 01:10 AM, Tom Lane wrote: Hmmm ... I'm now wondering about the "measurement error" theory. I tried to repeat this measurement locally, focusing on the select-only number since that should have a higher ratio of planning time to execution. Test setup: cassert-off build pgbench

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

Hello, Long time no see. I'm back. Although you may not remember me, I was certainly here more than a year ago, submitting tiny patches for bug fixes and trivial functionalities, and reviewing/testing patches from others. That was a fruitful and fun time for me. Thank you a lot for helping

Re: [HACKERS] ExecGather() + nworkers

On Fri, Mar 4, 2016 at 11:57 AM, Haribabu Kommi wrote: > On Wed, Jan 13, 2016 at 7:19 PM, Amit Kapila > wrote: > >> > > > > Changed the code such that nworkers_launched gets used wherever > > appropriate instead of nworkers. This includes places other than > > pointed out above. > > The changes

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

On Fri, Mar 4, 2016 at 8:20 PM, MauMau wrote: > Long time no see. I'm back. This is a good surprise. > Although you may not remember me, I was certainly here more than a year ago, > submitting tiny patches for bug fixes and trivial functionalities, and > reviewing/testing patches from others.

Re: [HACKERS] ExecGather() + nworkers

On Fri, Mar 4, 2016 at 10:33 PM, Amit Kapila wrote: > On Fri, Mar 4, 2016 at 11:57 AM, Haribabu Kommi > wrote: >> >> On Wed, Jan 13, 2016 at 7:19 PM, Amit Kapila >> wrote: >> >> >> > >> > Changed the code such that nworkers_launched gets used wherever >> > appropriate instead of nworkers. This

Re: [HACKERS] ExecGather() + nworkers

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 Kommi < > kommi.harib...@gmail.com> > > wrote: > >> > >> On Wed, Jan 13, 2016 at 7:19 PM, Amit Kapila > >> wrote: > >> >> > >> > > >> > Cha

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

Tasunakawa-san, Welcome back to PostgreSQL! -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp > Hello, > > > Long time no see. I'm back. > > Although you may not remember me, I was certainly here more than a year ago, > submitt

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

On 4 March 2016 at 05:08, Alvaro Herrera wrote: > > Okay, so far I have pushed 0001 and 0002 squashed (commit 5bec1ad4648), > 0003 (commit 7d9a4301c08), 0005 and 0006 squashed (commit 2c83f435a3de). > In the last one I chose to rename your psql_check to safe_psql and > tweaked a few other things

Re: [HACKERS] TAP / recovery-test fs-level backups, psql enhancements etc

On 4 March 2016 at 20:35, Craig Ringer wrote: > Fix attached. > > Apparently I need a "remind me if you see the word attach in an email" plugin. Sigh. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services From b7158678086f137e

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

On 2 March 2016 at 10:19, Michael Paquier wrote: > On Wed, Mar 2, 2016 at 12:40 AM, Andrew Dunstan > wrote: > > On 03/01/2016 08:00 AM, Michael Paquier wrote: > >> As of now the MSVC scripts control if TAP tests are enabled or not > >> using a boolean flag as $config->{tap_tests}. However, this

Re: [HACKERS] improving GROUP BY estimation

On Thu, 2016-03-03 at 11:42 -0800, Mark Dilger wrote: > > On Mar 3, 2016, at 11:27 AM, Alexander Korotkov > > wrote: > > > > On Thu, Mar 3, 2016 at 10:16 PM, Tomas Vondra > > wrote: > > So yes, each estimator works great for exactly the opposite cases. But > > notice that typically, the resul

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

On Fri, Mar 4, 2016 at 4:01 PM, Alexander Korotkov wrote: > On Fri, Mar 4, 2016 at 7:05 AM, Amit Kapila > wrote: > >> > I think the wait event types should be documented - and the wait >> > events too, perhaps. >> > >> >> As discussed upthread, I have added documentation for all the possible >>

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

On 4 March 2016 at 04:05, Amit Kapila wrote: > On Wed, Feb 24, 2016 at 7:14 PM, Robert Haas wrote: >> >> On Mon, Feb 22, 2016 at 10:05 AM, Amit Kapila >> wrote: >> >> I wouldn't bother tinkering with it at this point. The value isn't >> >> going to be recorded on disk anywhere, so it will be ea

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

On Fri, Mar 4, 2016 at 4:20 PM, Amit Kapila wrote: > On Fri, Mar 4, 2016 at 4:01 PM, Alexander Korotkov > wrote: > >> On Fri, Mar 4, 2016 at 7:05 AM, Amit Kapila >> wrote: >> >>> > I think the wait event types should be documented - and the wait >>> > events too, perhaps. >>> > >>> >>> As discu

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

On 4 March 2016 at 13:35, Thom Brown wrote: > On 4 March 2016 at 04:05, Amit Kapila wrote: >> On Wed, Feb 24, 2016 at 7:14 PM, Robert Haas wrote: >>> >>> On Mon, Feb 22, 2016 at 10:05 AM, Amit Kapila >>> wrote: >>> >> I wouldn't bother tinkering with it at this point. The value isn't >>> >> go

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

On 4 March 2016 at 13:41, Alexander Korotkov wrote: > On Fri, Mar 4, 2016 at 4:20 PM, Amit Kapila wrote: >> >> On Fri, Mar 4, 2016 at 4:01 PM, Alexander Korotkov >> wrote: >>> >>> On Fri, Mar 4, 2016 at 7:05 AM, Amit Kapila >>> wrote: > I think the wait event types should be documente

Re: [HACKERS] WIP: Upper planner pathification

On Tue, Mar 1, 2016 at 3:02 PM, Tom Lane wrote: > Well, my point is that no such path would have been generated if the > subquery hadn't had an internal reason to consider sorting on b.id. > The "accidental" part of this is that the subquery's GROUP BY key > matches what the outer query needs as a

Re: [HACKERS] postgres_fdw vs. force_parallel_mode on ppc

On Fri, Mar 4, 2016 at 12:46 AM, Tom Lane wrote: > Robert Haas writes: >> A couple of my colleagues have been looking into this. It's not >> entirely clear to me what's going on here yet, but it looks like the >> stats get there if you wait long enough. Rahila Syed was able to >> reproduce the

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

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 the existing > infrastructure. So if anybody has a Windows environment, feel free to > play with it and dig into tho

Re: [HACKERS] raw output from copy

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 ago, and so far the answers are to encode the contents in text and decode them in

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

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 compilation would fail. I > bumped into that so here is a patch. What I am proposing her

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

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 that the stats message >

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 other ref pages, wi

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 lo

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 the wait_for_stats() gua

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? -- Álv

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, because they get in

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 d42358efb16cc811, on 20 Feb. > It

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 patch I sent upthread, please credit Rahila Sy

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 timeline following patch to

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 so far is that the flapping test is new: it >>

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 next set of minor releases.

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 Okay,

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 that

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 think it > needs considera

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 in the tree currently, so t

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 order, so why not simply replace the >> existing

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 hand, we know that the stats updates are >>> delivered in a determ

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 y

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 confident and backpatch close to next >> weeke

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 years is >>> essentially nil. I think that the cos

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 > process will extend for

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 so

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 real-world users > are m

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 >>> applied only if DESC is used in this ORDER BY clause? > >> ... In this case we are

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 >> this function is defined in for

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 for the previous > string_length 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 ago, and so far the answers

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 use a new variable >> >> for character-based length, as in th

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 agreed but I like byte_length for

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, thank you for the comments. >>> >> I think we should leave string_length as it is and

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 me

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 incorrect error message in InitializeSessionUserId function >>> if you try to conn

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 vari

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 an ioctl(2) on the spe

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 o

[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] 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 Kommi >> > >> > wrote: >> >> >> >> On Wed, Jan 13, 2016 at 7:19 PM, Amit Kapil

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] 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] 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] Tom posted a large change to the grouping planner which >

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 first one is NULLs-related bugfix and the second is the >>

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 -- you

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 "some

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 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] 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 in SerializeSnapshot (snaps

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] 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] 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 — sometimes that means > “functio

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 description in transam/README is slightly >> outdat

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 w

[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: http://www.postgresql.org/mailpref/pgsql-h

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 now defined >> as: >> SELECT ('e

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] 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 show_plan_tlist checks whether t

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...) -- Robert Haas EnterpriseDB: http:

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 > pa

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 > reserves the 'pg_' rol

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 debug logging I have figured out what is hap

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 t

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 >>> that a native system st

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 >>they are a set of fixed mess

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 guess we have to eyeroll and live with it. >> > perl

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 compilation would fail. I

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 before or during the weekend; with it in the tree for >>> about a week we

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 this thread as soon as I'll hav

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 rename file persists in c

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 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 ENOENT. >> >> OK. So you mean more or less tha

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 not today, but tomorro

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 reason why switching to link() even in code >

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 store and >> how to represen

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 approach is not something I'

  1   2   >