Re: [HACKERS] Change pg_last_xlog_receive_location not to move backwards

On Sun, Jan 30, 2011 at 10:44 AM, Jeff Janes wrote: > I do not understand what doing so gets us. > > Say we previously received 2/3 of a WAL file, and replayed most of it. > So now the shared buffers have data that has been synced to that WAL > file already, and some of those dirty shared buffers

Re: [HACKERS] Spread checkpoint sync

On Tue, Nov 30, 2010 at 3:29 PM, Greg Smith wrote: > I've attached an updated version of the initial sync spreading patch here, > one that applies cleanly on top of HEAD and over top of the sync > instrumentation patch too.  The conflict that made that hard before is gone > now. With the fsync qu

Re: [HACKERS] review: FDW API

On Fri, 21 Jan 2011 18:28:19 +0200 Heikki Linnakangas wrote: > On 18.01.2011 17:26, Shigeru HANADA wrote: > > 3) 20110118-fdw_handler.patch - This patch adds support for HANDLER > > option to FOREIGN DATA WRAPPER object. > > Some quick comments on that: Thanks for the comments. I'll post revised

Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting

> On Mon, Jan 31, 2011 at 12:35 PM, Tatsuo Ishii wrote: >>> If the "pg_ctl promote" patch will have been committed, I recommend that >>> the C function should send the signal to the startup process rather than >>> creating the trigger file. Because the trigger file is checked every for 5s, >>> whi

Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting

On Mon, Jan 31, 2011 at 12:35 PM, Tatsuo Ishii wrote: >> If the "pg_ctl promote" patch will have been committed, I recommend that >> the C function should send the signal to the startup process rather than >> creating the trigger file. Because the trigger file is checked every for 5s, >> which wou

Re: [HACKERS] Add ENCODING option to COPY

2011/1/31 Robert Haas : > On Tue, Jan 25, 2011 at 10:24 AM, Hitoshi Harada wrote: >> I'll check the code more if we have better alternatives. > > Where are we with this? I'll post another version today. Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgres

Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting

On Mon, Jan 31, 2011 at 12:31 PM, Itagaki Takahiro wrote: > The C function needs to create a trigger file in $PGDATA/promote > before sending signals, no? No. At least in the current patch, just receipt of SIGUSR2 causes the startup process to end a recovery. The startup process doesn't check the

Re: [HACKERS] Extensions support for pg_dump, patch v27

On Fri, Jan 28, 2011 at 18:03, Dimitri Fontaine wrote: > After review, I included all your proposed changes, thanks a lot! > Please find attached a new version of the patch, v29, Additional questions and discussions: * "relocatable" and "schema" seems to be duplicated options. We could treat an

Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting

On Mon, Jan 31, 2011 at 11:52, Fujii Masao wrote: > On Sat, Jan 29, 2011 at 1:11 AM, Tatsuo Ishii wrote: >> Ok. I will write a C user function and add to pgpool source tree. I >> think it will be fairly easy to create a trigger file in the function. > > If the "pg_ctl promote" patch will have bee

Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting

> If the "pg_ctl promote" patch will have been committed, I recommend that > the C function should send the signal to the startup process rather than > creating the trigger file. Because the trigger file is checked every for 5s, > which would lengthen the failover time by an average 2.5s. Ok, prob

Re: [HACKERS] SSI patch version 14

1. In CheckForSerializableConflictIn(), I think the comment above may be out of date. It says: "A tuple insert is in conflict only if there is a predicate lock against the entire relation." That doesn't appear to be true if, for example, there's a predicate lock on the index page that the tuple

Re: [HACKERS] We need to log aborted autovacuums

On Sun, Jan 30, 2011 at 10:03 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of dom ene 30 23:37:51 -0300 2011: > >> Unless I'm missing something, making autovacuum.c call >> ConditionalLockRelationOid() is not going to work, because the vacuum >> transaction isn't started until w

Re: [HACKERS] We need to log aborted autovacuums

Excerpts from Robert Haas's message of dom ene 30 23:37:51 -0300 2011: > Unless I'm missing something, making autovacuum.c call > ConditionalLockRelationOid() is not going to work, because the vacuum > transaction isn't started until we get all the way down to > vacuum_rel(). Maybe we need Condit

Re: pg_ctl failover Re: [HACKERS] Latches, signals, and waiting

On Sat, Jan 29, 2011 at 1:11 AM, Tatsuo Ishii wrote: > Ok. I will write a C user function and add to pgpool source tree. I > think it will be fairly easy to create a trigger file in the function. If the "pg_ctl promote" patch will have been committed, I recommend that the C function should send t

Re: [HACKERS] Include WAL in base backup

On Sun, Jan 30, 2011 at 9:34 PM, Fujii Masao wrote: > On Mon, Jan 31, 2011 at 4:22 AM, Magnus Hagander wrote: >>> In pg_basebackup.sgml >>>     --checkpoint >> class="parameter">fast|spread >>> >>> Though this is not the problem of the patch, I found the inconsistency >>> of the descriptions abou

Re: [HACKERS] Error code for "terminating connection due to conflict with recovery"

On Sun, Jan 30, 2011 at 9:18 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Jan 30, 2011 at 8:42 PM, Tom Lane wrote: >>> BTW, so far as this goes: >>> http://archives.postgresql.org/pgsql-hackers/2011-01/msg01152.php >>> we should certainly *not* have the same text for two different >>> SQ

Re: [HACKERS] Include WAL in base backup

On Mon, Jan 31, 2011 at 4:22 AM, Magnus Hagander wrote: >> In pg_basebackup.sgml >>     --checkpoint > class="parameter">fast|spread >> >> Though this is not the problem of the patch, I found the inconsistency >> of the descriptions about options of pg_basebackup. We should >> s/--checkpoint/--che

Re: [HACKERS] We need to log aborted autovacuums

On Mon, Jan 17, 2011 at 4:08 PM, Tom Lane wrote: > Simon Riggs writes: >> On Mon, 2011-01-17 at 14:46 -0500, Tom Lane wrote: >>> Do we actually need a lock timeout either?  The patch that was being >>> discussed just involved failing if you couldn't get it immediately. >>> I suspect that's suffic

Re: [HACKERS] Error code for "terminating connection due to conflict with recovery"

Robert Haas writes: > On Sun, Jan 30, 2011 at 8:42 PM, Tom Lane wrote: >> BTW, so far as this goes: >> http://archives.postgresql.org/pgsql-hackers/2011-01/msg01152.php >> we should certainly *not* have the same text for two different >> SQLSTATEs.  If it's worth distinguishing two cases then it'

Re: [HACKERS] Error code for "terminating connection due to conflict with recovery"

On Sun, Jan 30, 2011 at 8:42 PM, Tom Lane wrote: >> Any opinion on what to do about the one that's returning >> ERRCODE_ADMIN_SHUTDOWN? > > Pretty much the same argument here, I think: if we are going to change > the SQLSTATE we should do it now not later.  However, I think Simon > was actually a

Re: [HACKERS] Error code for "terminating connection due to conflict with recovery"

Robert Haas writes: > On Sun, Jan 30, 2011 at 8:11 PM, Tom Lane wrote: >> I'm inclined to agree that 9.0 is new enough that changing this >> shouldn't be too traumatic.  If we leave it till 9.1 there will >> probably be more pain not less. > But if you and Tatsuo-san are both in favor of it, the

Re: [HACKERS] Error code for "terminating connection due to conflict with recovery"

On Sun, Jan 30, 2011 at 8:11 PM, Tom Lane wrote: > Tatsuo Ishii writes: >> On Fri, Jan 21, 2011 at 8:28 AM, Robert Haas wrote: >>> It seems like we have consensus to change >>> CheckRecoveryConflictDetected() to return >>> ERRCODE_T_R_DEADLOCK_DETECTED in 9.1, but not on whether to also >>> chan

Re: [HACKERS] Error code for "terminating connection due to conflict with recovery"

Tatsuo Ishii writes: > On Fri, Jan 21, 2011 at 8:28 AM, Robert Haas wrote: >> It seems like we have consensus to change >> CheckRecoveryConflictDetected() to return >> ERRCODE_T_R_DEADLOCK_DETECTED in 9.1, but not on whether to also >> change that in 9.0 (votes: Robert - for, Simon - against) >

Re: [HACKERS] Error code for "terminating connection due to conflict with recovery"

Robert, > On Fri, Jan 21, 2011 at 8:28 AM, Robert Haas wrote: >> On Fri, Jan 21, 2011 at 7:48 AM, Simon Riggs wrote: >>> Ah, thanks Florian. Now I understand. There are two related issues here. >>> >>> 1. The discussion around ERRCODE_ADMIN_SHUTDOWN is incorrect and the >>> specific patch should

Re: [HACKERS] WIP: RangeTypes

le? * representation or alignment issues * parser should be improved to handle spaces and quoting better * Should btree_gist be pulled into core to make it easier to use exclusion constraints with range types? * Typmod (optional) Regards, Jeff Davis rangetypes-20110130.pat

Re: [HACKERS] Snapshot synchronization, again...

On Sun, Jan 30, 2011 at 12:36:12PM -0500, Joachim Wieland wrote: > Here is a new version of the patch incorporating most of Noah's > suggestions. The patch now also adds documentation. Since I couldn't > really find a suitable section to document the two new functions, I > added a new one for now.

Re: [HACKERS] autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.)

I wrote: > Just in a quick read-through of the patches, the only things I noticed Oh, a third thing: the patch places errcodes.txt under src/include, which does not seem even approximately right. src/backend/utils seems like a saner place for it. regards, tom lane -- Se

Re: [HACKERS] autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.)

Robert Haas writes: > On Sun, Jan 30, 2011 at 5:47 PM, Tom Lane wrote: >> If you don't want to commit it yourself, I'll take it. > I'm happy to do it. I would have done it straight off, but thought > I'd give everyone one last chance to kvetch. Just in a quick read-through of the patches, the

Re: [HACKERS] pl/python SPI in subtransactions

On 31/01/11 00:03, Jan Urbański wrote: > On 29/01/11 22:13, Jan Urbański wrote: >> On 29/01/11 22:10, Steve Singer wrote: >>> On 11-01-29 03:39 PM, Jan Urbański wrote: D'oh, you're right, thanks. Attached patch with fix. Curiosly, right now in master your example with plpy.prepare wi

Re: [HACKERS] pl/python SPI in subtransactions

On 29/01/11 22:13, Jan Urbański wrote: > On 29/01/11 22:10, Steve Singer wrote: >> On 11-01-29 03:39 PM, Jan Urbański wrote: >>> >>> D'oh, you're right, thanks. Attached patch with fix. Curiosly, right now >>> in master your example with plpy.prepare will result in "savepoint" >>> being swallowed,

Re: [HACKERS] autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.)

On Sun, Jan 30, 2011 at 5:47 PM, Tom Lane wrote: > Robert Haas writes: >> I'll mark this one Ready for Committer. > > If you don't want to commit it yourself, I'll take it. I'm happy to do it. I would have done it straight off, but thought I'd give everyone one last chance to kvetch. -- Rober

Re: [HACKERS] autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.)

On 30/01/11 23:08, Robert Haas wrote: > On Wed, Jan 12, 2011 at 5:10 PM, Jan Urbański wrote: >> On 12/01/11 19:57, Jan Urbański wrote: >>> On 11/01/11 21:21, Jan Urbański wrote: On 11/01/11 18:59, Tom Lane wrote: > =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes: >> On 11/01/11 17:11, Tom La

Re: [HACKERS] wildcard search support for pg_trgm

On 30/01/11 23:04, Jan Urbański wrote: > On 30/01/11 23:02, Alexander Korotkov wrote: >> Hi! >> >> On Mon, Jan 31, 2011 at 12:52 AM, Jan Urbański > > wrote: >> >> I saw that the code tries to handle ILIKE searches, but apparently it's >> failing somewhere. >> >>

Re: [HACKERS] Review: Fix snapshot taking inconsistencies

On Wed, Oct 20, 2010 at 6:15 PM, Tom Lane wrote: > Alvaro Herrera writes: >> It strikes me that if we really want to restructure things to divide >> client interaction from other query-processing routines, we should >> create another file, say src/backend/tcop/queries.c; this would have >> stuff

Re: [HACKERS] autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.)

Robert Haas writes: > I'll mark this one Ready for Committer. If you don't want to commit it yourself, I'll take it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/m

Re: [HACKERS] mingw 64 build

On Sun, Jan 30, 2011 at 18:35, Andrew Dunstan wrote: > > > On 01/30/2011 11:52 AM, Magnus Hagander wrote: >> >> On Sun, Jan 30, 2011 at 16:47, Andrew Dunstan  wrote: >>> >>> The attached patch allows building a 64 bit Windows Postgres using the >>> mingw64 compiler from >>> >>>

Re: [HACKERS] autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.)

On Wed, Jan 12, 2011 at 5:10 PM, Jan Urbański wrote: > On 12/01/11 19:57, Jan Urbański wrote: >> On 11/01/11 21:21, Jan Urbański wrote: >>> On 11/01/11 18:59, Tom Lane wrote: =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes: > On 11/01/11 17:11, Tom Lane wrote: Peter would probably be a bett

Re: [HACKERS] autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.)

On Sun, Jan 30, 2011 at 5:23 PM, Jan Urbański wrote: > On 30/01/11 23:08, Robert Haas wrote: >> On Wed, Jan 12, 2011 at 5:10 PM, Jan Urbański wrote: >>> On 12/01/11 19:57, Jan Urbański wrote: On 11/01/11 21:21, Jan Urbański wrote: > On 11/01/11 18:59, Tom Lane wrote: >> =?UTF-8?B?SmF

Re: [HACKERS] pg_dump directory archive format / parallel pg_dump

On Wed, Jan 19, 2011 at 12:45 AM, Joachim Wieland wrote: > On Mon, Jan 17, 2011 at 5:38 PM, Jaime Casanova wrote: >> This one is the last version of this patch? if so, commitfest app >> should be updated to reflect that > > Here are the latest patches all of them also rebased to current HEAD. > W

Re: [HACKERS] keeping a timestamp of the last stats reset (for a db, table and function)

On Thu, Dec 23, 2010 at 2:41 PM, Tomas Vondra wrote: >>> OK, so here goes the simplified patch - it tracks one reset timestamp >>> for a background writer and for each database. >> >> I think you forgot the attachment. > > Yes, I did. Thanks! This patch no longer applies. Please update. -- Rob

Re: [HACKERS] WIP: RangeTypes

Jeff Davis writes: > On Sun, 2011-01-30 at 02:55 +, Thom Brown wrote: >> postgres=# select '[18,20]'::numrange @> 19; >> ERROR: operator does not exist: numrange @> integer >> LINE 1: select '[18,20]'::numrange @> 19; >> ^ >> HINT: No operator matches the given name and argument type(s). You

Re: [HACKERS] WIP: RangeTypes

On 30 January 2011 21:33, Jeff Davis wrote: > [ trying a third time to send this message, apparently there were > infrastructure problems before ] > > On Sun, 2011-01-30 at 02:55 +, Thom Brown wrote: >> postgres=# select '[18,20]'::numrange @> 19; >> ERROR:  operator does not exist: numrange @

Re: [HACKERS] log_hostname and pg_stat_activity

On Sun, Jan 30, 2011 at 4:30 PM, Peter Eisentraut wrote: > On sön, 2011-01-30 at 15:03 -0500, Robert Haas wrote: >> On Tue, Jan 18, 2011 at 7:24 PM, Steve Singer >> wrote: >> > If my connection is authorized through a line in pg_hba that uses >> > client_hostname then the column shows what I expe

Re: [HACKERS] wildcard search support for pg_trgm

On 30/01/11 23:02, Alexander Korotkov wrote: > Hi! > > On Mon, Jan 31, 2011 at 12:52 AM, Jan Urbański > wrote: > > I saw that the code tries to handle ILIKE searches, but apparently it's > failing somewhere. > > It was just a typo. Corrected version attached.

Re: [HACKERS] wildcard search support for pg_trgm

Hi! On Mon, Jan 31, 2011 at 12:52 AM, Jan Urbański wrote: > I saw that the code tries to handle ILIKE searches, but apparently it's > failing somewhere. > It was just a typo. Corrected version attached. With best regards, Alexander Korotkov. *** a/contrib/pg_trgm/pg_trgm.sql.in --- b/contr

Re: [HACKERS] SSI patch version 14

> Dan Ports wrote: > On Thu, Jan 27, 2011 at 09:18:23AM -0800, Jeff Davis wrote: > >> Is there a reason we can't check for a real cycle, which would let >> T1 succeed? > > I talked today with someone who experimented with doing exactly > that in MySQL as part of a research project (Perfectly Seria

Re: [HACKERS] wildcard search support for pg_trgm

On 29/01/11 13:07, Alexander Korotkov wrote: > Hello! Hi! > > New version of patch is in the attachment. Some comments was added in > this version. Likely these comments need significant correction because > of my english. Ooh, ok, the comments now helped me understand what's exactly going on i

Re: [HACKERS] WIP: RangeTypes

[ trying a third time to send this message, apparently there were infrastructure problems before ] On Sun, 2011-01-30 at 02:55 +, Thom Brown wrote: > postgres=# select '[18,20]'::numrange @> 19; > ERROR: operator does not exist: numrange @> integer > LINE 1: select '[18,20]'::numrange @> 19;

Re: [HACKERS] log_hostname and pg_stat_activity

On sön, 2011-01-30 at 15:03 -0500, Robert Haas wrote: > On Tue, Jan 18, 2011 at 7:24 PM, Steve Singer > wrote: > > If my connection is authorized through a line in pg_hba that uses > > client_hostname then the column shows what I expect even with > log_hostname > > set to off. > > > > However if I

Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support

On Sun, Jan 30, 2011 at 21:06, Robert Haas wrote: > On Sat, Jan 15, 2011 at 1:42 PM, Magnus Hagander wrote: >> On Mon, Jan 3, 2011 at 16:45, Brar Piening wrote: >>> On Mon, 3 Jan 2011 10:44:19 +0100, Magnus Hagander >>> wrote: Yeah, it looks that way - it's missing the ordering of the

Re: [HACKERS] Add ENCODING option to COPY

On Tue, Jan 25, 2011 at 10:24 AM, Hitoshi Harada wrote: > I'll check the code more if we have better alternatives. Where are we with this? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] log_checkpoints and restartpoint

On Tue, Jan 25, 2011 at 11:14 PM, Fujii Masao wrote: > When log_checkpoints is enabled, checkpoint logs the number of > WAL files created/deleted/recycled, but restartpoint doesn't. > This is OK before 9.0 because restartpoint had never created/ > deleted/recycled WAL files. But, in 9.0 or later,

Re: [HACKERS] [PERFORM] pgbench to the MAXINT

On Tue, Jan 18, 2011 at 1:42 PM, Greg Smith wrote: > Thanks for picking this up again and finishing the thing off.  I'll add this > into my queue of performance tests to run and we can see if this is worth > applying.  Probably take a little longer than the usual CF review time.  But > as this doe

Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support

On Sat, Jan 15, 2011 at 1:42 PM, Magnus Hagander wrote: > On Mon, Jan 3, 2011 at 16:45, Brar Piening wrote: >> On Mon, 3 Jan 2011 10:44:19 +0100, Magnus Hagander >> wrote: >>> >>> Yeah, it looks that way - it's missing the ordering of the contrib >>> I'll run it once for that now, and then pleas

Re: [HACKERS] log_hostname and pg_stat_activity

On Tue, Jan 18, 2011 at 7:24 PM, Steve Singer wrote: > If my connection is authorized through a line in pg_hba that uses > client_hostname then the column shows what I expect even with log_hostname > set to off. > > However if I connect with a line in pg_hba that matches on an IP network > then my

Re: [HACKERS] Error code for "terminating connection due to conflict with recovery"

On Fri, Jan 21, 2011 at 8:28 AM, Robert Haas wrote: > On Fri, Jan 21, 2011 at 7:48 AM, Simon Riggs wrote: >> Ah, thanks Florian. Now I understand. There are two related issues here. >> >> 1. The discussion around ERRCODE_ADMIN_SHUTDOWN is incorrect and the >> specific patch should be rejected as

Re: [HACKERS] Named restore points

On Fri, Jan 14, 2011 at 8:33 PM, Euler Taveira de Oliveira wrote: > OK. I will review your patch at the beginning of the week. Euler, are you still planning to review this? We're running out of time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company --

Re: [HACKERS] review: FDW API

On Mon, Jan 24, 2011 at 8:08 AM, Heikki Linnakangas wrote: >> How much review have you done of parts (3) and (4)?  The key issue for >> all of the FDW work in progress seems to be what the handler API is >> going to look like, and so once we get that committed it will unblock >> a lot of other thi

Re: [HACKERS] multiset patch review

On Mon, Jan 31, 2011 at 04:12, Robert Haas wrote: >> Well, do you want to revise this and submit a stripped-down version? >> I'm not averse to adding things that are required by the standard and >> won't cause backward compatibility problems later. Sure. I'll remove collect() function. I can also

Re: [HACKERS] Per-column collation, the finale

On Sat, Jan 29, 2011 at 2:52 AM, Noah Misch wrote: > The 13% slowdown with the feature unused seems worrisome Very worrisome. This is a frequently-requested feature, but this seems like a potential show-stopper. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL

[HACKERS] updated patch for foreach stmt

Hello I resend a patch with last update of this patch Regards Pavel Stehule *** ./doc/src/sgml/plpgsql.sgml.orig 2011-01-30 10:04:52.097002835 +0100 --- ./doc/src/sgml/plpgsql.sgml 2011-01-30 10:05:21.379877524 +0100 *** *** 2238,2243 --- 2238,2268 + +

Re: [HACKERS] Include WAL in base backup

On Thu, Jan 27, 2011 at 05:44, Fujii Masao wrote: > On Wed, Jan 26, 2011 at 5:17 AM, Magnus Hagander wrote: >> We should, and the easiest way is to actually use XLogRead() since the >> code is already there. How about the way in this patch? > > Thanks for the update. I reread the patch. > > +    

Re: [HACKERS] multiset patch review

On Sun, Jan 30, 2011 at 2:11 PM, Robert Haas wrote: > On Sun, Jan 30, 2011 at 1:46 PM, Itagaki Takahiro > wrote: >> On Mon, Jan 31, 2011 at 02:34, Robert Haas wrote: > I'm in favor of rejecting this patch in its entirety.  The > functionality looks useful, but once you remove the syntax

Re: [HACKERS] multiset patch review

On Sun, Jan 30, 2011 at 1:46 PM, Itagaki Takahiro wrote: > On Mon, Jan 31, 2011 at 02:34, Robert Haas wrote: I'm in favor of rejecting this patch in its entirety.  The functionality looks useful, but once you remove the syntax support, it could just as easily be distributed as a co

Re: [HACKERS] Include WAL in base backup

On 29.01.2011 09:10, Fujii Masao wrote: On Sat, Jan 29, 2011 at 6:02 AM, Heikki Linnakangas wrote: On 27.01.2011 06:44, Fujii Masao wrote: + XLByteToSeg(endptr, endlogid, endlogseg); + /* Have we reached our stop position yet? */ + i

Re: [HACKERS] REVIEW: Determining client_encoding from client locale

On 29.01.2011 19:23, Peter Eisentraut wrote: > Also, do we really need a new set of states for this..? I would have > thought, just reading through the patch, that we could use the existing > OPTION_SEND/OPTION_WAIT states.. Don't know. Maybe Heikki could comment; he wrote that initially.

Re: [HACKERS] multiset patch review

On Mon, Jan 31, 2011 at 02:34, Robert Haas wrote: >>> I'm in favor of rejecting this patch in its entirety.  The >>> functionality looks useful, but once you remove the syntax support, it >>> could just as easily be distributed as a contrib module rather than in >>> core. >> >> +1 ... if we're goi

Re: [HACKERS] Snapshot synchronization, again...

Here is a new version of the patch incorporating most of Noah's suggestions. The patch now also adds documentation. Since I couldn't really find a suitable section to document the two new functions, I added a new one for now. Any better ideas where it should go? On Thu, Jan 20, 2011 at 1:37 AM, No

Re: [HACKERS] mingw 64 build

On 01/30/2011 11:52 AM, Magnus Hagander wrote: On Sun, Jan 30, 2011 at 16:47, Andrew Dunstan wrote: The attached patch allows building a 64 bit Windows Postgres using the mingw64 compiler from

Re: [HACKERS] multiset patch review

On Sun, Jan 30, 2011 at 12:16 PM, Tom Lane wrote: > Robert Haas writes: >> So, the plan is to add this now with non-standard semantics and then >> change the semantics later if and when we implement what the standard >> requires?  That's not something we usually do, and I don't see why >> it's a

Re: [HACKERS] multiset patch review

2011/1/30 Robert Haas : > On Mon, Jan 24, 2011 at 7:27 AM, Itagaki Takahiro > wrote: >> On Mon, Jan 24, 2011 at 20:49, Robert Haas wrote: >>> I notice that this is adding keywords and syntax support for what is >>> basically a PostgreSQL extension (since we certainly can't possibly be >>> followi

Re: [HACKERS] multiset patch review

Robert Haas writes: > So, the plan is to add this now with non-standard semantics and then > change the semantics later if and when we implement what the standard > requires? That's not something we usually do, and I don't see why > it's a better idea in this case than it is in general. It's OK

Re: [HACKERS] multiset patch review

On Mon, Jan 24, 2011 at 7:27 AM, Itagaki Takahiro wrote: > On Mon, Jan 24, 2011 at 20:49, Robert Haas wrote: >> I notice that this is adding keywords and syntax support for what is >> basically a PostgreSQL extension (since we certainly can't possibly be >> following the SQL standards given that

Re: [HACKERS] mingw 64 build

On Sun, Jan 30, 2011 at 16:47, Andrew Dunstan wrote: > > The attached patch allows building a 64 bit Windows Postgres using the > mingw64 compiler from > . > It works both as a native compiler and

Re: [HACKERS] Sync Rep for 2011CF1

On Sat, Jan 22, 2011 at 8:31 AM, Simon Riggs wrote: > On Fri, 2011-01-21 at 13:32 -0500, Robert Haas wrote: > >> One idea might be to wait both before and after commit.  If >> allow_standalone_primary is off, and a commit is attempted, we check >> whether there's a slave connected, and if not, wai

[HACKERS] mingw 64 build

The attached patch allows building a 64 bit Windows Postgres using the mingw64 compiler from . It works both as a native compiler and for cross-compiling (which I tested on 32 bit Windows, but