Re: [HACKERS] pgbench small bug fix

Hello Robert, > While testing for something else I encountered two small bugs under very low > rate (--rate=0.1). The attached patches fixes these. > > - when a duration (-T) is specified, ensure that pgbench ends at that >time (i.e. do

Re: [HACKERS] pgcommitfest reply having corrupted subject line

On Fri, Feb 5, 2016 at 3:44 AM, Noah Misch wrote: > On Thu, Feb 04, 2016 at 09:19:19AM +0100, Magnus Hagander wrote: > > On Thu, Feb 4, 2016 at 7:26 AM, Noah Misch wrote: > > > The following message, which bears "User-Agent: pgcommitfest", > > > > > > > > >

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Sun, Feb 7, 2016 at 11:54 AM, Vik Fearing wrote: > On 02/07/2016 03:42 AM, Filip Rembiałkowski wrote: > You left the duplicate behavior with subtransactions, but didn't mention > it in the documentation. If I do NOTIFY DISTINCT chan, 'msg'; then I > expect only

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On 02/07/2016 04:00 PM, Filip Rembiałkowski wrote: > On Sun, Feb 7, 2016 at 11:54 AM, Vik Fearing wrote: >> I seem to remember some discussion about not using DEFAULT parameters in >> system functions so you should leave the old function alone and create a >> new function

Re: [HACKERS] Using quicksort for every external sort run

On Fri, Feb 5, 2016 at 9:31 AM, Robert Haas wrote: > Peter, please weigh in and let me know if I've gotten anything > incorrect here or if you think of other concerns afterwards. Right. Let me give you the executive summary first: I continue to believe, following thinking

[HACKERS] Does plpython support threading?

Hi, In my plpython function, I create new thread to do some routine works. But I found the thread doesn't work, it would run a while, but suddenly pause and stop working. For example, I write a test dead loop to print something to file, but it would stop printing after some time. I am wondering

Re: [HACKERS] Explanation for bug #13908: hash joins are badly broken

On 02/06/2016 10:22 PM, Tom Lane wrote: Tomas Vondra writes: What about using the dense allocation even for the skew buckets, but not one context for all skew buckets but one per bucket? Then when we delete a bucket, we simply destroy the context (and free the

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On 02/07/2016 03:42 AM, Filip Rembiałkowski wrote: > +1 > > ... and a patch (only adding ALL keyword, no hash table implemented yet). Please stop top-posting, it's very disruptive. My comments are below, where they belong. > On Sat, Feb 6, 2016 at 2:35 PM, Brendan Jurd

Re: [HACKERS] Recently added typedef "string" is a horrid idea

On Sun, Feb 7, 2016 at 8:03 AM, Peter Geoghegan wrote: > On Sat, Feb 6, 2016 at 2:11 PM, Tom Lane wrote: >> Remember that the effects of typedef names are >> *global*, so far as pgindent is concerned; not only varlena.c will >> be affected. > > I'll remember

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

On Wed, Jan 27, 2016 at 10:18 PM, David G. Johnston wrote: > Prepare creates a plan and a plan has a known output structure. What you > want is an ability to give a name to a parsed but unplanned query. This is > not something that prepare should do as it is not a

Re: [HACKERS] Recently added typedef "string" is a horrid idea

On Sat, Feb 6, 2016 at 2:11 PM, Tom Lane wrote: > Remember that the effects of typedef names are > *global*, so far as pgindent is concerned; not only varlena.c will > be affected. I'll remember that in the future. > Please rename this typedef with some less-generic name.

Re: [HACKERS] Idle In Transaction Session Timeout, revived

On 4 February 2016 at 09:04, Robert Haas wrote: > > I have the same uneasy feeling about it as JD. However, you could > > certainly argue that if the client application has lost its marbles > > to the extent of allowing a transaction to time out, there's no good > >

Re: [HACKERS] Parallel Aggregate

On Sun, Jan 24, 2016 at 7:56 PM, Haribabu Kommi wrote: > 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

Re: [HACKERS] Recently added typedef "string" is a horrid idea

Peter Geoghegan writes: > On Sat, Feb 6, 2016 at 2:11 PM, Tom Lane wrote: >> Please rename this typedef with some less-generic name. Probably >> some of the other identifiers added in the same commit should be >> adjusted to match. > I suggest "VarString".

[HACKERS] evaluating target list in parallel workers

On Thu, Oct 22, 2015 at 2:49 PM, Robert Haas wrote: > On Thu, Oct 22, 2015 at 1:38 PM, Tom Lane wrote: >> Um ... why would you not want the projections to happen in the child >> nodes, where they could be parallelized? Or am I missing something? > >

Re: [HACKERS] remove wal_level archive

On 1/26/16 10:56 AM, Simon Riggs wrote: > Removing one of "archive" or "hot standby" will just cause confusion and > breakage, so neither is a good choice for removal. > > What we should do is > 1. Map "archive" and "hot_standby" to one level with a new name that > indicates that it can be used

Re: [HACKERS] Parallel Aggregate

On Thu, Jan 21, 2016 at 11:25 PM, Haribabu Kommi wrote: > [ new patch ] This patch contains a number of irrelevant hunks that really ought not to be here and make the patch harder to understand, like this: -* Generate appropriate target list

Re: [HACKERS] Using quicksort for every external sort run

On Sun, Feb 7, 2016 at 8:21 PM, Robert Haas wrote: > On Sun, Feb 7, 2016 at 11:00 AM, Peter Geoghegan wrote: > > It was my understanding, based on your emphasis on producing only a > > single run, as well as your recent remarks on this thread about the > >

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

On Thu, Feb 4, 2016 at 11:34 PM, Kouhei Kaigai wrote: > I can agree that smgr hooks shall be primarily designed to make storage > systems pluggable, even if we can use this hooks for suspend & resume of > write i/o stuff. > In addition, "pluggable storage" is a long-standing

Re: [HACKERS] Explanation for bug #13908: hash joins are badly broken

On Sat, Feb 6, 2016 at 12:47 PM, Tom Lane wrote: > So I'm of the opinion that a great deal more work is needed here. > But it's not something we're going to be able to get done for 9.5.1, > or realistically 9.5.anything. Whereas adding additional klugery to >

Re: [HACKERS] Explanation for bug #13908: hash joins are badly broken

Robert Haas writes: > On Sat, Feb 6, 2016 at 12:47 PM, Tom Lane wrote: >> So I'm of the opinion that a great deal more work is needed here. >> But it's not something we're going to be able to get done for 9.5.1, >> or realistically 9.5.anything.

Re: [HACKERS] Using quicksort for every external sort run

On Sun, Feb 7, 2016 at 11:00 AM, Peter Geoghegan wrote: > Right. Let me give you the executive summary first: I continue to > believe, following thinking about the matter in detail, that this is a > sensible compromise, that weighs everyone's concerns. It is pretty > close to a

Re: [HACKERS] First-draft release notes for next week's back-branch releases

Michael Paquier writes: > Bruce is the main author of this patch. I used what he did as a base > to build a version correct for MSVC. Fixed, thanks. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

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

> On Wed, Feb 3, 2016 at 11:57 PM, Kouhei Kaigai wrote: > > At this moment, I tried to write up description at nodes/nodes.h. > > The amount of description is about 100lines. It is on a borderline > > whether we split off this chunk into another header file, in my sense. > >

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

On Wed, Jan 27, 2016 at 12:54 PM, Julien Rouhaud wrote: > On 27/01/2016 10:27, Fujii Masao wrote: >> >> Thanks for updating the patch! It looks good to me. >> >> Based on your patch, I just improved the doc. For example, I added >> the following note into the doc. >> >>

Re: [HACKERS] Combining Aggregates

On Thu, Jan 21, 2016 at 3:42 PM, David Rowley wrote: > On 21 January 2016 at 08:06, Robert Haas wrote: >> >> On Wed, Jan 20, 2016 at 7:38 AM, David Rowley >> wrote: >> > Agreed. So I've attached a version of the

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On Sun, Feb 7, 2016 at 4:37 PM, Vik Fearing wrote: >>> There is also no mention in the documentation about what happens if I do: >>> >>> NOTIFY ALL chan, 'msg'; >>> NOTIFY ALL chan, 'msg'; >>> NOTIFY DISTINCT chan, 'msg'; >>> NOTIFY ALL chan, 'msg'; >>> >>>

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

Hi Vinayak, Thanks for updating the patch, a couple of comments: On 2016/02/05 17:15, poku...@pm.nttdata.co.jp wrote: > Hello, > > Please find attached updated patch. >> The point of having pgstat_report_progress_update_counter() is so that >> you can efficiently update a single counter

Re: [HACKERS] Using quicksort for every external sort run

On Sun, Feb 7, 2016 at 4:50 PM, Peter Geoghegan wrote: >> I'm not even sure this is necessary. The idea of missing out on >> producing a single sorted run sounds bad but in practice since we >> normally do the final merge on the fly there doesn't seem like there's >> really any

Re: [HACKERS] Does plpython support threading?

The new thread do not call any pg API or access any pg specific data. The pg backend (main thread) puts string message into the python Queue, and the new thread gets from the Queue and write to file, it's simple and clear logic. I test the same codes standalone, it works, but when I move them

Re: [HACKERS] Using quicksort for every external sort run

On Sun, Feb 7, 2016 at 10:51 AM, Greg Stark wrote: >> > You don't want to change the behavior of the current patch for the >> > second or subsequent run; that should remain a quicksort, pure and >> > simple. Do I have that right? >> >> Yes. > > I'm not even sure this is necessary.

Re: [HACKERS] Parallel Aggregate

On Mon, Feb 8, 2016 at 2:00 AM, Robert Haas wrote: > On Sun, Jan 24, 2016 at 7:56 PM, Haribabu Kommi > wrote: >> On Sat, Jan 23, 2016 at 12:59 PM, Haribabu Kommi >> wrote: >>> Here I attached updated patch with

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

> -Original Message- > From: Robert Haas [mailto:robertmh...@gmail.com] > Sent: Monday, February 08, 2016 1:52 AM > To: Kaigai Kouhei(海外 浩平) > Cc: Jim Nasby; pgsql-hackers@postgresql.org; Amit Langote > Subject: Re: [HACKERS] Way to check whether a particular block is > on the

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

On Mon, Feb 8, 2016 at 9:53 AM, Jeff Janes wrote: > On Wed, Jan 27, 2016 at 12:54 PM, Julien Rouhaud > wrote: >> On 27/01/2016 10:27, Fujii Masao wrote: >>> >>> Thanks for updating the patch! It looks good to me. >>> >>> Based on your patch, I

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

On Sun, Feb 7, 2016 at 2:49 AM, Andres Freund wrote: > On 2016-02-06 22:03:15 +0900, Michael Paquier wrote: >> The patch attached will apply on master, on 9.5 there is one minor >> conflict. For older versions we will need another reworked patch. > > FWIW, I don't think we

Re: [HACKERS] WAL Re-Writes

On Wed, Feb 3, 2016 at 7:12 PM, Robert Haas wrote: > > On Wed, Feb 3, 2016 at 7:28 AM, Amit Kapila wrote: > > On further testing, it has been observed that misaligned writes could > > cause reads even when blocks related to file are not in-memory,

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

hello, I have tested v7 patch. but i think you forgot to remove some debug points in patch from src/backend/replication/syncrep.c file. for (i = 0; i < num_sync; i++) + { + elog(WARNING, "sync_standbys[%d] = %d", i, sync_standbys[i]); + } + elog(WARNING, "num_sync

Re: [HACKERS] proposal: multiple psql option -c

2016-02-05 2:35 GMT+01:00 Peter Eisentraut : > On 12/29/15 10:38 AM, Bruce Momjian wrote: > > On Thu, Dec 10, 2015 at 11:10:55AM -0500, Robert Haas wrote: > >> On Wed, Dec 9, 2015 at 12:15 AM, Pavel Stehule > wrote: > On Wed, Dec 9, 2015 at 2:07 PM,