On Mon, Mar 7, 2011 at 5:27 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Mar 7, 2011 at 7:51 AM, Simon Riggs si...@2ndquadrant.com wrote:
Efficient transaction-controlled synchronous replication.
If a standby is broadcasting reply messages and we have named
one or more standbys in
On 06.03.2011 23:33, Kevin Grittner wrote:
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.
On Sun, Mar 6, 2011 at 18:14, Magnus Hagander mag...@hagander.net wrote:
Hi!
If all things go according to plans, we will be moving the VM that
runs commitfest.postgresql.org to new hw+platform tomorrow, in the AM
European time. Expected downtime is just a couple of minutes, and I
will leave
Hi,
Thanks for your suggestion, Heikki. Btree_gist module provides Gist
implementation for various different data types, equivalent to btree.
Correct me if i wrong?
create index . using gist (coordinates,time). It will create index on
both but i think there would be no linkage between them.
On Mon, Mar 7, 2011 at 6:20 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2011-03-07 at 17:27 +0900, Fujii Masao wrote:
On Mon, Mar 7, 2011 at 7:51 AM, Simon Riggs si...@2ndquadrant.com wrote:
And,, I found one bug ;) You seem to have wrongly removed the check
of max_wal_senders in
On Mon, 2011-03-07 at 17:44 +0900, Fujii Masao wrote:
The above check should be required also after pg_ctl reload since
synchronous_standby_names can be changed by SIGHUP?
Or how about just removing that? If the patch I submitted is
committed,empty synchronous_standby_names and
On 07.03.2011 11:11, Nick Raj wrote:
create index . using gist (coordinates,time). It will create index on
both but i think there would be no linkage between them.
But i want linkage between location and time tree. I want for each location
i have Btree like
On Mon, Mar 7, 2011 at 6:30 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2011-03-07 at 17:44 +0900, Fujii Masao wrote:
The above check should be required also after pg_ctl reload since
synchronous_standby_names can be changed by SIGHUP?
Or how about just removing that? If the patch I
I've attached a small patch with a bit of clarification and a typo fix
in the synchronous_standby_names parameter info.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
sync_rep_doc_fix.patch
Description: Binary data
--
Sent via pgsql-hackers
On 08.02.2011 06:27, Robert Haas wrote:
On Mon, Jan 24, 2011 at 2:00 AM, Fujii Masaomasao.fu...@gmail.com wrote:
On Wed, Jan 5, 2011 at 5:08 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I finally got around to look at this. I wrote a patch to validate that the
TLI on
On 7 March 2011 15:27, Thom Brown t...@linux.com wrote:
I've attached a small patch with a bit of clarification and a typo fix
in the synchronous_standby_names parameter info.
Okay, I've noticed that the main documentation also needed some fixes,
so those have been included in this new patch.
On Mon, Mar 7, 2011 at 5:27 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Mar 7, 2011 at 7:51 AM, Simon Riggs si...@2ndquadrant.com wrote:
Efficient transaction-controlled synchronous replication.
If a standby is broadcasting reply messages and we have named
one or more standbys in
This was spotted by someone who sent in a doc comment, although didn't
go with their suggestion. Patch attached.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
for_update_of_typo_fix.patch
Description: Binary data
--
Sent via pgsql-hackers
On Mon, Mar 7, 2011 at 11:52, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 08.02.2011 06:27, Robert Haas wrote:
On Mon, Jan 24, 2011 at 2:00 AM, Fujii Masaomasao.fu...@gmail.com
wrote:
On Wed, Jan 5, 2011 at 5:08 AM, Heikki Linnakangas
On Mon, Mar 7, 2011 at 9:06 PM, Magnus Hagander mag...@hagander.net wrote:
I dropped the ball on this one, but now that we have pg_basebackup and
pg_ctl promote which make it easy to set up a standby and failover, I
think we should still do this in 9.1. Otherwise you need a restart to have a
On ons, 2011-03-02 at 22:28 +0100, Jan Urbański wrote:
I did some tests with the attached test script, calling various of the
functions defined there and the error messages more or less made sense
(or at least were not worse than before).
Is that script part of the regression tests you added?
On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote:
But fixing raise plpy.Fatal()
to actually cause a FATAL is something that should be extracted from
this patch and committed, even if the full patch does not make it.
Um, what? I didn't find any details about this in this thread, nor a
On 07/03/11 13:53, Peter Eisentraut wrote:
On ons, 2011-03-02 at 22:28 +0100, Jan Urbański wrote:
I did some tests with the attached test script, calling various of the
functions defined there and the error messages more or less made sense
(or at least were not worse than before).
Is that
On 07/03/11 13:53, Peter Eisentraut wrote:
On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote:
But fixing raise plpy.Fatal()
to actually cause a FATAL is something that should be extracted from
this patch and committed, even if the full patch does not make it.
Um, what? I didn't find
On 07/03/11 14:01, Jan Urbański wrote:
On 07/03/11 13:53, Peter Eisentraut wrote:
On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote:
But fixing raise plpy.Fatal()
to actually cause a FATAL is something that should be extracted from
this patch and committed, even if the full patch does not
On 2011-03-07 01:37, Simon Riggs wrote:
On Sat, 2011-03-05 at 21:11 +0100, Yeb Havinga wrote:
I also got a first first 1000 tps score
The committed version should be even faster. Would appreciate a retest.
pgbench 5 minute test pgbench -c 10 -M prepared -T 300 test
dbsize was -s 50, 1Gbit
On 03/07/2011 02:29 AM, Heikki Linnakangas wrote:
On 07.03.2011 01:28, Simon Riggs wrote:
On Sun, 2011-03-06 at 18:09 -0500, Andrew Dunstan wrote:
On 03/06/2011 05:51 PM, Simon Riggs wrote:
Efficient transaction-controlled synchronous replication.
I'm glad this is in, but I thought we
On Mon, 2011-03-07 at 14:20 +0100, Yeb Havinga wrote:
On 2011-03-07 01:37, Simon Riggs wrote:
On Sat, 2011-03-05 at 21:11 +0100, Yeb Havinga wrote:
I also got a first first 1000 tps score
The committed version should be even faster. Would appreciate a retest.
pgbench 5 minute test
On 07.03.2011 15:30, Andrew Dunstan wrote:
Previously, Simon said:
Truly synchronous requires two-phase commit, which this never was.
So I too am confused about how it's now become truly synchronous. Are
we saying this give the same or better guarantees than a 2PC setup?
The guarantee we
On 03/07/2011 09:02 AM, Heikki Linnakangas wrote:
On 07.03.2011 15:30, Andrew Dunstan wrote:
Previously, Simon said:
Truly synchronous requires two-phase commit, which this never was.
So I too am confused about how it's now become truly synchronous. Are
we saying this give the same or
On Mon, Mar 7, 2011 at 2:21 PM, Andrew Dunstan and...@dunslane.net wrote:
For me, that's enough to call it synchronous replication. It provides a
useful guarantee to the client. But you could argue for an even stricter
definition, requiring atomicity so that if a transaction is not
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
if you pull the power plug, the transaction that was just being
committed might be committed on the master, but not yet on the
standby.
For me, that's enough to call it synchronous replication. It
provides useful guarantee to
On 03/07/2011 09:29 AM, Aidan Van Dyk wrote:
On Mon, Mar 7, 2011 at 2:21 PM, Andrew Dunstanand...@dunslane.net wrote:
For me, that's enough to call it synchronous replication. It provides a
useful guarantee to the client. But you could argue for an even stricter
definition, requiring
On Mon, Mar 7, 2011 at 2:29 PM, Aidan Van Dyk ai...@highrise.ca wrote:
They they are either already hosed or already using 2PC.
Sorry, to expand on my all too brief comment, even *without*
replication, they are hosed.
Once you issue commit, you have know knowledge if the commit is
durable, (or
Andrew Dunstan and...@dunslane.net wrote:
Synchronous replication - guarantees zero data loss by the
means of atomic write operation, i.e. write either completes on
both sides or not at all.
So far, so good.
Write is not considered complete until acknowledgement by both
local
On 07.03.2011 17:03, Andrew Dunstan wrote:
This is about expectations. The thing that worries me is that the use of
this term might cause some people NOT to use 2PC because they think they
are getting an equivalent guarantee, when in fact they are not. And
that's hardly unreasonable. Here for
On 03/07/2011 10:46 AM, Heikki Linnakangas wrote:
On 07.03.2011 17:03, Andrew Dunstan wrote:
This is about expectations. The thing that worries me is that the use of
this term might cause some people NOT to use 2PC because they think they
are getting an equivalent guarantee, when in fact they
Excerpts from Andrew Dunstan's message of lun mar 07 12:51:49 -0300 2011:
On 03/07/2011 10:46 AM, Heikki Linnakangas wrote:
Hmm, I've read that wikipedia definition before, but the atomic part
never caught my eye. You do get zero data loss with what we have; if a
meteor strikes the
Is there any documentation of $SUBJECT? Because the more I look at
this patch the more I think it's misdesigned; either that or I
fundamentally misunderstand what it's trying to do. I complained
yesterday about why the planner wasn't using indcollation to identify
the sort order of an index. I
Excerpts from Greg Stark's message of jue mar 03 13:02:53 -0300 2011:
But I'm not sure it's worth bothering. Filling in the description
field is hardly the most annoying part of adding pg_proc entries for
operators. If we could move most or all of the entries to an SQL file
so that we didn't
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Greg Stark's message of jue mar 03 13:02:53 -0300 2011:
But I'm not sure it's worth bothering. Filling in the description
field is hardly the most annoying part of adding pg_proc entries for
operators. If we could move most or all
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown t...@linux.com wrote:
On 7 March 2011 15:27, Thom Brown t...@linux.com wrote:
I've attached a small patch with a bit of clarification and a typo fix
in the synchronous_standby_names parameter info.
Okay, I've noticed that the main documentation also
On Mon, Mar 7, 2011 at 7:05 AM, Thom Brown t...@linux.com wrote:
This was spotted by someone who sent in a doc comment, although didn't
go with their suggestion. Patch attached.
That's not really a typo so much as a think-o, I think. Maybe a
little more text would help clarify: A
On mån, 2011-03-07 at 11:43 -0500, Tom Lane wrote:
Is there any documentation of $SUBJECT? Because the more I look at
this patch the more I think it's misdesigned; either that or I
fundamentally misunderstand what it's trying to do. I complained
yesterday about why the planner wasn't using
On 7 March 2011 22:31, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown t...@linux.com wrote:
On 7 March 2011 15:27, Thom Brown t...@linux.com wrote:
I've attached a small patch with a bit of clarification and a typo fix
in the synchronous_standby_names
On sön, 2011-03-06 at 12:16 -0500, Tom Lane wrote:
I'm still not thrilled with the plan of sprinkling the code with
random fmgr_info_collation() calls to make up for the lack of a sane
default. IMO, that *is* a default, just a badly implemented one.
We have touched upon this point several
Tom Lane t...@sss.pgh.pa.us writes:
I'm not really convinced that it's worth the trouble though. Making
up those DATA lines is not the hardest part of making a new built-in
No but it's cumbersome. I'd welcome simplification here, even if to be
honest that itch isn't scratching me enough, some
Peter Eisentraut pete...@gmx.net writes:
On sön, 2011-03-06 at 12:16 -0500, Tom Lane wrote:
I'm still not thrilled with the plan of sprinkling the code with
random fmgr_info_collation() calls to make up for the lack of a sane
default. IMO, that *is* a default, just a badly implemented one.
On Mon, Mar 07, 2011 at 10:53:17PM +0530, Thom Brown wrote:
On 7 March 2011 22:31, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown t...@linux.com wrote:
On 7 March 2011 15:27, Thom Brown t...@linux.com wrote:
I've attached a small patch with a bit of
Peter Eisentraut pete...@gmx.net writes:
On mån, 2011-03-07 at 11:43 -0500, Tom Lane wrote:
... I now think that the reason it doesn't
obviously fail to fail is that indcollation is dead code, and so is
approximately 99% of what you added to the planner, because two
expressions that are
On 7 March 2011 22:39, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 7, 2011 at 7:05 AM, Thom Brown t...@linux.com wrote:
This was spotted by someone who sent in a doc comment, although didn't
go with their suggestion. Patch attached.
That's not really a typo so much as a think-o, I
On 7 March 2011 23:21, David Fetter da...@fetter.org wrote:
On Mon, Mar 07, 2011 at 10:53:17PM +0530, Thom Brown wrote:
On 7 March 2011 22:31, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown t...@linux.com wrote:
On 7 March 2011 15:27, Thom Brown
On Mon, Mar 07, 2011 at 11:34:48PM +0530, Thom Brown wrote:
On 7 March 2011 23:21, David Fetter da...@fetter.org wrote:
On Mon, Mar 07, 2011 at 10:53:17PM +0530, Thom Brown wrote:
On 7 March 2011 22:31, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown
On Mon, Mar 7, 2011 at 1:04 PM, Thom Brown t...@linux.com wrote:
On 7 March 2011 23:21, David Fetter da...@fetter.org wrote:
On Mon, Mar 07, 2011 at 10:53:17PM +0530, Thom Brown wrote:
On 7 March 2011 22:31, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown
On Mon, Mar 7, 2011 at 12:59 PM, Thom Brown t...@linux.com wrote:
On 7 March 2011 22:39, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 7, 2011 at 7:05 AM, Thom Brown t...@linux.com wrote:
This was spotted by someone who sent in a doc comment, although didn't
go with their suggestion.
On Sun, Mar 6, 2011 at 5:36 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2011-03-04 at 16:57 +0900, Fujii Masao wrote:
On Wed, Mar 2, 2011 at 11:30 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Mar 2, 2011 at 8:22 PM, Simon Riggs si...@2ndquadrant.com wrote:
The WALSender
Thom Brown t...@linux.com writes:
On 7 March 2011 23:21, David Fetter da...@fetter.org wrote:
As I'm putting together the patches section for the PostgreSQL Weekly
News, it helps me *enormously* to have only one list I need to check,
so at least for me, it's an enormous help to have all
On 7 March 2011 23:43, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 7, 2011 at 12:59 PM, Thom Brown t...@linux.com wrote:
On 7 March 2011 22:39, Robert Haas robertmh...@gmail.com wrote:
On Mon, Mar 7, 2011 at 7:05 AM, Thom Brown t...@linux.com wrote:
This was spotted by someone who
Hi,
On Monday, March 07, 2011 06:40:55 PM Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On sön, 2011-03-06 at 12:16 -0500, Tom Lane wrote:
I'm still not thrilled with the plan of sprinkling the code with
random fmgr_info_collation() calls to make up for the lack of a sane
Excerpts from Tom Lane's message of lun mar 07 15:16:31 -0300 2011:
If we do that then it becomes worth wondering what the -docs list is for
at all. Maybe we *should* get rid of it; I dunno. I see your point
about how the factual issues involved in a docs change ought to be
vetted on
On Mon, Mar 7, 2011 at 1:42 PM, Andres Freund and...@anarazel.de wrote:
that looks like it should be corrected btw:
src/backend/tsearch/{wparser_def.c,ts_locale.c}
Oid collation = DEFAULT_COLLATION_OID; /*TODO*/
Thats occuring 6 times in there...
At the risk of hijacking
On 3/7/11 10:59 AM, Robert Haas wrote:
On Mon, Mar 7, 2011 at 1:42 PM, Andres Freund and...@anarazel.de wrote:
that looks like it should be corrected btw:
src/backend/tsearch/{wparser_def.c,ts_locale.c}
Oid collation = DEFAULT_COLLATION_OID; /*TODO*/
Thats occuring 6
On Mon, Mar 07, 2011 at 03:45:17PM -0300, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of lun mar 07 15:16:31 -0300 2011:
If we do that then it becomes worth wondering what the -docs list is for
at all. Maybe we *should* get rid of it; I dunno. I see your point
about how the
On Mon, Mar 07, 2011 at 01:01:05PM -0600, Ross J. Reedstrom wrote:
On Mon, Mar 07, 2011 at 03:45:17PM -0300, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of lun mar 07 15:16:31 -0300
2011:
If we do that then it becomes worth wondering what the -docs
list is for at all.
On 3/7/11 11:07 AM, David Fetter wrote:
Re: docs, I'd actually like to see that list gone, as the separation
of docs from code is one that's actively unhelpful. We don't have a
separate docs team, and we rightly put the responsibility of
documenting changes on the person or people patching
On 07.03.2011 14:35, Fujii Masao wrote:
Comments:
+ if (!list_member_int(expectedTLIs,
+(int)
recoveryTargetTLI))
+ ereport(LOG,
+ (errmsg(new timeline %u is not a
On Mon, 2011-03-07 at 13:15 -0500, Robert Haas wrote:
On Sun, Mar 6, 2011 at 5:36 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2011-03-04 at 16:57 +0900, Fujii Masao wrote:
On Wed, Mar 2, 2011 at 11:30 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Mar 2, 2011 at 8:22 PM,
On Mon, Mar 7, 2011 at 20:16, Heikki Linnakangas
heikki.linnakan...@iki.fi wrote:
If recovery_target_timeline is set to 'latest' and standby mode is enabled,
periodically rescan the archive for new timelines, while waiting for new WAL
segments to arrive. This allows you to set up a standby
On 07.03.2011 21:20, Magnus Hagander wrote:
On Mon, Mar 7, 2011 at 20:16, Heikki Linnakangas
heikki.linnakan...@iki.fi wrote:
If recovery_target_timeline is set to 'latest' and standby mode is enabled,
periodically rescan the archive for new timelines, while waiting for new WAL
segments to
On Mon, Mar 7, 2011 at 20:24, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 07.03.2011 21:20, Magnus Hagander wrote:
On Mon, Mar 7, 2011 at 20:16, Heikki Linnakangas
heikki.linnakan...@iki.fi wrote:
If recovery_target_timeline is set to 'latest' and standby mode is
On Mon, Mar 7, 2011 at 2:07 PM, David Fetter da...@fetter.org wrote:
Re: docs, I'd actually like to see that list gone, as the separation
of docs from code is one that's actively unhelpful. We don't have a
separate docs team, and we rightly put the responsibility of
documenting changes on the
On Mon, Mar 07, 2011 at 02:31:18PM -0500, Robert Haas wrote:
On Mon, Mar 7, 2011 at 2:07 PM, David Fetter da...@fetter.org wrote:
Re: docs, I'd actually like to see that list gone, as the separation
of docs from code is one that's actively unhelpful. We don't have a
separate docs team, and
Robert Haas robertmh...@gmail.com writes:
At the risk of hijacking this thread to talk about the subject of this
thread, when are we going to cut alpha4?
Well, a prerequisite for cutting an alpha is closing the commitfest,
which at this point reduces to deciding what we are going to do with
the
On Mon, Mar 7, 2011 at 2:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
At the risk of hijacking this thread to talk about the subject of this
thread, when are we going to cut alpha4?
Well, a prerequisite for cutting an alpha is closing the commitfest,
On Mon, 2011-03-07 at 19:16 +, Heikki Linnakangas wrote:
If recovery_target_timeline is set to 'latest' and standby mode is enabled,
periodically rescan the archive for new timelines, while waiting for new WAL
segments to arrive. This allows you to set up a standby server that follows
the
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Well, a prerequisite for cutting an alpha is closing the
commitfest, which at this point reduces to deciding what we are
going to do with the plpython traceback patch.
AFAIK, there's nothing particularly special
On Mon, Mar 7, 2011 at 3:15 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Well, a prerequisite for cutting an alpha is closing the
commitfest, which at this point reduces to deciding what we are
going to do
Robert Haas robertmh...@gmail.com wrote:
Still, as happy as I am that we've made so much progress with
PL/python (and other things) this CommitFest, I think it's time to
pick a date and time to ship alpha4 and call this one good. If
the patch makes it, great; if not, oh well. We can't keep
On Mon, Mar 7, 2011 at 3:28 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
Still, as happy as I am that we've made so much progress with
PL/python (and other things) this CommitFest, I think it's time to
pick a date and time to ship alpha4 and
Thom Brown t...@linux.com writes:
On 7 March 2011 22:39, Robert Haas robertmh...@gmail.com wrote:
That's not really a typo so much as a think-o, I think. Maybe a
little more text would help clarify: A column-specific trigger (one
defined using the literalUPDATE OF
On Mon, Mar 07, 2011 at 11:43:20AM -0500, Tom Lane wrote:
Is there any documentation of $SUBJECT? Because the more I look at
this patch the more I think it's misdesigned; either that or I
fundamentally misunderstand what it's trying to do. I complained
yesterday about why the planner wasn't
Howdy,
I saw that Tom added the ModifyTable node to EXPLAIN output last week. I'd like
to update my explanation extension to use it, but I've no idea what it would
look like. Could someone send me an example in the XML format?
Thanks!
David
--
Sent via pgsql-hackers mailing list
On Sat, 2011-03-05 at 18:33 -0500, Bruce Momjian wrote:
I am seeing the following compile problem with gmake -j2:
For what it's worth, I'm still seeing this problem too:
http://archives.postgresql.org/pgsql-hackers/2010-12/msg00123.php
I can reproduce it every time.
Regards,
Jeff
On mån, 2011-03-07 at 14:19 +0100, Jan Urbański wrote:
On 07/03/11 14:01, Jan Urbański wrote:
On 07/03/11 13:53, Peter Eisentraut wrote:
On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote:
But fixing raise plpy.Fatal()
to actually cause a FATAL is something that should be extracted
On mån, 2011-03-07 at 15:19 -0500, Robert Haas wrote:
Sorry, you're right. Still, as happy as I am that we've made so much
progress with PL/python (and other things) this CommitFest, I think
it's time to pick a date and time to ship alpha4 and call this one
good. If the patch makes it,
On Mon, Mar 7, 2011 at 4:59 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2011-03-07 at 15:19 -0500, Robert Haas wrote:
Sorry, you're right. Still, as happy as I am that we've made so much
progress with PL/python (and other things) this CommitFest, I think
it's time to pick a date and
On Mon, 2011-03-07 at 11:00 -0800, Josh Berkus wrote:
At the risk of hijacking this thread to talk about the subject of
this
thread, when are we going to cut alpha4?
Any reason not to release it this week, like Thursday?
Let's release it before PGEast, please -- I will be there, and
On Fri, Mar 04, 2011 at 05:52:29PM +0200, Heikki Linnakangas wrote:
Hmm, if these all came from the same database, then it looks OldestXmin
has moved backwards. That would explain the warnings. First one vacuum
determines that all the tuples are visible to everyone and sets the
flag. Then
Martijn van Oosterhout klep...@svana.org writes:
On Mon, Mar 07, 2011 at 11:43:20AM -0500, Tom Lane wrote:
Is there any documentation of $SUBJECT?
The collation is a property of the operators/functions and not of the
values. An individual value does not have a collation, a column does.
OK.
David E. Wheeler da...@kineticode.com writes:
I saw that Tom added the ModifyTable node to EXPLAIN output last week. I'd
like to update my explanation extension to use it, but I've no idea what it
would look like. Could someone send me an example in the XML format?
It's already there in 9.0
On Mar 7, 2011, at 4:41 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
I saw that Tom added the ModifyTable node to EXPLAIN output last week. I'd
like to update my explanation extension to use it, but I've no idea what it
would look like. Could someone send me an example
Jeff Davis pg...@j-davis.com writes:
For what it's worth, I'm still seeing this problem too:
http://archives.postgresql.org/pgsql-hackers/2010-12/msg00123.php
I can reproduce it every time.
I think what is happening here is that make launches concurrent sub-jobs
to do make install in each of
On Mon, Mar 7, 2011 at 11:53 PM, daveg da...@sonic.net wrote:
Looking at the code, I don't see how that situation could arise, though.
The value calculated by GetOldestXmin() should never move backwards. And
GetOldestXmin() is called in lazy_vacuum_rel(), after it has acquired a
lock on the
On Wed, Feb 9, 2011 at 5:12 PM, Magnus Hagander mag...@hagander.net wrote:
I was also worried about the non-hot-standby case, but I see that the
patch makes sure you can't enable pause when not in hot standby mode.
Which in itself might be surprising - perhaps we need a NOTICE for
when that
I wrote:
I think what is happening here is that make launches concurrent sub-jobs
to do make install in each of interfaces/libpq and interfaces/ecpg,
and the latter launches a sub-sub-job to do make all in
interfaces/libpq, and make has no idea that these are duplicate sub-jobs
so it actually
Hi!
PostgreSQL is applying for GSoC again this year. We're looking for:
* Mentors
* Project ideas
Would you like to mentor? Please let me know! Our application closes
on Friday, so please contact me *before* Friday.
I've started a wiki page: http://wiki.postgresql.org/wiki/GSoC_2011
It's
91 matches
Mail list logo
