Re: [HACKERS] Parallel build with MSVC

On Mon, Sep 05, 2016 at 02:43:48PM +0900, Michael Paquier wrote: > On Mon, Sep 5, 2016 at 9:18 AM, Noah Misch wrote: > > Every vcbuild and msbuild invocation ought to recognize this variable, so > > please update the two places involving ecpg_regression.proj. Apart from > >

Re: [HACKERS] autonomous transactions

Hi, On 2016-08-30 21:50:05 -0400, Peter Eisentraut wrote: > I would like to propose the attached patch implementing autonomous > transactions for discussion and review. > > This work was mostly inspired by the discussion about pg_background a > while back [0]. It seemed that most people liked

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Thu, Sep 8, 2016 at 10:02 AM, Mark Kirkwood wrote: > > Repeating my tests with these new patches applied points to the hang issue > being solved. I tested several 10 minute runs (any of which was enough to > elicit the hang previously). I'll do some longer ones,

Re: [HACKERS] Hash Indexes

On Wed, Sep 7, 2016 at 11:49 PM, Jeff Janes wrote: > On Thu, Sep 1, 2016 at 8:55 PM, Amit Kapila wrote: >> >> >> I have fixed all other issues you have raised. Updated patch is >> attached with this mail. > > > I am finding the comments

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 07/09/16 21:58, Amit Kapila wrote: On Wed, Aug 24, 2016 at 10:32 PM, Jeff Janes wrote: On Tue, Aug 23, 2016 at 10:05 PM, Amit Kapila wrote: On Wed, Aug 24, 2016 at 2:37 AM, Jeff Janes wrote: After an intentionally

[HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

Hi all, Looking at the MSVC scripts for some stuff I have noticed the following thing: if ($options->{xml}) { if (!($options->{xslt} && $options->{iconv})) { die "XML requires both XSLT and ICONV\n"; } } But I don't understand the reason behind such

Re: [HACKERS] autonomous transactions

On 8 September 2016 at 08:18, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer >> Of course, if we could decrease the startup cost of a bgworker > >> For this use in

Re: [HACKERS] Is tuplesort_heap_siftup() a misnomer?

On Wed, Sep 7, 2016 at 2:42 PM, Tom Lane wrote: > The reason it's called siftup is that that's what Knuth calls it. > See Algorithm 5.2.3H (Heapsort), pp 146-147 in the first edition of > Volume 3; tuplesort_heap_siftup corresponds directly to steps H3-H8. I see that Knuth

Re: [HACKERS] autonomous transactions

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer > Of course, if we could decrease the startup cost of a bgworker For this use in autonomous tx's we could probably pool workers. Or at least lazily terminate them so that the loop

Re: [HACKERS] Long options for pg_ctl waiting

On Thu, Sep 8, 2016 at 8:56 AM, Tom Lane wrote: > Vik Fearing writes: >> On 09/08/2016 01:05 AM, Tom Lane wrote: >>> I'm pretty much -1 on printing a warning. There's no ambiguity, and no >>> real reason for us ever to remove the old spellings.

Re: [HACKERS] Long options for pg_ctl waiting

On Thu, Sep 8, 2016 at 5:41 AM, Alvaro Herrera wrote: > Gavin Flower wrote: > >> possibly '--nosync' (& any similar) should have a '--no-sync' variation >> added, with the '--nosync' variation documented as depreciated? > > I agree -- I would go as far as just

Re: [HACKERS] Long options for pg_ctl waiting

Vik Fearing writes: > On 09/08/2016 01:05 AM, Tom Lane wrote: >> I'm pretty much -1 on printing a warning. There's no ambiguity, and no >> real reason for us ever to remove the old spellings. Standardizing on >> "no-" going forward makes sense, but let's not slap people's

Re: [HACKERS] Long options for pg_ctl waiting

On 09/08/2016 01:05 AM, Tom Lane wrote: > Vik Fearing writes: >> On 09/07/2016 11:39 PM, Gavin Flower wrote: >>> Possibly generate warningswhen the non hyphenated form is used? > >> I'm not quite sure how I got volunteered to do this work, but it's easy >> enough so I don't

[HACKERS] High-CPU consumption on information_schema (only) query

Hi, An SQL (with only information_schema related JOINS) when triggered, runs with max CPU (and never ends - killed after 2 days). - It runs similarly (very slow) on a replicated server that acts as a read-only slave. - Top shows only postgres as hitting max CPU (nothing else). When query killed,

Re: [HACKERS] autonomous transactions

On 8 Sep. 2016 3:47 am, "Robert Haas" wrote: > > Of course, if we could decrease the startup cost of a bgworker For this use in autonomous tx's we could probably pool workers. Or at least lazily terminate them so that the loop cases work better by re-using an existing

Re: [HACKERS] Long options for pg_ctl waiting

Vik Fearing writes: > On 09/07/2016 11:39 PM, Gavin Flower wrote: >> Possibly generate warningswhen the non hyphenated form is used? > I'm not quite sure how I got volunteered to do this work, but it's easy > enough so I don't mind. > Here is a new patch that emits a warning

Re: [HACKERS] Long options for pg_ctl waiting

On 09/07/2016 11:39 PM, Gavin Flower wrote: > On 08/09/16 09:08, Vik Fearing wrote: >> On 09/07/2016 10:41 PM, Alvaro Herrera wrote: >>> Gavin Flower wrote: >>> possibly '--nosync' (& any similar) should have a '--no-sync' variation added, with the '--nosync' variation documented as

Re: [HACKERS] GiST penalty functions [PoC]

Heikki Linnakangas writes: > Unfortunately, sqrt(x) isn't very cheap. You'd be surprised: sqrt is built-in on most modern hardware. On my three-year-old workstation, sqrt(x) seems to take about 2.6ns. For comparison, the pack_float version posted in

Re: [HACKERS] (Comment)Bug in CteScanNext

On 9/6/16 12:00 PM, Tom Lane wrote: On the other hand, if eof_cte is true, then what happened on the last call is that we tried to fetch forwards, reached EOF on the underlying query, and returned NULL. In that case, a backwards fetch *should* produce the last row in the tuplestore. Patch

Re: [HACKERS] Is tuplesort_heap_siftup() a misnomer?

Peter Geoghegan writes: > On Fri, Aug 12, 2016 at 4:30 PM, Peter Geoghegan wrote: >> Doesn't tuplesort_heap_siftup() actually shift-down? The reason it's called siftup is that that's what Knuth calls it. See Algorithm 5.2.3H (Heapsort), pp 146-147 in the first

Re: [HACKERS] Long options for pg_ctl waiting

On 08/09/16 09:08, Vik Fearing wrote: On 09/07/2016 10:41 PM, Alvaro Herrera wrote: Gavin Flower wrote: possibly '--nosync' (& any similar) should have a '--no-sync' variation added, with the '--nosync' variation documented as depreciated? I agree -- I would go as far as just documenting

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

On 09/07/2016 09:17 AM, Peter Geoghegan wrote: On Tue, Sep 6, 2016 at 11:09 PM, Heikki Linnakangas wrote: The big picture here is that you can't only USEMEM() for tapes as the need arises for new tapes as new runs are created. You'll just run a massive availMem deficit, that

Re: [HACKERS] GiST penalty functions [PoC]

On 09/07/2016 09:20 PM, Andrew Borodin wrote: Well, arithmetics is too fragile. This version of float packing with arithmetical packaging static float pack_float(float actualValue, int realm) { double max,min; max = FLT_MAX / ( 8 >> realm ); min = FLT_MAX / ( 16 >> realm ); if( realm == 0 ) min

Re: [HACKERS] Is tuplesort_heap_siftup() a misnomer?

On Fri, Aug 12, 2016 at 4:30 PM, Peter Geoghegan wrote: > Doesn't tuplesort_heap_siftup() actually shift-down? > > The Wikipedia article on heaps [1] lists "shift-down" (never "sift > down", FWIW) as a common operation on a heap: > > "shift-down: move a node down in the tree,

Re: [HACKERS] \timing interval

> > ... and it would probably greatly reduce the amount of mailing list > traffic asking for version if nothing else. That was the major reason for wanting it. The second is that if an explain were posted to a forum like stackexchange, the reader wouldn't have to wonder what version produced the

Re: [HACKERS] \timing interval

On 9/6/16 1:45 PM, Tom Lane wrote: It's sorta out of my hands now, but what Tom said earlier is that because > this is client-side code, it wouldn't use existing interval code. > EXPLAIN *is* server-side, we couldn't use this code, but we could leverage > existing interval code there to achieve

Re: [HACKERS] Long options for pg_ctl waiting

On 09/07/2016 10:41 PM, Alvaro Herrera wrote: > Gavin Flower wrote: > >> possibly '--nosync' (& any similar) should have a '--no-sync' variation >> added, with the '--nosync' variation documented as depreciated? > > I agree -- I would go as far as just documenting --no-sync only and > keeping

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

Dilip Kumar writes: > Basically this patch changes error at three places. > 1. getBaseTypeAndTypmod: This is being called from domain_in exposed > function (domain_in-> > domain_state_setup-> getBaseTypeAndTypmod). Though this function is > being called from many other

Re: [HACKERS] Long options for pg_ctl waiting

Gavin Flower wrote: > possibly '--nosync' (& any similar) should have a '--no-sync' variation > added, with the '--nosync' variation documented as depreciated? I agree -- I would go as far as just documenting --no-sync only and keeping the --nosync one working with minimal (if any) visibility in

Re: [HACKERS] Possible optimization on Function Scan

Hi, On 2016-09-07 15:29:08 -0500, Jim Nasby wrote: > I was a bit surprised to discover the difference below in calling an SRF as > part of a target list vs part of the from clause. The from clause generates > a Function Scan, which (apparently blindly) builds a tuplestore. Is there a > relatively

[HACKERS] Possible optimization on Function Scan

I was a bit surprised to discover the difference below in calling an SRF as part of a target list vs part of the from clause. The from clause generates a Function Scan, which (apparently blindly) builds a tuplestore. Is there a relatively easy way to either transform this type of query so the

Re: [HACKERS] [PATCH] Alter or rename enum value

ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > Here is version 6 of the patch, which just adds RENAME VALUE with no IF > [NOT] EXISTS, rebased onto current master (particularly the > transactional ADD VALUE patch). Pushed with some adjustments. The only thing that wasn't

Re: [HACKERS] autonomous transactions

On Sat, Sep 3, 2016 at 7:09 AM, Simon Riggs wrote: > On 2 September 2016 at 09:45, Robert Haas wrote: >> On Wed, Aug 31, 2016 at 7:20 AM, Peter Eisentraut >> wrote: >>> I would like to propose the attached patch

Re: [HACKERS] Long options for pg_ctl waiting

On 08/09/16 07:31, Robert Haas wrote: On Sat, Sep 3, 2016 at 7:13 PM, Michael Paquier wrote: On Sun, Sep 4, 2016 at 5:57 AM, Vik Fearing wrote: One thing that has been irking me ever since I came to PostgreSQL is the fact that pg_ctl -w (and

Re: [HACKERS] Long options for pg_ctl waiting

On Sat, Sep 3, 2016 at 7:13 PM, Michael Paquier wrote: > On Sun, Sep 4, 2016 at 5:57 AM, Vik Fearing wrote: >> One thing that has been irking me ever since I came to PostgreSQL is the >> fact that pg_ctl -w (and -W) don't have longhand equivalents.

Re: [HACKERS] SELECT FOR UPDATE regression in 9.5

On 07/09/16 7:29 PM, Alvaro Herrera wrote: Marko, does this fix your reported problem too? Both the assertion and the overall test case that causes it to fire? The test case never realized anything was wrong, but the assertion is gone. So yup, problem solved on this end, at least. .m

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Fri, Sep 2, 2016 at 11:19 AM, Kevin Grittner wrote: > IMV the process is to post a patch to this list to certify that it > is yours to contribute and free of IP encumbrances that would > prevent us from using it. I will wait for that post. I attach my V3. There are only

Re: [HACKERS] GiST penalty functions [PoC]

Well, arithmetics is too fragile. This version of float packing with arithmetical packaging static float pack_float(float actualValue, int realm) { double max,min; max = FLT_MAX / ( 8 >> realm ); min = FLT_MAX / ( 16 >> realm ); if( realm == 0 ) min = 0; /* squeeze the actual value between min

Re: [HACKERS] Hash Indexes

On Thu, Sep 1, 2016 at 8:55 PM, Amit Kapila wrote: > > I have fixed all other issues you have raised. Updated patch is > attached with this mail. > I am finding the comments (particularly README) quite hard to follow. There are many references to an "overflow bucket",

Re: Install extensions using update scripts (was Re: [HACKERS] Remove superuser() checks from pgstattuple)

I wrote: > Still no SGML doc updates. And here's a doc addition. regards, tom lane diff --git a/doc/src/sgml/extend.sgml b/doc/src/sgml/extend.sgml index df88380..1c8c420 100644 *** a/doc/src/sgml/extend.sgml --- b/doc/src/sgml/extend.sgml *** SELECT * FROM

Re: [HACKERS] ICU integration

> - I can't remember the specific language but they had the collation rule > that "CH" was treated as a distinct entity between C and D. This gave the > order C < CG < CI < CZ < CH < D. Then they removed CH as special which gave > C < CG < CH < CI < CZ < D. Suppose there was the constraint CHECK

Re: [HACKERS] Optimization for lazy_scan_heap

On Tue, Sep 6, 2016 at 11:13 PM, Masahiko Sawada wrote: > I understood, thank you. > > I've measured the performance benefit of this patch by following steps. > 1. Create very large table and set all-visible flag to all blocks. > 2. Measure the execution time of vacuum that

Re: [HACKERS] ICU integration

> > This isn't a problem for Postgres, or at least wouldn't be right now, > because we don't have case insensitive collations. I was wondering if Postgres might be that way. It does avoid the RI constraint problem, but there are still troubles with range based predicates. (My previous project

Re: [HACKERS] SELECT FOR UPDATE regression in 9.5

Marti Raudsepp wrote: > Hello list > > While testing an application with PostgreSQL 9.5, we experienced an issue > involving aborted subtransactions and SELECT FOR UPDATE. In certain > situations, a locking query doesn't return rows that should be visible and > already locked by the current

Re: [HACKERS] ICU integration

> I understand that in principle, but I don't see operating system > providers shipping a bunch of ICU versions to facilitate that. They > will usually ship one. Yep. If you want the protection I've described, you can't depend on the OS copy of ICU. You need to have multiple ICU libraries that

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Sep 7, 2016 at 12:12 PM, Greg Stark wrote: > On Wed, Sep 7, 2016 at 1:45 PM, Simon Riggs wrote: >> On 6 September 2016 at 19:59, Tom Lane wrote: >> >>> The idea of looking to the stats to *guess* about how many tuples are >>>

Re: [HACKERS] Fun fact about autovacuum and orphan temp tables

On Mon, Sep 5, 2016 at 1:14 PM, Bruce Momjian wrote: > On Mon, Sep 5, 2016 at 12:48:32PM -0300, Alvaro Herrera wrote: >> > The least invasive solution would be to have a guc, something like >> > 'keep_orphan_temp_tables' with boolean value. >> > Which would determine a

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Sep 7, 2016 at 1:45 PM, Simon Riggs wrote: > On 6 September 2016 at 19:59, Tom Lane wrote: > >> The idea of looking to the stats to *guess* about how many tuples are >> removable doesn't seem bad at all. But imagining that that's going to be >>

Re: [HACKERS] Index Onlys Scan for expressions

Hi Vladimir, On 05.09.2016 16:38, Ildar Musin wrote: Hi Vladimir, On 03.09.2016 19:31, Vladimir Sitnikov wrote: Ildar>The reason why this doesn't work is that '~~' operator (which is a Ildar>synonym for 'like') isn't supported by operator class for btree. Since Ildar>the only operators

Re: [HACKERS] Suggestions for first contribution?

> On 05 Sep 2016, at 20:25, Christian Convey wrote: > > Hi guys, > > Can anyone suggest a project for my first PG contribution? > > My first two ideas didn't pan out: Yury doesn't seem to need help > with CMake, and the TODO list's "-Wcast-align" project (now

Re: [HACKERS] Suggestions for first contribution?

Christian Convey wrote: Yury doesn't seem to need help with CMake Hello. I am sorry that the only answer is now. I need help but with write CMake code: 1. Make ecpg tests 2. Make MinGW/Msys support 3. many many ... all targets and discussion here:

Re: [HACKERS] Patch: Implement failover on libpq connect level.

> > 8) get_next_element procedure implementation is way too smart (read > > "complicated"). You could probably just store current list length and > > generate a random number between 0 and length-1. > > No, algorithm here is more complicated. It must ensure that there would > not be second

Re: [HACKERS] Suggestions for first contribution?

Here is another idea for a contribution - refactoring. Currently there are a lot of procedures in PostgreSQL code that definitely don't fit on one screen (i.e. ~50 lines). Also many files are larger than say 1000 lines of code. For instance, psql_completion procedure is more than 2000 lines long!

Re: [HACKERS] pgbench - allow to store select results into variables

Hello Amit, Custom script looks like: \; select a \into a from tab where a = 1; \set i debug(:a) I get the following error: undefined variable "a" client 0 aborted in state 1; execution of meta-command failed Good catch! Indeed, there is a problem with empty commands which are simply

Re: [HACKERS] [COMMITTERS] pgsql: Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

Simon Riggs writes: > On 7 September 2016 at 13:47, Fujii Masao wrote: >> On Tue, Sep 6, 2016 at 11:41 PM, Simon Riggs wrote: >>> lazy_truncate_heap() was waiting for >>> VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL, but in microseconds

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Mon, 5 Sep 2016 14:03:11 +0300 Aleksander Alekseev wrote: > Hello, Victor. > > > 1) It looks like code is not properly formatted. > Thanks for pointing to the documentation and formatting problems. I'll fix them > > static int > > connectDBStart(PGconn

[HACKERS] Bug in two-phase transaction recovery

Hello. Some time ago two-phase state file format was changed to have variable size GID, but several places that read that files were not updated to use new offsets. Problem exists in master and 9.6 and can be reproduced on prepared transactions with savepoints. For example: create table t(id

Re: Install extensions using update scripts (was Re: [HACKERS] Remove superuser() checks from pgstattuple)

Andres Freund writes: > On 2016-09-05 22:24:09 -0400, Tom Lane wrote: >> Ordinarily I'd be willing to stick this on the queue for the next >> commitfest, but it seems like we ought to try to get it pushed now >> so that Stephen can make use of the feature for his superuser

Re: [HACKERS] ICU integration

On 9/6/16 1:40 PM, Doug Doole wrote: > We carried the ICU version numbers around on our collation and locale > IDs (such as fr_FR%icu36) . The database would load multiple versions of > the ICU library so that something created with ICU 3.6 would always be > processed with ICU 3.6. This avoided

Re: [HACKERS] WAL consistency check facility

On Wed, Sep 7, 2016 at 3:52 PM, Kuntal Ghosh wrote: > > I got two types of inconsistencies as following: > > 1. For Btree/UNLINK_PAGE_META, btpo_flags are different. In backup > page, BTP_DELETED and BTP_LEAF both the flags are set, whereas after > redo, only

Re: [HACKERS] [COMMITTERS] pgsql: Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

On 7 September 2016 at 13:47, Fujii Masao wrote: > On Tue, Sep 6, 2016 at 11:41 PM, Simon Riggs wrote: >> Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL >> >> lazy_truncate_heap() was waiting for >> VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL, but in microseconds >>

Re: [HACKERS] [COMMITTERS] pgsql: Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

On Tue, Sep 6, 2016 at 11:41 PM, Simon Riggs wrote: > Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL > > lazy_truncate_heap() was waiting for > VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL, but in microseconds > not milliseconds as originally intended. Don't we need to back-patch this?

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On 6 September 2016 at 19:59, Tom Lane wrote: > The idea of looking to the stats to *guess* about how many tuples are > removable doesn't seem bad at all. But imagining that that's going to be > exact is folly of the first magnitude. Yes. Bear in mind I had already

Re: [HACKERS] WAL consistency check facility

On Wed, Sep 7, 2016 at 3:52 PM, Kuntal Ghosh wrote: > Hello, > > As per the earlier discussions, I've attached the updated patch for > WAL consistency check feature. This is how the patch works: > The earlier patch (wal_consistency_v6.patch) was based on the commit id

Re: [HACKERS] PATCH: Exclude additional directories in pg_basebackup

On 9/7/16 8:21 AM, David Steele wrote: > On 9/6/16 10:25 PM, Michael Paquier wrote: >> I find that ugly. I'd rather use an array with undefined size for the >> fixed elements finishing by NULL, remove EXCLUDE_DIR_MAX and >> EXCLUDE_DIR_STAT_TMP and use a small routine to do the work done on >>

Re: [HACKERS] PATCH: Exclude additional directories in pg_basebackup

On 9/6/16 10:25 PM, Michael Paquier wrote: > On Wed, Sep 7, 2016 at 12:16 AM, David Steele wrote: >> Attached is a new patch that adds sgml documentation. I can expand on each >> directory individually if you think that's necessary, but thought it was >> better to lump them

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On 09/07/2016 01:13 PM, Amit Kapila wrote: > On Wed, Sep 7, 2016 at 1:08 AM, Tomas Vondra > wrote: >> On 09/06/2016 04:49 AM, Amit Kapila wrote: >>> On Mon, Sep 5, 2016 at 11:34 PM, Tomas Vondra >>> wrote: On 09/05/2016

Re: [HACKERS] identity columns

Hello, The first look at the patch: On 8/30/16, Peter Eisentraut wrote: > Here is another attempt to implement identity columns. This is a > standard-conforming variant of PostgreSQL's serial columns. > > ... > > Some comments on the implementation, and where

Re: [HACKERS] [PATCH] Alter or rename enum value

Emre Hasegeli writes: >> Bottom line here is that I'd rather commit ALTER TYPE RENAME VALUE with >> no EXISTS features and then see it accrete those features together with >> other types of RENAME, when and if there's a will to make that happen. > > This sounds like a good

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Wed, Sep 7, 2016 at 1:08 AM, Tomas Vondra wrote: > On 09/06/2016 04:49 AM, Amit Kapila wrote: >> On Mon, Sep 5, 2016 at 11:34 PM, Tomas Vondra >> wrote: >>> >>> >>> On 09/05/2016 06:03 AM, Amit Kapila wrote: So, in short we

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On Wed, 7 Sep 2016 17:09:17 +0900 Michael Paquier wrote: > On Sun, Sep 4, 2016 at 11:39 PM, Andreas Karlsson > wrote: > > 1) Serialize the certificates, key, and CRL and write them to the > > backend_var temp file and then deserialize everything in

Re: [HACKERS] Write Ahead Logging for Hash Indexes

> Thanks to Ashutosh Sharma for doing the testing of the patch and > helping me in analyzing some of the above issues. Hi All, I would like to summarize the test-cases that i have executed for validating WAL logging in hash index feature. 1) I have mainly ran the pgbench test with read-write

Re: [HACKERS] Declarative partitioning - another take

Hi, On 2016/09/07 17:56, Rajkumar Raghuwanshi wrote: > Hi, > > I have a query regarding list partitioning, > > For example if I want to store employee data in a table, with "IT" dept > employee in emp_p1 partition, "HR" dept employee in emp_p2 partition and if > employee belongs to other than

Re: [HACKERS] WAL consistency check facility

Hello, As per the earlier discussions, I've attached the updated patch for WAL consistency check feature. This is how the patch works: - If WAL consistency check is enabled for a rmgrID, we always include the backup image in the WAL record. - I've extended the RmgrTable with a new function

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Wed, Sep 7, 2016 at 3:28 PM, Amit Kapila wrote: > > Okay, I have fixed this issue as explained above. Apart from that, I > have fixed another issue reported by Mark Kirkwood upthread and few > other issues found during internal testing by Ashutosh Sharma. > Forgot to

Re: [HACKERS] Logical Replication WIP

On 07/09/16 02:56, Peter Eisentraut wrote: Review of 0002-Add-SUBSCRIPTION-catalog-and-DDL.patch: Similar concerns as before about ALTER syntax, e.g., does ALTER SUBSCRIPTION ... PUBLICATION add to or replace the publication set? It sets. For that matter, why is there no way to add?

Re: [HACKERS] Declarative partitioning - another take

Hi, I have a query regarding list partitioning, For example if I want to store employee data in a table, with "IT" dept employee in emp_p1 partition, "HR" dept employee in emp_p2 partition and if employee belongs to other than these two, should come in emp_p3 partition. In this case not sure

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On Sun, Sep 4, 2016 at 11:39 PM, Andreas Karlsson wrote: > 1) Serialize the certificates, key, and CRL and write them to the > backend_var temp file and then deserialize everything in the backends. > > Sounds like you would need to write some code for every SSL library to >

Re: [HACKERS] Speedup twophase transactions

> On 07 Sep 2016, at 03:09, Michael Paquier wrote: > >>> On 06 Sep 2016, at 12:03, Michael Paquier wrote: >>> >>> On Tue, Sep 6, 2016 at 5:58 PM, Stas Kelvich >>> wrote: Oh, I was preparing new version of

Re: [HACKERS] Forbid use of LF and CR characters in database and role names

On Wed, Sep 7, 2016 at 2:32 AM, Tom Lane wrote: > I think probably a better answer is to reject bad paths earlier, eg have > initdb error out before doing anything if the proposed -D path contains > CR/LF. Yes, that's a bug that we had better address. It is not nice to not

Re: [HACKERS] [PATCH] Alter or rename enum value

> Bottom line here is that I'd rather commit ALTER TYPE RENAME VALUE with > no EXISTS features and then see it accrete those features together with > other types of RENAME, when and if there's a will to make that happen. This sounds like a good conclusion to me. -- Sent via pgsql-hackers

Re: [HACKERS] Stopping logical replication protocol

>Review comments on the 2nd patch, i.e. the 2nd half of your original patch: > >* Other places in logical decoding use the CB suffix for callback >types. This should do the same. > >* I'm not too keen on the name is_active for the callback. We >discussed the name continue_decoding_cb in our prior

Re: [HACKERS] Supporting SJIS as a database encoding

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kyotaro > Thanks, by the way, there's another issue related to SJIS conversion. MS932 > has several characters that have multiple code points. By converting texts > in this encoding to and from

Re: [HACKERS] patch: function xmltable

On 7 September 2016 at 14:44, Pavel Stehule wrote: >> >> Suggested comment: >> >> /* >> * This is the parsenode for a column definition in a table-expression >> like XMLTABLE. >> * >> * We can't re-use ColumnDef here; the utility command column >> definition has all

Re: [HACKERS] Supporting SJIS as a database encoding

Hello, At Tue, 6 Sep 2016 03:43:46 +, "Tsunakawa, Takayuki" wrote in <0A3221C70F24FB45833433255569204D1F5E66CE@G01JPEXMBYT05> > > From: pgsql-hackers-ow...@postgresql.org > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kyotaro > > HORIGUCHI >

Re: [HACKERS] Optimization for lazy_scan_heap

On 7 September 2016 at 04:13, Masahiko Sawada wrote: > Since current HEAD could scan visibility map twice, the execution time > of Patched is approximately half of HEAD. Sounds good. To ensure we are doing exactly same amount of work as before, did you see the output of

Re: [HACKERS] GiST penalty functions [PoC]

Oh, sorry, made one more attemp and now I see your algorithm differently. So you propose to use oE and oV as a markers of borders for what I call Realm. But there may be very little significant bits in one of this ranges. pg_sphere and PostGiS extensions tried to use 1 as a marker, with alike

Re: [HACKERS] GiST penalty functions [PoC]

On 09/07/2016 09:42 AM, Andrew Borodin wrote: 2. Your algorithm, among loosing some bits of precision (which is absolutely acceptable - we have like 31 of them and that’s a lot) rely on false assumption. We compare tuples on page not by MBR of inserted tuple, but by MBR of tuple on page, which

[HACKERS] Illegal SJIS mapping

Hi, I found an useless entry in utf8_to_sjis.map > {0xc19c, 0x815f}, which is apparently illegal as UTF-8 which postgresql deliberately refuses. So it should be removed and the attached patch does that. 0x815f(SJIS) is also mapped from 0xefbcbc(U+FF3C FULLWIDTH REVERSE SOLIDUS) and it is a

Re: [HACKERS] patch: function xmltable

> > > Suggested comment: > > /* > * This is the parsenode for a column definition in a table-expression > like XMLTABLE. > * > * We can't re-use ColumnDef here; the utility command column > definition has all the > * wrong attributes for use in table-expressions and just doesn't make > sense

Re: [HACKERS] GiST penalty functions [PoC]

Hi Heikki! Thank you for reviewing the code, it's always inspiring when a work is noted (: >Looking at the code, by "margin", you mean the sum of all "edges", i.e. of each dimension, of the cube. Indeed. As far as I remember, this is a terminology of old R*-tree paper. Now they use the word

Re: [HACKERS] Let file_fdw access COPY FROM PROGRAM

On 2016/09/07 12:29, Corey Huinker wrote: > On Tue, Sep 6, 2016 at 9:46 PM, Amit Langote wrote: >> OK. > Well...maybe not, depending on what Craig and other can do to educate me > about the TAP tests. Sure. >>> Changing table-level options requires superuser privileges, for security >>> reasons:

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

On Tue, Sep 6, 2016 at 11:09 PM, Heikki Linnakangas wrote: >> The big picture here is that you can't only USEMEM() for tapes as the >> need arises for new tapes as new runs are created. You'll just run a >> massive availMem deficit, that you have no way of paying back, because >>

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

On 09/07/2016 09:01 AM, Peter Geoghegan wrote: On Tue, Sep 6, 2016 at 10:57 PM, Peter Geoghegan wrote: There isn't much point in that, because those buffers are never physically allocated in the first place when there are thousands. They are, however, entered into the

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

On Tue, Sep 6, 2016 at 10:57 PM, Peter Geoghegan wrote: > There isn't much point in that, because those buffers are never > physically allocated in the first place when there are thousands. They > are, however, entered into the tuplesort.c accounting as if they were, > denying