The attached patch allows building a 64 bit Windows Postgres using the
mingw64 compiler from
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/.
It works both as a native compiler and for cross-compiling (which I
tested on 32 bit Windows, but
On Sat, Jan 22, 2011 at 8:31 AM, Simon Riggs si...@2ndquadrant.com 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,
On Sun, Jan 30, 2011 at 16:47, Andrew Dunstan and...@dunslane.net wrote:
The attached patch allows building a 64 bit Windows Postgres using the
mingw64 compiler from
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/.
It works both as a native
On Mon, Jan 24, 2011 at 7:27 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Mon, Jan 24, 2011 at 20:49, Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
2011/1/30 Robert Haas robertmh...@gmail.com:
On Mon, Jan 24, 2011 at 7:27 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Mon, Jan 24, 2011 at 20:49, Robert Haas robertmh...@gmail.com wrote:
I notice that this is adding keywords and syntax support for what is
basically a PostgreSQL
On Sun, Jan 30, 2011 at 12:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On 01/30/2011 11:52 AM, Magnus Hagander wrote:
On Sun, Jan 30, 2011 at 16:47, Andrew Dunstanand...@dunslane.net wrote:
The attached patch allows building a 64 bit Windows Postgres using the
mingw64 compiler from
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,
On Mon, Jan 31, 2011 at 02:34, Robert Haas robertmh...@gmail.com 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
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.
On 29.01.2011 09:10, Fujii Masao wrote:
On Sat, Jan 29, 2011 at 6:02 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 27.01.2011 06:44, Fujii Masao wrote:
+ XLByteToSeg(endptr, endlogid, endlogseg);
snip
+ /* Have we reached our stop
On Sun, Jan 30, 2011 at 1:46 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Mon, Jan 31, 2011 at 02:34, Robert Haas robertmh...@gmail.com 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
On Sun, Jan 30, 2011 at 2:11 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 30, 2011 at 1:46 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Mon, Jan 31, 2011 at 02:34, Robert Haas robertmh...@gmail.com wrote:
I'm in favor of rejecting this patch in its entirety. The
On Thu, Jan 27, 2011 at 05:44, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Jan 26, 2011 at 5:17 AM, Magnus Hagander mag...@hagander.net 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
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
/para
/sect2
On Sat, Jan 29, 2011 at 2:52 AM, Noah Misch n...@leadboat.com 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
On Mon, Jan 31, 2011 at 04:12, Robert Haas robertmh...@gmail.com 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()
On Mon, Jan 24, 2011 at 8:08 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Fri, Jan 14, 2011 at 8:33 PM, Euler Taveira de Oliveira
eu...@timbira.com 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
On Fri, Jan 21, 2011 at 8:28 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 21, 2011 at 7:48 AM, Simon Riggs si...@2ndquadrant.com wrote:
Ah, thanks Florian. Now I understand. There are two related issues here.
1. The discussion around ERRCODE_ADMIN_SHUTDOWN is incorrect and the
On Tue, Jan 18, 2011 at 7:24 PM, Steve Singer ssinger...@sympatico.ca 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
On Sat, Jan 15, 2011 at 1:42 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jan 3, 2011 at 16:45, Brar Piening b...@gmx.de wrote:
On Mon, 3 Jan 2011 10:44:19 +0100, Magnus Hagander mag...@hagander.net
wrote:
Yeah, it looks that way - it's missing the ordering of the contrib
I'll run
On Tue, Jan 18, 2011 at 1:42 PM, Greg Smith g...@2ndquadrant.com 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.
On Tue, Jan 25, 2011 at 11:14 PM, Fujii Masao masao.fu...@gmail.com 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,
On Tue, Jan 25, 2011 at 10:24 AM, Hitoshi Harada umi.tan...@gmail.com 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
On Sun, Jan 30, 2011 at 21:06, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jan 15, 2011 at 1:42 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jan 3, 2011 at 16:45, Brar Piening b...@gmx.de wrote:
On Mon, 3 Jan 2011 10:44:19 +0100, Magnus Hagander mag...@hagander.net
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
ssinger...@sympatico.ca 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.
[ 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;
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
in
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 Serializable
Hi!
On Mon, Jan 31, 2011 at 12:52 AM, Jan Urbański wulc...@wulczer.org 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.
***
On 30/01/11 23:02, Alexander Korotkov wrote:
Hi!
On Mon, Jan 31, 2011 at 12:52 AM, Jan Urbański wulc...@wulczer.org
mailto:wulc...@wulczer.org wrote:
I saw that the code tries to handle ILIKE searches, but apparently it's
failing somewhere.
It was just a typo. Corrected version
On Sun, Jan 30, 2011 at 4:30 PM, Peter Eisentraut pete...@gmx.net 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
ssinger...@sympatico.ca wrote:
If my connection is authorized through a line in pg_hba that uses
client_hostname then
On 30 January 2011 21:33, Jeff Davis pg...@j-davis.com 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:
Jeff Davis pg...@j-davis.com 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).
On Thu, Dec 23, 2010 at 2:41 PM, Tomas Vondra t...@fuzzy.cz 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.
--
On Wed, Jan 19, 2011 at 12:45 AM, Joachim Wieland j...@mcknight.de wrote:
On Mon, Jan 17, 2011 at 5:38 PM, Jaime Casanova ja...@2ndquadrant.com 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
On Sun, Jan 30, 2011 at 5:23 PM, Jan Urbański wulc...@wulczer.org wrote:
On 30/01/11 23:08, Robert Haas wrote:
On Wed, Jan 12, 2011 at 5:10 PM, Jan Urbański wulc...@wulczer.org 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
On Wed, Jan 12, 2011 at 5:10 PM, Jan Urbański wulc...@wulczer.org 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==?= wulc...@wulczer.org writes:
On 11/01/11 17:11, Tom Lane wrote:
Peter
On Sun, Jan 30, 2011 at 18:35, Andrew Dunstan and...@dunslane.net wrote:
On 01/30/2011 11:52 AM, Magnus Hagander wrote:
On Sun, Jan 30, 2011 at 16:47, Andrew Dunstanand...@dunslane.net wrote:
The attached patch allows building a 64 bit Windows Postgres using the
mingw64 compiler from
Robert Haas robertmh...@gmail.com 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:
On Wed, Oct 20, 2010 at 6:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
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 wulc...@wulczer.org
mailto:wulc...@wulczer.org wrote:
I saw that the code tries to handle ILIKE searches, but apparently it's
failing somewhere.
On 30/01/11 23:08, Robert Haas wrote:
On Wed, Jan 12, 2011 at 5:10 PM, Jan Urbański wulc...@wulczer.org 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==?= wulc...@wulczer.org writes:
On
On Sun, Jan 30, 2011 at 5:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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, but it's of
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 will result in
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 30, 2011 at 5:47 PM, Tom Lane t...@sss.pgh.pa.us 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
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
--
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. Any
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.patch.gz
Description: GNU Zip compressed data
--
Sent via
Robert,
On Fri, Jan 21, 2011 at 8:28 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 21, 2011 at 7:48 AM, Simon Riggs si...@2ndquadrant.com wrote:
Ah, thanks Florian. Now I understand. There are two related issues here.
1. The discussion around ERRCODE_ADMIN_SHUTDOWN is incorrect
Tatsuo Ishii is...@postgresql.org writes:
On Fri, Jan 21, 2011 at 8:28 AM, Robert Haas robertmh...@gmail.com 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:
On Sun, Jan 30, 2011 at 8:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Tatsuo Ishii is...@postgresql.org writes:
On Fri, Jan 21, 2011 at 8:28 AM, Robert Haas robertmh...@gmail.com wrote:
It seems like we have consensus to change
CheckRecoveryConflictDetected() to return
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 30, 2011 at 8:11 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sun, Jan 30, 2011 at 8:42 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 30, 2011 at 8:42 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Jan 17, 2011 at 4:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
On Mon, Jan 31, 2011 at 4:22 AM, Magnus Hagander mag...@hagander.net wrote:
In pg_basebackup.sgml
termoption--checkpoint replaceable
class=parameterfast|spread/replaceable/option/term
Though this is not the problem of the patch, I found the inconsistency
of the descriptions about options
On Sun, Jan 30, 2011 at 9:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 30, 2011 at 8:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, so far as this goes:
http://archives.postgresql.org/pgsql-hackers/2011-01/msg01152.php
we should certainly
On Sun, Jan 30, 2011 at 9:34 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Jan 31, 2011 at 4:22 AM, Magnus Hagander mag...@hagander.net wrote:
In pg_basebackup.sgml
termoption--checkpoint replaceable
class=parameterfast|spread/replaceable/option/term
Though this is not the problem
On Sat, Jan 29, 2011 at 1:11 AM, Tatsuo Ishii is...@postgresql.org 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
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
On Sun, Jan 30, 2011 at 10:03 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
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
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, probably
On Mon, Jan 31, 2011 at 11:52, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Jan 29, 2011 at 1:11 AM, Tatsuo Ishii is...@postgresql.org 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
On Fri, Jan 28, 2011 at 18:03, Dimitri Fontaine dimi...@2ndquadrant.fr 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.
On Mon, Jan 31, 2011 at 12:31 PM, Itagaki Takahiro
itagaki.takah...@gmail.com 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
2011/1/31 Robert Haas robertmh...@gmail.com:
On Tue, Jan 25, 2011 at 10:24 AM, Hitoshi Harada umi.tan...@gmail.com 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
On Mon, Jan 31, 2011 at 12:35 PM, Tatsuo Ishii is...@postgresql.org 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,
On Mon, Jan 31, 2011 at 12:35 PM, Tatsuo Ishii is...@postgresql.org 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
On Fri, 21 Jan 2011 18:28:19 +0200
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On Tue, Nov 30, 2010 at 3:29 PM, Greg Smith g...@2ndquadrant.com 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.
On Sun, Jan 30, 2011 at 10:44 AM, Jeff Janes jeff.ja...@gmail.com 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
76 matches
Mail list logo
