Re: [HACKERS] Releasing in September

Hi, On 2016-01-26 00:26:18 -0600, Joshua Berkus wrote: > Let's do quarterly development releases and supported production > releases every 18 months. > A 3-month release cycle would let people see their code go into the wild a > lot faster; basically we'd do a CF then a development release.

Re: [HACKERS] Why format() adds double quote?

> 2016-01-24 8:04 GMT-02:00 Tatsuo Ishii : >>> On Wed, Jan 20, 2016 at 4:20 AM, Pavel Stehule >>> wrote: > If we would go this way, question is if we should back patch this or > not since the patch apparently changes the existing >

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On 1/21/16, Pavel Stehule wrote: > 2016-01-14 17:16 GMT+01:00 Catalin Iacob : >> Consider this call chain: SQL code 1 -> PL/Python code 1 -> SPI (via >> plpy.execute) -> SQL code 2 -> PL/Python code 2 >> >> If I'm writing PL/Python code 1 and I

[HACKERS] CustomScan under the Gather node?

Hello, What enhancement will be necessary to implement similar feature of partial seq-scan using custom-scan interface? It seems to me callbacks on the three points below are needed. * ExecParallelEstimate * ExecParallelInitializeDSM * ExecParallelInitializeWorker Anything else? Does

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-26 8:22 GMT+01:00 Pavel Stehule : > > > 2016-01-26 7:31 GMT+01:00 Catalin Iacob : > >> On 1/21/16, Pavel Stehule wrote: >> > 2016-01-14 17:16 GMT+01:00 Catalin Iacob : >> >> Consider this

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Wed, Jan 20, 2016 at 6:39 PM, Robert Haas wrote: > > On Tue, Jan 19, 2016 at 11:49 PM, Amit Kapila wrote: > >> On the topic of the UI, I understand that redefining > >> pg_stat_activity.waiting might cause some short-term annoyance. But I > >>

Re: [HACKERS] custom function for converting human readable sizes to bytes

Hello! I have reviewed this patch. It applies and compiles cleanly at the current master 1129c2b0ad2732f301f696ae2cf98fb063a4c1f8 and implements the behavior reached by a consensus. All size units (the same as used in the GUC) are supported. The documentation is present and describes behavior

Re: [HACKERS] Releasing in September

All, So the proximate cause of late releases are the following: 1. patches are getting kicked down the road from one CF to another, creating a big pileup in the final CF. This is exactly like the huge pile of unreviewed patches we used to have before the CF system. 2. Once the last CF is

Re: [HACKERS] Releasing in September

On 01/26/2016 02:09 AM, Peter Eisentraut wrote: > On 1/25/16 2:48 AM, Torsten Zühlsdorff wrote: >> In FreeBSD for example there is an online tool for review >> (http://review.freebsd.org) which was opened to public. There you can >> review any code, left comments in the parts you wanted, submit

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-26 7:31 GMT+01:00 Catalin Iacob : > On 1/21/16, Pavel Stehule wrote: > > 2016-01-14 17:16 GMT+01:00 Catalin Iacob : > >> Consider this call chain: SQL code 1 -> PL/Python code 1 -> SPI (via > >> plpy.execute) -> SQL

Re: [HACKERS] why pg_size_pretty is volatile?

2016-01-26 2:00 GMT+01:00 Michael Paquier : > On Tue, Jan 26, 2016 at 5:35 AM, Pavel Stehule > wrote: > > Vitaly Burovoy pointed on bug in my patch - a pg_size_bytes was VOLATILE > > function. It is copy/paste bug - I used pg_size_pretty

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On 25 January 2016 at 09:55, Tomas Vondra wrote: > Imagine for example a script that in some rare cases passes happens to > pass infinity into generate_series() - in that case I'd much rather error > out than wait till the end of the universe. > > So +1 from me to

Re: [HACKERS] custom function for converting human readable sizes to bytes

Hi 2016-01-26 6:25 GMT+01:00 Vitaly Burovoy : > Hello! > > > Regression tests are present (see p.II). > > pg_proc.h has changed, so the CATALOG_VERSION_NO must be also changed. > this is not a part of patch - only a commiter knows CATALOG_VERSION_NO > > Code

Re: [HACKERS] silent data loss with ext4 / all current versions

On Mon, Jan 25, 2016 at 6:50 PM, Tomas Vondra wrote: > Seems OK to me. Thanks for the time and improvements! Thanks. Perhaps a committer could have a look then? I have switched the patch as such in the CF app. Seeing the accumulated feedback upthread that's

Re: [HACKERS] Releasing in September

On Fri, Jan 22, 2016 at 1:16 PM, Simon Riggs wrote: > It has one important effect of current interest: establishing the truth that > multiple people and multiple companies are involved in producing and > maintaining PostgreSQL. Whether the names are properly attributed will

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 01:59:59PM -0800, Peter Geoghegan wrote: > I think that we've learned some lessons from the problems with 9.3. I > don't think that one of those lessons was "take more time to release". > There is reason to doubt that that would have changed matters one bit > with 9.3. It

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Mon, Jan 25, 2016 at 2:07 AM, Tom Lane wrote: > Corey Huinker writes: > > Incidentally, is there a reason behind the tendency of internal functions > > to avoid parameter defaults in favor of multiple pg_proc entries? > > Yes: you can't specify

Re: [HACKERS] WIP: Failover Slots

On 23 January 2016 at 00:40, Robert Haas wrote: > It occurred to me to wonder if it might be better to > propagate logical slots partially or entirely outside the WAL stream, > because with this design you will end up with the logical slots on > every replica, including

Re: [HACKERS] Improved tab completion for FDW DDL

On 01/23/2016 01:03 PM, Peter Eisentraut wrote: committed Thanks! Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WIP: Failover Slots

On 23 January 2016 at 00:51, Andres Freund wrote: > Not propagating them through the WAL also has the rather large advantage > of not barring the way to using such slots on standbys. > Yeah. So you could have a read-replica that has a slot and it has child nodes you can

[HACKERS] why pg_size_pretty is volatile?

Hi Vitaly Burovoy pointed on bug in my patch - a pg_size_bytes was VOLATILE function. It is copy/paste bug - I used pg_size_pretty definition, so the question is: why pg_size_pretty is volatile? It should be immutable too. Regards Pavel

Re: [HACKERS] Unbreak mbregression test

Tatsuo Ishii writes: > The multi-byte regression tests (src/test/regress/mb) have been broken > for sometime due to a warning message regarding hash index usage "hash > indexes are not WAL-logged and their use is discouraged" (the messages > are different from version to

Re: [HACKERS] Patch: ResourceOwner optimization for tables with many partitions

> Um, that's not too surprising, because they're exactly the same patch? Wrong diff. Here is correct one. Everything else is right. I just re-checked :) step2a: number of transactions actually processed: 16325 latency average: 49.008 ms latency stddev: 8.780 ms tps = 163.182594 (including

Re: [HACKERS] [POC] FETCH limited by bytes.

On Mon, Jan 25, 2016 at 1:21 PM, Corey Huinker wrote: >> - We could consider folding fetch_size into "Remote Execution >> Options", but maybe that's too clever. > > If you care to explain, I'm listening. Otherwise I'm going forward with the > other suggestions you've

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sat, Jan 23, 2016 at 11:22 AM, Tomas Vondra wrote: > Hi, > > On 01/20/2016 10:49 PM, Alvaro Herrera wrote: > >> >> Tom, are you reviewing this for the current commitfest? >> > > While I'm not the right Tom, I've been looking the the patch recently, so > let me

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

I want to treat 'prepare' operation as an optimization step, so it is functionally equivalent to sending a query text. In other words, I would like backend to track search_path and other parameters if necessary transparently‎, creating (caching) different execution plans if different plans are

Re: [HACKERS] 2016-01 Commitfest

Robert Haas writes: > On Mon, Jan 25, 2016 at 11:36 AM, Alvaro Herrera > wrote: >> Four "Moved to next commitfest" >> * https://commitfest.postgresql.org/8/129/ >> Unique Joins > I've been hoping Tom would pick this up. If he doesn't, I will

[HACKERS] Unbreak mbregression test

The multi-byte regression tests (src/test/regress/mb) have been broken for sometime due to a warning message regarding hash index usage "hash indexes are not WAL-logged and their use is discouraged" (the messages are different from version to version). Attached is a patch to fix the problem for

Re: [HACKERS] Patch: ResourceOwner optimization for tables with many partitions

Hello, Tom > Also, there are defined ways to convert between Datum format and > other formats (DatumGetPointer() etc). This code isn't using 'em. Fixed. But I was not sure how to deal with File and Buffer types since they are ints (see fd.h and buf.h) and there is no DatumGetInt macro, only

Re: [HACKERS] File based Incremental backup v8

On Tue, Mar 10, 2015 at 08:25:27AM +0900, Michael Paquier wrote: > On Tue, Mar 10, 2015 at 1:50 AM, Robert Haas wrote: > > I think there's absolutely no point in spending more time on this for > > 9.5. At least 4 committers have looked at it and none of them are > >

Re: [HACKERS] Releasing in September

On Mon, Jan 25, 2016 at 9:51 AM, Noah Misch wrote: > This signal is common, particularly for smaller patches, and it ought to > remain common. The product would advance slowly if every contrib module or > vacuumdb flag took full attention from two committers. Every release

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Thu, Jan 21, 2016 at 8:36 AM, Ashutosh Bapat wrote: >> What this patch does to the naming and calling conventions in >> deparse.c does not good. Previously, we had deparseTargetList(). >> Now, we sometimes use that and sometimes deparseAttrsUsed() for almost

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Thu, Jan 21, 2016 at 12:47 AM, Ashutosh Bapat wrote: >> Well, we kind of need to get it right, not just be guessing. >> >> It looks to me as though GetConnection() only uses the user ID as a >> cache lookup key. What it's trying to do is ensure that if user A

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Hi 2016-01-22 19:53 GMT+01:00 Daniel Verite : > Hi, > > Here's an updated patch improving on how the horizontal and vertical > headers can be sorted. > > The discussion upthread went into how it was desirable > to have independant sorts for these headers, possibly

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

On Mon, Jan 25, 2016 at 12:47 PM, Andres Freund wrote: > On 2016-01-25 12:39:29 -0500, Robert Haas wrote: >> What is the ideal behavior, in your view? > > FWIW, I think that for a lot of practical cases the previous behaviour, > where a prepared statement was defined in the

Re: [HACKERS] is there a deep unyielding reason to limit U&'' literals to ASCII?

Robert Haas writes: > On Sat, Jan 23, 2016 at 11:27 PM, Chapman Flack wrote: >> What I would have expected would be to allow s >> for any Unicode codepoint that's representable in the server encoding, >> whatever encoding that is. > I don't know

Re: [HACKERS] Patch: ResourceOwner optimization for tables with many partitions

Aleksander Alekseev writes: > I compared two implementations - "always use hashing" (step2a.path) and > "use hashing only for large arrays" (step2b.path). Both patches give > the same performance according to benchmark I described in a first > message of this thread.

Re: [HACKERS] 2016-01 Commitfest

On 2016-01-25 13:36:04 -0300, Alvaro Herrera wrote: > We still have 41 patches that haven't gotten enough review though. The > bad part about it is that there's a number of patches that have been > bouncing for many commitfests now. Here's a list of the patches with > the most such actions (both

Re: [HACKERS] 2016-01 Commitfest

Andres Freund wrote: > On 2016-01-25 13:36:04 -0300, Alvaro Herrera wrote: > > We still have 41 patches that haven't gotten enough review though. The > > bad part about it is that there's a number of patches that have been > > bouncing for many commitfests now. Here's a list of the patches with

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

On Thu, Jan 21, 2016 at 3:55 PM, Vladimir Sitnikov wrote: > Robert>Are you really seeing the same behavior in all versions? > > I do not have "pre 9.1" at hand, however all 9.1, 9.2, 9.3, 9.4, and > 9.5 are affected. > > 9.1 just silently executes "old statement" as

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

Andres Freund writes: > On 2016-01-25 12:39:29 -0500, Robert Haas wrote: >> What is the ideal behavior, in your view? > FWIW, I think that for a lot of practical cases the previous behaviour, > where a prepared statement was defined in the context of the search path > set

Re: [HACKERS] 2016-01 Commitfest

Into its third week, this commitfest is looking like this: Needs review: 41. Waiting on Author: 24. Ready for Committer: 10. Committed: 23. Rejected: 1. Total: 99. The number of committed patches continues to grow slowly but steadily, which is a good sign -- and in the past week it grew

Re: [HACKERS] is there a deep unyielding reason to limit U&'' literals to ASCII?

On Sat, Jan 23, 2016 at 11:27 PM, Chapman Flack wrote: > I see in the documentation (and confirm in practice) that a > Unicode character string literal U&'...' is only allowed to have > s representing Unicode characters if the > server encoding is, exactly and only, UTF8. >

Re: [HACKERS] [POC] FETCH limited by bytes.

On Thu, Dec 31, 2015 at 1:10 AM, Corey Huinker wrote: > Here's a re-based patch. Notable changes since the last patch are: > > - some changes had to move to postgres_fdw.h > - the regression tests are in their own script fetch_size.sql / > fetch_size.out. that should make

Re: [HACKERS] 2016-01 Commitfest

On 2016-01-25 15:02:02 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > On 2016-01-25 13:36:04 -0300, Alvaro Herrera wrote: > > > * https://commitfest.postgresql.org/8/260/ > > > checkpoint continuous flushing > > > > FWIW, I've been working and benchmarking this a lot over the last > >

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

On 2016-01-25 12:39:29 -0500, Robert Haas wrote: > What is the ideal behavior, in your view? FWIW, I think that for a lot of practical cases the previous behaviour, where a prepared statement was defined in the context of the search path set during the PREPARE, made a lot more sense. The current

Re: [HACKERS] [POC] FETCH limited by bytes.

> > > Review: > > - There is an established idiom in postgres_fdw for how to extract > data from lists of DefElems, and this patch does something else > instead. Please make it look like postgresIsForeignRelUpdatable, > postgresGetForeignRelSize, and postgresImportForeignSchema instead of >

Re: [HACKERS] custom function for converting human readable sizes to bytes

Hi 2016-01-22 7:03 GMT+01:00 Vitaly Burovoy : > On 1/20/16, Pavel Stehule wrote: > > ... > > New version is attached > > > > Regards > > Pavel > > Hello! > > 1. Why the function is marked as VOLATILE? It depends only on input > value, it does

Re: [HACKERS] [POC] FETCH limited by bytes.

On Mon, Jan 25, 2016 at 3:22 PM, Robert Haas wrote: > On Mon, Jan 25, 2016 at 1:21 PM, Corey Huinker > wrote: > >> - We could consider folding fetch_size into "Remote Execution > >> Options", but maybe that's too clever. > > > > If you care to

Re: [HACKERS] 2016-01 Commitfest

Hello Andres, FWIW, I've been working and benchmarking this a lot over the last weeks. I'm running a lot of tests as weel, on HDDs. It is basically always better with the patch, although sometimes not sorting but flushing is better than both, which suggest that the gucs should be kept just

Re: [HACKERS] Unbreak mbregression test

> Tatsuo Ishii writes: >> The multi-byte regression tests (src/test/regress/mb) have been broken >> for sometime due to a warning message regarding hash index usage "hash >> indexes are not WAL-logged and their use is discouraged" (the messages >> are different from version

Re: [HACKERS] count_nulls(VARIADIC "any")

2016-01-22 13:34 GMT+01:00 Jim Nasby : > On 1/21/16 1:48 PM, Pavel Stehule wrote: > >> the form of regress tests is not pretty significant issue. Jim's >> design is little bit transparent, Marko's is maybe little bit >> practical. Both has sense from my

Re: [HACKERS] 2016-01 Commitfest

On Mon, Jan 25, 2016 at 11:36 AM, Alvaro Herrera wrote: > We still have 41 patches that haven't gotten enough review though. The > bad part about it is that there's a number of patches that have been > bouncing for many commitfests now. Here's a list of the patches

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Mon, Jan 25, 2016 at 6:55 PM, Tomas Vondra wrote: > On 01/25/2016 07:22 AM, Tom Lane wrote: >> >> Michael Paquier writes: >>> >>> On Mon, Jan 25, 2016 at 3:00 PM, Corey Huinker >>> wrote: One thing I

Re: [HACKERS] File based Incremental backup v8

On Tue, Jan 26, 2016 at 12:55 AM, David Fetter wrote: > On Tue, Mar 10, 2015 at 08:25:27AM +0900, Michael Paquier wrote: >> On Tue, Mar 10, 2015 at 1:50 AM, Robert Haas wrote: >> > I think there's absolutely no point in spending more time on this for >> >

Re: [HACKERS] why pg_size_pretty is volatile?

On Tue, Jan 26, 2016 at 5:35 AM, Pavel Stehule wrote: > Vitaly Burovoy pointed on bug in my patch - a pg_size_bytes was VOLATILE > function. It is copy/paste bug - I used pg_size_pretty definition, so the > question is: why pg_size_pretty is volatile? It should be

Re: [HACKERS] Unbreak mbregression test

Reverting done. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp >> Tatsuo Ishii writes: >>> The multi-byte regression tests (src/test/regress/mb) have been broken >>> for sometime due to a

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

Hi Vinayak, On 2016/01/25 20:58, Vinayak Pokale wrote: > Hi, > > Please find attached updated patch with an updated interface. > Thanks for updating the patch. > I added the below interface to update the > scanned_heap_pages,scanned_index_pages and index_scan_count only. > void

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

Sorry for my late response. I've been unavailable to have enough time to touch code for the last 1.5 month. The attached patch is a revised one to handle private data of foregn/custom scan node more gracefully. The overall consensus upthread were: - A new ExtensibleNodeMethods structure defines

Re: [HACKERS] Releasing in September

On 1/25/16 2:48 AM, Torsten Zühlsdorff wrote: > Nobody, but there are different solutions. And the same solutions works > different in quality and quantity in the different projects. > In FreeBSD for example there is an online tool for review > (http://review.freebsd.org) which was opened to

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Thu, Jan 21, 2016 at 3:20 PM, Etsuro Fujita wrote: > On 2016/01/20 19:57, Rushabh Lathia wrote: > >> Overall I am quite done with the review of this patch. Patch is in good >> shape and covered most of the things which been discussed earlier >> or been mentioned

Re: [HACKERS] Releasing in September

On 20.01.2016 22:37, Peter Eisentraut wrote: On 1/20/16 1:44 PM, Robert Haas wrote: And, you know, I did my time fighting major wars to try to compress the release schedule, and honestly, it wasn't that much fun. The process we have now is imperfect in many ways, but I no longer have abuse

Re: [HACKERS] Batch update of indexes

On 21.01.2016 18:47, Konstantin Knizhnik wrote: On 21.01.2016 19:09, Anastasia Lubennikova wrote: What I meant is more like a BRIN-like combination of an index scan and heap scan. Maybe it could be called "deferred inserts" or "temporary read-only index" Maybe it's similar with mysql insert

Re: [HACKERS] silent data loss with ext4 / all current versions

On 01/25/2016 08:30 AM, Michael Paquier wrote: On Fri, Jan 22, 2016 at 9:32 PM, Michael Paquier wrote: ,,, My first line of thoughts after looking at the patch is that I am not against adding those fsync calls on HEAD as there is roughly an advantage to not go

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On 01/25/2016 07:22 AM, Tom Lane wrote: Michael Paquier writes: On Mon, Jan 25, 2016 at 3:00 PM, Corey Huinker wrote: One thing I discovered in doing this patch is that if you do a timestamp generate_series involving infinityit tries to

Re: [HACKERS] easy way of copying regex_t

On 01/24/2016 10:41 PM, Tom Lane wrote: Artur Zakirov writes: With this message I want to send some patch to your repository with draft of a code, which allows shared_ispell to copy regex_t. Allowing ispell.c to know that much about regex internals strikes me as

Re: [HACKERS] Declarative partitioning

Hi, On 2016/01/23 3:42, Corey Huinker wrote: >> So for now, you create an empty partitioned table specifying all the >> partition keys without being able to define any partitions in the same >> statement. Partitions (and partitions thereof, if any) will be created >> using CREATE PARTITION

Re: [HACKERS] easy way of copying regex_t

On 25.01.2016 13:07, Tomas Vondra wrote: Right, it's definitely not thread-safe so there'd need to be some lock protecting the regex_t copy. I was thinking about either using a group of locks, each protecting a small subset of the affixes (thus making it possible to work in parallel to some

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

Hi, Please find attached updated patch with an updated interface. I added the below interface to update the scanned_heap_pages,scanned_index_pages and index_scan_count only. void pgstat_report_progress_scanned_pages(int num_of_int, uint32 *progress_scanned_pages_param) Other interface functions

Re: [HACKERS] [Proposal] Table partition + join pushdown

> On Tue, Jan 19, 2016 at 7:59 AM, Greg Stark wrote: > > On Mon, Jan 18, 2016 at 5:55 PM, Robert Haas wrote: > >> For > >> example, suppose that x and y are numeric columns and P(x) is > >> length(x::text) == 3. Then you could have 1 in one table and 1.0 in

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

Hi Amit, Thank you for reviewing the patch. On Jan 26, 2016 9:51 AM, "Amit Langote" wrote: > > > Hi Vinayak, > > On 2016/01/25 20:58, Vinayak Pokale wrote: > > Hi, > > > > Please find attached updated patch with an updated interface. > > > > Thanks for updating the