[HACKERS] Behavior difference for walsender and walreceiver for n/w breakdown case

I have observed that currently incase there is a network break between master and standby, walsender process gets terminated immediately, however walreceiver detects the breakage after long time. The main reason I could see is due to replication_timeout configuration parameter, walsender checks f

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

On Wed, Sep 5, 2012 at 7:14 PM, Tom Lane wrote: > This seems to me to be going in exactly the wrong direction. What > I visualize this feature as responding to is demand for a *simple*, > minimal configuration, minimal administration, quasi-embedded database. > What you propose above is not that,

Re: [HACKERS] Draft release notes complete

On 09/05/2012 11:44 PM, Stephen Frost wrote: * Andrew Dunstan (and...@dunslane.net) wrote: You mean in my copious spare time? If you're alright with the concept, then anyone can do it. I was looking more for your concurrence on the idea of documenting this explicitly (which also implies that

Re: [HACKERS] Draft release notes complete

* Andrew Dunstan (and...@dunslane.net) wrote: > You mean in my copious spare time? If you're alright with the concept, then anyone can do it. I was looking more for your concurrence on the idea of documenting this explicitly (which also implies that it'll be supported, etc). I'd be happy to deve

Re: [HACKERS] Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav

On 08/15/2012 11:41 AM, Peter Geoghegan wrote: I know that someone is going to point out that in some particularly benchmark, they can get another relatively modest increase in throughput (perhaps 2%-3%) by splitting the difference between two adjoining millisecond integer values. In that scenari

Re: [HACKERS] Draft release notes complete

On 09/05/2012 11:01 PM, Stephen Frost wrote: * Andrew Dunstan (and...@dunslane.net) wrote: The buildfarm code does not run if there are no changes. The job runs, sees that there are no changes, and exits. Right, hence it makes great sense to use it for this (as opposed to Bruce's previous scri

Re: [HACKERS] too much pgbench init output

On Tue, 2012-09-04 at 23:44 -0400, Tom Lane wrote: > > b) There is no indication of where the end is. > > Well, surely *that* can be fixed in a noncontroversial way: just > print "M/N tuples done", where N is the target. I have made this change. I won't pursue using \r if others find it useful a

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

On Wed, Sep 5, 2012 at 10:46:17PM -0400, Andrew Dunstan wrote: > > On 09/05/2012 10:41 PM, Bruce Momjian wrote: > > > >I would like to see a more verbose comment, so we don't forget why we > >did this. I think my inability to quickly discover the cause of the > >previous log write problem is tha

Re: [HACKERS] Draft release notes complete

* Andrew Dunstan (and...@dunslane.net) wrote: > The buildfarm code does not run if there are no changes. The job > runs, sees that there are no changes, and exits. Right, hence it makes great sense to use it for this (as opposed to Bruce's previous script or some other new one). While it might ap

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

On 09/05/2012 10:41 PM, Bruce Momjian wrote: I would like to see a more verbose comment, so we don't forget why we did this. I think my inability to quickly discover the cause of the previous log write problem is that I didn't document which file descriptors are kept open on Windows. I sugges

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

On Wed, Sep 5, 2012 at 10:35:26PM -0400, Andrew Dunstan wrote: > diff --git a/contrib/pg_upgrade/exec.c b/contrib/pg_upgrade/exec.c > index 99f5006..f84d857 100644 > --- a/contrib/pg_upgrade/exec.c > +++ b/contrib/pg_upgrade/exec.c > @@ -63,7 +63,25 @@ exec_prog(const char *log_file, const char *o

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

On Wed, Sep 5, 2012 at 10:35:26PM -0400, Andrew Dunstan wrote: > >>Icky. I wish there were some nice portable flock() mechanism we could use. > >> > >>I just re-ran the test on the same machine, same code, same > >>everything as the reporte3d failure, and it passed, so it definitely > >>looks like

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

On 09/05/2012 10:07 PM, Bruce Momjian wrote: On Wed, Sep 5, 2012 at 10:04:07PM -0400, Andrew Dunstan wrote: On 09/05/2012 09:42 PM, Bruce Momjian wrote: On Wed, Sep 5, 2012 at 09:07:05PM -0400, Andrew Dunstan wrote: OK, I worked with Andrew on this issue, and have applied the attached patch

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

On 09/05/2012 10:14 PM, Tom Lane wrote: Aidan Van Dyk writes: So, in the spirit of not painting ourselves into a tiny corner here on the whole "single backend" and "embedded database" problem with pg options, can we generalize this a bit? Any way we could make psql connect to a "given fd", as

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

Aidan Van Dyk writes: > So, in the spirit of not painting ourselves into a tiny corner here on > the whole "single backend" and "embedded database" problem with pg > options, can we generalize this a bit? > Any way we could make psql connect to a "given fd", as an option? In > theory, that could

Re: [HACKERS] Draft release notes complete

On 09/05/2012 09:59 PM, Stephen Frost wrote: * Bruce Momjian (br...@momjian.us) wrote: How often do you want? After all, is presumably going to keep pointing to where it now points. Well, the old code checked every five minutes, and it

Re: [HACKERS] Draft release notes complete

On Wed, Sep 5, 2012 at 09:59:50PM -0400, Stephen Frost wrote: > * Bruce Momjian (br...@momjian.us) wrote: > > > How often do you want? After all, > > > is > > > presumably going to keep pointing to where it now points. > > > > Well, the o

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

On Wed, Sep 5, 2012 at 10:04:07PM -0400, Andrew Dunstan wrote: > > On 09/05/2012 09:42 PM, Bruce Momjian wrote: > >On Wed, Sep 5, 2012 at 09:07:05PM -0400, Andrew Dunstan wrote: > >>>OK, I worked with Andrew on this issue, and have applied the attached > >>>patch which explains what is happening

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

On 09/05/2012 09:42 PM, Bruce Momjian wrote: On Wed, Sep 5, 2012 at 09:07:05PM -0400, Andrew Dunstan wrote: OK, I worked with Andrew on this issue, and have applied the attached patch which explains what is happening in this case. Andrew's #ifndef WIN32 was the correct fix. I consider this i

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

So, in the spirit of not painting ourselves into a tiny corner here on the whole "single backend" and "embedded database" problem with pg options, can we generalize this a bit? Any way we could make psql connect to a "given fd", as an option? In theory, that could be something opened by some out-

Re: [HACKERS] Draft release notes complete

* Bruce Momjian (br...@momjian.us) wrote: > > How often do you want? After all, > > is > > presumably going to keep pointing to where it now points. > > Well, the old code checked every five minutes, and it rebuilt in 4 > minutes, so there

Re: [HACKERS] Cascading replication on Windows bug

On 05.09.2012 16:45, Heikki Linnakangas wrote: On 05.09.2012 14:28, Tom Lane wrote: Heikki Linnakangas writes: That doesn't work on Windows. As long as a walsender is keeping the old file open, the unlink() on it fails. You get an error like this in the startup process: FATAL: could not rename

Re: [HACKERS] Report proper GUC parameter names in error messages

Gurjeet Singh writes: > Error messages when terminating xlog redo leads the user to believe that > there are parameters named max_prepared_xacts and max_locks_per_xact, which > is not true. This patch corrects the parameter names emitted in the logs. Good catch --- applied.

Re: [HACKERS] Draft release notes complete

On Wed, Sep 5, 2012 at 09:33:35PM -0400, Andrew Dunstan wrote: > > On 09/05/2012 09:25 PM, Bruce Momjian wrote: > >On Wed, Sep 5, 2012 at 09:56:32PM -0300, Alvaro Herrera wrote: > >>Excerpts from Tom Lane's message of mié sep 05 20:24:08 -0300 2012: > >>>Andrew Dunstan writes: > The only re

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

On Wed, Sep 5, 2012 at 09:07:05PM -0400, Andrew Dunstan wrote: > >OK, I worked with Andrew on this issue, and have applied the attached > >patch which explains what is happening in this case. Andrew's #ifndef > >WIN32 was the correct fix. I consider this issue closed. > > > > > It looks like w

Re: [HACKERS] Draft release notes complete

On Wed, Sep 5, 2012 at 06:32:48PM -0700, Josh Berkus wrote: > > > Correct. I have always had a working SGML toolset. If we are not going > > to have the developer site run more often, I will just go back to > > setting up my own public doc build, like I used to do. I removed mine > > when the

Re: [HACKERS] Draft release notes complete

On 09/05/2012 09:25 PM, Bruce Momjian wrote: On Wed, Sep 5, 2012 at 09:56:32PM -0300, Alvaro Herrera wrote: Excerpts from Tom Lane's message of mié sep 05 20:24:08 -0300 2012: Andrew Dunstan writes: The only reason there is a significant delay is that the administrators have chosen not to r

Re: [HACKERS] Draft release notes complete

> Correct. I have always had a working SGML toolset. If we are not going > to have the developer site run more often, I will just go back to > setting up my own public doc build, like I used to do. I removed mine > when the official one was more current/reliable --- if that has changed, > I wil

Re: [HACKERS] Draft release notes complete

On Wed, Sep 5, 2012 at 09:56:32PM -0300, Alvaro Herrera wrote: > Excerpts from Tom Lane's message of mié sep 05 20:24:08 -0300 2012: > > Andrew Dunstan writes: > > > The only reason there is a significant delay is that the administrators > > > have chosen not to run the process more than once ev

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

On 09/05/2012 12:02 AM, Bruce Momjian wrote: On Mon, Sep 3, 2012 at 12:44:09PM -0400, Andrew Dunstan wrote: The attached very small patch allows pg_upgrade's "make check" to succeed on REL9_2_STABLE on my Mingw system. However, I consider the issue I mentioned earlier regarding use of forward

Re: [HACKERS] Draft release notes complete

Excerpts from Tom Lane's message of mié sep 05 20:24:08 -0300 2012: > Andrew Dunstan writes: > > The only reason there is a significant delay is that the administrators > > have chosen not to run the process more than once every 4 hours. That's > > a choice not dictated by the process they are u

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

On Wed, Sep 5, 2012 at 3:17 PM, Peter Eisentraut wrote: > On 9/5/12 5:59 PM, Daniel Farina wrote: >> I agree with this, even though in theory (but not in practice) >> creative use of unix sockets (sorry windows, perhaps some >> port-allocating and URL mangling can be done instead) and conventions

Re: [HACKERS] Cascading replication on Windows bug

On 05.09.2012 14:28, Tom Lane wrote: Heikki Linnakangas writes: That doesn't work on Windows. As long as a walsender is keeping the old file open, the unlink() on it fails. You get an error like this in the startup process: FATAL: could not rename file "pg_xlog/RECOVERYXLOG" to "pg_xlog/00

Re: [HACKERS] Draft release notes complete

Andrew Dunstan writes: > The only reason there is a significant delay is that the administrators > have chosen not to run the process more than once every 4 hours. That's > a choice not dictated by the process they are using, but by other > considerations concerning the machine it's being run o

Re: [HACKERS] Draft release notes complete

On 09/05/2012 06:13 PM, Peter Eisentraut wrote: On 8/29/12 11:52 PM, Andrew Dunstan wrote: Why does this need to be tied into the build farm? Someone can surely set up a script that just runs the docs build at every check-in, like it used to work. What's being proposed now just sounds like a

[HACKERS] Report proper GUC parameter names in error messages

Error messages when terminating xlog redo leads the user to believe that there are parameters named max_prepared_xacts and max_locks_per_xact, which is not true. This patch corrects the parameter names emitted in the logs. Best regards, -- Gurjeet Singh proper_GUC_names.patch Description: Binar

Re: [HACKERS] [bugfix] sepgsql didn't follow the latest core API changes

2012/9/5 Robert Haas : > On Sun, Sep 2, 2012 at 2:53 PM, Kohei KaiGai wrote: >> This patch fixes a few portions on which sepgsql didn't follow the latest >> core API changes. >> >> 1) Even though the prototype of ProcessUtility_hook was recently changed, >> sepgsql side didn't follow this update,

Re: [HACKERS] plperl sigfpe reset can crash the server

Andres Freund writes: > On Wednesday, September 05, 2012 07:15:52 PM Tom Lane wrote: >> OK. Do we want to commit this now, or wait till after 9.2.0? >> My feeling is it's probably okay to include in 9.2.0, but I can see >> that somebody might want to argue not to. Any objections out there? > Pe

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

> Um ... true with respect to autovacuum, perhaps, but what about > checkpoints? A standalone backend will never perform a checkpoint > unless explicitly told to. Hmmm, that's definitely an issue. > (Before we invented the bgwriter, the > postmaster was in charge of launching checkpoints every

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

On 9/5/12 2:50 PM, Peter Eisentraut wrote: > On 9/5/12 5:03 PM, Tom Lane wrote: >> I don't see people wanting to use this feature for unit tests. > > If this is going to become an official feature (as opposed to an > internal interface only for use by pg_upgrade), then I think that's > exactly wha

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

On 9/5/12 5:59 PM, Daniel Farina wrote: > I agree with this, even though in theory (but not in practice) > creative use of unix sockets (sorry windows, perhaps some > port-allocating and URL mangling can be done instead) and conventions > for those would allow even better almost-like-embedded resul

[HACKERS] Cascading replication on Windows bug

Starting with 9.2, when a WAL segment is restored from the archive, it is copied over any existing file in pg_xlog with the same name. This is done in two steps: first the file is restored from archive to a temporary file called RECOVERYXLOG, then the old file is deleted and the temporary file

Re: [HACKERS] Draft release notes complete

On 8/29/12 11:52 PM, Andrew Dunstan wrote: > >> Why does this need to be tied into the build farm? Someone can surely >> set up a script that just runs the docs build at every check-in, like it >> used to work. What's being proposed now just sounds like a lot of >> complication for little or no a

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

On Wed, Sep 5, 2012 at 2:50 PM, Peter Eisentraut wrote: > On 9/5/12 5:03 PM, Tom Lane wrote: >> I don't see people wanting to use this feature for unit tests. > > If this is going to become an official feature (as opposed to an > internal interface only for use by pg_upgrade), then I think that's

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

On 9/5/12 5:03 PM, Tom Lane wrote: > I don't see people wanting to use this feature for unit tests. If this is going to become an official feature (as opposed to an internal interface only for use by pg_upgrade), then I think that's exactly what people will want to use it for. In fact, it might e

Re: [HACKERS] State of the on-disk bitmap index

Hi Daniel, On Wed, Sep 05, 2012 at 01:37:59PM +0200, Daniel Bausch wrote: > Is that, what your bmi-perf-test.tar.gz from 2008 does? I did not > look into that. IIRC yes (but it's been a long time and I don't have a copy at hand now). Best regards, Dr. Gianni Ciolli - 2ndQuadrant Italia PostgreS

Re: [HACKERS] Cascading replication on Windows bug

Heikki Linnakangas writes: > That doesn't work on Windows. As long as a walsender is keeping the old > file open, the unlink() on it fails. You get an error like this in the > startup process: > FATAL: could not rename file "pg_xlog/RECOVERYXLOG" to > "pg_xlog/0001000D": Permis

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

On Wed, Sep 5, 2012 at 01:50:06PM -0700, Josh Berkus wrote: > Tom, > > > However, there are some additional things > > we'd need to think about before advertising it as a fit solution for that. > > Notably, while the lack of any background processes is just what you want > > for pg_upgrade and di

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

Josh Berkus writes: >> However, there are some additional things >> we'd need to think about before advertising it as a fit solution for that. >> Notably, while the lack of any background processes is just what you want >> for pg_upgrade and disaster recovery, an ordinary application is probably >

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

Tom, > However, there are some additional things > we'd need to think about before advertising it as a fit solution for that. > Notably, while the lack of any background processes is just what you want > for pg_upgrade and disaster recovery, an ordinary application is probably > going to want to r

Re: [HACKERS] pg_upgrade diffs on WIndows

On Wed, Sep 5, 2012 at 04:22:18PM -0400, Andrew Dunstan wrote: > >>So, right now we are only add \r for function bodies, which is mostly > >>harmless, but what if a function body has strings with an embedded > >>newlines? What about creating a table with newlines in its identifiers: > >> > >>CREA

Re: [HACKERS] [bugfix] sepgsql didn't follow the latest core API changes

2012/9/5 Andrew Dunstan : > > On 09/05/2012 09:11 AM, Alvaro Herrera wrote: >> >> Excerpts from Kohei KaiGai's message of mié sep 05 08:30:37 -0300 2012: >>> >>> 2012/9/3 Alvaro Herrera : Excerpts from Kohei KaiGai's message of dom sep 02 15:53:22 -0300 2012: > > This patch fixes

Re: [HACKERS] pg_upgrade diffs on WIndows

On 09/05/2012 03:50 PM, Andrew Dunstan wrote: On 09/05/2012 03:40 PM, Bruce Momjian wrote: On Wed, Sep 5, 2012 at 03:17:40PM -0400, Andrew Dunstan wrote: The PG_BINARY_W change has only been verified on a non-buildfarm setup on my laptop (Mingw) Note that while it does look like there's a b

Re: [HACKERS] pg_upgrade diffs on WIndows

On Wed, Sep 5, 2012 at 03:50:13PM -0400, Andrew Dunstan wrote: > >>The second lot of CRs (seen in the second dump file in the diff i > >>previously sent) is produced by pg_upgrade writing its output in > >>text mode, which turns LF into CRLF. The solution to that is the > >>patch to dump.c I poste

Re: [HACKERS] pg_upgrade diffs on WIndows

On 09/05/2012 03:40 PM, Bruce Momjian wrote: On Wed, Sep 5, 2012 at 03:17:40PM -0400, Andrew Dunstan wrote: The PG_BINARY_W change has only been verified on a non-buildfarm setup on my laptop (Mingw) Note that while it does look like there's a bug either in pg_upgrade or pg_dumpall, it's prob

Re: [HACKERS] pg_upgrade diffs on WIndows

On 09/05/2012 03:36 PM, Tom Lane wrote: Andrew Dunstan writes: OK, I now have a complete handle on what's going on here, and withdraw my earlier statement that I am confused on this issue :-) First, one lot of CRs is produced because the pg_upgrade test script calls pg_dumpall without -f and r

Re: [HACKERS] pg_upgrade diffs on WIndows

On Wed, Sep 5, 2012 at 03:17:40PM -0400, Andrew Dunstan wrote: > >The PG_BINARY_W change has only been verified on a non-buildfarm > >setup on my laptop (Mingw) > > > >Note that while it does look like there's a bug either in > >pg_upgrade or pg_dumpall, it's probably mostly harmless (adding > >so

Re: [HACKERS] pg_upgrade diffs on WIndows

Andrew Dunstan writes: > OK, I now have a complete handle on what's going on here, and withdraw > my earlier statement that I am confused on this issue :-) > First, one lot of CRs is produced because the pg_upgrade test script > calls pg_dumpall without -f and redirects that to a file, which Wi

Re: [HACKERS] pg_upgrade diffs on WIndows

On 09/05/2012 09:46 AM, Andrew Dunstan wrote: On 09/05/2012 09:11 AM, Bruce Momjian wrote: I reviewed this idea and supports this patch's inclusion in 9.2. I was unclear why it was needed, but I see pg_dumpall, which is the file pg_upgrade splits apart, as also using binary mode to write thi

Re: [HACKERS] [bugfix] sepgsql didn't follow the latest core API changes

On Sun, Sep 2, 2012 at 2:53 PM, Kohei KaiGai wrote: > This patch fixes a few portions on which sepgsql didn't follow the latest > core API changes. > > 1) Even though the prototype of ProcessUtility_hook was recently changed, > sepgsql side didn't follow this update, so it made build failed. > > 2

Re: [HACKERS] plperl sigfpe reset can crash the server

On Wednesday, September 05, 2012 07:15:52 PM Tom Lane wrote: > Andres Freund writes: > > On Sunday, August 26, 2012 06:10:02 PM Andres Freund wrote: > >> On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote: > >>> Surely that's breaking perl's expectations, to more or less the same > >>> degree

Re: [HACKERS] plperl sigfpe reset can crash the server

Andres Freund writes: > On Sunday, August 26, 2012 06:10:02 PM Andres Freund wrote: >> On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote: >>> Surely that's breaking perl's expectations, to more or less the same >>> degree they're breaking ours? >> In the referenced bug they agree that this

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

On 05.09.2012 07:55, Dimitri Fontaine wrote: Heikki Linnakangas writes: I was worried about that too at first, but Fujii pointed out that's OK: see last paragraph at http://archives.postgresql.org/pgsql-hackers/2012-08/msg01203.php. Mmm, ok. I'm worried about master-standby-standby setup whe

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

Tom Lane schrieb: >Andres Freund writes: >> I don't find that a convincing comparison. Normally don't need to >shutdown the >> server between two pg_dump commands. Which very well might be >scripted. > >> Especially as for now, without a background writer/checkpointer >writing stuff >> befor

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

"anara...@anarazel.de" writes: > I am not saying its bad that it is slower, that's absolutely OK. Just that it > will take a variable amount of time till you can run pgdump again and its not > easily detectable without looping and trying again. Well, that's why the proposed libpq code is writte

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

Andres Freund writes: > I don't find that a convincing comparison. Normally don't need to shutdown > the > server between two pg_dump commands. Which very well might be scripted. > Especially as for now, without a background writer/checkpointer writing stuff > beforehand, the shutdown checkpoi

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

On Tuesday, September 04, 2012 12:11:28 PM Amit Kapila wrote: > On Tuesday, September 04, 2012 11:00 AM Andres Freund wrote: > > On Tuesday, September 04, 2012 06:20:59 AM Tom Lane wrote: > > Andres Freund writes: > >> > I can see why that would be nice, but is it really realistic? Don't we > >>

Re: [HACKERS] 9.2rc1 produces incorrect results

BTW, after considerable fooling around with Vik's example, I've been able to produce a regression test case that fails in all PG versions with WITH: with A as ( select q2 as id, (select q1) as x from int8_tbl ), B as ( select id, row_number() over (partition by id) as r from A ), C as ( select A.i

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

Heikki Linnakangas writes: > I was worried about that too at first, but Fujii pointed out that's OK: see > last paragraph at > http://archives.postgresql.org/pgsql-hackers/2012-08/msg01203.php. Mmm, ok. I'm worried about master-standby-standby setup where the master disappear, we promote a stand

Re: [HACKERS] 9.2rc1 produces incorrect results

Thom Brown writes: > On 5 September 2012 05:09, Tom Lane wrote: >> Attached is a draft patch against HEAD for this. I think it makes the >> planner's handling of outer-level Params far less squishy than it's ever >> been, but it is rather a large change. Not sure whether to risk pushing >> it i

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

On 05.09.2012 01:03, Dimitri Fontaine wrote: Heikki Linnakangas writes: On 04.09.2012 03:02, Dimitri Fontaine wrote: Heikki Linnakangas writes: Hmm, I was thinking that when walsender gets the position it can send the WAL up to, in GetStandbyFlushRecPtr(), it could atomically check the curr

Re: [HACKERS] plperl sigfpe reset can crash the server

On Sunday, August 26, 2012 06:10:02 PM Andres Freund wrote: > On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote: > > Andres Freund writes: > > > Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3 > > > seems to work. Is that acceptable? > > > > Surely that's breaking perl'

Re: [HACKERS] [bugfix] sepgsql didn't follow the latest core API changes

On 09/05/2012 09:11 AM, Alvaro Herrera wrote: Excerpts from Kohei KaiGai's message of mié sep 05 08:30:37 -0300 2012: 2012/9/3 Alvaro Herrera : Excerpts from Kohei KaiGai's message of dom sep 02 15:53:22 -0300 2012: This patch fixes a few portions on which sepgsql didn't follow the latest cor

Re: [HACKERS] pg_upgrade diffs on WIndows

On 09/05/2012 09:11 AM, Bruce Momjian wrote: I reviewed this idea and supports this patch's inclusion in 9.2. I was unclear why it was needed, but I see pg_dumpall, which is the file pg_upgrade splits apart, as also using binary mode to write this file: OPF = fopen(filename, P

Re: [HACKERS] pg_upgrade diffs on WIndows

On Tue, Sep 4, 2012 at 03:44:35PM -0400, Andrew Dunstan wrote: > > On 09/04/2012 03:09 PM, Andrew Dunstan wrote: > >I realized this morning that I might have been a bit cavalier in > >using dos2unix to smooth away differences in the dumpfiles > >produced by pg_upgrade. Attached is a dump of the d

Re: [HACKERS] [bugfix] sepgsql didn't follow the latest core API changes

Excerpts from Kohei KaiGai's message of mié sep 05 08:30:37 -0300 2012: > 2012/9/3 Alvaro Herrera : > > Excerpts from Kohei KaiGai's message of dom sep 02 15:53:22 -0300 2012: > >> This patch fixes a few portions on which sepgsql didn't follow the latest > >> core API changes. > > > > I think you s

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

On Wednesday, September 05, 2012 3:58 PM Magnus Hagander wrote: On Wed, Sep 5, 2012 at 7:31 AM, Amit Kapila wrote: > On Tuesday, September 04, 2012 12:40 AM Tom Lane wrote: > Magnus Hagander writes: >> On Mon, Sep 3, 2012 at 8:51 PM, Tom Lane wrote: > I have another question after thinking a

Re: [HACKERS] State of the on-disk bitmap index

Hi Gianni! Thank you for your attention and response! >> I used the (more recent) patches posted by Gianni Ciolli in 2008 and >> currently am in the process of porting those to master HEAD -- like I >> promised. > > Back in 2008 the PostgreSQL project wasn't using git, and I wasn't > either; hen

Re: [HACKERS] [bugfix] sepgsql didn't follow the latest core API changes

2012/9/3 Alvaro Herrera : > Excerpts from Kohei KaiGai's message of dom sep 02 15:53:22 -0300 2012: >> This patch fixes a few portions on which sepgsql didn't follow the latest >> core API changes. > > I think you should get a buildfarm animal installed that builds and > tests sepgsql, to avoid thi

Re: [HACKERS] State of the on-disk bitmap index

Dear Albe and Daniel, On Wed, Sep 05, 2012 at 11:28:18AM +0200, Daniel Bausch wrote: > Hi Albe and the list, > > >> I am going to implement a simple kind of "encoded bitmap indexes" (EBI). > >> > >> I thought, it could be a good idea to base my work on the long proposed > >> on-disk bitmap index

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

On Wed, Sep 5, 2012 at 7:31 AM, Amit Kapila wrote: > On Tuesday, September 04, 2012 12:40 AM Tom Lane wrote: > Magnus Hagander writes: >> On Mon, Sep 3, 2012 at 8:51 PM, Tom Lane wrote: I have another question after thinking about that for awhile: is there any security concern there?

[HACKERS] fixing variadic parameters for type "ANY"

Hello Our customer reported issue with "format" function - http://archives.postgresql.org/pgsql-bugs/2012-09/msg00011.php. This issue is related to our implementation of variadic functions - there are gap in implemented functionality - parameter cannot be marked as VARIADIC in function call, when

Re: [HACKERS] State of the on-disk bitmap index

Hi Albe and the list, >> I am going to implement a simple kind of "encoded bitmap indexes" (EBI). >> >> I thought, it could be a good idea to base my work on the long proposed >> on-disk bitmap index implementation. Regarding to the wiki, you, >> Jonah and Simon, were the last devs that touched

Re: [HACKERS] 9.2rc1 produces incorrect results

On 5 September 2012 05:09, Tom Lane wrote: > I wrote: >> I think probably the best fix is to rejigger things so that Params >> assigned by different executions of SS_replace_correlation_vars and >> createplan.c can't share PARAM_EXEC numbers. This will result in >> rather larger ecxt_param_exec_v

Re: [HACKERS] State of the on-disk bitmap index

Daniel Bausch wrote: > I am going to implement a simple kind of "encoded bitmap indexes" (EBI). > I thought, it could be a good idea to base my work on the long proposed > on-disk bitmap index implementation. Regarding to the wiki, you, Jonah > and Simon, were the last devs that touched this thin

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

Heikki Linnakangas writes: > On 04.09.2012 03:02, Dimitri Fontaine wrote: >> Heikki Linnakangas writes: >>> Hmm, I was thinking that when walsender gets the position it can send the >>> WAL up to, in GetStandbyFlushRecPtr(), it could atomically check the current >>> recovery timeline. If it has c

Re: [HACKERS] 9.2rc1 produces incorrect results

On Wed, Sep 5, 2012 at 6:09 AM, Tom Lane wrote: > I wrote: > > I think probably the best fix is to rejigger things so that Params > > assigned by different executions of SS_replace_correlation_vars and > > createplan.c can't share PARAM_EXEC numbers. This will result in > > rather larger ecxt_pa