Re: SIGPIPE in TAP tests

On Mon, Dec 11, 2017 at 04:19:52PM +0900, Michael Paquier wrote: > On Sun, Dec 10, 2017 at 6:02 AM, Noah Misch wrote: > If SIGPIPE is ignored then test output just stops after generating the > FATAL message. Oops. You mean "If SIGPIPE is not ignored ...", right? > > To fix

Re: [HACKERS] postgres_fdw bug in 9.6

(2017/12/09 5:53), Robert Haas wrote: On Sun, Dec 3, 2017 at 2:56 PM, Tom Lane wrote: Not sure where that leaves us for the patch at hand. It feels to me like it's a temporary band-aid for code that we want to get rid of in the not-too-long run. As such, it'd be okay if

Re: Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD

On Mon, Dec 11, 2017 at 8:21 AM, Thomas Munro wrote: > Hi hackers, > > > ... and then it called _bt_parallel_seize() itself, in violation of > the rule (by my reading of the code) that you must call > _bt_parallel_release() (via _bt_readpage()) or

Re: Added PostgreSQL internals learning materials in Developer FAQ

On Mon, Dec 11, 2017 at 8:43 AM, Tsunakawa, Takayuki wrote: > Hello, > > FYI > I collected Web resources to learn PostgreSQL internals in the Developer FAQ > page. I did this because I need to provide self-education materials for new > developers. Specifically,

Re: no partition pruning when partitioning using array type

On 2017/12/09 3:46, Robert Haas wrote: > On Fri, Dec 8, 2017 at 5:40 AM, Amit Langote > wrote: >> I noticed that if you partition using a array type column, partition >> pruning using constraint exclusion fails to work due to a minor problem. >> >> Example: >> >>

Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.

On Mon, Dec 11, 2017 at 2:03 PM, Masahiko Sawada wrote: > On Sat, Dec 9, 2017 at 2:24 AM, Robert Haas wrote: >> On Fri, Dec 8, 2017 at 4:13 AM, Michael Paquier >> wrote: >>> I would just write "To >>> avoid calling

Re: BUG #14941: Vacuum crashes

On Wed, Dec 6, 2017 at 1:52 AM, Bossart, Nathan wrote: > 0001_fix_unparenthesized_vacuum_grammar_v1.patch > > One VacuumStmt grammar rule allows users to specify the VACOPT_ANALYZE > option by including an AnalyzeStmt at the end of the command. This > appears to have been

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Sat, Dec 9, 2017 at 2:00 AM, Robert Haas wrote: > On Fri, Dec 8, 2017 at 3:20 AM, Masahiko Sawada wrote: >>> The first hunk in monitoring.sgml looks unnecessary. >> >> You meant the following hunk? >> >> diff --git a/doc/src/sgml/monitoring.sgml

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

Thanks Tels for reviewing the patch. On Fri, Dec 8, 2017 at 2:54 PM, Tels wrote: > Hello Rushabh, > > On Fri, December 8, 2017 2:28 am, Rushabh Lathia wrote: > > Thanks for review. > > > > On Fri, Dec 8, 2017 at 6:27 AM, Peter Geoghegan wrote: > > >

Re: BUG #14941: Vacuum crashes

On Sat, Dec 2, 2017 at 6:16 AM, Bossart, Nathan wrote: > On 12/1/17, 3:04 PM, "Robert Haas" wrote: >> Seems entirely reasonable to me, provided that we only update the >> extensible-options syntax: >> >> VACUUM [ ( option [, ...] ) ] [

Re: [HACKERS] parallel.c oblivion of worker-startup failures

On Fri, Dec 8, 2017 at 9:45 PM, Robert Haas wrote: > On Fri, Dec 8, 2017 at 4:56 AM, Amit Kapila wrote: >> I think the optimization you are suggesting has a merit over what I >> have done in the patch. However, one point to note is that we are >>

Added PostgreSQL internals learning materials in Developer FAQ

Hello, FYI I collected Web resources to learn PostgreSQL internals in the Developer FAQ page. I did this because I need to provide self-education materials for new developers. Specifically, I modified "How is the source code organized?", and added "What information is available to learn

Re: Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD

On Mon, Dec 11, 2017 at 3:51 PM, Thomas Munro wrote: > I heard a report of a 10.1 cluster hanging with several 'BtreePage' > wait_events showing in pg_stat_activity. I forgot to add, for bug reporter credit purposes: thanks to Patrick Hemmer for the off-list report

Parallel Index Scan vs BTP_DELETED and BTP_HALF_DEAD

Hi hackers, I heard a report of a 10.1 cluster hanging with several 'BtreePage' wait_events showing in pg_stat_activity. The query plan involved Parallel Index Only Scan, and the table is concurrently updated quite heavily. I tried and failed to make a reproducer, but from the clues available

Re: ScalarArrayOpExpr and multi-dimensional arrays

On 2017/12/08 23:34, Tom Lane wrote: > Amit Langote writes: >> I wonder if ScalarArrayOpExpr is not really meant for multi-dimensional >> arrays appearing on the right hand side? Because: >> # select array[1] = any (array[array[1], array[2]]); > >> ERROR:

Re: Out of date comment in cached_plan_cost

On 9 December 2017 at 06:05, Robert Haas wrote: > On Thu, Dec 7, 2017 at 3:14 AM, David Rowley > wrote: >> The attached is my attempt at putting this right. > > I don't feel entirely right about the way this seems to treat > inheritance and

Re: pl/perl extension fails on Windows

On Sun, Dec 10, 2017 at 12:36:13PM +, Christian Ullrich wrote: > * Noah Misch wrote: > > On Wed, Nov 29, 2017 at 11:45:35PM -0500, Tom Lane wrote: > >> Oh, OK. In that case, we need to get some representatives of these > >> more modern builds into the buildfarm while we're at it. > > > >

Inconsistency in plpgsql's error context reports

I noticed that since I put in commit 390d58135, buildfarm members that use CLOBBER_CACHE_ALWAYS are failing the added test case with diffs like *** 5051,5057 NOTICE: y = 2 ERROR: record "r" is not assigned yet DETAIL: The tuple structure of a not-yet-assigned record is

Re: Postgres with pthread

On 06/12/2017 17:26, Andreas Karlsson wrote: An additional issue is that this could break a lot of extensions and in a way that it is not apparent at compile time. This means we may need to break all extensions to force extensions authors to check if they are thread safe. I do not like

Re: Rethinking MemoryContext creation

Peter Geoghegan writes: > On Sat, Dec 9, 2017 at 5:53 PM, Tom Lane wrote: >> Overall I'm seeing about a 5% improvement in a "pgbench -S" scenario, >> although that number is a bit shaky since the run-to-run variation >> is a few percent anyway. > Is that with

Re: [HACKERS] Uninterruptible slow geo_ops.c

[Replying to an old thread...] > A customer of ours hit some very slow code while running the > @>(polygon, polygon) operator with some big polygons. I'm not familiar > with this stuff but I think the problem is that the algorithm converges > too slowly to a solution and also has some pretty