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 seede
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
On Wed, Feb 9, 2011 at 5:12 PM, Magnus Hagander 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 happens as well?
On Mon, Mar 7, 2011 at 11:53 PM, daveg 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 table, whi
Jeff Davis 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 interfaces/lib
On Mar 7, 2011, at 4:41 PM, Tom Lane wrote:
> "David E. Wheeler" 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 f
"David E. Wheeler" 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 --- I just added
Martijn van Oosterhout 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.
> A pathkey r
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. The
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
On Mon, Mar 7, 2011 at 4:59 PM, Peter Eisentraut 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 time to sh
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, gr
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 b
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 D
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 (pgsql-hacker
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 was
Thom Brown writes:
> On 7 March 2011 22:39, Robert Haas 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 UPDATE OF
>> column_name syntax) will fire
>> when...
>>
>> It should rea
On Mon, Mar 7, 2011 at 3:28 PM, Kevin Grittner
wrote:
> Robert Haas 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
Robert Haas 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 letting
> this dr
On Mon, Mar 7, 2011 at 3:15 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> Tom Lane 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
Robert Haas wrote:
> Tom Lane 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 about that patch,
> other than th
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
>
On Mon, Mar 7, 2011 at 2:43 PM, Tom Lane wrote:
> Robert Haas 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 dec
Robert Haas 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 plpython traceback
On Mon, Mar 07, 2011 at 02:31:18PM -0500, Robert Haas wrote:
> On Mon, Mar 7, 2011 at 2:07 PM, 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 righ
On Mon, Mar 7, 2011 at 2:07 PM, 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
On Mon, Mar 7, 2011 at 20:24, Heikki Linnakangas
wrote:
> On 07.03.2011 21:20, Magnus Hagander wrote:
>>
>> On Mon, Mar 7, 2011 at 20:16, Heikki Linnakangas
>> wrote:
>>>
>>> If recovery_target_timeline is set to 'latest' and standby mode is
>>> enabled,
>>> periodically rescan the archive for n
On 07.03.2011 21:20, Magnus Hagander wrote:
On Mon, Mar 7, 2011 at 20: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 se
On Mon, Mar 7, 2011 at 20: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 T
On Mon, 2011-03-07 at 13:15 -0500, Robert Haas wrote:
> On Sun, Mar 6, 2011 at 5:36 PM, Simon Riggs wrote:
> > On Fri, 2011-03-04 at 16:57 +0900, Fujii Masao wrote:
> >> On Wed, Mar 2, 2011 at 11:30 PM, Fujii Masao wrote:
> >> > On Wed, Mar 2, 2011 at 8:22 PM, Simon Riggs
> >> > wrote:
> >>
>
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 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 patchi
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
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 ho
On 3/7/11 10:59 AM, Robert Haas wrote:
> On Mon, Mar 7, 2011 at 1:42 PM, Andres Freund 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 the
On Mon, Mar 7, 2011 at 1:42 PM, Andres Freund 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 this thread to
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 -ha
Hi,
On Monday, March 07, 2011 06:40:55 PM Tom Lane wrote:
> Peter Eisentraut 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
On 7 March 2011 23:43, Robert Haas wrote:
> On Mon, Mar 7, 2011 at 12:59 PM, Thom Brown wrote:
>> On 7 March 2011 22:39, Robert Haas wrote:
>>> On Mon, Mar 7, 2011 at 7:05 AM, Thom Brown wrote:
This was spotted by someone who sent in a doc comment, although didn't
go with their sugges
Thom Brown writes:
> On 7 March 2011 23:21, David Fetter 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 patches at least
>> CC'd, or b
On Sun, Mar 6, 2011 at 5:36 PM, Simon Riggs wrote:
> On Fri, 2011-03-04 at 16:57 +0900, Fujii Masao wrote:
>> On Wed, Mar 2, 2011 at 11:30 PM, Fujii Masao wrote:
>> > On Wed, Mar 2, 2011 at 8:22 PM, Simon Riggs wrote:
>> >> The WALSender deliberately does *not* wake waiting users if the standby
On Mon, Mar 7, 2011 at 12:59 PM, Thom Brown wrote:
> On 7 March 2011 22:39, Robert Haas wrote:
>> On Mon, Mar 7, 2011 at 7:05 AM, Thom Brown 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
On Mon, Mar 7, 2011 at 1:04 PM, Thom Brown wrote:
> On 7 March 2011 23:21, David Fetter wrote:
>> On Mon, Mar 07, 2011 at 10:53:17PM +0530, Thom Brown wrote:
>>> On 7 March 2011 22:31, Robert Haas wrote:
>>> > On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown wrote:
>>> >> On 7 March 2011 15:27, Thom
On Mon, Mar 07, 2011 at 11:34:48PM +0530, Thom Brown wrote:
> On 7 March 2011 23:21, David Fetter wrote:
> > On Mon, Mar 07, 2011 at 10:53:17PM +0530, Thom Brown wrote:
> >> On 7 March 2011 22:31, Robert Haas wrote:
> >> > On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown wrote:
> >> >> On 7 March 2011
On 7 March 2011 23:21, David Fetter wrote:
> On Mon, Mar 07, 2011 at 10:53:17PM +0530, Thom Brown wrote:
>> On 7 March 2011 22:31, Robert Haas wrote:
>> > On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown wrote:
>> >> On 7 March 2011 15:27, Thom Brown wrote:
>> >>> I've attached a small patch with a b
On 7 March 2011 22:39, Robert Haas wrote:
> On Mon, Mar 7, 2011 at 7:05 AM, Thom Brown 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
Peter Eisentraut 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 equal() mus
On Mon, Mar 07, 2011 at 10:53:17PM +0530, Thom Brown wrote:
> On 7 March 2011 22:31, Robert Haas wrote:
> > On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown wrote:
> >> On 7 March 2011 15:27, Thom Brown wrote:
> >>> I've attached a small patch with a bit of clarification and a typo fix
> >>> in the sy
Peter Eisentraut 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.
> We have
Tom Lane 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 others are much
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 t
On 7 March 2011 22:31, Robert Haas wrote:
> On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown wrote:
>> On 7 March 2011 15:27, Thom Brown 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
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 usi
On Mon, Mar 7, 2011 at 7:05 AM, Thom Brown 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 column-specific trigger (
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown wrote:
> On 7 March 2011 15:27, Thom Brown 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,
> s
Alvaro Herrera 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 of the entries to a
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
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 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 strike
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
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 exa
Andrew Dunstan 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 and remote st
On Mon, Mar 7, 2011 at 2:29 PM, Aidan Van Dyk 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 even posibly see
On 03/07/2011 09:29 AM, Aidan Van Dyk wrote:
On Mon, Mar 7, 2011 at 2:21 PM, Andrew Dunstan 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 t
Heikki Linnakangas 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 the client.
I don't think mo
On Mon, Mar 7, 2011 at 2:21 PM, Andrew Dunstan 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 successfully
>> replica
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 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 w
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 mi
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 agr
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 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 p
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
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).
>
> I
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 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 Mon, Mar 7, 2011 at 9:06 PM, Magnus Hagander 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
>> 2nd standby
On Mon, Mar 7, 2011 at 11:52, Heikki Linnakangas
wrote:
> On 08.02.2011 06:27, Robert Haas wrote:
>>
>> On Mon, Jan 24, 2011 at 2:00 AM, Fujii Masao
>> wrote:
>>>
>>> On Wed, Jan 5, 2011 at 5:08 AM, Heikki Linnakangas
>>> wrote:
I finally got around to look at this. I wrote a patch to
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 mailing
On Mon, Mar 7, 2011 at 5:27 PM, Fujii Masao wrote:
> On Mon, Mar 7, 2011 at 7:51 AM, Simon Riggs wrote:
>> Efficient transaction-controlled synchronous replication.
>> If a standby is broadcasting reply messages and we have named
>> one or more standbys in synchronous_standby_names then allow
>>
On 7 March 2011 15:27, Thom Brown 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.
--
Thom Brow
On 08.02.2011 06:27, Robert Haas wrote:
On Mon, Jan 24, 2011 at 2:00 AM, Fujii Masao wrote:
On Wed, Jan 5, 2011 at 5:08 AM, Heikki Linnakangas
wrote:
I finally got around to look at this. I wrote a patch to validate that the
TLI on xlog page header matches ThisTimeLineID during recovery, and
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 mailing
On Mon, Mar 7, 2011 at 6:30 PM, Simon Riggs 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 submitted is
>
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, 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 max_wal_sen
On Mon, Mar 7, 2011 at 6:20 PM, Simon Riggs wrote:
> On Mon, 2011-03-07 at 17:27 +0900, Fujii Masao wrote:
>> On Mon, Mar 7, 2011 at 7:51 AM, Simon Riggs wrote:
>
>> And,, I found one bug ;) You seem to have wrongly removed the check
>> of max_wal_senders in SyncRepWaitForLSN. This can make the
>
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.
Bu
On Sun, Mar 6, 2011 at 18:14, Magnus Hagander 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 the old serve
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. I
On Mon, Mar 7, 2011 at 5:27 PM, Fujii Masao wrote:
> On Mon, Mar 7, 2011 at 7:51 AM, Simon Riggs wrote:
>> Efficient transaction-controlled synchronous replication.
>> If a standby is broadcasting reply messages and we have named
>> one or more standbys in synchronous_standby_names then allow
>>
91 matches
Mail list logo