[HACKERS] problem/bug in drop tablespace?

2012-05-07 Thread Michael Nolan
While researching a problem reported on the -general list by a user who lost a disk containing his index tablespace, I ran into something, but I'm not sure is a serious bug or just an inconsistency in how \d shows tables. Here are the steps I took. 1. Create a new database 'MYDB' and connect to

[HACKERS] CLOG background writing

2012-05-07 Thread Robert Haas
I spent a significant chunk of my time last week, and also a whole lot of machine time, trying to evaluate the effectiveness of flushing CLOG pages to disk in the background. Simon made the last effort in this area: http://archives.postgresql.org/pgsql-hackers/2012-01/msg00571.php ...but we were

Re: [HACKERS] c-function variants running time

2012-05-07 Thread Robert Haas
On Fri, May 4, 2012 at 12:41 PM, Armando wrote: > Hi everybody. > > First of all I have to thank you for your wonderful job! PostgreSQL rocks! > > I am writing you because I am interested in understanding some specifics > related > to PostgreSQL internals. More precisely, I am investigating the r

Re: [HACKERS] Latch for the WAL writer - further reducing idle wake-ups.

2012-05-07 Thread Simon Riggs
On 7 May 2012 20:06, Tom Lane wrote: > Simon Riggs writes: >> It also leaves the situation that we have a catalog view called >> pg_stat_bgwriter that would be accessing "checkpointer" things. That's >> really the thorny one that I wasn't sure how to handle. Good example >> of why we shouldn't ex

Re: [HACKERS] Latch for the WAL writer - further reducing idle wake-ups.

2012-05-07 Thread Tom Lane
Simon Riggs writes: > It also leaves the situation that we have a catalog view called > pg_stat_bgwriter that would be accessing "checkpointer" things. That's > really the thorny one that I wasn't sure how to handle. Good example > of why we shouldn't expose internals too much. Yeah, that's a bit

Re: [HACKERS] Latch for the WAL writer - further reducing idle wake-ups.

2012-05-07 Thread Simon Riggs
On 7 May 2012 19:44, Tom Lane wrote: > Simon Riggs writes: >> On 7 May 2012 18:09, Tom Lane wrote: >>> I also notice that the separate-checkpointer patch failed to rename >>> assorted things like BgWriterCommLock, BgWriterRequest, >>> BgWriterShmemStruct, which are all 100% inappropriately named

Re: [HACKERS] Latch for the WAL writer - further reducing idle wake-ups.

2012-05-07 Thread Tom Lane
Simon Riggs writes: > On 7 May 2012 18:09, Tom Lane wrote: >> I also notice that the separate-checkpointer patch failed to rename >> assorted things like BgWriterCommLock, BgWriterRequest, >> BgWriterShmemStruct, which are all 100% inappropriately named now. >> And it still contains various obsol

Re: [HACKERS] Latch for the WAL writer - further reducing idle wake-ups.

2012-05-07 Thread Simon Riggs
On 7 May 2012 18:09, Tom Lane wrote: > Peter Geoghegan writes: >> This latest revision also covers the checkpointer. The code for that >> is far simpler than that for the WAL Writer, so it doesn't >> particularly feel like I'm pushing my luck by slipping that into >> something to be slipped in. >

Re: [HACKERS] "unexpected EOF" messages

2012-05-07 Thread Tom Lane
Magnus Hagander writes: > On Mon, May 7, 2012 at 7:18 PM, Robert Haas wrote: >> Since the following hunk is repeated 3x, maybe it should be stuffed >> into a function that is then called in three places: > I considered it trivial enough not to do that for it. I can perhaps be > convinced otherwi

Re: [HACKERS] Uppercase tab completion keywords in psql?

2012-05-07 Thread Robert Haas
On Sat, May 5, 2012 at 9:03 AM, Bruce Momjian wrote: > On Fri, May 04, 2012 at 08:46:28PM +0300, Peter Eisentraut wrote: >> On tor, 2012-05-03 at 15:47 -0400, Bruce Momjian wrote: >> > Peter, where are we on this? >> >> I hadn't received any clear feedback, but if no one objects, I can >> commit i

Re: [HACKERS] "unexpected EOF" messages

2012-05-07 Thread Magnus Hagander
On Mon, May 7, 2012 at 7:18 PM, Robert Haas wrote: > On Mon, May 7, 2012 at 12:39 PM, Magnus Hagander wrote: >> Makes sense, will change and commit. > > Since the following hunk is repeated 3x, maybe it should be stuffed > into a function that is then called in three places: I considered it triv

Re: [HACKERS] "unexpected EOF" messages

2012-05-07 Thread Robert Haas
On Mon, May 7, 2012 at 12:39 PM, Magnus Hagander wrote: > Makes sense, will change and commit. Since the following hunk is repeated 3x, maybe it should be stuffed into a function that is then called in three places: + if (IsTransactionState()) + ereport(COMMER

Re: [HACKERS] Latch for the WAL writer - further reducing idle wake-ups.

2012-05-07 Thread Tom Lane
Peter Geoghegan writes: > This latest revision also covers the checkpointer. The code for that > is far simpler than that for the WAL Writer, so it doesn't > particularly feel like I'm pushing my luck by slipping that into > something to be slipped in. Well ... maybe, or maybe not, or maybe you a

Re: [HACKERS] "unexpected EOF" messages

2012-05-07 Thread Magnus Hagander
On Mon, May 7, 2012 at 5:15 PM, Tom Lane wrote: > Magnus Hagander writes: >> Any further suggestoins for which codes to use? If not, I think I'm >> going to commit the patch as I had it, because it's not any worse than >> what we had before (but fixes the annoying messages), and we can >> always

Re: [HACKERS] smart shutdown at end of transaction (was: Default mode for shutdown)

2012-05-07 Thread Robert Haas
On Sat, May 5, 2012 at 12:41 PM, Fujii Masao wrote: > On Sat, Apr 28, 2012 at 4:00 AM, Robert Haas wrote: >> On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane wrote: >>> I'm not necessarily opposed to commandeering the name "smart" for the >>> new behavior, so that what we have to find a name for is the

Re: [HACKERS] "unexpected EOF" messages

2012-05-07 Thread Tom Lane
Magnus Hagander writes: > Any further suggestoins for which codes to use? If not, I think I'm > going to commit the patch as I had it, because it's not any worse than > what we had before (but fixes the annoying messages), and we can > always revisit the actual errorcodes later. I'm still a bit u

Re: [HACKERS] more possible dead ports cleanup

2012-05-07 Thread Robert Haas
On Sun, May 6, 2012 at 9:04 AM, Peter Eisentraut wrote: > I think a few more things could removed/simplified after the recent > round of port removal: > > - Remove definition of offsetof() in c.h I see no particular virtue to getting rid of this. > - (Side point, the definition of endof() in the

[HACKERS] 9.2 Beta release notes

2012-05-07 Thread Bruce Momjian
FYI, I am planning to complete the 9.2 beta release notes by this Wednesday night, America-time, so developers will have Thursday to make adjustments before we ship the release notes as part of the beta. I wanted to complete them sooner, but I also wanted to be current on email before I started.

Re: [HACKERS] Temporary tables under hot standby

2012-05-07 Thread Merlin Moncure
On Tue, Apr 24, 2012 at 10:55 PM, Noah Misch wrote: > A key barrier to migrations from trigger-based replication to WAL-based > replication is the lack of temporary tables under hot standby.  I'd like to > close that gap; the changes needed will also reduce the master-side cost of > temporary tabl

Re: [HACKERS] "unexpected EOF" messages

2012-05-07 Thread Magnus Hagander
On Thu, May 3, 2012 at 9:26 PM, Magnus Hagander wrote: > On Thu, May 3, 2012 at 7:48 PM, Tom Lane wrote: >> Magnus Hagander writes: >>> Heh - we already used ERRCODE_CONNECTION_FAILURE on the errors in >>> copy.c. Since COPY can only happen when there is a transaction >>> (right?), I just change

Re: [HACKERS] smart shutdown at end of transaction (was: Default mode for shutdown)

2012-05-07 Thread Albe Laurenz
Fujii Masao wrote: >>> I'm not necessarily opposed to commandeering the name "smart" for the >>> new behavior, so that what we have to find a name for is the old "smart" >>> behavior.  How about >>> >>>        slow    - allow existing sessions to finish (old "smart") >>>        smart   - allow exis