Re: [HACKERS] Sync Rep v19

On Sun, Mar 6, 2011 at 4:51 PM, Fujii Masao wrote: > One comment; what about introducing built-in function to wake up all the > waiting backends? When replication connection is closed, if we STONITH > the standby, we can safely (for not physical data loss but logical one) > switch the primary to s

Re: [HACKERS] Sync Rep v19

On Sun, Mar 6, 2011 at 1:53 AM, Simon Riggs wrote: > On Sat, 2011-03-05 at 20:08 +0900, Fujii Masao wrote: >> On Sat, Mar 5, 2011 at 7:28 AM, Simon Riggs wrote: >> > Yes, that can happen. As people will no doubt observe, this seems to be >> > an argument for wait-forever. What we actually need is

Re: [HACKERS] Sync Rep v19

On Sun, Mar 6, 2011 at 2:59 AM, Robert Haas wrote: > On Sat, Mar 5, 2011 at 11:56 AM, Simon Riggs wrote: >>> Even though postmaster dies, the waiting backend keeps waiting until >>> the timeout expires. Instead, the backends should periodically check >>> whether postmaster is alive, and then they

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On Sat, Mar 5, 2011 at 5:28 PM, Tom Lane wrote: > "David E. Wheeler" writes: >> On Mar 4, 2011, at 7:44 PM, Robert Haas wrote: >>> So it seems like the only thing that is an absolute must-do is write >>> some release notes. > >> What about this? >>> http://archives.postgresql.org/message-id/27152

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

Robert, Some minor fixes: 197 198 199 Implement a truly serializable isolation level 200 201 Should be: Implement Serializable Snapshot Isolation, in order to provide a more robust serializable transaction mode 212 Allow multiple co

[HACKERS] fix for pg_upgrade

I got a report from someone using pg_upgrade coming from PG 8.3 --- turns out we didn't rename toast tables to match the new relfilenode in pre-8.4, so the attached applied patch avoids the check for these cases. This check is new in pg_upgrade for 9.1. -- Bruce Momjian http://momjian.

[HACKERS] Parallel make problem with git master

I am seeing the following compile problem with gmake -j2: /bin/sh ../../../config/install-sh -c -d '/usr/local/pgsql/lib' /bin/sh ../../../../config/install-sh -c -m 644 ./plpgsql.control '/usr/local/pgsql/share/extension' /bin/sh ../../../config/install-sh -c -m 644 ./plp

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

Ah. Finally after trying to stare down the code for some more time the issue is pretty simple. index_getprocinfo did this: /* Initialize the lookup info if first time through */ if (locinfo->fn_oid == InvalidOid) { ... fmgr_info_cxt(procId, locinfo, irel->

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

"David E. Wheeler" writes: > On Mar 4, 2011, at 7:44 PM, Robert Haas wrote: >> So it seems like the only thing that is an absolute must-do is write >> some release notes. > What about this? >> http://archives.postgresql.org/message-id/27152(dot)1299015062(at)sss(dot)pgh(dot)pa(dot)us Well, nobod

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On Mar 4, 2011, at 7:44 PM, Robert Haas wrote: > So it seems like the only thing that is an absolute must-do is write > some release notes. What about this? > Yeah, the real problem in my mind is not so much citext as whether the > current representation of a type's collation property is sane in

Re: [HACKERS] Sync Rep v19

On Sat, Mar 5, 2011 at 3:11 PM, Yeb Havinga wrote: > > Summary of preliminary testing: > 1) it is confusing to show messages/ contents of stat_replication that hints > at syncrep, when synchronous_replication is on. [for the record, Yeb explain he means OFF not on...] the thing is that once you

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On lör, 2011-03-05 at 12:43 -0500, Tom Lane wrote: > Why aren't we just setting finfo.fn_collation to DEFAULT_COLLATION_OID > by default, or maybe better letting places that inspect it take zero > as meaning default collation? Because then you'd just get silently wrong results instead of an error.

Re: [HACKERS] Sync Rep v19

On 2011-03-05 21:11, Yeb Havinga wrote: Summary of preliminary testing: 1) it is confusing to show messages/ contents of stat_replication that hints at syncrep, when synchronous_replication is on. s/on/off/ Also forgot to mention these tests are againt the latest v21 syncrep patch. Y

Re: [HACKERS] Sync Rep v19

On 2011-03-05 18:25, Yeb Havinga wrote: On Sat, Mar 5, 2011 at 5:53 PM, Simon Riggs > wrote: On a positive note this is one less parameter and will improve performance as well. All above changes made. Ready to commit, barring concrete objections t

Re: [HACKERS] German Ladies start translation project

On 05.03.2011 11:57, Susanne Ebrecht wrote: For me this means - it is finally time to translate / update old Peter docs. Peter and me think - just translate all again is faster then taking and checking his old texts. I'm curious, what percentage of the text has changed since 7.3? I did this: ~

Re: [HACKERS] Extensions vs. shared procedural language handler functions

Tom Lane writes: > The next question is how come this regression test ever worked on that > platform. The reason is that up till my changes for $SUBJECT, when you > issued "CREATE LANGUAGE plpython2u" in a database that already had > plpythonu installed, CREATE LANGUAGE found C functions of the e

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On Sat, Mar 5, 2011 at 10:33 AM, Andy Colson wrote: > On 03/05/2011 08:54 AM, Robert Haas wrote: >> >> On Sat, Mar 5, 2011 at 9:44 AM, Andy Colson  wrote: Support unlogged tables.  The contents of an unlogged table are WAL-logged; >>> >>> um.. are _not_ WAL-logged? >> >> Uh, yeah.  

Re: [HACKERS] Replication server timeout patch

On Mon, Feb 28, 2011 at 8:08 AM, Fujii Masao wrote: > On Sun, Feb 27, 2011 at 11:52 AM, Fujii Masao wrote: >>> There are two things that I think are pretty clear.  If the receiver >>> has wal_receiver_status_interval=0, then we should ignore >>> replication_timeout for that connection. >> >> The

Re: [HACKERS] Quick Extensions Question

On Mar 5, 2011, at 10:03 AM, Tom Lane wrote: > On reflection I think it makes no sense at all to leave those tools > issuing CREATE/DROP LANGUAGE. We want to move people over to managing > languages via extensions, and leaving those tools unchanged will not > serve that goal. However, I don't mi

Re: [HACKERS] Quick Extensions Question

Robert Haas writes: > On Fri, Mar 4, 2011 at 11:19 AM, Tom Lane wrote: >> Hmm. Personally I do use createdb/dropdb but never createlang/droplang; >> but I'm well aware that my usage may not be typical. I'm a bit hesitant >> to just go and drop these without any warning. I could see deprecating

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On Sat, Mar 5, 2011 at 10:17 AM, Andy Colson wrote: > On 03/05/2011 08:54 AM, Robert Haas wrote: >> >> On Sat, Mar 5, 2011 at 9:44 AM, Andy Colson  wrote: Support unlogged tables.  The contents of an unlogged table are WAL-logged; >>> >>> um.. are _not_ WAL-logged? >> >> Uh, yeah.  

Re: [HACKERS] Sync Rep v19

On Sat, Mar 5, 2011 at 11:56 AM, Simon Riggs wrote: >> Even though postmaster dies, the waiting backend keeps waiting until >> the timeout expires. Instead, the backends should periodically check >> whether postmaster is alive, and then they should exit immediately >> if it's not alive, as well as

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On Saturday 05 March 2011 18:43:31 Tom Lane wrote: > Andres Freund writes: > > I have a WIP patch fixing one of the two issues. > > > > Several places in selfuncs.c didn't setup collations. That lead for > > example to errors during patternsel. > > Hmm. I have to say that this seems like quite

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

Andres Freund writes: > I have a WIP patch fixing one of the two issues. > Several places in selfuncs.c didn't setup collations. That lead for example > to > errors during patternsel. Hmm. I have to say that this seems like quite the wrong way to go. If everyplace in the system that could be

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On Saturday 05 March 2011 18:37:30 Andres Freund wrote: > On Saturday 05 March 2011 17:46:13 Tom Lane wrote: > > Andres Freund writes: > I am currently looking at the other one. Its quite strange: The backtrace during the operations described earlier: 0 index_getprocinfo (irel=0x7f5426cbc820, at

Re: [HACKERS] Extensions vs. shared procedural language handler functions

Andrew Dunstan writes: > FYI, I'm working on the MSVC issues. Ah, great. I was just about to start hacking something together, but it'd be better for somebody to do it who can test it before committing... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On Saturday 05 March 2011 17:46:13 Tom Lane wrote: > Andres Freund writes: > > On Saturday 05 March 2011 04:44:20 Robert Haas wrote: > >>> * Collation-related regression failure on buildfarm member pika. This > >>> is clearly a bug we need to identify, but maybe we can ship the alpha > >>> withou

Re: [HACKERS] Extensions vs. shared procedural language handler functions

On 03/05/2011 12:17 PM, Tom Lane wrote: Dimitri Fontaine writes: Tom Lane writes: The only easy fix I can see at the moment is to arbitrarily create two pg_proc entries --- they can both point at the same C function, but there need to be two of 'em. So for 9.1, I think you took the simples

Re: [HACKERS] Sync Rep v19

On Sat, Mar 5, 2011 at 5:53 PM, Simon Riggs wrote: > > On a positive note this is one less parameter and will improve > performance as well. > > All above changes made. > > Ready to commit, barring concrete objections to important behaviour. > > I will do one final check tomorrow evening then com

Re: [HACKERS] Extensions vs. shared procedural language handler functions

Dimitri Fontaine writes: > Tom Lane writes: >> The only easy fix I can see at the moment is to arbitrarily create two >> pg_proc entries --- they can both point at the same C function, but >> there need to be two of 'em. > So for 9.1, I think you took the simplest path available. It's never tha

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On Sat, Mar 05, 2011 at 11:46:13AM -0500, Tom Lane wrote: > Andres Freund writes: > > On Saturday 05 March 2011 04:44:20 Robert Haas wrote: > >>> * Collation-related regression failure on buildfarm member pika. This > >>> is clearly a bug we need to identify, but maybe we can ship the alpha > >>>

Re: [HACKERS] Sync Rep v19

On Sun, Mar 6, 2011 at 12:42 AM, Fujii Masao wrote: > New comments; Another one; + longtimeout = SyncRepGetWaitTimeout(); + else if (timeout > 0 && + TimestampDifferenceExceeds(wait_start, now, timeout)) +

Re: [HACKERS] Sync Rep v19

On Sun, 2011-03-06 at 00:42 +0900, Fujii Masao wrote: > On Sat, Mar 5, 2011 at 9:21 PM, Simon Riggs wrote: > > I've added code to shmqueue.c to allow this. > > > > New version pushed. > > New comments; None of the requested changes are in v21, as yet. > It looks odd to report the sync_state of

Re: [HACKERS] Sync Rep v19

On Sat, 2011-03-05 at 11:42 -0500, Jaime Casanova wrote: > El 05/03/2011 11:18, "Fujii Masao" escribió: > > > > On Sun, Mar 6, 2011 at 12:07 AM, Simon Riggs > wrote: > > > I'm not in favour. > > > > > > If the user has a preferred order, they can specify it. If there > is no > > > preferred order

Re: [HACKERS] Sync Rep v19

On Sun, 2011-03-06 at 01:17 +0900, Fujii Masao wrote: > On Sun, Mar 6, 2011 at 12:07 AM, Simon Riggs wrote: > > I'm not in favour. > > > > If the user has a preferred order, they can specify it. If there is no > > preferred order, how will we maintain that order? > > > > What are the rules for mai

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

Andres Freund writes: > On Saturday 05 March 2011 04:44:20 Robert Haas wrote: >>> * Collation-related regression failure on buildfarm member pika. This >>> is clearly a bug we need to identify, but maybe we can ship the alpha >>> without a fix --- for one thing, getting more than one report of th

Re: [HACKERS] Sync Rep v19

El 05/03/2011 11:18, "Fujii Masao" escribió: > > On Sun, Mar 6, 2011 at 12:07 AM, Simon Riggs wrote: > > I'm not in favour. > > > > If the user has a preferred order, they can specify it. If there is no > > preferred order, how will we maintain that order? > > > > What are the rules for maintaini

Re: [HACKERS] Sync Rep v19

On Mar 5, 2011, at 11:17 AM, Fujii Masao wrote: > On Sun, Mar 6, 2011 at 12:07 AM, Simon Riggs wrote: >> I'm not in favour. >> >> If the user has a preferred order, they can specify it. If there is no >> preferred order, how will we maintain that order? >> >> What are the rules for maintaining

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On lör, 2011-03-05 at 09:33 -0600, Andy Colson wrote: > Can we add a line saying "-j still doesnt work, dont use it yet" or > "make -j2 works great now". I admit I've never tried to use -j > before... is this telling me its ok to use now? Has make -j ever made any sense? Other than for locking u

Re: [HACKERS] Sync Rep v19

On Sun, Mar 6, 2011 at 12:07 AM, Simon Riggs wrote: > I'm not in favour. > > If the user has a preferred order, they can specify it. If there is no > preferred order, how will we maintain that order? > > What are the rules for maintaining this arbitrary order? Probably what Robert, Yeb and I thin

Re: [HACKERS] Sync Rep v19

On Sat, Mar 5, 2011 at 9:21 PM, Simon Riggs wrote: > I've added code to shmqueue.c to allow this. > > New version pushed. New comments; It looks odd to report the sync_state of walsender in BACKUP state as ASYNC. +SyncRepCleanupAtProcExit(int code, Datum arg) +{ + if (WaitingForSyncRep &&

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On 03/05/2011 08:54 AM, Robert Haas wrote: On Sat, Mar 5, 2011 at 9:44 AM, Andy Colson wrote: Support unlogged tables. The contents of an unlogged table are WAL-logged; um.. are _not_ WAL-logged? Uh, yeah. It looks like I fixed that in the version I committed, but introduced another, simi

Re: [HACKERS] Sync Rep v19

On Sat, 2011-03-05 at 20:08 +0900, Fujii Masao wrote: > On Sat, Mar 5, 2011 at 7:28 AM, Simon Riggs wrote: > > Yes, that can happen. As people will no doubt observe, this seems to be > > an argument for wait-forever. What we actually need is a wait that lasts > > longer than it takes for us to dec

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On 03/05/2011 08:54 AM, Robert Haas wrote: On Sat, Mar 5, 2011 at 9:44 AM, Andy Colson wrote: Support unlogged tables. The contents of an unlogged table are WAL-logged; um.. are _not_ WAL-logged? Uh, yeah. It looks like I fixed that in the version I committed, but introduced another, simi

Re: [HACKERS] Sync Rep v19

On Sat, 2011-03-05 at 14:44 +0100, Yeb Havinga wrote: > On Sat, Mar 5, 2011 at 2:05 PM, Robert Haas > wrote: > On Sat, Mar 5, 2011 at 7:49 AM, Simon Riggs > wrote: > > If the order is arbitrary, why does it matter if it changes? > > > > The user has the pow

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On Sat, Mar 5, 2011 at 9:44 AM, Andy Colson wrote: >> Support unlogged tables.  The contents of an unlogged table are >> WAL-logged; > > um.. are _not_ WAL-logged? Uh, yeah. It looks like I fixed that in the version I committed, but introduced another, similar mistake which I have now also fixed

Re: [HACKERS] Extensions vs. shared procedural language handler functions

Tom Lane writes: > I can imagine that someplace down the road we might want to allow > multiple extensions to own the same SQL object; I know that RPMs can > share ownership of files, for comparison. But today is not that day. […] > Anyone have a different answer? What could be done is to have a

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On 03/04/2011 10:22 PM, Robert Haas wrote: On Fri, Mar 4, 2011 at 10:44 PM, Robert Haas wrote: So it seems like the only thing that is an absolute must-do is write some release notes. Here's a rough attempt at filtering the post-alpha3 commit log down to approximately the set of things worth

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On Sat, Mar 5, 2011 at 8:41 AM, Robert Haas wrote: > On Fri, Mar 4, 2011 at 11:22 PM, Robert Haas wrote: >> On Fri, Mar 4, 2011 at 10:44 PM, Robert Haas wrote: >>> So it seems like the only thing that is an absolute must-do is write >>> some release notes. >> >> Here's a rough attempt at filteri

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On Sat, Mar 5, 2011 at 8:48 AM, Alexander Korotkov wrote: > On Sat, Mar 5, 2011 at 7:22 AM, Robert Haas wrote: >> >> Here's a rough attempt at filtering the post-alpha3 commit log down to >> approximately the set of things worth adding to the alpha4 release >> notes. > > > Seems that support LIKE

Re: [HACKERS] SET TRANSACTION .. DEFERRABLE missing docs?

Magnus Hagander wrote: > I was reading through ref/set_transaction.sgml and noticed that the > only documentation of DEFERRABLE is that it's a PostgreSQL language > extension, not anything about what it actually does. Same for begin > and start_transaction. I see it described in README-SSI and f

Re: [HACKERS] Sync Rep v19

On Sat, Mar 5, 2011 at 2:05 PM, Robert Haas wrote: > On Sat, Mar 5, 2011 at 7:49 AM, Simon Riggs wrote: > > If the order is arbitrary, why does it matter if it changes? > > > > The user has the power to specify a sequence, yet they have not done so. > > They are told the results are indeterminat

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On Fri, Mar 4, 2011 at 11:22 PM, Robert Haas wrote: > On Fri, Mar 4, 2011 at 10:44 PM, Robert Haas wrote: >> So it seems like the only thing that is an absolute must-do is write >> some release notes. > > Here's a rough attempt at filtering the post-alpha3 commit log down to > approximately the s

Re: [HACKERS] Sync Rep v19

On Sat, Mar 5, 2011 at 7:49 AM, Simon Riggs wrote: > On Sat, 2011-03-05 at 07:24 -0500, Robert Haas wrote: >> On Sat, Mar 5, 2011 at 6:04 AM, Simon Riggs wrote: >> > It is documented that the selection of standby from a set of similar >> > priorities is indeterminate. Users don't like it, they ca

Re: [HACKERS] Sync Rep v19

On Sat, 2011-03-05 at 07:24 -0500, Robert Haas wrote: > On Sat, Mar 5, 2011 at 6:04 AM, Simon Riggs wrote: > > It is documented that the selection of standby from a set of similar > > priorities is indeterminate. Users don't like it, they can change it. > > That doesn't seem like a good argument

Re: [HACKERS] Sync Rep v19

On Sat, Mar 5, 2011 at 6:04 AM, Simon Riggs wrote: > It is documented that the selection of standby from a set of similar > priorities is indeterminate. Users don't like it, they can change it. That doesn't seem like a good argument to *change* the synchronous standby once it's already set. --

Re: [HACKERS] Sync Rep v19

On Sat, 2011-03-05 at 11:04 +, Simon Riggs wrote: > > + /* > > + * Assume the queue is ordered by LSN > > + */ > > + if (XLByteLT(walsndctl->lsn, proc->waitLSN)) > > + return numprocs; > > > > The code to ensure the assumpti

Re: [HACKERS] Alpha4 release blockers (was Re: wrapping up this CommitFest)

On Saturday 05 March 2011 04:44:20 Robert Haas wrote: > > * Collation-related regression failure on buildfarm member pika. This > > is clearly a bug we need to identify, but maybe we can ship the alpha > > without a fix --- for one thing, getting more than one report of the > > problem would be he

Re: [HACKERS] Sync Rep v19

On Sat, Mar 5, 2011 at 7:28 AM, Simon Riggs wrote: > Yes, that can happen. As people will no doubt observe, this seems to be > an argument for wait-forever. What we actually need is a wait that lasts > longer than it takes for us to decide to failover, if the standby is > actually up and this is s

Re: [HACKERS] Sync Rep v19

On Sat, 2011-03-05 at 16:13 +0900, Fujii Masao wrote: > On Sat, Mar 5, 2011 at 7:28 AM, Simon Riggs wrote: > > Almost-working patch attached for the above feature. Time to stop for > > the day. Patch against current repo version. > > > > Current repo version attached here also (v20), which include

Re: [HACKERS] why is max standby delay only 35 minutes?

On Fri, Mar 4, 2011 at 18:19, Robert Treat wrote: > On Fri, Mar 4, 2011 at 2:03 AM, Magnus Hagander wrote: >> On Fri, Mar 4, 2011 at 04:00, Robert Treat wrote: >>> I have a server where I wanted to do some reporting on a standby, and >>> wanted to set the max standby delay to 1 hour. upon doing

[HACKERS] German Ladies start translation project

Hello, I just wanted to inform you that Cornelia and me start the project to translate and publish the documentation German. Means the project will have a really high women concentration at the beginning :) pgsql-www suggested to take postgresql.de for publishing. I thought it is a great idea a

[HACKERS] SET TRANSACTION .. DEFERRABLE missing docs?

I was reading through ref/set_transaction.sgml and noticed that the only documentation of DEFERRABLE is that it's a PostgreSQL language extension, not anything about what it actually does. Same for begin and start_transaction. I see it described in README-SSI and for the guc default_transaction_def