Re: [HACKERS] LSN as a recovery target

On Wed, May 25, 2016 at 1:32 AM, Michael Paquier wrote: > On Tue, May 24, 2016 at 9:29 AM, Alvaro Herrera > wrote: >> Christoph Berg wrote: >>> Re: Michael Paquier 2016-05-24 >>>

Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

On Thu, Jun 9, 2016 at 12:47 AM, Tom Lane wrote: > Oleg Bartunov writes: >> On Wed, Jun 8, 2016 at 8:12 PM, Tom Lane wrote: >>> Another thing I noticed: if you test with tsvectors that don't contain >>> position info, <-> seems to

Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

On 2016/06/08 23:16, Amit Langote wrote: > On Wed, Jun 8, 2016 at 9:27 PM, Robert Haas wrote: >> On Tue, Jun 7, 2016 at 10:41 PM, Noah Misch wrote: >>> [Action required within 72 hours. This is a generic notification.] >>> >>> The above-described topic

Re: [HACKERS] Reviewing freeze map code

On Thu, Jun 9, 2016 at 8:48 AM, Amit Kapila wrote: > > On Wed, Jun 8, 2016 at 6:31 PM, Robert Haas wrote: > > > > > > Here's my proposal: > > > > 1. You already implemented a function to find non-frozen tuples on > > supposedly all-frozen pages.

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

On Thu, Jun 9, 2016 at 9:37 AM, Amit Kapila wrote: > On Thu, Jun 9, 2016 at 8:47 AM, Robert Haas wrote: >> On Mon, Jun 6, 2016 at 6:07 AM, Amit Kapila >> wrote: >> > That seems doable, as for such rels we can only have

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

On Thu, Jun 9, 2016 at 7:44 PM, Robert Haas wrote: > > On Thu, Jun 9, 2016 at 9:37 AM, Amit Kapila wrote: > > On Thu, Jun 9, 2016 at 8:47 AM, Robert Haas wrote: > >> On Mon, Jun 6, 2016 at 6:07 AM, Amit Kapila

Re: [HACKERS] Reviewing freeze map code

On Thu, Jun 9, 2016 at 5:48 AM, Amit Kapila wrote: > Attached patch implements the above 2 functions. I have addressed the > comments by Sawada San and you in latest patch and updated the documentation > as well. I made a number of changes to this patch. Here is the

Re: [HACKERS] parallel workers and client encoding

On 6/6/16 9:45 PM, Peter Eisentraut wrote: There appears to be a problem with how client encoding is handled in the communication from parallel workers. I have added this to the open items for now. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7

Re: [HACKERS] parallel workers and client encoding

Robert Haas writes: > On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut > wrote: >> ... So this whole thing >> actually happens to work as long as round tripping is possible between the >> involved encodings. > Hmm. I didn't realize that

Re: [HACKERS] [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted

On Thu, Jun 9, 2016 at 1:02 PM, Tom Lane wrote: > Robert Haas writes: >> Don't generate parallel paths for rels with parallel-restricted outputs. > > Surely this bit is wrong on its face: > > @@ -971,6 +980,7 @@ set_append_rel_size(PlannerInfo *root,

Re: [HACKERS] parallel workers and client encoding

On Thu, Jun 9, 2016 at 1:14 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut >> wrote: >>> ... So this whole thing >>> actually happens to work as long as round tripping is

Re: [HACKERS] Reviewing freeze map code

Hi Robert, Amit, thanks for working on this. On 2016-06-09 12:11:15 -0400, Robert Haas wrote: > 4. The tests as written were not safe under concurrency; they could > return spurious results if the page changed between the time you > checked the visibility map and the time you actually examined

Re: [HACKERS] Parallel safety tagging of extension functions

Robert Haas writes: > On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote: >> Yes, let's fix it. This will also take care of the questions about >> whether the GIN/GIST opclass tweaks I made a few months ago require >> module version bumps. > Tom,

Re: [HACKERS] parallel workers and client encoding

Robert Haas writes: > On Thu, Jun 9, 2016 at 1:14 PM, Tom Lane wrote: >> The current code results in failures if any non-latin1 data has to be >> transmitted from worker to leader, even though the query might not have >> ever sent that data to the

Re: [HACKERS] [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted

On Thu, Jun 9, 2016 at 1:44 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Jun 9, 2016 at 1:02 PM, Tom Lane wrote: >>> It seems like the only reason that we would need such a flag is that >>> applying has_parallel_hazard() to

Re: [HACKERS] Parallel safety tagging of extension functions

On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote: > Peter Eisentraut writes: >> On 5/20/16 7:37 PM, Robert Haas wrote: >>> I guess my first question is whether we have consensus on the release >>> into which we should put this. Some people

Re: [HACKERS] parallel workers and client encoding

On Thu, Jun 9, 2016 at 1:47 PM, Tom Lane wrote: >> Second, if you can't convert an error or notice message (or possibly a >> notify message) from the server encoding to the client coding, you are >> definitely going to fail, with or without parallel query, because that >>

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 9, 2016 at 2:05 PM, Peter Geoghegan wrote: > On Thu, Jun 9, 2016 at 7:04 AM, Robert Haas wrote: >> OK, I pushed this after re-reviewing it and fixing a number of >> oversights. There remains only the task of adding max_parallel_degree >> as a

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 9, 2016 at 7:04 AM, Robert Haas wrote: > OK, I pushed this after re-reviewing it and fixing a number of > oversights. There remains only the task of adding max_parallel_degree > as a system-wide limit (as opposed to max_parallel_degree now >

Re: [HACKERS] Parallel safety tagging of extension functions

On Thu, Jun 9, 2016 at 1:51 PM, Tom Lane wrote: > Robert Haas writes: >> On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote: >>> Yes, let's fix it. This will also take care of the questions about >>> whether the GIN/GIST opclass

Re: [HACKERS] Parallel safety tagging of extension functions

On 2016-06-09 17:40:24 -0400, Robert Haas wrote: > On Thu, Jun 9, 2016 at 4:48 PM, Tom Lane wrote: > > Robert Haas writes: > >> On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote: > >>> Yes, let's fix it. This will also take care of

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 9, 2016 at 6:09 PM, Peter Geoghegan wrote: > On Thu, Jun 9, 2016 at 1:08 PM, Robert Haas wrote: >>> I am in favor of having something similar to >>> max_parallel_workers_per_gather for utility statements like CREATE >>> INDEX. That will need a

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Thu, Jun 9, 2016 at 10:28 AM, Kevin Grittner wrote: > [Thanks to Robert to stepping up to keep this moving while I was > down yesterday with a minor injury. I'm back on it today.] >> Generally, I think I see the hazard you're concerned about: I had >> failed to realize, as

Re: [HACKERS] parallel workers and client encoding

> There appears to be a problem with how client encoding is handled in > the communication from parallel workers. Ouch. > In a parallel worker, the > client encoding setting is inherited from its creating process as part > of the GUC setup. So any plain-text stuff the parallel worker sends >

Re: [HACKERS] [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted

I wrote: > Robert Haas writes: >> There's one other related thing I'm concerned about, which is that the >> code in namespace.c that manages pg_temp doesn't know anything about >> parallelism. So it will interpret pg_temp to mean the pg_temp_NNN >> schema for its own

Re: [HACKERS] Perf Benchmarking and regression.

On Fri, Jun 10, 2016 at 9:19 AM, Andres Freund wrote: > On 2016-06-09 14:37:31 -0700, Andres Freund wrote: >> I'm writing a patch right now, planning to post it later today, commit >> it tomorrow. > > Attached. -/* see bufmgr.h: OS dependent default */ -

Re: [HACKERS] Perf Benchmarking and regression.

On Fri, Jun 10, 2016 at 9:42 AM, Andres Freund wrote: > On 2016-06-10 09:41:09 +0900, Michael Paquier wrote: >> On Fri, Jun 10, 2016 at 9:37 AM, Andres Freund wrote: >> > On 2016-06-10 09:34:33 +0900, Michael Paquier wrote: >> >> On Fri, Jun 10, 2016 at

Re: [HACKERS] [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted

Robert Haas writes: > On Thu, Jun 9, 2016 at 1:02 PM, Tom Lane wrote: >> It seems like the only reason that we would need such a flag is that >> applying has_parallel_hazard() to a Var is a bit expensive thanks to >> the typeid_is_temp() test --- but if

Re: [HACKERS] [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted

Robert Haas writes: > On Thu, Jun 9, 2016 at 1:44 PM, Tom Lane wrote: >> Well, yeah, you could remove it. It's inappropriate. The right place >> for such an error check is an attempt to actually access any data within >> a temp table, ie someplace in

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-06-09 14:37:31 -0700, Andres Freund wrote: > I'm writing a patch right now, planning to post it later today, commit > it tomorrow. Attached. >From d86fc0c966efe544b1926652196059539966b137 Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Thu, 9 Jun 2016 17:15:42

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-06-10 09:41:09 +0900, Michael Paquier wrote: > On Fri, Jun 10, 2016 at 9:37 AM, Andres Freund wrote: > > On 2016-06-10 09:34:33 +0900, Michael Paquier wrote: > >> On Fri, Jun 10, 2016 at 9:19 AM, Andres Freund wrote: > >> > On 2016-06-09 14:37:31

Re: [HACKERS] Perf Benchmarking and regression.

On Fri, Jun 10, 2016 at 9:37 AM, Andres Freund wrote: > On 2016-06-10 09:34:33 +0900, Michael Paquier wrote: >> On Fri, Jun 10, 2016 at 9:19 AM, Andres Freund wrote: >> > On 2016-06-09 14:37:31 -0700, Andres Freund wrote: >> >> I'm writing a patch right

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-06-10 09:34:33 +0900, Michael Paquier wrote: > On Fri, Jun 10, 2016 at 9:19 AM, Andres Freund wrote: > > On 2016-06-09 14:37:31 -0700, Andres Freund wrote: > >> I'm writing a patch right now, planning to post it later today, commit > >> it tomorrow. > > > > Attached. >

Re: [HACKERS] Parallel safety tagging of extension functions

On Thu, Jun 9, 2016 at 4:48 PM, Tom Lane wrote: > Robert Haas writes: >> On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote: >>> Yes, let's fix it. This will also take care of the questions about >>> whether the GIN/GIST opclass

Re: [HACKERS] Parallel safety tagging of extension functions

On Tue, Jun 7, 2016 at 11:44 AM, Robert Haas wrote: > More later. ltree: Skipped per your other email. ltree_plpython: No point. pageinspect: Committed. pg_buffercache: Committed. pgcrypto: Committed. pg_freespacemap: Committed. pg_prewarm: Committed. pgrowlocks:

Re: [HACKERS] Rename max_parallel_degree?

On Thu, Jun 9, 2016 at 1:08 PM, Robert Haas wrote: >> I am in favor of having something similar to >> max_parallel_workers_per_gather for utility statements like CREATE >> INDEX. That will need a cost model, at least where the DBA isn't >> explicit about the number of

Re: [HACKERS] Perf Benchmarking and regression.

On 2016-06-08 23:00:15 -0400, Noah Misch wrote: > On Sun, May 29, 2016 at 01:26:03AM -0400, Noah Misch wrote: > > On Thu, May 12, 2016 at 10:49:06AM -0400, Robert Haas wrote: > > > On Thu, May 12, 2016 at 8:39 AM, Ashutosh Sharma > > > wrote: > > > > Please find the test

Re: [HACKERS] Parallel safety tagging of extension functions

On Thu, Jun 9, 2016 at 5:45 PM, Andres Freund wrote: > On 2016-06-09 17:40:24 -0400, Robert Haas wrote: >> On Thu, Jun 9, 2016 at 4:48 PM, Tom Lane wrote: >> > Robert Haas writes: >> >> On Sat, May 21, 2016 at 11:45 AM, Tom Lane

Re: [HACKERS] WIP: Data at rest encryption

On Tue, Jun 7, 2016 at 11:56 PM, Ants Aasma wrote: > Hi all, > > I have been working on data-at-rest encryption support for PostgreSQL. > In my experience this is a common request that customers make. The > short of the feature is that all PostgreSQL data files are encrypted

Re: [HACKERS] Reviewing freeze map code

Hi, I found two, relatively minor, issues. 1) I think we should perform a relkind check in collect_corrupt_items(). Atm we'll "gladly" run against an index. If we actually entered the main portion of the loop in collect_corrupt_items(), that could end up corrupting the table (via

Re: [HACKERS] Reviewing freeze map code

On June 9, 2016 7:46:06 PM PDT, Amit Kapila wrote: >On Fri, Jun 10, 2016 at 8:08 AM, Andres Freund >wrote: > >> On 2016-06-09 19:33:52 -0700, Andres Freund wrote: >> > I played with it for a while, and besides >> > finding intentionally caused

Re: [HACKERS] Reviewing freeze map code

On 2016-06-09 19:33:52 -0700, Andres Freund wrote: > I played with it for a while, and besides > finding intentionally caused corruption, it didn't flag anything > (besides crashing on a standby, as in 2)). Ugh. Just sends after I sent that email: oid|t_ctid

Re: [HACKERS] Reviewing freeze map code

On Fri, Jun 10, 2016 at 8:08 AM, Andres Freund wrote: > On 2016-06-09 19:33:52 -0700, Andres Freund wrote: > > I played with it for a while, and besides > > finding intentionally caused corruption, it didn't flag anything > > (besides crashing on a standby, as in 2)). > >

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

On Thu, Jun 9, 2016 at 8:47 AM, Robert Haas wrote: > > On Mon, Jun 6, 2016 at 6:07 AM, Amit Kapila wrote: > > That seems doable, as for such rels we can only have Vars and > > PlaceHolderVars in targetlist. Basically, whenever we are adding > >

[HACKERS] [BUG] pg_basebackup from disconnected standby fails

Hello, I found that pg_basebackup from a replication standby fails after the following steps, on 9.3 and the master. - start a replication master - start a replication standby - stop the master in the mode other than immediate. pg_basebackup to the standby will fail with the following error.

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 8, 2016 at 10:18 AM, Tom Lane wrote: > Josh Berkus writes: >> On 06/07/2016 11:01 PM, Robert Haas wrote: >>> Here's a patch change max_parallel_degree to >>> max_parallel_workers_per_gather, and also changing parallel_degree to >>>

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

[Thanks to Robert to stepping up to keep this moving while I was down yesterday with a minor injury. I'm back on it today.] On Wed, Jun 8, 2016 at 3:11 PM, Robert Haas wrote: > On Wed, Jun 8, 2016 at 4:04 PM, Kevin Grittner wrote: >> -- connection 1

Re: [HACKERS] pgindent fixups

Robert Haas writes: > So I really would like to get a pgindent run done. Any objections to > doing it sometime RSN? It is of course possible that it might make > something that we want to revert later harder to revert, but I think > we should just accept that risk and

Re: [HACKERS] pgindent fixups

On Tue, May 3, 2016 at 11:31 AM, Robert Haas wrote: > On Tue, May 3, 2016 at 11:23 AM, Tom Lane wrote: >> Robert Haas writes: >>> OK, I committed this. Barring objections, I'll go ahead and pgindent >>> the whole tree tomorrow.

Re: [HACKERS] Parallel safety tagging of extension functions

Robert Haas writes: > On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote: >> Yes, let's fix it. This will also take care of the questions about >> whether the GIN/GIST opclass tweaks I made a few months ago require >> module version bumps. > Tom,

Re: [HACKERS] [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted

On Thu, Jun 9, 2016 at 2:08 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Jun 9, 2016 at 1:44 PM, Tom Lane wrote: >>> Well, yeah, you could remove it. It's inappropriate. The right place >>> for such an error check is an

Re: [HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

On Thu, Jun 9, 2016 at 5:50 AM, Amit Langote wrote: > On 2016/06/08 23:16, Amit Langote wrote: >> On Wed, Jun 8, 2016 at 9:27 PM, Robert Haas wrote: >>> On Tue, Jun 7, 2016 at 10:41 PM, Noah Misch wrote: [Action

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

On Thu, Jun 9, 2016 at 10:44 AM, Amit Kapila wrote: > No, I don't have a test case. I have tried a bit, but it seems even if > there is a problem, one needs to spend quite some time to generate an exact > test. I think the current patch fixes the reproducible problem

Re: [HACKERS] parallel workers and client encoding

On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut wrote: > There appears to be a problem with how client encoding is handled in the > communication from parallel workers. In a parallel worker, the client > encoding setting is inherited from its creating process