Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

On 2015/04/15 2:27, Jim Nasby wrote: On 4/14/15 1:05 AM, Kyotaro HORIGUCHI wrote: As an example, the following operations cause an "unexpected" result. Those results are indeed surprising, but since we allow it in a direct connection I don't see why we wouldn't allow it in the Postgres FDW...

[HACKERS] Supporting src/test/modules in MSVC builds

Hi all, As mentioned previously (cab7npqscphafxs2rzeb-fbccjqiknqxjhloztkggim1mf5x...@mail.gmail.com), attached are patches to add support for src/test/modules in MSVC builds, modules whose tests are not supported since they have been moved from contrib/: - 0001 adds support for the build portion.

Re: [HACKERS] show xl_prev in xlog.c errcontext

On Thu, Apr 16, 2015 at 3:25 PM, Heikki Linnakangas wrote: > On 04/15/2015 11:35 PM, Alvaro Herrera wrote: >> >> I found this patch in my local repo that I wrote some weeks or months >> ago while debugging some XLog corruption problem: it was difficult to >> pinpoint what XLog record in a long seq

Re: [HACKERS] show xl_prev in xlog.c errcontext

On 04/15/2015 11:35 PM, Alvaro Herrera wrote: I found this patch in my local repo that I wrote some weeks or months ago while debugging some XLog corruption problem: it was difficult to pinpoint what XLog record in a long sequence of WAL files was causing a problem, and the displaying the prev po

Re: [HACKERS] inherit support for foreign tables

Hello, At Thu, 16 Apr 2015 12:20:47 +0900, Etsuro Fujita wrote in <552f2a8f.2090...@lab.ntt.co.jp> > On 2015/04/15 3:52, Alvaro Herrera wrote: > >> On 4/14/15 5:49 AM, Etsuro Fujita wrote: > >>> postgres=# create foreign table ft1 (c1 int) server myserver options > >>> (table_name 't1'); > >>> C

Re: [HACKERS] reparsing query

On Wed, Apr 15, 2015 at 8:39 PM, Qingqing Zhou wrote: > > It is not difficult to output parsed query in some tool readable > format but it comes with a maintain overhead: once tools rely on it, > we have to conform to some schema continuously, like the xml/xmlns. Do > we want to take this? Depends

Re: [HACKERS] Improve sleep processing of pg_rewind TAP tests

On Thu, Apr 16, 2015 at 12:51 PM, Alvaro Herrera wrote: > Michael Paquier wrote: > >> However after discussion with a colleague we have noticed that those >> values may not be enough in slow environments, a value of up to 10s >> being sometimes needed after promotion to make tests pass. > > Yeah, h

Re: [HACKERS] Improve sleep processing of pg_rewind TAP tests

Michael Paquier wrote: > However after discussion with a colleague we have noticed that those > values may not be enough in slow environments, a value of up to 10s > being sometimes needed after promotion to make tests pass. Yeah, hardcoded sleep times are not reliable. (/me would love to get ri

Re: [HACKERS] reparsing query

On Wed, Apr 15, 2015 at 5:19 PM, Lukas Fittl wrote: > It'd be interesting to explore if there is some way to make this less > hack-ish, and enable tools to parse queries in a better way. Essentially > what is needed is some way to reliably translate SQL into an AST-like > output, from an outside t

Re: [HACKERS] PATCH: default_index_tablespace

On Thu, Apr 16, 2015 at 8:01 AM, Bruce Momjian wrote: > > On Wed, Apr 15, 2015 at 07:12:11PM -0400, Tom Lane wrote: > > jltal...@adv-solutions.net writes: > > > This small patch implements a new GUC (default_index_tablespace) plus > > > supporting code. > > > Originated from a customer request, th

Re: [HACKERS] inherit support for foreign tables

On 2015/04/15 3:52, Alvaro Herrera wrote: On 4/14/15 5:49 AM, Etsuro Fujita wrote: postgres=# create foreign table ft1 (c1 int) server myserver options (table_name 't1'); CREATE FOREIGN TABLE postgres=# create foreign table ft2 (c1 int) server myserver options (table_name 't2'); CREATE FOREIGN T

Re: [HACKERS] PATCH: default_index_tablespace

* Bruce Momjian (br...@momjian.us) wrote: > On Wed, Apr 15, 2015 at 07:12:11PM -0400, Tom Lane wrote: > > jltal...@adv-solutions.net writes: > > > This small patch implements a new GUC (default_index_tablespace) plus > > > supporting code. > > > Originated from a customer request, the feature inte

[HACKERS] Improve sleep processing of pg_rewind TAP tests

Hi all, TAP tests of pg_rewind are using in 2 places hardcoded values to wait for a given amount of time for some events. In HEAD, those things are: 1) Wait for 1s for standby to catch up. 2) Wait for 2s for promotion of standby. However after discussion with a colleague we have noticed that those

Re: [HACKERS] PATCH: default_index_tablespace

On Wed, Apr 15, 2015 at 07:12:11PM -0400, Tom Lane wrote: > jltal...@adv-solutions.net writes: > > This small patch implements a new GUC (default_index_tablespace) plus > > supporting code. > > Originated from a customer request, the feature intends to make > > creation of indexes on SSD-backed t

Re: [HACKERS] [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/

Michael Paquier wrote: > On Thu, Apr 16, 2015 at 4:15 AM, Alvaro Herrera > wrote: > > Well, *I* can't write the MSVC patch, but I can't find anyone to > > volunteer some time either :-( I think it's best to have MSVC skip the > > step and have the Makefile-based animals run it. That would give

Re: [HACKERS] [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/

On Thu, Apr 16, 2015 at 4:15 AM, Alvaro Herrera wrote: > Andrew Dunstan wrote: > >> Yes, we do want support for testmodules. I think that needs to be built into >> src/tools/msvc, probably in vcregress.pl. Once we have that the buildfarm >> changes will be trivial. But if that's not forthcoming qu

Re: [HACKERS] TAP tests of pg_rewind not stopping servers used for the tests

On Thu, Apr 16, 2015 at 1:57 AM, Heikki Linnakangas wrote: > Thanks, committed. I kept the END block, though, so that we still clean up > if the test dies with an exception. That makes sense. Thanks. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chang

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On Wed, Apr 15, 2015 at 6:10 AM, Andres Freund wrote: >> > Of >> > course, that applies in all cases, but when the page is already dirty, >> > the cost of pruning it is probably quite small - we're going to have >> > to write the page anyway, and pruning it before it gets evicted >> > (perhaps eve

Re: [HACKERS] reparsing query

On Wed, Apr 15, 2015 at 2:43 PM, Qingqing Zhou wrote: > > Is this a proposal to have a better formatted (JSON etc) > debug_print_parse results? I've run into the need for this as well for monitoring purposes, my solution was to compile the needed object files into a library (see [0]). It'd be i

Re: [HACKERS] PATCH: default_index_tablespace

jltal...@adv-solutions.net writes: > This small patch implements a new GUC (default_index_tablespace) plus > supporting code. > Originated from a customer request, the feature intends to make > creation of indexes on SSD-backed tablespaces easy and convenient > (almost transparent) for users: th

[HACKERS] PATCH: default_index_tablespace

Hi, This small patch implements a new GUC (default_index_tablespace) plus supporting code. Originated from a customer request, the feature intends to make creation of indexes on SSD-backed tablespaces easy and convenient (almost transparent) for users: the DBA can just set it and indexes will

Re: [HACKERS] reparsing query

On Wed, Apr 15, 2015 at 2:04 PM, Alvaro Herrera wrote: > His old posting: > https://www.postgresql.org/message-id/1247323023.16438.35.camel%40ab-desktop > Is this a proposal to have a better formatted (JSON etc) debug_print_parse results? Thanks, Qingqing -- Sent via pgsql-hackers mailing li

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

On Wed, Apr 15, 2015 at 5:26 AM, Robert Haas wrote: >> The way our cache works we promote when a buffer is accessed but we only >> demote when a buffer is flushed. We flush a lot less often than we touch >> buffers so it's not surprising that the cache ends up full of buffers that >> are all in th

Re: [HACKERS] reparsing query

Qingqing Zhou wrote: > On Wed, Apr 15, 2015 at 1:40 PM, Andrzej Barszcz wrote: > > I knock once again with this : reparse query to XML ( last knock 5-6 years > > before) . > > > > What exactly "reparse query to XML" does? His old posting: https://www.postgresql.org/message-id/1247323023.16438.35

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

On Wed, Apr 15, 2015 at 12:37:44AM -0400, Robert Haas wrote: > > I think such a solution will be good for the cases when many evictions > > needs to be performed to satisfy the workload, OTOH when there are > > not too many evictions that needs to be done, in such a case some of > > the buffers th

Re: [HACKERS] reparsing query

On Wed, Apr 15, 2015 at 1:40 PM, Andrzej Barszcz wrote: > I knock once again with this : reparse query to XML ( last knock 5-6 years > before) . > What exactly "reparse query to XML" does? Regards, Qingqing -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

[HACKERS] reparsing query

Hi I knock once again with this : reparse query to XML ( last knock 5-6 years before) . Motivation: more info for front-end developers about query. Users of jdbc driver are not able to gather information from meta data about such simple query : "select x.a,y.b from xxx x, yyy y" Solution : modif

[HACKERS] show xl_prev in xlog.c errcontext

I found this patch in my local repo that I wrote some weeks or months ago while debugging some XLog corruption problem: it was difficult to pinpoint what XLog record in a long sequence of WAL files was causing a problem, and the displaying the prev pointer in errcontext made finding it much easier

Re: [HACKERS] raw output from copy

It would be nice, but it is not true. You can get correct non utf8 xml with encoding specification only when binary mode is used. Psql doesn't support binary mode. Regards Pavel Dne 15. 4. 2015 22:06 napsal uživatel "Peter Eisentraut" : > On 4/10/15 5:26 PM, Pavel Stehule wrote: > > Hi > > > > I

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 15 April 2015 at 16:01, Alvaro Herrera wrote: > Simon Riggs wrote: >> On 15 April 2015 at 12:39, Robert Haas wrote: > >> On 04/15/2015 05:44 PM, Alvaro Herrera wrote: >> > Robert's proposal is "when reading a page, if dirty HOT-clean it; if not >> > dirty, also HOT-clean it but only 5 times in

Re: [HACKERS] raw output from copy

On 4/10/15 5:26 PM, Pavel Stehule wrote: > Hi > > I wrote a prototype of this patch, and it works well > > postgres=# set client_encoding to 'latin2'; > SET > Time: 1.488 ms > postgres=# \copy (select xmlelement(name xx, d) from d) to ~/d.xml > (format 'raw') > COPY 1 > Time: 1.108 ms > postgres=

Re: [HACKERS] Turning off HOT/Cleanup sometimes

Simon Riggs wrote: > On 15 April 2015 at 12:39, Robert Haas wrote: > On 04/15/2015 05:44 PM, Alvaro Herrera wrote: > > Robert's proposal is "when reading a page, if dirty HOT-clean it; if not > > dirty, also HOT-clean it but only 5 times in each scan". This runs > > HOT-cleanup some number of ti

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 15 April 2015 at 12:39, Robert Haas wrote: > On Wed, Apr 15, 2015 at 8:42 AM, Simon Riggs wrote: >>> I won't take responsibility for paying my neighbor's tax bill, but I >>> might take responsibility for picking up his mail while he's on >>> holiday. >> >> That makes it sound like this is an o

[HACKERS] Use outerPlanState() consistently in executor code

In executor context, outerPlanState(node) is the same as node->ss.ps.lefttree. We follow this in most places except a few. This patch clean up the outliers and might save us a few instructions by removing indirection. Most of changes are trivial. Except I take out an outerPlan nullable check in gr

Re: [HACKERS] [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/

Andrew Dunstan wrote: > Yes, we do want support for testmodules. I think that needs to be built into > src/tools/msvc, probably in vcregress.pl. Once we have that the buildfarm > changes will be trivial. But if that's not forthcoming quickly I can just > avoid the step on msvc for now. Well, *I*

Re: [HACKERS] [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/

On 04/15/2015 12:23 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: OK, the fix is here: and the new TestUpgrade.pm can be grabbed from here:

Re: [HACKERS] Assert there is no duplicated exit callbacks

On Wed, Apr 15, 2015 at 11:14:43AM -0700, Qingqing Zhou wrote: > Hmm, the email text seems corrupted? I think it was an encoding issue. Here's what I got when I piped it through less. Cheers, David. On 04/15/2015 07:52 PM, Qingqing Zhou wrote: > Attached is a patch to assert there is no duplica

Re: [HACKERS] Assert there is no duplicated exit callbacks

Hmm, the email text seems corrupted? Regards, Qingqing On Wed, Apr 15, 2015 at 10:03 AM, Heikki Linnakangas wrote: > 湏〠⼴㔱㈯㄰‵㜰㔺′䵐‬楑杮楱杮娠潨⁵牷瑯㩥਍‾瑁慴档摥椠⁳⁡慰捴⁨潴愠獳牥⁴ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mai

Re: [HACKERS] Auditing extension for PostgreSQL (Take 2)

On 4/14/15 8:37 PM, Tatsuo Ishii wrote: > BTW, in my understanding pg_audit allows to track a table access even > if it's used in a view. I think this is a nice feature and it would be > better explicitly stated in the document and the test case is better > included in the regression test. > > Her

Re: [HACKERS] Assert there is no duplicated exit callbacks

湏〠⼴㔱㈯㄰‵㜰㔺′䵐‬楑杮楱杮娠潨⁵牷瑯㩥㸊䄠瑴捡敨⁤獩愠瀠瑡档琠獡敳瑲琠敨敲椠⁳潮搠灵楬慣整⁤硥瑩挠污扬捡獫ਮ䤊搠湯琧爠浥浥敢⁲桴瑡攠敶⁲敢湥愠瀠潲汢浥ਮ㸊䄠潬杮琠敨眠祡‬⁉潤湷牧摡⁥桴⁥畲瑮浩⁥攢潮杵⁨潲浯•档捥潴愠੮‾獡敳瑲潩㩮琠敨挠污扬捡獫愠敲爠来獩整敲⁤湩瀠敲瑴⁹楦數⁤湩瑩慩楬慺楴湯㸊挠摯⁥慰桴‬桴獵愠獳牥楴湯椠⁳潧摯攠潮杵⁨潴瀠敲敶瑮漠敶汲潯桴牥⹥䤠੦‾敷搠湯琧愠牧敥眠瑩⁨桴獩‬桴湥琠敨搠灵楬慣楴湯挠敨正猠慨汬愠獬畢灭㸊琠畲瑮浩⁥档捥獫ਮ䤊搠湯琧琠楨歮愠祮漠⁦桴獩椠⁳敮摥摥ਮⴊ䠠楥歫੩ਊⴊ‭匊湥⁴楶⁡杰煳⵬慨正牥⁳慭汩湩⁧楬瑳⠠杰煳⵬慨正牥䁳潰瑳牧獥汱漮杲਩潔洠歡⁥

Re: [HACKERS] TAP tests of pg_rewind not stopping servers used for the tests

On 04/15/2015 03:07 PM, Michael Paquier wrote: Hi all, In the refactoring of pg_rewind tests committed as 53ba107, it happens that some of the servers used for the tests are not stopped at the end of the test. The issue is that RewindTest.pm uses END to stop the servers, but now that the local a

[HACKERS] Assert there is no duplicated exit callbacks

Attached is a patch to assert there is no duplicated exit callbacks. Along the way, I downgrade the runtime "enough room" check to an assertion: the callbacks are registered in pretty fixed initialization code path, thus assertion is good enough to prevent overlook there. If we don't agree with th

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On Wed, Apr 15, 2015 at 8:42 AM, Simon Riggs wrote: >> I won't take responsibility for paying my neighbor's tax bill, but I >> might take responsibility for picking up his mail while he's on >> holiday. > > That makes it sound like this is an occasional, non-annoying thing. > > It's more like, who

Re: [HACKERS] [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/

Andrew Dunstan wrote: > OK, the fix is here: > > and the new TestUpgrade.pm can be grabbed from here: >

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 04/15/2015 07:11 PM, Alvaro Herrera wrote: Heikki Linnakangas wrote: On 04/15/2015 05:44 PM, Alvaro Herrera wrote: Robert's proposal is "when reading a page, if dirty HOT-clean it; if not dirty, also HOT-clean it but only 5 times in each scan". This runs HOT-cleanup some number of times (

Re: [HACKERS] Bugs in CreateCheckPoint

On 04/15/2015 07:02 PM, Zhang Zq wrote: hi, To avoid inserting duplicate checkpoints when the system is idle, the code of CreateCheckPoint make two tests to determine that nothing has happened since the start of the last checkpoint. But because the layout of XLOG record was changed, the con

Re: [HACKERS] Turning off HOT/Cleanup sometimes

Heikki Linnakangas wrote: > On 04/15/2015 05:44 PM, Alvaro Herrera wrote: > >Robert's proposal is "when reading a page, if dirty HOT-clean it; if not > >dirty, also HOT-clean it but only 5 times in each scan". This runs > >HOT-cleanup some number of times (as many as there are dirty), and > >caus

[HACKERS] Bugs in CreateCheckPoint

hi, To avoid inserting duplicate checkpoints when the system is idle, the code of CreateCheckPoint make two tests to determine that nothing has happened since the start of the last checkpoint. But because the layout of XLOG record was changed, the condition would never to be true. The attachm

Re: [HACKERS] INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0

On 04/15/2015 06:01 PM, Andres Freund wrote: On 2015-04-15 17:58:54 +0300, Heikki Linnakangas wrote: On 04/15/2015 07:51 AM, Peter Geoghegan wrote: +heap_finish_speculative(Relation relation, HeapTuple tuple, bool conflict) +{ + if (!conflict) + { + /* +

Re: [HACKERS] Auditing extension for PostgreSQL (Take 2)

On Wed, Apr 15, 2015 at 10:52 AM, Sawada Masahiko wrote: > On Wed, Apr 15, 2015 at 8:57 AM, David Steele wrote: >> On 4/14/15 7:13 PM, Tatsuo Ishii wrote: >>> This patch does not apply cleanly due to the moving of pgbench (patch >>> to filelist.sgml failed). >> >> Thank you for pointing that out!

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 04/15/2015 05:44 PM, Alvaro Herrera wrote: Simon Riggs wrote: On 15 April 2015 at 09:10, Andres Freund wrote: I don't really see the downside to this suggestion. The suggestion makes things better than they are now but is still less than I have proposed. If what you both mean is "IMHO

Re: [HACKERS] [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/

On 04/15/2015 10:51 AM, Andrew Dunstan wrote: On 04/15/2015 08:31 AM, Michael Paquier wrote: On Wed, Apr 15, 2015 at 7:54 PM, Peter Eisentraut wrote: On 4/14/15 8:32 PM, Peter Eisentraut wrote: Move pg_upgrade from contrib/ to src/bin/ Oh dear. It appears the buildfarm client code needs t

Re: [HACKERS] INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0

On 2015-04-15 17:58:54 +0300, Heikki Linnakangas wrote: > On 04/15/2015 07:51 AM, Peter Geoghegan wrote: > >+heap_finish_speculative(Relation relation, HeapTuple tuple, bool conflict) > >+{ > >+if (!conflict) > >+{ > >+/* > >+ * Update the tuple in-place, in the comm

Re: [HACKERS] INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0

On 04/15/2015 07:51 AM, Peter Geoghegan wrote: +heap_finish_speculative(Relation relation, HeapTuple tuple, bool conflict) +{ + if (!conflict) + { + /* +* Update the tuple in-place, in the common case where no conflict was +* detected dur

Re: [HACKERS] [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/

On 04/15/2015 08:31 AM, Michael Paquier wrote: On Wed, Apr 15, 2015 at 7:54 PM, Peter Eisentraut wrote: On 4/14/15 8:32 PM, Peter Eisentraut wrote: Move pg_upgrade from contrib/ to src/bin/ Oh dear. It appears the buildfarm client code needs to be updated to support this. How do we do this

Re: [HACKERS] Turning off HOT/Cleanup sometimes

Simon Riggs wrote: > On 15 April 2015 at 09:10, Andres Freund wrote: > > I don't really see the downside to this suggestion. > > The suggestion makes things better than they are now but is still less > than I have proposed. > > If what you both mean is "IMHO this is an acceptable compromise", I

Re: [HACKERS] WAL format changes break the suppression of do-nothing checkpoints.

On 03/31/2015 09:09 PM, Jeff Janes wrote: On Tue, Mar 31, 2015 at 6:19 AM, Heikki Linnakangas wrote: On 03/30/2015 09:01 PM, Jeff Janes wrote: commit 2c03216d831160bedd72d45f7 has invalidated the part of the docs saying "If no WAL has been written since the previous checkpoint, new checkpoin

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 15 April 2015 at 09:10, Andres Freund wrote: > On 2015-04-15 08:42:33 -0400, Simon Riggs wrote: >> > Because it makes it subsequent accesses to the page cheaper. >> >> Cheaper for whom? > > Everyone. I think what you mean is "Everyone else". It is demonstrably quicker and more consistent for a

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

> >> Attached explain_forein_join.patch adds capability to show join combination > of > >> a ForeignScan in EXPLAIN output as an additional item “Relations”. I > >> thought > >> that using array to list relations is a good way too, but I chose one > >> string > value > >> because users would lik

Re: [HACKERS] moving from contrib to bin

On 4/12/15 8:00 PM, Alvaro Herrera wrote: > Peter Eisentraut wrote: >> On 3/11/15 8:21 PM, Michael Paquier wrote: >>> Attached is a series of patch rebased on current HEAD, there were some >>> conflicts after perl-tidying the refactoring patch for MSVC. Note that >>> this series still uses PGXS in

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 2015-04-15 08:42:33 -0400, Simon Riggs wrote: > > Because it makes it subsequent accesses to the page cheaper. > > Cheaper for whom? Everyone. Including further readers. Following HOT chains in read mostly workloads can be really expensive. If you have workloads with a 'hot' value range that's

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

On Wed, Apr 15, 2015 at 10:07 AM, Robert Haas wrote: > > On Wed, Apr 15, 2015 at 12:15 AM, Amit Kapila wrote: > > IIUC, this will allow us to increase usage count only when the buffer > > is touched by clocksweep to decrement the usage count. > > Yes. > > > I think such a solution will be good fo

Re: [HACKERS] FPW compression leaks information

On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier wrote: > On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wrote: >> On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier wrote: >>> 1) Doc patch to mention that it is possible that compression can give >>> hints to attackers when working on sensible fields

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 15 April 2015 at 08:04, Robert Haas wrote: > On Wed, Apr 15, 2015 at 3:37 AM, Simon Riggs wrote: >> On 14 April 2015 at 21:53, Robert Haas wrote: >>> Peter commented previously that README.HOT should get an update. The >>> relevant section seems to be "When can/should we prune or >>> defragm

Re: [HACKERS] [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/

On Wed, Apr 15, 2015 at 7:54 PM, Peter Eisentraut wrote: > On 4/14/15 8:32 PM, Peter Eisentraut wrote: >> Move pg_upgrade from contrib/ to src/bin/ > > Oh dear. It appears the buildfarm client code needs to be updated to > support this. How do we do this? (I guess the critters that are still >

Re: [HACKERS] FPW compression leaks information

On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wrote: > On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier wrote: >> 1) Doc patch to mention that it is possible that compression can give >> hints to attackers when working on sensible fields that have a >> non-fixed size. > > I think that this patch is

[HACKERS] TAP tests of pg_rewind not stopping servers used for the tests

Hi all, In the refactoring of pg_rewind tests committed as 53ba107, it happens that some of the servers used for the tests are not stopped at the end of the test. The issue is that RewindTest.pm uses END to stop the servers, but now that the local and remote tests are grouped half of the servers a

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On Wed, Apr 15, 2015 at 3:37 AM, Simon Riggs wrote: > On 14 April 2015 at 21:53, Robert Haas wrote: >> Peter commented previously that README.HOT should get an update. The >> relevant section seems to be "When can/should we prune or >> defragment?". > > That's easy enough to change once we agree

Re: [HACKERS] [COMMITTERS] pgsql: Move pg_upgrade from contrib/ to src/bin/

On 4/14/15 8:32 PM, Peter Eisentraut wrote: > Move pg_upgrade from contrib/ to src/bin/ Oh dear. It appears the buildfarm client code needs to be updated to support this. How do we do this? (I guess the critters that are still green are not running this test.) Should I revert this patch while

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 14 April 2015 at 21:53, Robert Haas wrote: > Peter commented previously that README.HOT should get an update. The > relevant section seems to be "When can/should we prune or > defragment?". That's easy enough to change once we agree to commit. > I wonder if it would be a useful heuristic to

Re: [HACKERS] FPW compression leaks information

On 04/10/2015 05:17 AM, Robert Haas wrote: I bet that there are at least 1000 covert channel attacks that are more practically exploitable than this. When this is anywhere near the top of the list of things to worry about, I recommend we throw a huge party and then fly home in our faster-than-lig