Re: [HACKERS] Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

On 01/21/2013 02:17 AM, Magnus Hagander wrote: On Jan 21, 2013 3:06 AM, "Craig Ringer" > wrote: > > On 01/21/2013 10:03 AM, Craig Ringer wrote: > > On 01/19/2013 04:08 AM, Boszormenyi Zoltan wrote: > >> However, I am not sure whether Cygwin provides the mkstemp()

Re: [HACKERS] standby, pg_basebackup and last xlog file

On 21.01.2013 09:14, Миша Тюрин wrote: Is there any reason why pg_basebackup has limitation in an online backup from the standby: "The backup history file is not created in the database cluster backed up." ? WAL archiving isn't active in a standby, so even if it created a backup history f

Re: [HACKERS] [PATCH] Fix NULL checking in check_TSCurrentConfig()

On 1/20/13 10:35 PM, Tom Lane wrote: Great catch, will commit. (But first I'm looking through commit 2594cf0e to see if I made the same mistake anywhere else :-(.) How did you find that, coverity or some such tool? Thanks for reviewing the patch. It was found using a homemade static undefine

Re: [HACKERS] Removing PD_ALL_VISIBLE

On Mon, 2013-01-21 at 12:49 +0530, Pavan Deolasee wrote: > At the minimum your patch will need to have one additional buffer > pinned for every K < 8192 * 8 heap pages. I assume it's the same K I referred to when responding to Robert: the max number of heap buffers we read before we unpin and rep

Re: [HACKERS] Visual Studio 2012 RC

On 01/01/2013 10:54 AM, Noah Misch wrote: > On Mon, Oct 15, 2012 at 07:53:51AM -0400, Noah Misch wrote: >> The only matter still requiring attention is a fix for IsoLocaleName(). > Following off-list coordination with Brar, I went about finishing up this > patch. The above problem proved deeper th

Re: [HACKERS] Removing PD_ALL_VISIBLE

On 21.01.2013 11:10, Jeff Davis wrote: That confuses me. The testing was to show it didn't hurt other workloads (like scans or inserts/updates/deletes); so the best possible result is that they don't show signs either way. I went back to look at the initial test results that demonstrated that

Re: [HACKERS] parallel pg_dump

On 12/09/2012 04:05 AM, Bruce Momjian wrote: > > FYI, I will be posting pg_upgrade performance numbers using Unix > processes. I will try to get the Windows code working but will also > need help. I'm interested ... or at least willing to help ... re the Windows side. Let me know if I can be of an

Re: [HACKERS] More subtle issues with cascading replication over timeline switches

On 19.01.2013 14:26, Amit kapila wrote: On Friday, January 18, 2013 5:27 PM Heikki Linnakangas wrote: Indeed, looking at the pg_xlog, it's not there (I did a couple of extra timeline switches: ~/pgsql.master$ ls -l data-master/pg_xlog/ total 131084 -rw--- 1 heikki heikki 16777216 Jan 18

Re: [HACKERS] Visual Studio 2012 RC

On Mon, Jan 21, 2013 at 05:32:37PM +0800, Craig Ringer wrote: > On 01/01/2013 10:54 AM, Noah Misch wrote: > > Tester warning: if you currently have some form of VS2010 installed, > > including > > the compilers of Windows SDK 7.1, beware of this problem: > > http://stackoverflow.com/questions/1088

Re: [HACKERS] Visual Studio 2012 RC

On 01/21/2013 07:23 PM, Noah Misch wrote: > What fun. Thanks for working that out. It's made even more fun by Microsoft's answer to "how do I silent-install the VS 2012 SP1 compiler update" - you don't. Yeah, it's great. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

On Mon, Jan 21, 2013 at 9:01 AM, Andrew Dunstan wrote: > > On 01/21/2013 02:17 AM, Magnus Hagander wrote: > >> >> >> On Jan 21, 2013 3:06 AM, "Craig Ringer" > > wrote: >> > >> > On 01/21/2013 10:03 AM, Craig Ringer wrote: >> > > On 01/19/2013 04:08 AM, Boszormenyi Zol

Re: [HACKERS] Visual Studio 2012 RC

On 01/21/2013 04:32 AM, Craig Ringer wrote: On 01/01/2013 10:54 AM, Noah Misch wrote: On Mon, Oct 15, 2012 at 07:53:51AM -0400, Noah Misch wrote: The only matter still requiring attention is a fix for IsoLocaleName(). Following off-list coordination with Brar, I went about finishing up this p

Re: Review of "pg_basebackup and pg_receivexlog to use non-blocking socket communication", was: Re: [HACKERS] Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown

On Fri, Jan 18, 2013 at 7:50 AM, Amit Kapila wrote: > On Wednesday, January 16, 2013 4:02 PM Heikki Linnakangas wrote: >> On 07.01.2013 16:23, Boszormenyi Zoltan wrote: >> > Since my other patch against pg_basebackup is now committed, >> > this patch doesn't apply cleanly, patch rejects 2 hunks. >

Re: [HACKERS] parallel pg_dump

On 01/21/2013 06:02 PM, Craig Ringer wrote: > On 12/09/2012 04:05 AM, Bruce Momjian wrote: >> FYI, I will be posting pg_upgrade performance numbers using Unix >> processes. I will try to get the Windows code working but will also >> need help. > I'm interested ... or at least willing to help ... r

Re: [HACKERS] Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

On 01/21/2013 07:05 AM, Magnus Hagander wrote: No, I only use the client. But then I support plenty of things I don't use. Oh, I somehow thought you were. And yes, we all support things we don't use - but it certainly helps if there is *someone* out there who uses it. Having a buildfarm animal

Re: [HACKERS] Making testing on Windows easier

On Mon, Jan 21, 2013 at 10:01:29AM +0800, Craig Ringer wrote: > I've found EC2 to be unusably slow for Windows builds, with a medium > instance taking an hour and a half to do a simple build and "vcregress > check". They're also restrictive in disk space terms, so you land up > needing to add a sec

Re: [HACKERS] pg_dump transaction's read-only mode

Pavan Deolasee writes: > On Sun, Jan 20, 2013 at 4:29 AM, Tom Lane wrote: >> As submitted, this broke pg_dump for dumping from pre-8.0 servers. >> (7.4 didn't accept commas in SET TRANSACTION syntax, and versions >> before that didn't have the READ ONLY option at all.) > My bad. I did not realiz

Re: [HACKERS] Making testing on Windows easier

On 01/21/2013 08:55 PM, Noah Misch wrote: > On Mon, Jan 21, 2013 at 10:01:29AM +0800, Craig Ringer wrote: >> I've found EC2 to be unusably slow for Windows builds, with a medium >> instance taking an hour and a half to do a simple build and "vcregress >> check". They're also restrictive in disk spa

Re: [HACKERS] gistchoose vs. bloat

Jeff Davis writes: > On Mon, 2013-01-21 at 00:48 -0500, Tom Lane wrote: >> I looked at this patch. ISTM we should not have the option at all but >> just do it always. I cannot believe that always-go-left is ever a >> preferable strategy in the long run; the resulting imbalance in the >> index wi

Re: [HACKERS] Visual Studio 2012 RC

On 01/21/2013 08:44 PM, Andrew Dunstan wrote: > > On 01/21/2013 04:32 AM, Craig Ringer wrote: >> On 01/01/2013 10:54 AM, Noah Misch wrote: >>> On Mon, Oct 15, 2012 at 07:53:51AM -0400, Noah Misch wrote: The only matter still requiring attention is a fix for IsoLocaleName(). >>> Following

[HACKERS] Re: Doc patch making firm recommendation for setting the value of commit_delay

On Mon, Jan 21, 2013 at 12:23:21AM +, Peter Geoghegan wrote: > On 19 January 2013 20:38, Noah Misch wrote: > > staticloud.com seems to be gone. Would you repost these? > > I've pushed these to a git repo, hosted on github. > > https://github.com/petergeoghegan/commit_delay_benchmarks > > I

Re: [HACKERS] Making testing on Windows easier

On Mon, Jan 21, 2013 at 1:00 PM, Craig Ringer wrote: > On 01/21/2013 08:55 PM, Noah Misch wrote: >> On Mon, Jan 21, 2013 at 10:01:29AM +0800, Craig Ringer wrote: >>> I've found EC2 to be unusably slow for Windows builds, with a medium >>> instance taking an hour and a half to do a simple build and

Re: [HACKERS] gistchoose vs. bloat

On 21.01.2013 15:06, Tom Lane wrote: Jeff Davis writes: On Mon, 2013-01-21 at 00:48 -0500, Tom Lane wrote: I looked at this patch. ISTM we should not have the option at all but just do it always. I cannot believe that always-go-left is ever a preferable strategy in the long run; the resultin

Re: [HACKERS] Making testing on Windows easier

On 01/21/2013 08:11 AM, Dave Page wrote: I was never able to determine why the Windows instances were so much slower than the corresponding Linux instance of the same type. Full vs. para-virtualisation perhaps? No, Windows builds just are slower. For some time the buildfarm has been repor

Re: [HACKERS] Making testing on Windows easier

On Mon, Jan 21, 2013 at 1:59 PM, Andrew Dunstan wrote: > > On 01/21/2013 08:11 AM, Dave Page wrote: > >>> >>> I was never able to determine why the Windows instances were so much >>> slower than the corresponding Linux instance of the same type. >> >> Full vs. para-virtualisation perhaps? >> > > N

Re: [HACKERS] Making testing on Windows easier

On Mon, Jan 21, 2013 at 3:03 PM, Dave Page wrote: > On Mon, Jan 21, 2013 at 1:59 PM, Andrew Dunstan wrote: >> >> On 01/21/2013 08:11 AM, Dave Page wrote: >> I was never able to determine why the Windows instances were so much slower than the corresponding Linux instance of the same

Re: [HACKERS] More subtle issues with cascading replication over timeline switches

On 18.01.2013 13:57, Heikki Linnakangas wrote: When a standby starts up, and catches up with the master through the archive, it copies the target timeline's history file from the archive to pg_xlog. That's enough for that standby's purposes, but if there is a cascading standby or pg_receivexlog c

Re: [HACKERS] pg_upgrade and system() return value

On Sun, Jan 20, 2013 at 11:14:47AM -0500, Tom Lane wrote: > Bruce Momjian writes: > > Can someone comment on the attached patch? pg_upgrade was testing if > > system() returned a non-zero value, while I am thinking I should be > > adjusting system()'s return value with WEXITSTATUS(). > > AFAIK

Re: [HACKERS] Doc patch making firm recommendation for setting the value of commit_delay

On 21 January 2013 13:10, Noah Misch wrote: > What filesystem did you use for testing? Would you also provide /proc/cpuinfo > or a rough description of the system's CPUs? Unfortunately, I don't have access to that server at the moment. It's under Greg Smith's control. I believe you yourself had

Re: [HACKERS] pg_dump transaction's read-only mode

On Mon, Jan 21, 2013 at 8:00 AM, Tom Lane wrote: > Pavan Deolasee writes: >> On Sun, Jan 20, 2013 at 4:29 AM, Tom Lane wrote: >>> As submitted, this broke pg_dump for dumping from pre-8.0 servers. >>> (7.4 didn't accept commas in SET TRANSACTION syntax, and versions >>> before that didn't have t

Re: [HACKERS] ALTER command reworks

Tom Lane escribió: > Kohei KaiGai writes: > > About ALTER FUNCTION towards aggregate function, why we should raise > > an error strictly? > > I agree we probably shouldn't --- traditionally we have allowed that, > AFAIR, so changing it would break existing applications for little > benefit. Okay

Re: [HACKERS] pg_ctl idempotent option

On Fri, Jan 18, 2013 at 8:48 PM, Phil Sorber wrote: > > +1 > Is there more work being done on this, or is the current patch ready to review? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hack

Re: [HACKERS] Teaching pg_receivexlog to follow timeline switches

On Fri, Jan 18, 2013 at 7:55 AM, Heikki Linnakangas wrote: > On 18.01.2013 06:38, Phil Sorber wrote: >> Is it possible to re-use walreceiver code from the backend? >> >> I was thinking that it would actually be very useful to have the whole >> replication functionality modularized and in a standal

Re: [HACKERS] Review: Patch to compute Max LSN of Data Pages

On Sunday, January 20, 2013 10:50 AM Amit kapila wrote: On Sunday, January 20, 2013 4:04 AM Dickson S. Guedes wrote: 2013/1/18 Amit kapila : >>> Please find the rebased Patch for Compute MAX LSN. >>The function 'remove_parent_refernces' couldn't be called >>'remove_parent_references' ? > Shall f

Re: [HACKERS] Request for vote to move forward with recovery.conf overhaul

On Fri, Dec 21, 2012 at 2:46 PM, Bruce Momjian wrote: > There has been discussion in the past of removing or significantly > changing the way streaming replication/point-in-time-recovery (PITR) is > setup in Postgres. Currently the file recovery.conf is used, but that > was designed for PITR and

Re: [HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 13-01-21 02:28 AM, Andres Freund wrote: I haven't removed it from the patch afaik, so it would be great to get a profile here! Its "only" for xlogdump, but that tool helped me immensely and I don't want to maintain it independently... Here is the output from tprof Here is the baseline: Av

Re: [HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 2013-01-21 11:59:18 -0500, Steve Singer wrote: > On 13-01-21 02:28 AM, Andres Freund wrote: > > > >I haven't removed it from the patch afaik, so it would be great to get a > >profile here! Its "only" for xlogdump, but that tool helped me immensely > >and I don't want to maintain it independently

[HACKERS] [PATCH] pg_isready (was: [WIP] pg_ping utility)

Changing up the subject line because this is no longer a work in progress nor is it pg_ping anymore. On Sun, Jan 20, 2013 at 10:36 PM, Craig Ringer wrote: > On 01/21/2013 11:26 AM, Robert Haas wrote: >> On Sun, Jan 20, 2013 at 2:59 PM, Phil Sorber wrote: >>> Ok. I can add something to the notes

Re: [HACKERS] Event Triggers: adding information

Robert Haas writes: >> Ok. Will prepare a non controversial patch for ddl_command_end. > > Thanks. I will make a forceful effort to review that in a timely > fashion when it's posted. Please find it attached to this email. COLUMNS=72 git diff --stat doc/src/sgml/event-trigger.sgml

Re: [HACKERS] count(*) of zero rows returns 1

On Tue, Jan 15, 2013 at 5:47 AM, Gurjeet Singh wrote: > postgres=# select * from test_0_col_table ; > -- > (20 rows) Interestingly, PostgreSQL 9.2 has regressed here. Not sure if we care, but worth mentioning: psql (9.2.2) test=# select count(*) from foo1; count -- 1000 (1 ro

Re: [HACKERS] proposal: fix corner use case of variadic fuctions usage

Hello 2013/1/19 Tom Lane : > Pavel Stehule writes: >> 2013/1/18 Tom Lane : >>> The approach is also inherently seriously inefficient. ... > >> What is important - for this use case - there is simple and perfect >> possible optimization - in this case "non variadic manner call of >> variadic "any"

Re: [HACKERS] pg_dump transaction's read-only mode

On 01/21/2013 02:00 PM, Tom Lane wrote: > Pavan Deolasee writes: >> On Sun, Jan 20, 2013 at 4:29 AM, Tom Lane wrote: >>> As submitted, this broke pg_dump for dumping from pre-8.0 servers. >>> (7.4 didn't accept commas in SET TRANSACTION syntax, and versions >>> before that didn't have the READ ON

[HACKERS] [PATCH] PQping Docs

Attached is a patch that adds a note about the FATAL messages that appear in the logs if you don't pass a valid user or dbname to PQping or PQpingParams. This was requested in the pg_isready thread. libpq_pqping_doc.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-ha

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

> IMHO that's the single most important task of a review. Really? I'd say the most important task for a review is "does the patch do what it says it does?". That is, if the patch is supposed to implement feature X, does it actually? If it's a performance patch, does performance actually improv

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

Josh Berkus writes: >> IMHO that's the single most important task of a review. > Really? I'd say the most important task for a review is "does the patch > do what it says it does?". That is, if the patch is supposed to > implement feature X, does it actually? If it's a performance patch, > doe

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

> But even before that, you have to ask whether what it's supposed to do > is something we want. The reviewer can't usually answer that though. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes t

Re: [HACKERS] count(*) of zero rows returns 1

Marti Raudsepp writes: > Interestingly, PostgreSQL 9.2 has regressed here. Not sure if we care, > but worth mentioning: Regressed? The output looks the same to me as it has for some time. > test=# select * from foo1; > (No rows) > Time: 1012.567 ms How did you get that? I don't believe it's p

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

On Mon, Jan 21, 2013 at 2:09 PM, Josh Berkus wrote: >> But even before that, you have to ask whether what it's supposed to do >> is something we want. > > The reviewer can't usually answer that though. They can answer whether THEY want it, though. And Tom, Andrew, and I all just got through argu

Re: [HACKERS] pg_dump transaction's read-only mode

Stefan Kaltenbrunner writes: > On 01/21/2013 02:00 PM, Tom Lane wrote: >> (It's entirely likely that the 7.0 server I keep around for testing this >> is the last one in captivity anywhere. But IIRC, we've heard fairly >> recent reports of people still using 7.2. We'd have to desupport before >>

Re: [HACKERS] count(*) of zero rows returns 1

On Mon, Jan 21, 2013 at 9:33 PM, Tom Lane wrote: >> test=# select * from foo1; >> (No rows) >> Time: 1012.567 ms > > How did you get that? I don't believe it's possible in the default > output format. Oh I see, it's because I have \x auto in my .psqlrc. If I set \x auto or \x on then it says "(N

Re: [HACKERS] Removing PD_ALL_VISIBLE

On Mon, Jan 21, 2013 at 1:52 AM, Jeff Davis wrote: >> Of course, there is an argument that this patch will >> simplify the code, but I'm not sure if its enough to justify the >> additional contention which may or may not show up in the benchmarks >> we are running, but we know its there. > > What

Re: [HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 13-01-21 12:15 PM, Andres Freund wrote: On 2013-01-21 11:59:18 -0500, Steve Singer wrote: On 13-01-21 02:28 AM, Andres Freund wrote: I haven't removed it from the patch afaik, so it would be great to get a profile here! Its "only" for xlogdump, but that tool helped me immensely and I don't w

Re: [HACKERS] Teaching pg_receivexlog to follow timeline switches

This patch was in Needs Review status, but you committed it on 2013-01-17. I have marked it as such in the CF app. -- 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] CF3+4 (was Re: Parallel query execution)

Robert Haas writes: > On Sun, Jan 20, 2013 at 7:07 PM, Jeff Janes wrote: >> As a junior reviewer, I'd like to know if my main task should be to decide >> between 1) writing a review convincing you or Tom that your judgement is >> hasty, or 2) to convince the author that your judgement is correct.

Re: [HACKERS] Event Triggers: adding information

On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine wrote: > Please find it attached to this email. Nice clean patch, thanks! Committed, after tinkering with the CommandCounterIncrement() stuff a bit. I will respond to the rest of your email later. Reading through this patch left me with a slig

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

On Wed, Jan 16, 2013 at 8:18 AM, Abhijit Menon-Sen wrote: > Here's a breakdown based purely on the names from the CF page (i.e. I > didn't check archives to see who actually posted reviews, and didn't > take into account reviews posted without updating the CF page). FWIW, I reviewed at least one

Re: [HACKERS] Request for vote to move forward with recovery.conf overhaul

On Tue, Jan 22, 2013 at 1:11 AM, Phil Sorber wrote: > On Fri, Dec 21, 2012 at 2:46 PM, Bruce Momjian wrote: > > There has been discussion in the past of removing or significantly > > changing the way streaming replication/point-in-time-recovery (PITR) is > > setup in Postgres. Currently the fil

[HACKERS] Prepared statements fail after schema changes with surprising error

A user reported an interesting issue today. After restoring a dump created with --clean on a running application in his development environment his application started complaining of missing tables despite those tables very clearly existing. After a little thinking, we determined that this was due

Re: [HACKERS] Event Triggers: adding information

2013/1/21 Robert Haas : > Another thing is that we might want to document that if a command > errors out, ddl_command_end will never be reached; and perhaps also > that if ddl_command_start errors out, the command itself will never be > reached. Perhaps this is so obvious as to not bear mentioning

Re: [HACKERS] Prepared statements fail after schema changes with surprising error

Peter van Hardenberg writes: > A user reported an interesting issue today. After restoring a dump created > with --clean on a running application in his development environment his > application started complaining of missing tables despite those tables very > clearly existing. > After a little t

Re: [HACKERS] Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave

On Fri, Jan 18, 2013 at 6:20 PM, Heikki Linnakangas wrote: > Hmm, so it's the same issue I thought I fixed yesterday. My patch only > fixed it for the case that the timeline switch is in the first page of the > segment. When it's not, you still get two calls for a WAL record, first one > for the

Re: [HACKERS] Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave

On Tue, Jan 22, 2013 at 9:06 AM, Michael Paquier wrote: > > > On Fri, Jan 18, 2013 at 6:20 PM, Heikki Linnakangas < > hlinnakan...@vmware.com> wrote: > >> Hmm, so it's the same issue I thought I fixed yesterday. My patch only >> fixed it for the case that the timeline switch is in the first page o

Re: [HACKERS] Request for vote to move forward with recovery.conf overhaul

On Mon, Jan 21, 2013 at 6:23 PM, Michael Paquier wrote: > Yes, that is one of the most important patches in the list, and I could put > some effort in it for either review or coding. I think it would be great if you could elaborate on your reasons for feeling that this patch is particularly impor

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

On Mon, Jan 21, 2013 at 6:23 PM, Phil Sorber wrote: > On Wed, Jan 16, 2013 at 8:18 AM, Abhijit Menon-Sen > wrote: >> Here's a breakdown based purely on the names from the CF page (i.e. I >> didn't check archives to see who actually posted reviews, and didn't >> take into account reviews posted w

Re: [HACKERS] Prepared statements fail after schema changes with surprising error

On 22 January 2013 00:00, Tom Lane wrote: > Works for me ... That's what I thought. But looking at RangeVarGetRelidExtended() and recomputeNamespacePath(), do you suppose that the problem could be that access privileges used by the app differed for a schema (or, more accurately, two physically di

Re: [HACKERS] Request for vote to move forward with recovery.conf overhaul

On Tue, Jan 22, 2013 at 9:27 AM, Robert Haas wrote: > On Mon, Jan 21, 2013 at 6:23 PM, Michael Paquier > wrote: > > Yes, that is one of the most important patches in the list, and I could > put > > some effort in it for either review or coding. > > I think it would be great if you could elaborat

Re: [HACKERS] Prepared statements fail after schema changes with surprising error

2013/1/21 Peter van Hardenberg : > A user reported an interesting issue today. After restoring a dump created > with --clean on a running application in his development environment his > application started complaining of missing tables despite those tables very > clearly existing. > > After a litt

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

On Mon, Jan 21, 2013 at 5:48 PM, Dimitri Fontaine wrote: > Advice:You don't do things that way, this way is the only one we > will ever accept, because we've been sweating blood over > the years to get in a position where it now works. > > Hint: it's no

Re: [HACKERS] Prepared statements fail after schema changes with surprising error

Peter Geoghegan writes: > On 22 January 2013 00:00, Tom Lane wrote: >> Works for me ... > That's what I thought. But looking at RangeVarGetRelidExtended() and > recomputeNamespacePath(), do you suppose that the problem could be > that access privileges used by the app differed for a schema (or,

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

Robert, > http://www.postgresql.org/message-id/28927.1236820...@sss.pgh.pa.us > > That's not a positive review, but when it comes down to it, it's a > pretty factual email. IMHO, anyway, and YMMV. Really? I've always thought that was a pretty constructive review. It certainly gave me the laun

Re: [HACKERS] dividing privileges for replication role.

Hi, Magnus, Josh, Michael, Craig Thank you for comments and registring to CommitFest. >> I made a patch to divide privileges for replication role. >> >> Currently(9.2), the privilege for replication role is >> true / false which means that standby server is able to >> connect to another server or

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

On Mon, Jan 21, 2013 at 8:23 PM, Robert Haas wrote: > What I don't like is when I > (or anyone) posts a patch and somebody says something that boils down > to "no one wants that". *That* ticks me off. Because you know what? > At a minimum, *I* want that. If I didn't, I wouldn't have written a >

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

On Mon, Jan 21, 2013 at 8:47 PM, Josh Berkus wrote: >> My own experience is different from yours, I guess. I actually like >> it when I post a patch, or suggest a concept, and Tom fires back with >> a laundry list of reasons it won't work. > > This can be a problem with new submitters, though. I

Re: [HACKERS] proposal: fix corner use case of variadic fuctions usage

Pavel Stehule writes: > so here is rewritten patch I've applied the infrastructure parts of this, but not the changes to format() and concat(). Why are the format and concat patches so randomly different? Not only is the internal implementation completely different for no obvious reason, but the

Re: [HACKERS] dividing privileges for replication role.

Tomonari Katsumata writes: >> Why is it better to do this with a privilege, rather than just using >> pg_hba.conf? > You are right. > Handling with pg_hba.conf is an easy way. > But I think many users think about switch over, so > the pg_hba.conf is same on master and standby. > it's not convini

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

On Mon, Jan 21, 2013 at 8:47 PM, Josh Berkus wrote: >> http://www.postgresql.org/message-id/28927.1236820...@sss.pgh.pa.us >> >> That's not a positive review, but when it comes down to it, it's a >> pretty factual email. IMHO, anyway, and YMMV. > > Really? I've always thought that was a pretty c

Re: [HACKERS] Patch for removng unused targets

I'd like to rework on this optimization and submit a patch at the next CF. Is that okay? Thanks, Best regards, Etsuro Fujita From: Craig Ringer [mailto:cr...@2ndquadrant.com] Sent: Friday, January 18, 2013 8:30 PM To: Alexander Korotkov Cc: Tom Lane; Etsuro Fujita; pgsql-hackers Subj

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

On Tue, Jan 22, 2013 at 7:57 AM, Phil Sorber wrote: > On Mon, Jan 21, 2013 at 8:47 PM, Josh Berkus wrote: >>> My own experience is different from yours, I guess. I actually like >>> it when I post a patch, or suggest a concept, and Tom fires back with >>> a laundry list of reasons it won't work.

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

Pavan Deolasee writes: > For me our reluctance for any kind of change is a major demoralizing > factor. I hardly think we're "reluctant for any kind of change" --- the rate of commits belies that. What we want is a convincing case that a proposed change is an improvement over what we have. (You

Re: Review of "pg_basebackup and pg_receivexlog to use non-blocking socket communication", was: Re: [HACKERS] Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown

On Monday, January 21, 2013 6:22 PM Magnus Hagander > On Fri, Jan 18, 2013 at 7:50 AM, Amit Kapila > wrote: > > On Wednesday, January 16, 2013 4:02 PM Heikki Linnakangas wrote: > >> On 07.01.2013 16:23, Boszormenyi Zoltan wrote: > >> > Since my other patch against pg_basebackup is now committed, >

Re: [HACKERS] Patch for removng unused targets

On 01/22/2013 01:24 PM, Etsuro Fujita wrote: > > I'd like to rework on this optimization and submit a patch at the next > CF. Is that okay? > That sounds very sensible to me, given how busy CF2013-01 is and the remaining time before 9.3. -- Craig Ringer http://www.2ndQuadrant.

Re: [HACKERS] Prepared statements fail after schema changes with surprising error

Hm - I'm still able to recreate the test the user's running using pg_dump/pg_restore. I'm still working to see if I can minimize the test-case, but this is against 9.2.2. Would you prefer I test against HEAD? regression=# create table z1 (f1 int); CREATE TABLE regression=# prepare sz1 as select *

Re: [HACKERS] Prepared statements fail after schema changes with surprising error

Okay - I've narrowed it down to an interaction with schema recreation. Here's a minimal test-case I created by paring back the restore from the pg_restore output until I only had the essence remaining: -- setup drop table z1; create table z1 (f1 int); insert into z1 values (1); prepare sz1 as sele

Re: [HACKERS] Prepared statements fail after schema changes with surprising error

Peter van Hardenberg writes: > Okay - I've narrowed it down to an interaction with schema recreation. > Here's a minimal test-case I created by paring back the restore from the > pg_restore output until I only had the essence remaining: Hm ... I'm too tired to trace through the code to prove this

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

On Jan 22, 2013 1:31 AM, "Robert Haas" wrote: > > On Mon, Jan 21, 2013 at 6:23 PM, Phil Sorber wrote: > > On Wed, Jan 16, 2013 at 8:18 AM, Abhijit Menon-Sen wrote: > >> Here's a breakdown based purely on the names from the CF page (i.e. I > >> didn't check archives to see who actually posted rev