Re: [HACKERS] Streaming replication and non-blocking I/O

Heikki Linnakangas wrote: > I've pushed that 'replication-dynmodule' branch in my git repo. The diff > is hard to read, because it mostly just moves code around, but I've > attached libpqwalreceiver.c here, which is the dynamic module part. You > can also browse the tree via the web interface > (ht

Re: [HACKERS] Streaming replication and non-blocking I/O

Tom Lane wrote: > Heikki Linnakangas writes: >> Before we sprinkle all the global variables it touches with that, let me >> explain what I meant by dividing walreceiver code differently between >> dynamically loaded module and backend code. Right now I have to go to >> sleep, though, but I'll try

Re: [HACKERS] Testing with concurrent sessions

Hi, Kevin Grittner wrote: Based on Andrew's suggestion, I changed line 276 to: args=['psql', '-A', '--pset=pager=off', That looks like a correct fix for psql, yes. Thanks for pointing that out Andrew. Other processes might be confused by (or at least act differently with) a P

Re: [HACKERS] Testing with concurrent sessions

Hi, Kevin Grittner wrote: I'm a little unclear about the differences between "uses", "depends", and "onlyAfter". Here's what they *sound* like they mean, to me; although I don't think the code isn't entirely consistent with this interpretation. Wow, you are way ahead of me. I intended to writ

Re: [HACKERS] New XLOG record indicating WAL-skipping

On Fri, Jan 15, 2010 at 8:28 PM, Heikki Linnakangas wrote: > I don't like special-casing UNLOGGED records in XLogInsert and > ReadRecord(). Those functions are complicated enough already. The > special handling from XLogInsert() (and a few other places) is only > required because the UNLOGGED reco

Re: [HACKERS] Streaming replication, loose ends

Simon Riggs wrote: > On Fri, 2010-01-15 at 19:29 +0200, Heikki Linnakangas wrote: > > > File-based Log Shipping > > Planning > > Implementation > > Streaming Replication > > Setting up > > How about "Log Streaming Replication"? > > So its a particular kind of replicatio

Re: [HACKERS] Streaming replication, loose ends

Heikki Linnakangas wrote: > > Uh, do we really want to call this "replication" rather than archive log > > streaming or something. It seems "replication" is a generic term and > > will confuse people who are using other replication solutions like > > Slony. > > Good question. OTOH, if we move the

Re: [HACKERS] Mammoth in Core?

"Joshua D. Drake" writes: > O.k. I know there is no way we will hit this for 8.5. So this is more of > a future discussion more than anything. Well, this is not really the time to be having such a discussion; right now we need to all have our noses to the grindstone dealing with the already-submi

Re: [HACKERS] bug in integration SQL parser to plpgsq

2010/1/15 Tom Lane : > Pavel Stehule writes: >> it doesn't support EXPLAIN as possible begin of SQL statement: > > I've applied a fix for that. Thank you Pavel Stehule > >                        regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make c

Re: [HACKERS] Streaming replication and non-blocking I/O

Andrew Dunstan writes: > I ran an extra cycle. Still a bit of work to do: > Well, at least now we're down to the variables that haven't got PGDLLIMPORT, rather than wondering what's wrong with the build ...

Re: [HACKERS] Streaming replication and non-blocking I/O

Tom Lane wrote: Before we sprinkle all the global variables it touches with that, let me explain what I meant by dividing walreceiver code differently between dynamically loaded module and backend code. Right now I have to go to sleep, though, but I'll try to get back to during the weekend.

[HACKERS] Mammoth in Core?

Hello, O.k. I know there is no way we will hit this for 8.5. So this is more of a future discussion more than anything. We at CMD have been working diligently on our next version of Mammoth Replicator, 1.9. It is currently revved at 8.4. I expect that we will be close to done if not done, by the r

Re: [HACKERS] Streaming replication, loose ends

On Fri, 2010-01-15 at 22:38 +, Greg Stark wrote: > On Fri, Jan 15, 2010 at 6:39 PM, Simon Riggs wrote: > > On Fri, 2010-01-15 at 19:29 +0200, Heikki Linnakangas wrote: > > How about "Log Streaming Replication"? > > > > So its a particular kind of replication, which seems correct to me. > > I

Re: [HACKERS] review: More frame options in window functions

> Thanks for the review. I've found another crash today and attached is > fixed version. The case is: > > SELECT four, sum(ten) over (PARTITION BY four ORDER BY four RANGE 1 > PRECEDING) FROM tenk1 WHERE unique1 < 10; > Hi, The patch (more_frame_options.20100115.patc

Re: [HACKERS] Hot Standby and handling max_standby_delay

On Fri, 2010-01-15 at 20:50 +0200, Heikki Linnakangas wrote: > > So in either case, when we are waiting for new input we reset the timer > > as soon as new WAL is received. The resolution/accuracy of standby_delay > > will be no more than the time taken to replay a single file. This > > shouldn't

Re: [HACKERS] Streaming replication, loose ends

On Fri, Jan 15, 2010 at 6:39 PM, Simon Riggs wrote: > On Fri, 2010-01-15 at 19:29 +0200, Heikki Linnakangas wrote: > How about "Log Streaming Replication"? > > So its a particular kind of replication, which seems correct to me. I thought the whole point of this effort was to be able to bill it as

Re: [HACKERS] bug in integration SQL parser to plpgsq

Pavel Stehule writes: > it doesn't support EXPLAIN as possible begin of SQL statement: I've applied a fix for that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/ma

Re: [HACKERS] Testing with concurrent sessions

Markus Wanner wrote: > Go try it, read the code and simply ask, if you get stuck. I'll > try to come up with some more documentation and such... I'm a little unclear about the differences between "uses", "depends", and "onlyAfter". Here's what they *sound* like they mean, to me; although I do

Re: [HACKERS] Streaming replication and non-blocking I/O

Heikki Linnakangas writes: > Tom Lane wrote: >> Specifically, I think you missed out $(BE_DLLLIBS) in SHLIB_LINK. >> We'll find out at the next mingw build... > Thanks. But what is BE_DLLLIBS? I can't find any description of it. It was the wrong theory anyway --- it already is included (in Makef

Re: [HACKERS] Testing with concurrent sessions

Markus Wanner wrote: > Please recheck with the StreamReporter and try to grep the lines > starting with "[psql0]", "[psql1]" and "[psql2]". Dtester simply > logs all and any output of all 3rd party processes started. For me, all psql output seems to be [psql0]; no [psql1] or [psql2]. Bug?

Re: [HACKERS] Streaming replication and non-blocking I/O

Tom Lane wrote: > I wrote: >> I think it's a tools/build process problem and should be attacked that >> way. > > Specifically, I think you missed out $(BE_DLLLIBS) in SHLIB_LINK. > We'll find out at the next mingw build... Thanks. But what is BE_DLLLIBS? I can't find any description of it. I sus

Re: [HACKERS] Testing with concurrent sessions

"Kevin Grittner" wrote: > Also, in looking closer at how you have the tests defined, it > doesn't look to me like you're carefully interleaving specific > sequences of statements on specific connections so much as opening > multiple connections and then for each statement saying "run this > on a

Re: [HACKERS] Streaming replication and non-blocking I/O

Aidan Van Dyk writes: > Maybe an insane question, but why can postmaster just not "exec" > walreceiver? It'd greatly complicate access to shared memory. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subsc

Re: [HACKERS] Streaming replication and non-blocking I/O

I wrote: > I think it's a tools/build process problem and should be attacked that > way. Specifically, I think you missed out $(BE_DLLLIBS) in SHLIB_LINK. We'll find out at the next mingw build... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@po

Re: [HACKERS] plpython3

On Fri, 2010-01-15 at 13:26 -0700, James William Pye wrote: > On Jan 14, 2010, at 2:03 PM, Joshua D. Drake wrote: > > What I would (as a non hacker) would look for is: > > > > (1) Generalized benchmarks between plpython(core) and plpython3u > > > > I know a lot of these are subjective, but it is

Re: [HACKERS] Testing with concurrent sessions

Markus Wanner wrote: > So, the solution probably lies in adjusting the environment, > before starting psql. (Maybe even dropping all existing > environment variables for better control of the situation). Will > add that for dtester 0.1. Based on Andrew's suggestion, I changed line 276 to:

Re: [HACKERS] Streaming replication and non-blocking I/O

* Heikki Linnakangas [100115 15:20]: > Ok. I'll look at splitting walreceiver code between the shared module > and backend binary slightly differently. At first glance, it doesn't > seem that hard after all, and will make the code more modular anyway. Maybe an insane question, but why can postma

Re: [HACKERS] plpython3

On Jan 14, 2010, at 2:03 PM, Joshua D. Drake wrote: > What I would (as a non hacker) would look for is: > > (1) Generalized benchmarks between plpython(core) and plpython3u > > I know a lot of these are subjective, but it is still good to see if > there are any curves or points that bring the per

Re: [HACKERS] Streaming replication and non-blocking I/O

Heikki Linnakangas writes: > Magnus Hagander wrote: >> Yeah. FWIW, I don't use mingw do do any windows development, but >> definitely +1 on working hard to keep support for it if at all >> possible. > Ok. I'll look at splitting walreceiver code between the shared module > and backend binary sligh

Re: [HACKERS] Streaming replication and non-blocking I/O

Magnus Hagander wrote: > 2010/1/15 Andrew Dunstan : >> >> Heikki Linnakangas wrote: >>> Do people still use MinGW for any real work? Could we just drop >>> walreceiver support from MinGW builds? >>> >>> Or maybe we should consider splitting walreceiver into two parts after >>> all. Only the bare mi

Re: [HACKERS] Streaming replication and non-blocking I/O

2010/1/15 Andrew Dunstan : > > > Heikki Linnakangas wrote: >> >> Do people still use MinGW for any real work? Could we just drop >> walreceiver support from MinGW builds? >> >> Or maybe we should consider splitting walreceiver into two parts after >> all. Only the bare minimum that needs to access

Re: [HACKERS] Streaming replication and non-blocking I/O

Heikki Linnakangas wrote: Do people still use MinGW for any real work? Could we just drop walreceiver support from MinGW builds? Or maybe we should consider splitting walreceiver into two parts after all. Only the bare minimum that needs to access libpq would go into the shared object, and the

Re: [HACKERS] mailing list archiver chewing patches

Hi everyone, Il 14/01/2010 19:36, David Fetter ha scritto: On Thu, Jan 14, 2010 at 03:08:22PM +0100, Matteo Beccati wrote: Il 14/01/2010 14:39, Dimitri Fontaine ha scritto: Matteo Beccati writes:> Any improvements to sorting are welcome :) ... ARRAY[uid] ... Thanks David, using

Re: [HACKERS] Testing with concurrent sessions

Markus Wanner wrote: Hi, Kevin Grittner wrote: My pager is "less"; could that cause it? Could the twisted environment look like one where the pager should kick in? Yes, that could be it. At least it fails here, too, if I set PAGER=less. Try: PAGER=more make dcheck Surely for automa

Re: [HACKERS] Streaming replication and non-blocking I/O

2010/1/15 Heikki Linnakangas : > Fujii Masao wrote: >> On Wed, Jan 13, 2010 at 3:37 AM, Magnus Hagander wrote: This change which moves walreceiver process into a dynamically loaded module caused the following compile error on my MinGW environment. >>> That sounds strange - it should pick

Re: [HACKERS] Streaming replication and non-blocking I/O

Fujii Masao wrote: > On Wed, Jan 13, 2010 at 3:37 AM, Magnus Hagander wrote: >>> This change which moves walreceiver process into a dynamically loaded >>> module caused the following compile error on my MinGW environment. >> That sounds strange - it should pick those up from the -lpostgres. Any >>

Re: [HACKERS] missing data in information_schema grant_* tables?

On fre, 2010-01-15 at 15:06 +0100, Fabien COELHO wrote: > > The whole point of role_table_grants is that it shows everything that > > table_privileges shows except privileges granted to public. So the > > behavior you observe is correct. > > This is not my understanding of ISO/IEC 9075-11:2003(E)

Re: [HACKERS] Testing with concurrent sessions

Hi, Kevin Grittner wrote: My pager is "less"; could that cause it? Could the twisted environment look like one where the pager should kick in? Yes, that could be it. At least it fails here, too, if I set PAGER=less. Try: PAGER=more make dcheck So, the solution probably lies in adjusting

Re: [HACKERS] Testing with concurrent sessions

Markus Wanner wrote: > Strangely, your log has escape codes in it, which I'm assuming > makes the parsing choke. Is that something special to your > installation? My pager is "less"; could that cause it? Could the twisted environment look like one where the pager should kick in? -Kevin --

Re: [HACKERS] Streaming replication, retrying from archive

On Fri, 2010-01-15 at 20:11 +0200, Heikki Linnakangas wrote: > The states we have at the moment in standby are: > > 1. Archive recovery. Standby fetches WAL files from archive using > restore_command. When a file is not found in archive, we switch to state 2 > > 2. Streaming replication. Standby

Re: [HACKERS] Testing with concurrent sessions

Hi, Kevin Grittner wrote: I haven't configured anything like that intentionally. I don't *see* any colors when I use psql. Can you think of anywhere I should check something which might be causing this? No idea ATM. However, just to make sure that has absolutely nothing to do with the curs

Re: [HACKERS] Hot Standby and handling max_standby_delay

Simon Riggs wrote: > We need to calculate a more accurate time since WAL arrived to make > max_standby_delay sensible in all cases. Difficult to know exactly when > to record new timestamps for received WAL. So, proposal is... > > if (Base time is earlier than WAL record time) > standby_dela

Re: [HACKERS] Streaming replication status

Stefan Kaltenbrunner wrote: Another popular question is "how far behind real-time is the archiver process?" You can do this right now by duplicating the same xlog file name scanning and sorting that the archiver does in your own code, looking for .ready files. It would be simpler if you cou

Re: [HACKERS] Streaming replication, loose ends

On Fri, 2010-01-15 at 19:29 +0200, Heikki Linnakangas wrote: > File-based Log Shipping > Planning > Implementation > Streaming Replication > Setting up How about "Log Streaming Replication"? So its a particular kind of replication, which seems correct to me. -- Simon

Re: [HACKERS] Testing with concurrent sessions

Markus Wanner wrote: > Strangely, your log has escape codes in it, which I'm assuming > makes the parsing choke. Is that something special to your > installation? My psql never colors its outputs... I haven't configured anything like that intentionally. I don't *see* any colors when I use psq

Re: [HACKERS] Testing with concurrent sessions

Markus Wanner wrote: > I wasn't aware I had non-ascii characters in there. Inserting an > encoding line seems fine. I'll fix that for the upcoming version > 0.1. Yeah, I couldn't find any, either. I just tried creating a minimal python file in Kate, and it gave me that even though I *know* i

Re: [HACKERS] Testing with concurrent sessions

Hi, Kevin Grittner wrote: You are trying to save a python file as non ASCII, without specifiying a correct source encoding line for encoding "utf-8" I wasn't aware I had non-ascii characters in there. Inserting an encoding line seems fine. I'll fix that for the upcoming version 0.1. Regards

Re: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

Leonardo F wrote: >> Yeah, I think you could do that, I agree it feels better that way. >> You'll still need new copytup and comparetup functions, though, to deal >> with HeapTupleHeaders instead of MinimalTuples, or modify the existing >> ones to handle both. > > You meant HeapTuple, not HeapTup

Re: [HACKERS] Testing with concurrent sessions

Hi, Kevin Grittner wrote: Not sure what's relevant there. Entire file tarball attached. Due to reasons mentioned in this thread as well, I've decided to use psql to connect to the database. dtester is parsing its output and checks that against expectations. Hawever, that has its own pitfall

[HACKERS] Hot Standby and handling max_standby_delay

We need to calculate a more accurate time since WAL arrived to make max_standby_delay sensible in all cases. Difficult to know exactly when to record new timestamps for received WAL. So, proposal is... if (Base time is earlier than WAL record time) standby_delay = WAL record time - Base ti

Re: [HACKERS] Streaming replication, retrying from archive

Dimitri Fontaine wrote: > But how we handle failures when transitioning from one state to the > other should be a lot easier to discuss and decide as soon as we have > the possible states and the transitions we want to allow and support. I > think. > > My guess is that those states and transitions

[HACKERS] ECPG documentation patch

Hi, here's the documentation patch for the new ECPG features. - I changed the order of sections "Using Descriptor Areas" and "Informix compatibility mode" - split the "Using Descriptor Areas", so it now have two subsections: "Named SQL Descriptor Areas" and "SQLDA Descriptor Areas". The sec

Re: [HACKERS] Streaming replication status

Stefan Kaltenbrunner wrote: > Kevin Grittner wrote: >> Right, we don't want to give the monitoring software an OS login >> for the database servers, for security reasons. > > depending on what you exactly mean by that I do have to wonder how > you monitor more complex stuff (or stuff that requi

Re: [HACKERS] Streaming replication, loose ends

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 +1, it is not replication. I would call it something like continuous archiving or streaming pitr I agree we should consider a different name. > But I'm still wondering why this isn't replication. Because replication is an ambiguous

Re: [HACKERS] Application name patch - v3

Le 08/01/2010 23:22, Guillaume Lelarge a écrit : > Le 07/01/2010 19:13, Robert Haas a écrit : >> On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge >> wrote: >>> Le 04/01/2010 22:36, Guillaume Lelarge a écrit : Le 29/12/2009 14:12, Guillaume Lelarge a écrit : > Le 29/12/2009 00:03, Guilla

Re: [HACKERS] Streaming replication, loose ends

On Fri, Jan 15, 2010 at 12:11:01PM -0500, Tom Lane wrote: > Heikki Linnakangas writes: > > I moved the line for src/backend/replication/walreceiver in > > src/Makefile further down, after src/interfaces. That should fix > > the build failures for now, but I'm all ears if there's better > > suggest

Re: [HACKERS] Streaming replication, loose ends

On Jan 15, 2010, at 9:37 AM, Robert Haas wrote: > But I'm still wondering why this isn't replication. I was wondering the same thing. ISTM that the docs could reference third-party replication solutions, too (or a wiki page listing them, since they'll change often). Anyway, I think Heikki's pr

Re: [HACKERS] Streaming replication, loose ends

On Fri, Jan 15, 2010 at 12:30 PM, Heikki Linnakangas wrote: > Robert Haas wrote: >> On Fri, Jan 15, 2010 at 12:17 PM, Joshua D. Drake >> wrote: Uh, do we really want to call this "replication" rather than archive log streaming or something.  It seems "replication" is a generic term and

Re: [HACKERS] Streaming replication, loose ends

On Fri, 2010-01-15 at 19:30 +0200, Heikki Linnakangas wrote: > Robert Haas wrote: > > On Fri, Jan 15, 2010 at 12:17 PM, Joshua D. Drake > > wrote: > >>> Uh, do we really want to call this "replication" rather than archive log > >>> streaming or something. It seems "replication" is a generic term

Re: [HACKERS] Streaming replication status

Kevin Grittner wrote: Greg Smith wrote: In many of the more secure environments I've worked in (finance, defense), there is *no* access to the database server beyond what comes out of port 5432 without getting a whole separate team of people involved. If the DBA can write a simple monitorin

Re: [HACKERS] Streaming replication, loose ends

Robert Haas wrote: > On Fri, Jan 15, 2010 at 12:17 PM, Joshua D. Drake > wrote: >>> Uh, do we really want to call this "replication" rather than archive log >>> streaming or something. It seems "replication" is a generic term and >>> will confuse people who are using other replication solutions

Re: [HACKERS] Streaming replication, loose ends

Bruce Momjian wrote: > Heikki Linnakangas wrote: >> I've now committed streaming replication. I moved the files around a >> bit, and put the walreceiver/walsender stuff in a new >> src/backend/replication subdirectory. There's enough stuff there already >> to deserve a new subdirectory, and if we a

Re: [HACKERS] Streaming replication status

Greg Smith wrote: Stefan Kaltenbrunner wrote: Greg Smith wrote: The other popular request that keeps popping up here is providing an easy way to see how backlogged the archive_command is, to make it easier to monitor for out of disk errors that might prove catastrophic to replication. I

Re: [HACKERS] Streaming replication, loose ends

On Fri, Jan 15, 2010 at 12:17 PM, Joshua D. Drake wrote: >> Uh, do we really want to call this "replication" rather than archive log >> streaming or something.  It seems "replication" is a generic term and >> will confuse people who are using other replication solutions like >> Slony. > > +1, it

Re: [HACKERS] Streaming replication, loose ends

On Fri, 2010-01-15 at 05:36 -0500, Bruce Momjian wrote: > Heikki Linnakangas wrote: > > I've now committed streaming replication. I moved the files around a > > bit, and put the walreceiver/walsender stuff in a new > > src/backend/replication subdirectory. There's enough stuff there already > > to

Re: [HACKERS] Streaming replication, loose ends

Heikki Linnakangas writes: > I moved the line for src/backend/replication/walreceiver in src/Makefile > further down, after src/interfaces. That should fix the build failures > for now, but I'm all ears if there's better suggestions. Yeah, I saw. Seems like a reasonable solution for now.

Re: [HACKERS] Streaming replication, loose ends

Robert Haas wrote: > On Fri, Jan 15, 2010 at 11:47 AM, Heikki Linnakangas > wrote: >> Tom Lane wrote: >>> Heikki Linnakangas writes: Yep. What's happening is that "make -j" starts building libpq and walreceiver.so simultaneously, because of the above line in the Makefile. We actual

Re: [HACKERS] Streaming replication, loose ends

Heikki Linnakangas writes: > Tom Lane wrote: >> I'm actually fairly uncomfortable with the notion that something buried >> deep within the src/backend tree is going to reach over and cause libpq >> to get built. Maybe the real answer is that you put walreceiver in the >> wrong place, and it ought

Re: [HACKERS] Streaming replication, loose ends

On Fri, Jan 15, 2010 at 11:47 AM, Heikki Linnakangas wrote: > Tom Lane wrote: >> Heikki Linnakangas writes: >>> Yep. What's happening is that "make -j" starts building libpq and >>> walreceiver.so simultaneously, because of the above line in the >>> Makefile. We actually have the same problem in

Re: [HACKERS] Streaming replication status

Greg Smith wrote: > In many of the more secure environments I've worked in (finance, > defense), there is *no* access to the database server beyond what > comes out of port 5432 without getting a whole separate team of > people involved. If the DBA can write a simple monitoring program > thems

Re: [HACKERS] Streaming replication status

Stefan Kaltenbrunner wrote: Greg Smith wrote: The other popular request that keeps popping up here is providing an easy way to see how backlogged the archive_command is, to make it easier to monitor for out of disk errors that might prove catastrophic to replication. I tend to disagree -

Re: [HACKERS] Streaming replication, loose ends

Tom Lane wrote: > Heikki Linnakangas writes: >> Yep. What's happening is that "make -j" starts building libpq and >> walreceiver.so simultaneously, because of the above line in the >> Makefile. We actually have the same problem in src/bin/*/Makefile, but >> we don't notice it there because src/int

Re: [HACKERS] New XLOG record indicating WAL-skipping

Greg Stark wrote: > What if someone takes a hot backup while an unlogged operation is in progress. Can't do that, pg_start_backup() throws an error if archive_mode=off. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@po

Re: [HACKERS] Testing with concurrent sessions

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Dead or not, it still works, even against 8.4. I have many programs > that use it. It's simply a wrapper around the libpq interface and as > long as the libpq interface remains stable (which we go to great pains >

Re: [HACKERS] Streaming replication, loose ends

Heikki Linnakangas writes: > Yep. What's happening is that "make -j" starts building libpq and > walreceiver.so simultaneously, because of the above line in the > Makefile. We actually have the same problem in src/bin/*/Makefile, but > we don't notice it there because src/interfaces is listed befo

Re: [HACKERS] New XLOG record indicating WAL-skipping

On Fri, Jan 15, 2010 at 11:28 AM, Heikki Linnakangas wrote: > I can see that it > was required to avoid the flooding from heap_insert(), but we can move > the XLogSkipLogging() call from heap_insert() to heap_sync(). > > Attached is an updated patch, doing the above. Am I missing anything? Hm, pe

Re: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

> Yeah, I think you could do that, I agree it feels better that way. > You'll still need new copytup and comparetup functions, though, to deal > with HeapTupleHeaders instead of MinimalTuples, or modify the existing > ones to handle both. You meant HeapTuple, not HeapTupleHeaders, right? Mmh, di

Re: [HACKERS] Testing with concurrent sessions

Markus Wanner wrote: > Second: at the very end of pg_dtester.py, you find the line: > reporter = StreamReporter() > > Try a CursesReporter() instead, it gives much nicer output! When I try to do that, Kate complains (I'm even copying their typo): You are trying to save a python file as no

Re: [HACKERS] Testing with concurrent sessions

"Markus Wanner" wrote: > Quoting "Kevin Grittner" : >> I haven't quite gotten it to work yet; I'll start over with 3.0 >> and see how it goes. > > Let's stick to 2.x versions, first... OK > It does: "temp_install: creating temporary installation" means > it's running make install in the backgr

Re: [HACKERS] Testing with concurrent sessions

Hi, Quoting "Kevin Grittner" : I haven't quite gotten it to work yet; I'll start over with 3.0 and see how it goes. Let's stick to 2.x versions, first... I'll also attach the results of the 2.6 attempt. Thanks, that looks already pretty promising. ;-) A few other issues in testing so far

Re: [HACKERS] Testing with concurrent sessions

I wrote: > I'll also attach the results of the 2.6 attempt. Let's try that again. -Kevin kgri...@kgrittn-desktop:~/git/postgresql/kgrittn$ make dcheck make -C src/test dcheck make[1]: Entering directory `/home/kgrittn/git/postgresql/kgrittn/src/test' make

Re: [HACKERS] Testing with concurrent sessions

Markus Wanner wrote: > I must admit that I haven't ever tested on python 2.6 before. I'll > try that (especially as it's the staircase to 3.0, IIUC). I don't use python much, so I can't comment on that. I do see that my system has these two versions on it, with a symlink that makes 2.6 the de

Re: [HACKERS] missing data in information_schema grant_* tables?

Dear Peter, (1) Would you agree that it is a "bug"? That is, if the grantee is PUBLIC, it is an enabled role for the current user, so it should appear in the role_table_grants view... The whole point of role_table_grants is that it shows everything that table_privileges shows except privileg

Re: [HACKERS] Streaming replication, loose ends

Heikki Linnakangas wrote: > Also, I'm seeing a failure in buildfarm member 'colugos': > > /opt/local/bin/ccache /Developer/usr/bin/llvm-gcc-4.2 -no-cpp-precomp > -I/opt/local/include -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing > -f

Re: [HACKERS] Streaming replication status

Greg Smith wrote: > to make it easier to monitor for out of disk errors that might > prove catastrophic to replication. We handle that with the fsutil functions (in pgfoundry). This can actually measure free space on each volume. These weren't portable enough to include in core, but maybe th

Re: [HACKERS] ECPG DESCRIBE [OUTPUT] support

On Fri, Jan 15, 2010 at 01:16:18PM +0100, Boszormenyi Zoltan wrote: > Please, also add this small change that adds ecpg_raise() > calls to ECPGdescribe() to return the proper sqlca error > in error paths for: > ... Done. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes d

Re: [HACKERS] per-user pg_service.conf

> > I was surprised/annoyed to find out that there is no way to have > > per-user pg_service.conf, something like ~/.pg_service.conf (well, > > except by export PGSYSCONFDIR). That would be easy to add. > > Comments? > > Here's a patch. Perhaps those who had said they would like that can > valid

Re: [HACKERS] Streaming replication, loose ends

Boszormenyi Zoltan wrote: > Heikki Linnakangas írta: >> I've now committed streaming replication. I moved the files around a >> bit, and put the walreceiver/walsender stuff in a new >> src/backend/replication subdirectory. [snip] > > there's one loose end indeed. > "make maintainer-clean" doesn't

Re: [HACKERS] missing data in information_schema grant_* tables?

On fre, 2010-01-15 at 12:00 +0100, Fabien COELHO wrote: > INSERT to PUBLIC is shown on the last line of the access privileges > column. However, when looking at the information_schema: > > psql> SELECT grantor, grantee, privilege_type > FROM information_schema.role_table_grants >

Re: [HACKERS] ECPG DESCRIBE [OUTPUT] support

Hi, I just saw that you committed the DESCRIBE patch. Please, also add this small change that adds ecpg_raise() calls to ECPGdescribe() to return the proper sqlca error in error paths for: - unsupported call for DESCRIBE INPUT - no such connection name - no such prepared statement Thanks and bes

Re: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

Leonardo F wrote: > I read the thread "Our CLUSTER implementation is pessimal" > http://archives.postgresql.org/pgsql-hackers/2008-08/msg01371.php . > > I would like to try/integrate that patch as we use CLUSTER a lot on our > system. Great! > About that patch: > > 1) would it be possible to

[HACKERS] About "Our CLUSTER implementation is pessimal" patch

Hi, I read the thread "Our CLUSTER implementation is pessimal" http://archives.postgresql.org/pgsql-hackers/2008-08/msg01371.php . I would like to try/integrate that patch as we use CLUSTER a lot on our system. I was going to try to add the proper cost_index/cost_sort calls to decide which "pa

Re: [HACKERS] New XLOG record indicating WAL-skipping

Fujii Masao wrote: > On Wed, Dec 9, 2009 at 6:25 PM, Fujii Masao wrote: >> Here is the patch: >> >> - Write an XLOG UNLOGGED record in WAL if WAL-logging is skipped for only >> the reason that WAL archiving is not enabled and such record has not been >> written yet. >> >> - Cause archive recover

[HACKERS] missing data in information_schema grant_* tables?

Hello pgdevs, I'm trying to use the information_schema, and I'm looking at the grant tables. ISTM that some views do not show all expected permissions. psql> CREATE TABLE foo(); psql> CREATE USER calvin NOLOGIN; psql> GRANT SELECT ON TABLE foo TO calvin; psql> GRANT INSERT ON TABLE foo TO P

Re: [HACKERS] Streaming replication, loose ends

Hi, Heikki Linnakangas írta: > I've now committed streaming replication. I moved the files around a > bit, and put the walreceiver/walsender stuff in a new > src/backend/replication subdirectory. [snip] there's one loose end indeed. "make maintainer-clean" doesn't delete these: src/backend/repli

Re: [HACKERS] Streaming replication, loose ends

2010/1/15 Bruce Momjian : > Heikki Linnakangas wrote: >> I've now committed streaming replication. I moved the files around a >> bit, and put the walreceiver/walsender stuff in a new >> src/backend/replication subdirectory. There's enough stuff there already >> to deserve a new subdirectory, and if

Re: [HACKERS] Streaming replication, loose ends

Heikki Linnakangas wrote: > I've now committed streaming replication. I moved the files around a > bit, and put the walreceiver/walsender stuff in a new > src/backend/replication subdirectory. There's enough stuff there already > to deserve a new subdirectory, and if we add the capability for > str

[HACKERS] Streaming replication, loose ends

I've now committed streaming replication. I moved the files around a bit, and put the walreceiver/walsender stuff in a new src/backend/replication subdirectory. There's enough stuff there already to deserve a new subdirectory, and if we add the capability for streaming base backups etc. that has be

Re: [HACKERS] [PL/PgSQL] EXECUTE...USING enhancement proposal

2010/1/15 Vincenzo Romano : > 2010/1/15 Pavel Stehule : >> I disagree with this functionality for USING clause. Main parser >> doesn't support some enhanced syntax. But we can discus about some >> function 'printf' or 'format' that can help with similar task. >> >> some like >> >> EXECUTE format('A

Re: [HACKERS] [PL/PgSQL] EXECUTE...USING enhancement proposal

2010/1/15 Pavel Stehule : > I disagree with this functionality for USING clause. Main parser > doesn't support some enhanced syntax. But we can discus about some > function 'printf' or 'format' that can help with similar task. > > some like > > EXECUTE format('ALTER TABLE % ADD CHECK (col1=% AND co

  1   2   >