Re: [HACKERS] Hot Standby conflict resolution handling

On Thu, Jan 17, 2013 at 12:08 PM, Tom Lane wrote: > > But having said that ... are we sure this code is not actually broken? > I'm not. > ISTM that if we dare not interrupt for fear of confusing OpenSSL, we > cannot safely attempt to send an error message to the client either; > but ereport(FA

Re: [HACKERS] CF3+4 (was Re: Parallel query execution)

On Wed, Jan 16, 2013 at 1:51 PM, Abhijit Menon-Sen wrote: > At 2013-01-16 02:07:29 -0500, t...@sss.pgh.pa.us wrote: > > > > In case you hadn't noticed, we've totally lost control of > > the CF process. > > What can we do to get it back on track? > > I know various people (myself included) have bee

Re: [HACKERS] CF3+4

At 2013-01-17 16:05:05 +0900, michael.paqu...@gmail.com wrote: > > Is it really necessary to create a new commit fest just to move the > items? Marking the patches that are considered as being too late for > 9.3 should be just returned with feedback. Opening 2013-03 is not so much to move existing

Re: [HACKERS] CF3+4

On Thu, Jan 17, 2013 at 3:52 PM, Craig Ringer wrote: > This seems sensible to me. 2012-11 is gone, whether truly finished or > not, and if everyone's OK with it I'd like to move all open work into > 2013-01, close 2012-11, and open 2013-03 for post-9.3 work. That'll at > least provide a place for

Re: [HACKERS] CF3+4

On 01/17/2013 12:48 PM, Abhijit Menon-Sen wrote: > At 2013-01-16 22:40:07 -0500, t...@sss.pgh.pa.us wrote: >> However, since we already missed the scheduling agreed to then, the >> question that's on the table now is what we should do instead. > I suggest we close CF3 and bring the pending CF3 patc

Re: [HACKERS] Hot Standby conflict resolution handling

Abhijit Menon-Sen writes: > Sorry for nitpicking, but "we can't long jumps" made me cringe. Agreed :-( > Here's a slightly more condensed version: I find this still not quite right, because where it's placed, it applies to both the DoingCommandRead and !DoingCommandRead branches of the if/else

Re: [HACKERS] CF3+4

Peter Eisentraut writes: > If you postpone the start of the last commit fest to mid-February, I'd > expect that we will have a much larger number of patches. Since some people seem to be under the impression that new work is still okay to submit now, you have a point ... we are definitely past wh

Re: [HACKERS] tuplesort memory usage: grow_memtuples

Peter Geoghegan writes: > I took another look at this. Since Greg S. seems to have lost interest in committing this, I am picking it up. > My strategy for preventing overflow is to use a uint64, and to use > Min()/Max() as appropriate. As Robert mentioned, even a 64-bit integer > could overflow

Re: [HACKERS] Hot Standby conflict resolution handling

On Thu, Jan 17, 2013 at 9:26 AM, Abhijit Menon-Sen wrote: > At 2012-12-29 14:23:45 -0500, sfr...@snowman.net wrote: > > > > Regarding the actual comment, here's the wording that I'd use: > > Sorry for nitpicking, but "we can't long jumps" made me cringe. > Here's a slightly more condensed version:

Re: [HACKERS] CF3+4

On Wed, 2013-01-16 at 15:13 -0500, Tom Lane wrote: > I think a realistic answer might be to admit that we've slipped quite > a bit. Set the end date of CF3 to perhaps end of January, do triage > the first week of February, and then start CF4 after that, about three > or four weeks later than plann

Re: [HACKERS] bad examples in pg_dump README

On Tue, 2013-01-08 at 19:55 -0700, Josh Kupershmidt wrote: > On Mon, Jan 7, 2013 at 8:12 PM, Peter Eisentraut wrote: > > On Sat, 2013-01-05 at 15:34 +0100, Magnus Hagander wrote: > >> On Fri, Jan 4, 2013 at 3:36 AM, Josh Kupershmidt > >> wrote: > >> > I propose slimming down the pg_dump README,

Re: [HACKERS] CF3+4

At 2013-01-16 22:40:07 -0500, t...@sss.pgh.pa.us wrote: > > However, since we already missed the scheduling agreed to then, the > question that's on the table now is what we should do instead. I suggest we close CF3 and bring the pending CF3 patches into CF4, but still have a triage of CF4 patches

Re: [HACKERS] CF3+4 (was Re: Parallel query execution)

On 01/17/2013 06:01 AM, Robert Haas wrote: > On Wed, Jan 16, 2013 at 12:36 PM, Josh Berkus wrote: >>> I would like to nominate Craig Ringer to be independent CF mgr for Jan2013 >>> CF. >> +1, although I'll suggest that we should have *two* CF managers for this >> one to keep the workload manageab

Re: [HACKERS] Hot Standby conflict resolution handling

At 2012-12-29 14:23:45 -0500, sfr...@snowman.net wrote: > > Regarding the actual comment, here's the wording that I'd use: Sorry for nitpicking, but "we can't long jumps" made me cringe. Here's a slightly more condensed version: /* * We can't use ereport(ERROR) here, because any longjmps

Re: [HACKERS] CF3+4

Simon Riggs writes: > I agree we need triage, and have no problem if you lead that. But lets > wait until early Feb, please. See my later response in the thread, where I corrected my initial recollection (of the first proposal) to be what the meeting minutes say we agreed to. However, since we a

Re: [HACKERS] Parallel query execution

On Wednesday, January 16, 2013, Stephen Frost wrote: > * Bruce Momjian (br...@momjian.us ) wrote: > > I am not sure how a COPY could be easily parallelized, but I supposed it > > could be done as part of the 1GB segment feature. People have > > complained that COPY is CPU-bound, so it might be ve

Re: [HACKERS] Parallel query execution

On Wed, Jan 16, 2013 at 11:56:21PM -0300, Claudio Freire wrote: > On Wed, Jan 16, 2013 at 11:44 PM, Bruce Momjian wrote: > > On Wed, Jan 16, 2013 at 05:04:05PM -0800, Jeff Janes wrote: > >> On Tuesday, January 15, 2013, Stephen Frost wrote: > >> > >> * Gavin Flower (gavinflo...@archidevsys.co.

Re: [HACKERS] pgcrypto seeding problem when ssl=on

On Mon, Jan 14, 2013 at 03:42:42PM +0200, Marko Kreen wrote: > On Mon, Jan 14, 2013 at 3:00 PM, Noah Misch wrote: > > On Mon, Jan 14, 2013 at 02:21:00PM +0200, Marko Kreen wrote: > >> Note: reading from /dev/urandom does not affect /dev/random. > > > > Reading from /dev/urandom drains the pool tha

Re: [HACKERS] Enabling Checksums

On Tue, 2013-01-15 at 19:36 -0500, Greg Smith wrote: > First rev of a simple corruption program is attached, in very C-ish > Python. Great. Did you verify that my patch works as you expect at least in the simple case? > The parameters I settled on are to accept a relation name, byte > offset,

Re: [HACKERS] Removing PD_ALL_VISIBLE

Rebased patch attached. No significant changes. Regards, Jeff Davis rm-pd-all-visible-20130116.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] Parallel query execution

On Wed, Jan 16, 2013 at 11:44 PM, Bruce Momjian wrote: > On Wed, Jan 16, 2013 at 05:04:05PM -0800, Jeff Janes wrote: >> On Tuesday, January 15, 2013, Stephen Frost wrote: >> >> * Gavin Flower (gavinflo...@archidevsys.co.nz) wrote: >> > How about being aware of multiple spindles - so if the

Re: [HACKERS] [PATCH] COPY .. COMPRESSED

On Wed, Jan 16, 2013 at 8:19 PM, Robert Haas wrote: > On Tue, Jan 15, 2013 at 4:50 PM, Tom Lane wrote: >> I find the argument that this supports compression-over-the-wire to be >> quite weak, because COPY is only one form of bulk data transfer, and >> one that a lot of applications don't ever use

Re: [HACKERS] Parallel query execution

On Wed, Jan 16, 2013 at 05:04:05PM -0800, Jeff Janes wrote: > On Tuesday, January 15, 2013, Stephen Frost wrote: > > * Gavin Flower (gavinflo...@archidevsys.co.nz) wrote: > > How about being aware of multiple spindles - so if the requested > > data covers multiple spindles, then data c

Re: [HACKERS] Parallel query execution

On Wed, Jan 16, 2013 at 10:04 PM, Jeff Janes wrote: >> Hmm... >> >> How about being aware of multiple spindles - so if the requested data >> covers multiple spindles, then data could be extracted in parallel. This >> may, or may not, involve multiple I/O channels? > > > > effective_io_concurrency

Re: [HACKERS] log_lock_waits to identify transaction's relation

On 16 January 2013 16:12, Stephen Frost wrote: > * Simon Riggs (si...@2ndquadrant.com) wrote: >> > A couple quick notes regarding the patch- what does >> > GetXactLockTableRelid really provide..? >> >> The ability to access a static variable in a different module. It >> doesn't provide anything ot

Re: [HACKERS] Enabling Checksums

), so if the PD_ALL_VISIBLE patch is committed first then it will make reviewing this patch easier. Regardless, the second patch to be committed will need to be rebased on top of the first. Regards, Jeff Davis replace-tli-with-checksums-20130116.patch.gz Description: GNU Zip compressed

Re: [HACKERS] review: pgbench - aggregation of info written into log

>>> This might be way more than we want to do, but there is an article >>> that describes some techniques for doing what seems to be missing >>> (AIUI): >>> >>> >> Even this would be doable, I'm afraid it may not fit in 9.3 if we >> think abo

Re: [HACKERS] CF3+4

On 16 January 2013 19:28, Tom Lane wrote: > Stephen Frost writes: >> * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: >>> Also, what should he start with? CF3 as it stands today, or CF4 with all >>> of the pending patches moved from CF3, immense though the result may be? >>> I slightly prefer th

Re: [HACKERS] review: pgbench - aggregation of info written into log

On 01/16/2013 08:05 PM, Tatsuo Ishii wrote: It seems instr_time.h on Windows simply does not provide current timestamp. From pgbench.c: /* * if transaction finished, record the time it took in the log */ if (logfile && commands[s

Re: [HACKERS] string escaping in tutorial/syscat.source

On Tuesday, January 15, 2013, Josh Kupershmidt wrote: > On Tue, Jan 15, 2013 at 6:35 PM, Jeff Janes > > > wrote: > > > Do you propose back-patching this? You could argue that this is a bug in > > 9.1 and 9.2. Before that, they generate deprecation warnings, but do > not > > give the wrong answ

Re: [HACKERS] review: pgbench - aggregation of info written into log

>> It seems instr_time.h on Windows simply does not provide current >> timestamp. From pgbench.c: >> >> /* >> * if transaction finished, record the time it took in the log >> */ >> if (logfile && commands[st->state + 1] == NULL) >>

Re: [HACKERS] Parallel query execution

On Tuesday, January 15, 2013, Gavin Flower wrote: > On 16/01/13 11:14, Bruce Momjian wrote: > > I mentioned last year that I wanted to start working on parallelism: > > https://wiki.postgresql.org/wiki/Parallel_Query_Execution > > Years ago I added thread-safety to libpq. Recently I added

Re: [HACKERS] Parallel query execution

On Tuesday, January 15, 2013, Stephen Frost wrote: > * Gavin Flower (gavinflo...@archidevsys.co.nz ) wrote: > > How about being aware of multiple spindles - so if the requested > > data covers multiple spindles, then data could be extracted in > > parallel. This may, or may not, involve multiple I

Re: [HACKERS] review: pgbench - aggregation of info written into log

On 01/16/2013 06:48 PM, Tatsuo Ishii wrote: I'm looking into this as a committer. It seems that this is the newest patch and the reviewer(Pavel) stated that it is ready for commit. However, I noticed that this patch adds a Linux/UNIX only feature(not available on Windows). So I would like to as

Re: [HACKERS] review: pgbench - aggregation of info written into log

>> I'm looking into this as a committer. It seems that this is the >> newest patch and the reviewer(Pavel) stated that it is ready for >> commit. However, I noticed that this patch adds a Linux/UNIX only >> feature(not available on Windows). So I would like to ask cores if >> this is ok or not. >

Re: [HACKERS] Event Triggers: adding information

On Wed, Jan 16, 2013 at 6:14 PM, Tom Lane wrote: > What was discussed at the last dev meeting was assigning a committer to > each large patch to start with, which would reduce the risk of the > goalposts moving that way. It seems to me that Robert's at least > unofficially taken that role for eve

Re: [HACKERS] review: pgbench - aggregation of info written into log

On 01/16/2013 05:59 PM, Tatsuo Ishii wrote: Hi, I'm looking into this as a committer. It seems that this is the newest patch and the reviewer(Pavel) stated that it is ready for commit. However, I noticed that this patch adds a Linux/UNIX only feature(not available on Windows). So I would like

Re: [HACKERS] [PATCH] COPY .. COMPRESSED

On Wed, Jan 16, 2013 at 06:19:09PM -0500, Robert Haas wrote: > On Tue, Jan 15, 2013 at 4:50 PM, Tom Lane wrote: > > I find the argument that this supports compression-over-the-wire to be > > quite weak, because COPY is only one form of bulk data transfer, and > > one that a lot of applications don

Re: [HACKERS] Re: Privileges for INFORMATION_SCHEMA.SCHEMATA (was Re: [DOCS] Small clarification in "34.41. schemata")

2013/1/15 Tom Lane : > Casey Allen Shobe writes: >> On Wed, Jan 9, 2013 at 8:56 PM, Tom Lane wrote: >>> However, it seems to me that this behavior is actually wrong for our >>> purposes, as it represents a too-literal reading of the spec. The SQL >>> standard has no concept of privileges on sche

Re: [HACKERS] [PATCH] COPY .. COMPRESSED

* Bruce Momjian (br...@momjian.us) wrote: > On Wed, Jan 16, 2013 at 06:19:09PM -0500, Robert Haas wrote: > > But presumably this would transparently compress at one end and > > decompress at the other end, which is again a somewhat different use > > case. To get compressed output on the client sid

Re: [HACKERS] [PATCH] COPY .. COMPRESSED

On Tue, Jan 15, 2013 at 4:50 PM, Tom Lane wrote: > I find the argument that this supports compression-over-the-wire to be > quite weak, because COPY is only one form of bulk data transfer, and > one that a lot of applications don't ever use. If we think we need to > support transmission compressi

Re: [HACKERS] Event Triggers: adding information

Dimitri Fontaine writes: > There's a difference between "it's not the way I would have done it" and > "the author didn't think about what he's doing". That's also the reason > why it's very hard to justify sending a polished enough patch as a non > commiter. > And then this patch is like the next

Re: [HACKERS] review: pgbench - aggregation of info written into log

Hi, I'm looking into this as a committer. It seems that this is the newest patch and the reviewer(Pavel) stated that it is ready for commit. However, I noticed that this patch adds a Linux/UNIX only feature(not available on Windows). So I would like to ask cores if this is ok or not. -- Tatsuo Is

Re: [HACKERS] [PATCH] COPY .. COMPRESSED

On Wed, Jan 16, 2013 at 5:15 PM, Robert Haas wrote: > On Tue, Jan 15, 2013 at 3:37 PM, Christopher Browne > wrote: >> That points towards a fix that involves having a set of non-arbitrary >> commands >> that we allow plain users to use. >> >> Hmm. There's an interesting thought... >> >> How ab

Re: [HACKERS] Teaching pg_receivexlog to follow timeline switches

Fujii Masao writes: > Thanks for elaborating the reason why .partial suffix should be kept. > I agree that keeping the .partial suffix would be safer. +1 to both points. So +2 I guess :) Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- S

Re: [HACKERS] [PATCH] COPY .. COMPRESSED

On Tue, Jan 15, 2013 at 3:37 PM, Christopher Browne wrote: > That points towards a fix that involves having a set of non-arbitrary commands > that we allow plain users to use. > > Hmm. There's an interesting thought... > > How about having a "pg_filters" table in pg_catalog which allows capturing

Re: [HACKERS] [PATCH] COPY .. COMPRESSED

On Mon, Jan 14, 2013 at 11:28 AM, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Stephen Frost writes: >> > I do like the idea of a generalized answer which just runs a >> > user-provided command on the server but that's always going to require >> > superuser privileges. >> >> T

Re: [HACKERS] CF3+4 (was Re: Parallel query execution)

On Wed, Jan 16, 2013 at 12:36 PM, Josh Berkus wrote: >> I would like to nominate Craig Ringer to be independent CF mgr for Jan2013 >> CF. > > +1, although I'll suggest that we should have *two* CF managers for this > one to keep the workload manageable. That has never worked before, so I'm reluc

Re: [HACKERS] Parallel query execution

On Wed, Jan 16, 2013 at 07:57:01PM -0200, Dickson S. Guedes wrote: > 2013/1/16 Bruce Momjian : > > Wiki updated: > > > > https://wiki.postgresql.org/wiki/Parallel_Query_Execution > > Could we add CTE to that opportunities list? I think that some kind of > queries in CTE queries could be ea

Re: [HACKERS] Event Triggers: adding information

On Wed, Jan 16, 2013 at 4:16 PM, Dimitri Fontaine wrote: > Ok. Now I want to talk about our process a little. That's a 2 paragraphs > diversion, after that it's getting back to technical matters. > > There's a difference between "it's not the way I would have done it" and > "the author didn't thin

Re: [HACKERS] Parallel query execution

2013/1/16 Bruce Momjian : > Wiki updated: > > https://wiki.postgresql.org/wiki/Parallel_Query_Execution Could we add CTE to that opportunities list? I think that some kind of queries in CTE queries could be easilly parallelized. []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net -

Re: [HACKERS] Parallel query execution

On Wed, Jan 16, 2013 at 10:06:51PM +0100, Pavel Stehule wrote: > 2013/1/16 Stephen Frost : > > * Bruce Momjian (br...@momjian.us) wrote: > >> I am not sure how a COPY could be easily parallelized, but I supposed it > >> could be done as part of the 1GB segment feature. People have > >> complained

Re: [HACKERS] Event Triggers: adding information

Robert Haas writes: > I think this points to a couple of problems: this patch isn't > well-enough thought out, and it's got several features jammed into a > single patch. This should really be split up into several patches and > each one submitted separately. Ok. Now I want to talk about our pro

Re: [HACKERS] Parallel query execution

2013/1/16 Stephen Frost : > * Bruce Momjian (br...@momjian.us) wrote: >> I am not sure how a COPY could be easily parallelized, but I supposed it >> could be done as part of the 1GB segment feature. People have >> complained that COPY is CPU-bound, so it might be very interesting to >> see if we c

Re: [HACKERS] CF3+4

On Wed, Jan 16, 2013 at 03:13:50PM -0500, Tom Lane wrote: > I think a realistic answer might be to admit that we've slipped quite a > bit. Set the end date of CF3 to perhaps end of January, do triage the > first week of February, and then start CF4 after that, about three or > four weeks later tha

Re: [HACKERS] CF3+4

Josh Berkus writes: >> If we decide to fold CF3 and CF4 together, either we lose that step >> (which would make me sad, it seems like a good idea) or we need to >> figure another way to work it into the process. > Well, we should have the triage discussion ASAP then. We were really > supposed to

Re: [HACKERS] [PATCH] COPY .. COMPRESSED

* Peter Eisentraut (pete...@gmx.net) wrote: > On 1/15/13 2:53 PM, Stephen Frost wrote: > > You're right, to clarify, for *file_fdw*, which is a backend-only > > operation, the popen patch is great (thought I made that clear before). > > I would think that if we get writable FDWs, you would want fi

Re: [HACKERS] Parallel query execution

* Bruce Momjian (br...@momjian.us) wrote: > I am not sure how a COPY could be easily parallelized, but I supposed it > could be done as part of the 1GB segment feature. People have > complained that COPY is CPU-bound, so it might be very interesting to > see if we could offload some of that parsin

Re: [HACKERS] [PATCH] COPY .. COMPRESSED

On 1/15/13 2:53 PM, Stephen Frost wrote: > You're right, to clarify, for *file_fdw*, which is a backend-only > operation, the popen patch is great (thought I made that clear before). I would think that if we get writable FDWs, you would want file_fdw to go through zlib so that it can write directl

Re: [HACKERS] CF3+4

> If we decide to fold CF3 and CF4 together, either we lose that step > (which would make me sad, it seems like a good idea) or we need to > figure another way to work it into the process. Well, we should have the triage discussion ASAP then. We were really supposed to have it a week ago. --

Re: [HACKERS] CF3+4

Stephen Frost writes: > * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: >> Also, what should he start with? CF3 as it stands today, or CF4 with all >> of the pending patches moved from CF3, immense though the result may be? >> I slightly prefer the latter, so that we're all on the same page when

Re: [HACKERS] [PATCH 3/5] Split out xlog reading into its own module called xlogreader

Andres Freund wrote: > The way xlog reading was done up to now made it impossible to use that > nontrivial code outside of xlog.c although it is useful for different purposes > like debugging wal (xlogdump) and decoding wal back into logical changes. I have pushed this part after some more editor

Re: [HACKERS] Materialized views WIP patch

> Do we really need unlogged MVs in the first iteration? Seems like > that's adding a whole bunch of new issues, when you have quite enough > already without that. While I think there is strong user demand for unlogged MVs, if we can get MVs without unlogged ones for 9.3, I say go for that. We'

Re: [HACKERS] Materialized views WIP patch

"Kevin Grittner" writes: > Tom Lane wrote: >> Surely that should fall out automatically given that the >> dependency is properly expressed in pg_depend? > The *definitions* sort properly, but what I'm trying to do is > define them WITH NO DATA and load data after all the COPY > statements for tab

Re: [HACKERS] CF3+CF4 WAS: Parallel query execution

> Well, I usually do stuff no one wants to do, and it seems we have people > doing this. Also, I had my hand in deciding lots of things when I was > committing all those patches in the past, so I thought others should get > the chance. Well, we clearly don't have *enough* people committing patch

Re: [HACKERS] CF3+CF4 WAS: Parallel query execution

On Wed, Jan 16, 2013 at 09:50:07AM -0800, Josh Berkus wrote: > > > I assume you know I was the most frequent committer of other people's > > patches for years before the commit-fests started, so I thought I would > > move on to other things. > > Why would you think that? Given the volume of inco

Re: [HACKERS] CF3+CF4 WAS: Parallel query execution

> I assume you know I was the most frequent committer of other people's > patches for years before the commit-fests started, so I thought I would > move on to other things. Why would you think that? Given the volume of incoming patches, we need more committers than ever. -- Josh Berkus Postgre

Re: [HACKERS] CF3+4 (was Re: Parallel query execution)

> I would like to nominate Craig Ringer to be independent CF mgr for Jan2013 CF. +1, although I'll suggest that we should have *two* CF managers for this one to keep the workload manageable. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (

Re: [HACKERS] Parallel query execution

On 01/16/2013 12:20 PM, Bruce Momjian wrote: On Wed, Jan 16, 2013 at 09:05:39AM -0500, Andrew Dunstan wrote: On 01/15/2013 11:32 PM, Bruce Momjian wrote: On Wed, Jan 16, 2013 at 01:28:18PM +0900, Michael Paquier wrote: On Wed, Jan 16, 2013 at 1:22 PM, Josh Berkus wrote: Claudio, Stephe

Re: [HACKERS] Materialized views WIP patch

On 16 January 2013 17:20, Kevin Grittner wrote: > Thom Brown wrote: > > > Some weirdness: > > > > postgres=# CREATE VIEW v_test2 AS SELECT 1 moo; > > CREATE VIEW > > postgres=# CREATE MATERIALIZED VIEW mv_test2 AS SELECT moo, 2*moo FROM > > v_test2 UNION ALL SELECT moo, 3*moo FROM v_test2; > > SE

Re: [HACKERS] Materialized views WIP patch

Thom Brown wrote: > Some weirdness: > > postgres=# CREATE VIEW v_test2 AS SELECT 1 moo; > CREATE VIEW > postgres=# CREATE MATERIALIZED VIEW mv_test2 AS SELECT moo, 2*moo FROM > v_test2 UNION ALL SELECT moo, 3*moo FROM v_test2; > SELECT 2 > postgres=# \d+ mv_test2 >  Materialized view "public.mv_t

Re: [HACKERS] Parallel query execution

On Wed, Jan 16, 2013 at 09:05:39AM -0500, Andrew Dunstan wrote: > > On 01/15/2013 11:32 PM, Bruce Momjian wrote: > >On Wed, Jan 16, 2013 at 01:28:18PM +0900, Michael Paquier wrote: > >> > >>On Wed, Jan 16, 2013 at 1:22 PM, Josh Berkus wrote: > >> > >> Claudio, Stephen, > >> > >> It really

Re: [HACKERS] Parallel query execution

On Wed, Jan 16, 2013 at 08:11:06AM -0500, Robert Haas wrote: > > We kind of do - when in a CF we should do reviewing of existing > > patches, when outside a CF we should do discussions and work on new > > features. It's on http://wiki.postgresql.org/wiki/CommitFest. It > > doesn't specifically say

Re: [HACKERS] Parallel query execution

On Wed, Jan 16, 2013 at 01:48:29AM -0300, Alvaro Herrera wrote: > Bruce Momjian escribió: > > On Wed, Jan 16, 2013 at 01:28:18PM +0900, Michael Paquier wrote: > > > > > > > > > On Wed, Jan 16, 2013 at 1:22 PM, Josh Berkus wrote: > > > > > > Claudio, Stephen, > > > > > > It really seems

Re: [HACKERS] Parallel query execution

On Wed, Jan 16, 2013 at 01:37:28PM +0900, Michael Paquier wrote: > > > On Wed, Jan 16, 2013 at 1:32 PM, Bruce Momjian wrote: > > On Wed, Jan 16, 2013 at 01:28:18PM +0900, Michael Paquier wrote: > > > > > > On Wed, Jan 16, 2013 at 1:22 PM, Josh Berkus wrote: > > > >

Re: [HACKERS] Materialized views WIP patch

On 16 January 2013 05:40, Kevin Grittner wrote: > Here is a new version of the patch, with most issues discussed in > previous posts fixed. > > I've been struggling with two areas: > > - pg_dump sorting for MVs which depend on other MVs > - proper handling of the relisvalid flag for unlogged MV

Re: [HACKERS] Teaching pg_receivexlog to follow timeline switches

On Thu, Jan 17, 2013 at 1:08 AM, Heikki Linnakangas wrote: > On 15.01.2013 20:22, Fujii Masao wrote: >> >> On Tue, Jan 15, 2013 at 11:05 PM, Heikki Linnakangas >> wrote: >>> >>> Now that a standby server can follow timeline switches through streaming >>> replication, we should do teach pg_receiv

Re: [HACKERS] Materialized views WIP patch

Tom Lane wrote: > "Kevin Grittner" writes: >> I've been struggling with two areas: >> - pg_dump sorting for MVs which depend on other MVs > > Surely that should fall out automatically given that the > dependency is properly expressed in pg_depend? > > If you mean you're trying to get it to cope

Re: [HACKERS] Materialized views WIP patch

"Kevin Grittner" writes: > I've been struggling with two areas: > - pg_dump sorting for MVs which depend on other MVs Surely that should fall out automatically given that the dependency is properly expressed in pg_depend? If you mean you're trying to get it to cope with circular dependencies be

Re: [HACKERS] pg_trgm partial-match

On Fri, Nov 23, 2012 at 2:11 AM, Fujii Masao wrote: > On Mon, Nov 19, 2012 at 10:56 AM, Tomas Vondra wrote: >> I've done a quick review of the current patch: > > Thanks for the commit! > > As Alexander pointed out upthread, another infrastructure patch is required > before applying this patch. So

Re: [HACKERS] log_lock_waits to identify transaction's relation

* Simon Riggs (si...@2ndquadrant.com) wrote: > > A couple quick notes regarding the patch- what does > > GetXactLockTableRelid really provide..? > > The ability to access a static variable in a different module. It > doesn't provide anything other than that, It isn't actually necessary for that c

Re: [HACKERS] Teaching pg_receivexlog to follow timeline switches

On 15.01.2013 20:22, Fujii Masao wrote: On Tue, Jan 15, 2013 at 11:05 PM, Heikki Linnakangas wrote: Now that a standby server can follow timeline switches through streaming replication, we should do teach pg_receivexlog to do the same. Patch attached. I made one change to the way START_STREAM

Re: [HACKERS] Parallel query execution

On Wed, Jan 16, 2013 at 08:42:29AM -0500, Stephen Frost wrote: > * Daniel Farina (dan...@heroku.com) wrote: > > I have been skimming the commitfest application, and unlike some of > > the previous commitfests a huge number of patches have had review at > > some point in time, but probably need more

Re: [HACKERS] CF3+4 (was Re: Parallel query execution)

On Wed, Jan 16, 2013 at 01:08:27PM +0100, Magnus Hagander wrote: > On Wed, Jan 16, 2013 at 9:21 AM, Abhijit Menon-Sen > wrote: > > At 2013-01-16 02:07:29 -0500, t...@sss.pgh.pa.us wrote: > >> > >> In case you hadn't noticed, we've totally lost control of > >> the CF process. > > > > What can we d

Re: [HACKERS] Curious buildfarm failures (fwd)

Sergey Koposov writes: > On Wed, 16 Jan 2013, Andres Freund wrote: >> What about switching to -O1 of 11.1? > I don't know. It is up to -hackers to decide. I think that icc on ia64 > have shown bugginess time after time. But if you think that buildfarm > with icc 11.1 -O1 carry more information

Re: [HACKERS] json api WIP patch

On Mon, Jan 14, 2013 at 11:02 PM, Andrew Dunstan wrote: > After a couple of iterations, some performance enhancements to the json > parser and lexer have ended up with a net performance improvement over git > tip. On our test rig, the json parse test runs at just over 13s per 1 > parses on git

Re: [HACKERS] [sepgsql 1/3] add name qualified creation label

On Tue, Jan 15, 2013 at 3:02 PM, Kohei KaiGai wrote: > This patch adds sepgsql the feature of name qualified creation label. > > Background, on creation of a certain database object, sepgsql assigns > a default security label according to the security policy that has a set of > rules to determine

Re: [HACKERS] Parallel query execution

On Wed, Jan 16, 2013 at 10:33 AM, Stephen Frost wrote: > * Claudio Freire (klaussfre...@gmail.com) wrote: >> Well, there's the fault in your logic. It won't be as linear. > > I really don't see how this has become so difficult to communicate. > > It doesn't have to be linear. > > We're currently d

Re: [HACKERS] Re: [PATCH] Compile without warning with gcc's -Wtype-limits, -Wempty-body

On 1/15/13 6:36 AM, Andres Freund wrote: > I just think that the price of fixing a single Assert() that hasn't > changed in years where the variable isn't likely to ever get signed is > acceptable. Well, once you get past that one change you proposed, you will also find pg_standby.c: In function

Re: [HACKERS] log_lock_waits to identify transaction's relation

On 16 January 2013 03:47, Stephen Frost wrote: > Simon, > > * Simon Riggs (si...@2ndquadrant.com) wrote: >> Attached patch passes through further information about the lock wait, >> so we can display the following message instead >>LOG: process %d acquired %s on transaction %u on relation %u o

Re: [HACKERS] Curious buildfarm failures (fwd)

On Wed, 16 Jan 2013, Andres Freund wrote: So unless somebody suggest otherwise, i'm going to switch to gcc on this buildfarm. What about switching to -O1 of 11.1? I don't know. It is up to -hackers to decide. I think that icc on ia64 have shown bugginess time after time. But if you think tha

Re: [HACKERS] Curious buildfarm failures (fwd)

On 01/16/2013 09:41 AM, Sergey Koposov wrote: So unless somebody suggest otherwise, i'm going to switch to gcc on this buildfarm. If you switch compiler it should be a new buildfarm animal. (That just means re-registering so you get a new name/secret pair.) We have provision for upgrading

Re: [HACKERS] Curious buildfarm failures (fwd)

On 2013-01-16 14:41:47 +, Sergey Koposov wrote: > Hi, > > On Wed, 16 Jan 2013, Andres Freund wrote: > >On 2013-01-16 01:28:09 -0500, Tom Lane wrote: > >>It's a compiler bug. > > Thanks for investigating. But I'm not sure there is any way other way for me > other than switching to gcc, because

Re: [HACKERS] Curious buildfarm failures (fwd)

Hi, On Wed, 16 Jan 2013, Andres Freund wrote: On 2013-01-16 01:28:09 -0500, Tom Lane wrote: It's a compiler bug. Thanks for investigating. But I'm not sure there is any way other way for me other than switching to gcc, because intel stopped providing their IA64 version of compilers free of

Re: [HACKERS] CF3+4

* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: > Also, what should he start with? CF3 as it stands today, or CF4 with all > of the pending patches moved from CF3, immense though the result may be? > I slightly prefer the latter, so that we're all on the same page when it > comes to seeing what n

Re: [HACKERS] pkg-config files for libpq and ecpg

On Tue, Jan 15, 2013 at 02:16:01PM -0500, Peter Eisentraut wrote: > A side issue that arose: libecpg_compat is linked with libpq, but > doesn't seem to use it. This was added many years ago in > cd75f94dafd43358305811b7576ad75d889097e3, but it doesn't appear to be > required anymore. Needs some c

Re: [HACKERS] CF3+4 (was Re: Parallel query execution)

On 01/16/2013 08:12 PM, Simon Riggs wrote: > I would like to nominate Craig Ringer to be independent CF mgr for > Jan2013 CF. I'm happy to step up and help out. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent v

Re: [HACKERS] CF3+4 (was Re: Parallel query execution)

On 01/16/2013 10:02 PM, Stephen Frost wrote: > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: >>> I would like to nominate Craig Ringer to be independent CF mgr for Jan2013 CF. >> >> Seconded. I particularly like the fact that Craig is not already a PG >> developer, so he's not going to be work

Re: [HACKERS] CF3+4

At 2013-01-16 09:02:45 -0500, sfr...@snowman.net wrote: > > So when can he start? :D Also, what should he start with? CF3 as it stands today, or CF4 with all of the pending patches moved from CF3, immense though the result may be? I slightly prefer the latter, so that we're all on the same page wh

Re: [HACKERS] Parallel query execution

On 01/15/2013 11:32 PM, Bruce Momjian wrote: On Wed, Jan 16, 2013 at 01:28:18PM +0900, Michael Paquier wrote: On Wed, Jan 16, 2013 at 1:22 PM, Josh Berkus wrote: Claudio, Stephen, It really seems like the areas where we could get the most "bang for the buck" in parallelism wo

  1   2   >