Re: [HACKERS] pg_basebackup vs. Windows and tablespaces

On Sat, Dec 13, 2014 at 10:48 PM, Tom Lane wrote: > > Andrew Dunstan writes: > > On 11/20/2014 02:27 AM, Amit Kapila wrote: > >> Now the part where I would like to receive feedback before revising the > >> patch is on the coding style. It seems to me from Tom's comments that > >> he is not happy

Re: [HACKERS] Commitfest problems

On 13/12/14 22:37, Craig Ringer wrote: On 12/12/2014 06:02 AM, Josh Berkus wrote: Speaking as the originator of commitfests, they were *always* intended to be a temporary measure, a step on the way to something else like continuous integration. I'd really like to see the project revisit some

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Sun, Dec 14, 2014 at 1:16 PM, Andres Freund wrote: > On 2014-12-14 09:56:59 +0900, Michael Paquier wrote: >> On Sun, Dec 14, 2014 at 5:45 AM, Simon Riggs wrote: >> > On 13 December 2014 at 14:36, Michael Paquier >> > wrote: >> > >> >> Something to be aware of btw is that this patch introduce

Re: [HACKERS] pgbench -f and vacuum

On 14 December 2014 at 13:50, Jim Nasby wrote: > > On 12/13/14, 6:17 PM, Tatsuo Ishii wrote: > >> Problem with "-f implies -n" approach is, it breaks backward >> compatibility. There are use cases using custom script*and* pgbench_* >> tables. For example the particular user wants to use the stand

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On 2014-12-14 09:56:59 +0900, Michael Paquier wrote: > On Sun, Dec 14, 2014 at 5:45 AM, Simon Riggs wrote: > > On 13 December 2014 at 14:36, Michael Paquier > > wrote: > > > >> Something to be aware of btw is that this patch introduces an > >> additional 8 bytes per block image in WAL as it cont

Re: [HACKERS] pgbench -f and vacuum

> If we care enough about that case to attempt the vacuum anyway then we > need to do something about the error message; either squelch it or > check for the existence of the tables before attempting to > vacuum. Since there's no way to squelch in the server logfile, I think > checking for the tabl

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Sun, Dec 14, 2014 at 5:45 AM, Simon Riggs wrote: > On 13 December 2014 at 14:36, Michael Paquier > wrote: > >> Something to be aware of btw is that this patch introduces an >> additional 8 bytes per block image in WAL as it contains additional >> information to control the compression. In thi

Re: [HACKERS] pgbench -f and vacuum

On 12/13/14, 6:17 PM, Tatsuo Ishii wrote: Problem with "-f implies -n" approach is, it breaks backward compatibility. There are use cases using custom script*and* pgbench_* tables. For example the particular user wants to use the standard pgbench tables and is not satisfied with the built in sce

Re: [HACKERS] split builtins.h to quote.h

On Sun, Dec 14, 2014 at 1:00 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 11/08/2014 12:37 AM, Michael Paquier wrote: >>> Well, yes :) I missed that. Note that I am leaning to Robert's >>> direction as well to do a clear separation... Now if the final >>> consensus is different, then let's

Re: [HACKERS] On partitioning

On Sun, Dec 14, 2014 at 1:40 AM, José Luis Tallón wrote: > On 12/12/2014 05:43 AM, Amit Langote wrote: > > Amit: mind if I add the DB2 syntax for partitioning to the wiki, too? > > This might as well help with deciding the final form of partitioning > (and define the first implementation bound

Re: [HACKERS] On partitioning

On Sun, Dec 14, 2014 at 1:57 AM, José Luis Tallón wrote: > On 12/13/2014 03:09 AM, Alvaro Herrera wrote: >> >> [snip] >> Arbitrary SQL expressions (including functions) are not the thing to use >> for partitioning -- at least that's how I understand this whole >> discussion. I don't think you wan

Re: [HACKERS] pgbench -f and vacuum

> On 14 December 2014 at 04:39, Tom Lane wrote: >> >> Tatsuo Ishii writes: >> > Currently pgbench -f (run custom script) executes vacuum against >> > pgbench_* tables before stating bench marking if -n (or --no-vacuum) >> > is not specified. If those tables do not exist, pgbench fails. To >> > pr

Re: [HACKERS] operator does not exist: character varying[] <> character[]

On 12/12/14, 7:16 PM, Tom Lane wrote: Jim Nasby writes: I'd say that array_eq (and probably _cmp) just needs to be taught to fall back to what oper() does, but this part of the commit message gives me pause: "Change the operator search algorithms to look for appropriate btree or hash index

Re: [HACKERS] CINE in CREATE TABLE AS ... and CREATE MATERIALIZED VIEW ...

Em sábado, 13 de dezembro de 2014, Andrew Dunstan escreveu: > > On 11/03/2014 07:35 AM, Fabrízio de Royes Mello wrote: > >> On Mon, Nov 3, 2014 at 3:12 AM, Rushabh Lathia > > wrote: >> > >> > Patch looks good, assigning to committer. >> > >> >> Thanks for your rev

Re: [HACKERS] pgbench -f and vacuum

On 14 December 2014 at 04:39, Tom Lane wrote: > > Tatsuo Ishii writes: > > Currently pgbench -f (run custom script) executes vacuum against > > pgbench_* tables before stating bench marking if -n (or --no-vacuum) > > is not specified. If those tables do not exist, pgbench fails. To > > prevent th

[HACKERS] PATCH: Reducing lock strength of trigger and foreign key DDL

Hi, I have attached a patch with the current status of my work on reducing the lock level of trigger and foreign key related DDL. This commit reduces the lock level of the following commands from ACCESS EXCLUSIVE to SHARE ROW EXCLUSIVE, plus that it does the same for the referred table of th

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On 13 December 2014 at 14:36, Michael Paquier wrote: > Something to be aware of btw is that this patch introduces an > additional 8 bytes per block image in WAL as it contains additional > information to control the compression. In this case this is the > uint16 compress_len present in XLogRecord

Re: [HACKERS] Commitfest problems

On 12/12/14 20:43, Josh Berkus wrote: On 12/12/2014 11:35 AM, Alvaro Herrera wrote: Uh, really? Last I looked at the numbers from SPI treasurer reports, they are not impressive enough to hire a full-time engineer, let alone a senior one. The Linux Foundation has managed to pay for Linus Torva

Re: [HACKERS] CINE in CREATE TABLE AS ... and CREATE MATERIALIZED VIEW ...

On 11/03/2014 07:35 AM, Fabrízio de Royes Mello wrote: On Mon, Nov 3, 2014 at 3:12 AM, Rushabh Lathia mailto:rushabh.lat...@gmail.com>> wrote: > > Patch looks good, assigning to committer. > Thanks for your review! Committed. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-

Re: [HACKERS] On partitioning

On 12/13/2014 05:57 PM, José Luis Tallón wrote: On 12/13/2014 03:09 AM, Alvaro Herrera wrote: [snip] Arbitrary SQL expressions (including functions) are not the thing to use for partitioning -- at least that's how I understand this whole discussion. I don't think you want to do "proofs" as such

Re: [HACKERS] add modulo (%) operator to pgbench

On 12/13/2014 01:19 PM, Fabien COELHO wrote: As it doesn't have documentation, I'm inclined to say we should mark this as Waiting on Author or Returned with Feedback. I'm planing to have a detailed look at Robert's patch before the end of the year. I could update pgbench documentation while

Re: [HACKERS] add modulo (%) operator to pgbench

As it doesn't have documentation, I'm inclined to say we should mark this as Waiting on Author or Returned with Feedback. I'm planing to have a detailed look at Robert's patch before the end of the year. I could update pgbench documentation while doing that. -- Fabien. -- Sent via pgsql-h

Re: [HACKERS] On partitioning

On Fri, Dec 12, 2014 at 09:03:12AM -0500, Robert Haas wrote: > Yeah, range and list partition definitions are very similar, but > hash partition definitions are a different kettle of fish. I don't > think we really need hash partitioning for anything right away - > it's pretty useless unless you'

Re: [HACKERS] On partitioning

On 12/12/14, 3:48 PM, Robert Haas wrote: On Fri, Dec 12, 2014 at 4:28 PM, Jim Nasby wrote: Sure. Mind you, I'm not proposing that the syntax I just mooted is actually for the best. What I'm saying is that we need to talk about it. Frankly, if we're going to require users to explicitly defin

Re: [HACKERS] pg_rewind in contrib

On Fri, Dec 12, 2014 at 10:06:32AM -0500, Tom Lane wrote: > Heikki Linnakangas writes: > > I'd like to include pg_rewind in contrib. > > I don't object to adding the tool as such, but let's wait to see > what happens with Peter's proposal to move contrib command-line > tools into src/bin/. If it

Re: [HACKERS] pg_basebackup vs. Windows and tablespaces

Andrew Dunstan writes: > On 11/20/2014 02:27 AM, Amit Kapila wrote: >> Now the part where I would like to receive feedback before revising the >> patch is on the coding style. It seems to me from Tom's comments that >> he is not happy with the code, now I am not sure which part of the patch >> he

Re: [HACKERS] moving Orafce from pgFoundry - pgFoundry management

On Sat, Dec 13, 2014 at 11:19:08AM +0100, Pavel Stehule wrote: > Hi > > a Orafce package on pgFoundry is obsolete - we migrated to github few years > ago. Please, can somebody modify a description about this migration? Or > drop this project there. Pavel, I've removed pgFoundry references from t

Re: [HACKERS] On partitioning

On 12/13/2014 03:09 AM, Alvaro Herrera wrote: [snip] Arbitrary SQL expressions (including functions) are not the thing to use for partitioning -- at least that's how I understand this whole discussion. I don't think you want to do "proofs" as such -- they are expensive. Yup. Plus, it looks lik

Re: [HACKERS] On partitioning

On 12/12/2014 05:43 AM, Amit Langote wrote: [snip] In case of what we would have called a 'LIST' partition, this could look like ... FOR VALUES (val1, val2, val3, ...) Assuming we only support partition key to contain only one column in such a case. Hmmm…. [...] PARTITION BY LIST(col1 [, co

Re: [HACKERS] duplicate #define

On 12/13/2014 04:45 PM, Mark Dilger wrote: In commit 2c03216d831160bedd72d45f712601b6f7d03f1c, the following define occurs twice in src/include/access/xlogrecord.h: #define SizeOfXLogRecordDataHeaderLong (sizeof(uint8) + sizeof(uint32)) It is no big deal, as the definitions don't contradict eac

Re: [HACKERS] add modulo (%) operator to pgbench

On 11/24/2014 07:26 AM, Heikki Linnakangas wrote: On 09/25/2014 05:10 AM, Robert Haas wrote: On Wed, Sep 24, 2014 at 2:34 PM, Fabien COELHO wrote: Sigh. How to transform a trivial 10 lines patch into a probably 500+ lines project involving flex & bison & some non trivial data structures, an

Re: [HACKERS] pg_basebackup vs. Windows and tablespaces

On 11/20/2014 02:27 AM, Amit Kapila wrote: On Wed, Nov 19, 2014 at 11:46 PM, Robert Haas > wrote: > On Tue, Nov 18, 2014 at 9:19 AM, Alvaro Herrera > mailto:alvhe...@2ndquadrant.com>> wrote: > >> Right, but they provide same functionality as symlinks and now we > >>

Re: [HACKERS] split builtins.h to quote.h

Andrew Dunstan writes: > On 11/08/2014 12:37 AM, Michael Paquier wrote: >> Well, yes :) I missed that. Note that I am leaning to Robert's >> direction as well to do a clear separation... Now if the final >> consensus is different, then let's use the patch attached that puts >> the SQL functions to

Re: [HACKERS] split builtins.h to quote.h

On 11/08/2014 12:37 AM, Michael Paquier wrote: On Sat, Nov 8, 2014 at 5:55 AM, Alvaro Herrera wrote: Michael Paquier wrote: On Fri, Nov 7, 2014 at 2:31 AM, Alvaro Herrera wrote: I thought the consensus was that the SQL-callable function declarations should remain in builtins.h -- mainly so

Re: [HACKERS] pgbench -f and vacuum

Tatsuo Ishii writes: > Currently pgbench -f (run custom script) executes vacuum against > pgbench_* tables before stating bench marking if -n (or --no-vacuum) > is not specified. If those tables do not exist, pgbench fails. To > prevent this, -n must be specified. For me this behavior seems insane

Re: [HACKERS] 9.4rc bug in percentile_cont

Andrew Gierth writes: > Just got a report on IRC of a bug in the array version of > percentile_cont; if two of the requested percentiles were between the > same pair of input rows, the result could be wrong or an error would > be generated. Oooh, good catch. > Proposed patch (against current mas

Re: [HACKERS] Status of CF 2014-10 and upcoming 2014-12

On 12/13/2014 10:00 AM, Michael Paquier wrote: Hi all, Looking at the CF app as of today, there is the following status for pending patches: - Needs Review: 18 - Waiting on Author: 1 - Ready for Committer: 8 And the next coming fest that should begin on Monday has this status: - Needs Review:

Re: [HACKERS] [TODO] Track number of files ready to be archived in pg_stat_archiver

On Sat, Dec 13, 2014 at 11:53 PM, Julien Rouhaud wrote: > I agree with you about the problems of the v2 patch I originally sent. > I think this v3 is the right way of keeping track of .ready files, so > it's ok for me. The v3 also still applies well on current head. Simon got a good point mentioni

[HACKERS] Status of CF 2014-10 and upcoming 2014-12

Hi all, Looking at the CF app as of today, there is the following status for pending patches: - Needs Review: 18 - Waiting on Author: 1 - Ready for Committer: 8 And the next coming fest that should begin on Monday has this status: - Needs Review: 34 - Waiting on Author: 3 - Ready for Committer: 1

Re: [HACKERS] [TODO] Track number of files ready to be archived in pg_stat_archiver

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 18/11/2014 08:36, Michael Paquier a écrit : > On Wed, Oct 22, 2014 at 12:50 AM, Brightwell, Adam > wrote: >> Though, I would think that the general desire would be to keep >> the patch relevant ONLY to the necessary changes. I would not >> qualif

[HACKERS] Custom timestamp format in logs

Hi all, This week, we heard about a user willing to use a custom timestamp format across a set of services to improve the debugability of the whole set, Postgres being one of them. Unfortunately datestyle does not take into account the logs. Would it be worth adding a new GUC able to control the t

[HACKERS] duplicate #define

In commit 2c03216d831160bedd72d45f712601b6f7d03f1c, the following define occurs twice in src/include/access/xlogrecord.h: #define SizeOfXLogRecordDataHeaderLong (sizeof(uint8) + sizeof(uint32)) It is no big deal, as the definitions don't contradict each other. We could probably live with just on

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Fri, Dec 12, 2014 at 11:50 PM, Michael Paquier wrote: > > > On Wed, Dec 10, 2014 at 11:25 PM, Bruce Momjian wrote: >> >> On Wed, Dec 10, 2014 at 07:40:46PM +0530, Rahila Syed wrote: >> > The tests ran for around 30 mins.Manual checkpoint was run before each >> > test. >> > >> > Compression W

Re: [HACKERS] Final Patch for GROUPING SETS

> "Tom" == Tom Lane writes: With the high-priority questions out of the way, time to tackle the rest: Tom> My single biggest complaint is about the introduction of struct Tom> GroupedVar. If we stick with that, we're going to have to teach Tom> an extremely large number of places that kn

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On 12 December 2014 at 21:40, Robert Haas wrote: > On Fri, Dec 12, 2014 at 1:51 PM, Simon Riggs wrote: >> What I don't understand is why we aren't working on double buffering, >> since that cost would be paid in a background process and would be >> evenly spread out across a checkpoint. Plus we'd

Re: [HACKERS] Compression of full-page-writes

On Tue, Dec 9, 2014 at 10:45 AM, Amit Kapila wrote: > On Mon, Dec 8, 2014 at 3:17 PM, Simon Riggs wrote: > > > > On 8 December 2014 at 11:46, Michael Paquier wrote: > > > I don't really like those new names, but I'd prefer > > > wal_compression_level if we go down that road with 'none' as defaul

Re: [HACKERS] Reducing lock strength of adding foreign keys

On 10/28/2014 01:33 AM, Noah Misch wrote: ALTER TRIGGER is not bad; like you say, change pg_get_triggerdef_worker() the way commit e5550d5 changed pg_get_constraintdef_worker(). DROP TRIGGER is more difficult. pg_constraint.tgqual of a dropped trigger may reference other dropped objects, which

[HACKERS] moving Orafce from pgFoundry - pgFoundry management

Hi a Orafce package on pgFoundry is obsolete - we migrated to github few years ago. Please, can somebody modify a description about this migration? Or drop this project there. Regards Pavel

[HACKERS] pgbench -f and vacuum

Currently pgbench -f (run custom script) executes vacuum against pgbench_* tables before stating bench marking if -n (or --no-vacuum) is not specified. If those tables do not exist, pgbench fails. To prevent this, -n must be specified. For me this behavior seems insane because "-f" does not necessa

Re: [HACKERS] Commitfest problems

On 12/12/2014 06:01 AM, David G Johnston wrote: > The "patch list" concept should be formalized, and should include a > "targeted release" concept. IMO, the "patch list" concept should be discarded in favour of a "working tree list". At this point, given the challenges the CF process faces, I can

Re: [HACKERS] moving from contrib to bin

Re: Alvaro Herrera 2014-12-12 <20141212203700.gb1...@alvh.no-ip.org> > > Pardon me for not knowing much about Debian packages, but how would > > that work exactly? Is it possible to do make install-client, then > > package the installed files, then rm -rf the install tree, then > > repeat for inst

Re: [HACKERS] Commitfest problems

On 12/12/2014 06:02 AM, Josh Berkus wrote: > > Speaking as the originator of commitfests, they were *always* intended > to be a temporary measure, a step on the way to something else like > continuous integration. I'd really like to see the project revisit some of the underlying assumptions that'

[HACKERS] Making BackgroundWorkerHandle a complete type or offering a worker enumeration API?

Hi all While working on BDR, I've run into a situation that I think highlights a limitation of the dynamic bgworker API that should be fixed. Specifically, when the postmaster crashes and restarts shared memory gets cleared but dynamic bgworkers don't get unregistered, and that's a mess. I have a