[HACKERS] GSoC 2011 - Mentors? Projects?

[Selena Deckelmann]

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 seeded with last year's todo lists and information. We need to
add project ideas for students to it.

The wiki pages for 2008 and 2010 are available, including links to the
original student proposals:

http://wiki.postgresql.org/wiki/GSoC_2010
http://wiki.postgresql.org/wiki/GSoC_2008

Thanks!
-selena

-- 
http://chesnok.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Parallel make problem with git master

[Tom Lane]

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 tries to run both concurrently.  Whereupon you get all
> sorts of fun failures.  I'm not sure if there is any cure that's not
> worse than the disease.

BTW, how many people here have read "Recursive Make Considered Harmful"?

http://aegis.sourceforge.net/auug97.pdf

Because what we're presently doing looks mighty similar to what he's
saying doesn't work and can't be made to work.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,

[Fujii Masao]

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?

I didn't include this fix in the patch because I prefer FATAL to
NOTICE for that.
NOTICE doesn't stop recovery. So we might be unable to notice such a NOTICE
message and stop the recovery before it's too late, i.e., the recovery has
completed at the undesirable point. So I think that emitting FATAL is safer.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum

[Greg Stark]

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, which should protect from a race condition where two
>> vacuums could run on the table one after another, in a way where the
>> later vacuum runs with an OldestXmin calculated before the first vacuum.
>>
>> Hmm, fiddling with vacuum_defer_cleanup_age on the fly could cause that,
>> though. You don't do that, do you?
>
> No.
>
> I've updated the patch to collect db and schema and added Merlins patch as
> well and run it for a while. The attached log is all the debug messages
> for pg_statistic page 333 from one database. I've also attached the two
> most recent page images for that particular page, the last digits in the
> filename are the hour and minute of when the page was saved.


Well from that log you definitely have OldestXmin going backwards. And
not by a little bit either. at 6:33 it set the all_visible flag and
then at 7:01 it was almost 1.3 million transactions earlier. In fact
to precisely the same value that was in use for a transaction at 1:38.
That seems like a bit of a coincidence though it's not repeated
earlier.

It also seems odd that it happens only with this one block of this one table.

What does SHOW ALL show for the current settings in effect? And what
was process 23896, are there any other log messages from it? When did
it start?


-- 
greg

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Parallel make problem with git master

[Tom Lane]

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/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 tries to run both concurrently.  Whereupon you get all
sorts of fun failures.  I'm not sure if there is any cure that's not
worse than the disease.

FWIW, doing a parallel "make all" works perfectly reliably for me.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] ModifyTable EXPLAIN Node

[David E. Wheeler]

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 format?
> 
> It's already there in 9.0 --- I just added the relation-name property.
> But since you ask:
> 
> regression=# explain (format xml) update int8_tbl set q1 = q1+1;
> QUERY PLAN  
> -
> http://www.postgresql.org/2009/explain";>   +
> +
>  +
>   ModifyTable   +
>   Update+

Oh, just new values for the Node-Type and Operation elements. That's okay, 
then. I thought it was a new  element. Great, nothing for me to 
change.

And thanks for sending this to me, much appreciated.

Best,

David



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] ModifyTable EXPLAIN Node

[Tom Lane]

"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 the relation-name property.
But since you ask:

regression=# explain (format xml) update int8_tbl set q1 = q1+1;
 QUERY PLAN  
-
 http://www.postgresql.org/2009/explain";>   +
 +
  +
   ModifyTable   +
   Update+
   int8_tbl  +
   int8_tbl  +
   0.00+
   1.06+
   5 +
   22  +
 +
  +
   Seq Scan  +
   Member+
   int8_tbl  +
   int8_tbl  +
   0.00+
   1.06+
   5 +
   22  +
 +
+
 +
+
 
(1 row)


regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Theory of operation of collation patch

[Tom Lane]

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 represents a sort order, right? To define a sort order you
> need a collation and so the path key is the natural place to put it.

Only if the expression-to-be-sorted does not already fully specify the
collation, which so far as I can tell (either from the code or your
description above) it does.  I think that the explicit representation
of collation as part of the PathKey node is unnecessary, inefficient,
and bug-inducing --- the latter because it promotes fuzzy thinking about
where the collation information is coming from.  (And this isn't just
hypothetical: IMO the bugs I exhibited upthread are *directly* due to
fuzzy thinking about what defines an index's sort order.)

Or, to put it another way: the properties that define a sort order are
the sort comparison operator, the collation, the ASC/DESC bit, and the
NULLS FIRST/LAST bit.  Given the way that the SQL committee has
constructed the language, the operator and the two flag bits are
attached to the ORDER BY clause, but the collation is a property of the
expression-to-be-sorted.  If we fail to preserve that distinction in the
internal representation, we're just creating problems for ourselves.

I'm willing to take a pass at fixing this code during the alpha cycle,
but I want to be sure I understand it correctly first.  So, if there's
a hole in my thinking, please point it out.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum

[daveg]

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 another vacuum runs with an older OldestXmin, and determines 
> that there's a tuple on the page with an xmin that is not yet visible to 
> everyone, hence it thinks that the flag should not have been set yet.
> 
> 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, which should protect from a race condition where two 
> vacuums could run on the table one after another, in a way where the 
> later vacuum runs with an OldestXmin calculated before the first vacuum.
> 
> Hmm, fiddling with vacuum_defer_cleanup_age on the fly could cause that, 
> though. You don't do that, do you?
 
No.

I've updated the patch to collect db and schema and added Merlins patch as
well and run it for a while. The attached log is all the debug messages
for pg_statistic page 333 from one database. I've also attached the two
most recent page images for that particular page, the last digits in the
filename are the hour and minute of when the page was saved.

What else can I be doing to help figure this out?

Thanks

-dg

-- 
David Gould   da...@sonic.net  510 536 1443510 282 0869
If simplicity worked, the world would be overrun with insects.
2011-03-05 00:50:03.238 PST  13304  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 337186202)
2011-03-05 21:55:00.004 PST  10702  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 341342282)
2011-03-05 23:28:06.368 PST  16660  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 342000646)
2011-03-06 05:24:03.461 PST  12850  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 343420345)
2011-03-06 06:23:40.174 PST  21650  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 343773970)
2011-03-06 07:50:49.921 PST  3847  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 344373260)
2011-03-06 09:11:35.662 PST  10820  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 344660206)
2011-03-07 01:23:57.124 PST  14121  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 347873961)
2011-03-07 01:25:01.129 PST  14266  WARNING:  PD_ALL_VISIBLE flag was 
incorrectly set in relation "c57.pg_catalog.pg_statistic" page 333 via 
OldestXmin (OldestXmin 347186993)
2011-03-07 01:26:01.143 PST  14356  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 347879220)
2011-03-07 01:27:01.158 PST  14456  WARNING:  PD_ALL_VISIBLE flag was 
incorrectly set in relation "c57.pg_catalog.pg_statistic" page 333 via 
OldestXmin (OldestXmin 347186993)
2011-03-07 01:33:05.353 PST  15108  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 347705144)
2011-03-07 01:38:09.298 PST  15869  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 347705144)
2011-03-07 01:51:17.622 PST  18829  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 348042728)
2011-03-07 02:24:41.994 PST  22594  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 348116608)
2011-03-07 06:33:47.460 PST  18384  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 349004767)
2011-03-07 07:01:51.400 PST  23896  WARNING:  PD_ALL_VISIBLE flag was 
incorrectly set in relation "c57.pg_catalog.pg_statistic" page 333 via 
OldestXmin (OldestXmin 347705144)
2011-03-07 10:23:31.416 PST  10654  WARNING:  debugging: setting PD_ALL_VISIBLE 
in relation "c57.pg_catalog.pg_statistic" on page 333 (OldestXmin 349660381)


pageimage_c57_pg_catalog_pg_statistic_333.0127
Description: Binary data


pageimage_c57_pg_catalog_pg_statistic_333.0701
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Devrim GÜNDÜZ]

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 won't be
able to spend time on packaging.
-- 
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz


signature.asc
Description: This is a digitally signed message part

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

[Robert Haas]

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 ship alpha4 and call this one
>> good.  If the patch makes it, great; if not, oh well.  We can't keep
>> letting this drag out.
>
> Go for it.
>
> We might add the traceback patch afterwards, but it's not ready at the
> moment.

OK, then I propose we tag and cut the tarball on Wednesday morning,
say around 9am Eastern.

Objections?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Peter Eisentraut]

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, great; if not, oh well.  We can't keep
> letting this drag out.

Go for it.

We might add the traceback patch afterwards, but it's not ready at the
moment.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pl/python tracebacks

[Peter Eisentraut]

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 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
> >> test case.
> 
> > So this in fact are three separate things, tracebacks, fix for
> > plpy.Fatal and a one-line fix for reporting errors in Python iterators,
> > that as I noticed has a side effect of changing the SQLCODE being raised
> > :( I think I'll just respin the tracebacks patch as 3 separate ones,
> > coming right up.
> 
> Respun as three separate patches. Sorry for the confusion. BTW: looks
> like plpy.Fatal behaviour has been broken for quite some time now.

Committed 1 and 2.

Your traceback implementation in PLy_elog is now using two errdetail
calls in one ereport call, which doesn't work (first one wins).  Please
reconsider that.  Also, the comment still talks about the traceback
going into detail.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Parallel make problem with git master

[Jeff Davis]

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 Davis


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] ModifyTable EXPLAIN Node

[David E . Wheeler]

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-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Theory of operation of collation patch

[Martijn van Oosterhout]

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 using indcollation to identify
> the sort order of an index.  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() must necessarily have the same collation
> property.  Tracking the collation as a separate property of a pathkey
> is thus a useless activity.  If this conclusion isn't correct, please
> explain why not.

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.

A pathkey represents a sort order, right? To define a sort order you
need a collation and so the path key is the natural place to put it.
Two path keys that differ only by the collation are *not* compatable,
but obviously can be converted by a sort node.

After the plan phase, the collation will be ignored in 99% of the
executer, except for operators like =, < and > that need to look at it.

Have a nice day,
-- 
Martijn van Oosterhout  http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first. 
>   - Charles de Gaulle


signature.asc
Description: Digital signature

Re: [HACKERS] [DOCS] Column-level trigger doc typo fix

[Tom Lane]

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 really go on to say... "where event can be one of...", like
>> EXPLAIN and COPY do, shouldn't it?  Otherwise it's pretty hard to tell
>> what you should put there without looking up the main docs.

> Yes, absolutely.  In fact that's what I was looking for when I first
> visited that page.

Applied both of these changes along with a bit of markup cleanup.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Robert Haas]

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 it, great; if not, oh well.  We can't keep letting
>> this drag out.
>
> Oh, I agree, all around.  I just didn't want there to be a
> misunderstanding.

Agreed, and I appreciate the correction.  I mis-remembered the history
of that patch; yeah for the audit log.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Kevin Grittner]

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 drag out.
 
Oh, I agree, all around.  I just didn't want there to be a
misunderstanding.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Robert Haas]

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 nothing particularly special about that patch,
>> other than that the author chose to move it back from Returned
>> with Feedback to some other status.
>
> I don't see it having been in Returned with Feedback.  The reviewer
> moved it to Ready for Committer, committers raised issues and moved
> it to Waiting for Author, and the author submitted a new patch and
> moved it back to Ready for Committer.

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, great; if not, oh well.  We can't keep
letting this drag out.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Kevin Grittner]

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 that the author chose to move it back from Returned
> with Feedback to some other status.
 
I don't see it having been in Returned with Feedback.  The reviewer
moved it to Ready for Committer, committers raised issues and moved
it to Waiting for Author, and the author submitted a new patch and
moved it back to Ready for Committer.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Re: [COMMITTERS] pgsql: If recovery_target_timeline is set to 'latest' and standby mode

[Simon Riggs]

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 TLI change if another standby server is promoted to master. Before this,
> you had to restart the standby server to make it notice the new timeline.
> 
> This patch only scans the archive for TLI changes, it won't follow a TLI
> change in streaming replication. That is much needed too, but it would be a
> much bigger patch than I dare to sneak in this late in the release cycle.
> 
> There was discussion on improving the sanity checking of the WAL segments so
> that the system would notice more reliably if the new timeline isn't an
> ancestor of the current one, but that is not included in this patch.

This appears to rely on the existence of an archive, which isn't always
there. That isn't documented nor checked for that I can see.

If the idea is to support downstream standbys via file based replication
it should really say that. Shame it doesn't support streaming only.

There's also a comment in the code about something the admin needs to
make sure doesn't happen. That needs to be in the docs also.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Robert Haas]

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 deciding what we are going to do with
> the plpython traceback patch.
>
> Other than that, I think we're pretty close.

AFAIK, there's nothing particularly special about that patch, other
than that the author chose to move it back from Returned with Feedback
to some other status.  I think we should just pick a time to wrap some
time in the next day or two, and it either makes it or it doesn't.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Tom Lane]

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 patch.

Other than that, I think we're pretty close.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Sync rep doc corrections

[David Fetter]

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 rightly put the responsibility of
> > documenting changes on the person or people patching them in.
> 
> You're in the minority on this one.

It happens, but I keep speaking up anyhow.  Minority status isn't
always permanent. :)

Cheers,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Sync rep doc corrections

[Robert Haas]

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 people patching them in.

You're in the minority on this one.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: If recovery_target_timeline is set to 'latest' and standby mode

[Magnus Hagander]

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 new timelines, while waiting for new
>>> WAL
>>> segments to arrive. This allows you to set up a standby server that
>>> follows
>>> the TLI change if another standby server is promoted to master. Before
>>> this,
>>> you had to restart the standby server to make it notice the new timeline.
>>
>> Can we make recovery_target_timeline='latest' the default when we are
>> in standby mode?  That would suddenly make it a lot easier to "repoint
>
>> a slave" after a switchover...
>
> Hmm, seems reasonable. 'latest' is what you usually want, at least in
> standby mode. Though it would be strange to have a different default
> depending on the value of another setting. Maybe we should change the
> default regardless of standby_mode?

Seems like a much narrower usecase in ordinary recovery mode, but we
could definitely change both..


> Wë́'d need a magic value to mean the current default behavior, to recover to
> the current timeline. 'current'?

I didn't realize we didn't already have that. In principle, i think we
should *always* be able to specify in a config file whatever comes out
as a default. There should be no magic behavior that cannot be
explicitly specified.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: If recovery_target_timeline is set to 'latest' and standby mode

[Heikki Linnakangas]

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 set up a standby server that follows
the TLI change if another standby server is promoted to master. Before this,
you had to restart the standby server to make it notice the new timeline.


Can we make recovery_target_timeline='latest' the default when we are
in standby mode?  That would suddenly make it a lot easier to "repoint

> a slave" after a switchover...

Hmm, seems reasonable. 'latest' is what you usually want, at least in 
standby mode. Though it would be strange to have a different default 
depending on the value of another setting. Maybe we should change the 
default regardless of standby_mode?


Wë́'d need a magic value to mean the current default behavior, to recover 
to the current timeline. 'current'?


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Re: [COMMITTERS] pgsql: If recovery_target_timeline is set to 'latest' and standby mode

[Magnus Hagander]

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 TLI change if another standby server is promoted to master. Before this,
> you had to restart the standby server to make it notice the new timeline.

Can we make recovery_target_timeline='latest' the default when we are
in standby mode? That would suddenly make it a lot easier to "repoint
a slave" after a switchover...

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: How should the primary behave when the sync standby goes away? Re: [HACKERS] Sync Rep v17

[Simon Riggs]

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:

> >>
> >> Also I think that the waiting backends should be released as soon as the
> >> last synchronous standby switches to asynchronous mode. Since there is
> >> no standby which is planning to reconnect, obviously they no longer need
> >> to wait.
> >
> > I've not done this, but we could.
> >
> > It can't run in a WALSender, so this code would need to live in either
> > WALWriter or BgWriter.
> 
> I would have thought that the last WALSender to switch to async would
> have been responsible for doing this at that time.  Why doesn't that
> work?

The main time we get extended waits is when there are no WALsenders.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Tracking latest timeline in standby mode

[Heikki Linnakangas]

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 child of 
database system timeline %u",

We should check whether recoveryTargetTLI is a member of newExpectedTLIs
instead of expectedTLIs?


Thanks, fixed.


+   /* Switch target */

+   recoveryTargetTLI = newtarget;
+   expectedTLIs = newExpectedTLIs;

 Before "expectedTLIs = newExpectedTLIs", we should call
 list_free_deep(expectedTLIs)?

It's an integer list so list_free(expectedTLIs) is enough, and I doubt that 
leakage will ever be a problem in practice, but in principle you're right.


True. But I think that it's good habit to fix a leakage no matter how
small it's.


Ah, thanks for the reminder.

Added that and committed.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Sync rep doc corrections

[Josh Berkus]

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 them in.

The -hackers list has enough traffic as it is.

And if we don't have docs contributors who aren't code contributors (and
I think we do), then that's a problem to be solved, not casually accepted.

-- 
  -- Josh Berkus
 PostgreSQL Experts Inc.
 http://www.pgexperts.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Sync rep doc corrections

[David Fetter]

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.  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 -hackers, but on the other hand the
> > > traffic on -hackers is so high already that I'm not happy about
> > > folding another list with a reasonably distinct charter into it.
> > 
> > Searching for doc changes/suggestions is helped tremendously by
> > having them in a separate list.  -1 for merging it with -hackers.
> > I have no opinion on the -hackers crossposting issue as it doesn't
> > affect me at all.
> 
> Definitely don't merge. Crossposting, I think, should be reserved
> for significant factual changes to docs of features that are in
> current development, like ... syncrep. :-) Basically, keep docs work
> on docs, but cross-post to hackers when a cross-check is needed.
> Don't routinely crosspost, lest that train hackers to ignore the
> docs posts. After all, we insist that developers of patches submit
> docs: correct documentation is a valid concern for all developers. 
> 
> Ross P.S. Everyone is aware of the settings for majordomo, so you
> only get one of any crosspost, right?

It's not that simple.  If it were, I wouldn't have been asking for
this in the first place.

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 them in.

Cheers,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Sync rep doc corrections

[Ross J. Reedstrom]

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 factual issues involved in a docs change ought to be
> > vetted on -hackers, but on the other hand the traffic on -hackers is so
> > high already that I'm not happy about folding another list with a
> > reasonably distinct charter into it.
> 
> Searching for doc changes/suggestions is helped tremendously by having
> them in a separate list.  -1 for merging it with -hackers.  I have no
> opinion on the -hackers crossposting issue as it doesn't affect me at
> all.

Definitely don't merge. Crossposting, I think, should be reserved for
significant factual changes to docs of features that are in current
development, like ... syncrep. :-) Basically, keep docs work on docs,
but cross-post to hackers when a cross-check is needed. Don't routinely
crosspost, lest that train hackers to ignore the docs posts. After all,
we insist that developers of patches submit docs: correct documentation
is a valid concern for all developers. 

Ross
P.S. Everyone is aware of the settings for majordomo, so you only get
one of any crosspost, right?
-- 
Ross Reedstrom, Ph.D. reeds...@rice.edu
Systems Engineer & Admin, Research Scientistphone: 713-348-6166
Connexions  http://cnx.orgfax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E  F888 D3AE 810E 88F0 BEDE

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Josh Berkus]

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 there...
> 
> 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?

Peter?

-- 
  -- Josh Berkus
 PostgreSQL Experts Inc.
 http://www.pgexperts.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Robert Haas]

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 talk about the subject of this
thread, when are we going to cut alpha4?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Sync rep doc corrections

[Alvaro Herrera]

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 -hackers, but on the other hand the traffic on -hackers is so
> high already that I'm not happy about folding another list with a
> reasonably distinct charter into it.

Searching for doc changes/suggestions is helped tremendously by having
them in a separate list.  -1 for merging it with -hackers.  I have no
opinion on the -hackers crossposting issue as it doesn't affect me at
all.

-- 
Álvaro Herrera 
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Andres Freund]

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.  IMO, that *is* a default, just a badly implemented one.
> > 
> > We have touched upon this point several times during the development of
> > this patch.  The main problem is that you need to distinguish no
> > collation from the default collation, so they can't both be OID zero.
> 
> Fair enough, but throwing in fmgr_info_collation(DEFAULT_COLLATION)
> anytime we have a problem seems to me to introduce the exact same issue.
Its comparatively easier to grep for when you notice something itchy.

> Who's to say that that's really the appropriate value to use?
I actually am quite doubtfull that thats the correct value for patternsel and 
the other places I added it in the patch. I think that should that be C. On 
the other hand its not likely to be that influential.

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...

Andres

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Column-level trigger doc typo fix

[Thom Brown]

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 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 (one
>>> defined using the UPDATE OF
>>> column_name syntax) will fire
>>> when...
>>>
>>> I think it would also be worth modifying this page so that the
>>> definition of event is in the syntax synopsis.
>>>
>>> Right now:
>>>
>>> rhaas=# \h create trigger
>>> Command:     CREATE TRIGGER
>>> Description: define a new trigger
>>> Syntax:
>>> CREATE [ CONSTRAINT ] TRIGGER name { BEFORE | AFTER | INSTEAD OF } {
>>> event [ OR ... ] }
>>>    ON table
>>>    [ FROM referenced_table_name ]
>>>    { NOT DEFERRABLE | [ DEFERRABLE ] { INITIALLY IMMEDIATE |
>>> INITIALLY DEFERRED } }
>>>    [ FOR [ EACH ] { ROW | STATEMENT } ]
>>>    [ WHEN ( condition ) ]
>>>    EXECUTE PROCEDURE function_name ( arguments )
>>>
>>> It should really go on to say... "where event can be one of...", like
>>> EXPLAIN and COPY do, shouldn't it?  Otherwise it's pretty hard to tell
>>> what you should put there without looking up the main docs.
>>
>> Yes, absolutely.  In fact that's what I was looking for when I first
>> visited that page.
>>
>> So it would look like this:
>>
>> where event can be one of:
>>
>>    INSERT [ OF column ]
>>    UPDATE [ OF column ]
>>    DELETE [ OF column ]
>>    TRUNCATE
>
> Well, the existing documentation says that OF column is only allowed for 
> UPDATE.

*copy/paste fail* Yes, utterly meaningless for INSERT/DELETE.

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Sync rep doc corrections

[Tom Lane]

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 better still, only posted, to -hackers.

I'm not certain that David's convenience should be the exclusive
consideration when deciding what goes where ;-)

> I cross-posted as it's a docs change, but I want to invite the
> critical eye of those who dev'd it.  Okay, so doc patches should go
> exclusively to the -hackers list?  Last time I recall some disparity
> surrounding what I should be doing.

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 -hackers, but on the other hand the traffic on -hackers is so
high already that I'm not happy about folding another list with a
reasonably distinct charter into it.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: How should the primary behave when the sync standby goes away? Re: [HACKERS] Sync Rep v17

[Robert Haas]

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
>> >> disconnects. Doing so would break the whole reason for having sync rep
>> >> in the first place. What we do is allow a potential standby to takeover
>> >> the role of sync standby, if one is available. Or the failing standby
>> >> can reconnect and then release waiters.
>> >
>> > If there is potential standby when synchronous standby has gone, I agree
>> > that it's not good idea to release the waiting backends soon. In this case,
>> > those backends should wait for next synchronous standby.
>> >
>> > On the other hand, if there is no potential standby, I think that the 
>> > waiting
>> > backends should not wait for the timeout and should wake up as soon as
>> > synchronous standby has gone. Otherwise, those backends suspend for
>> > a long time (i.e., until the timeout expires), which would decrease the
>> > high-availability, I'm afraid.
>> >
>> > Keeping those backends waiting for the failed standby to reconnect is an
>> > idea. But this looks like the behavior for "allow_standalone_primary = 
>> > off".
>> > If allow_standalone_primary = on, it looks more natural to make the
>> > primary work alone without waiting the timeout.
>>
>> Also I think that the waiting backends should be released as soon as the
>> last synchronous standby switches to asynchronous mode. Since there is
>> no standby which is planning to reconnect, obviously they no longer need
>> to wait.
>
> I've not done this, but we could.
>
> It can't run in a WALSender, so this code would need to live in either
> WALWriter or BgWriter.

I would have thought that the last WALSender to switch to async would
have been responsible for doing this at that time.  Why doesn't that
work?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Column-level trigger doc typo fix

[Robert Haas]

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 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...
>>
>> I think it would also be worth modifying this page so that the
>> definition of event is in the syntax synopsis.
>>
>> Right now:
>>
>> rhaas=# \h create trigger
>> Command:     CREATE TRIGGER
>> Description: define a new trigger
>> Syntax:
>> CREATE [ CONSTRAINT ] TRIGGER name { BEFORE | AFTER | INSTEAD OF } {
>> event [ OR ... ] }
>>    ON table
>>    [ FROM referenced_table_name ]
>>    { NOT DEFERRABLE | [ DEFERRABLE ] { INITIALLY IMMEDIATE |
>> INITIALLY DEFERRED } }
>>    [ FOR [ EACH ] { ROW | STATEMENT } ]
>>    [ WHEN ( condition ) ]
>>    EXECUTE PROCEDURE function_name ( arguments )
>>
>> It should really go on to say... "where event can be one of...", like
>> EXPLAIN and COPY do, shouldn't it?  Otherwise it's pretty hard to tell
>> what you should put there without looking up the main docs.
>
> Yes, absolutely.  In fact that's what I was looking for when I first
> visited that page.
>
> So it would look like this:
>
> where event can be one of:
>
>    INSERT [ OF column ]
>    UPDATE [ OF column ]
>    DELETE [ OF column ]
>    TRUNCATE

Well, the existing documentation says that OF column is only allowed for UPDATE.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Sync rep doc corrections

[Robert Haas]

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 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.
>>> >
>>> > I don't think it's necessary to cross-post these emails
>>>
>>> I've received conflicting information in the past on this, but I'm
>>> assuming you're suggesting to send this just to the -docs list in
>>> future?
>>
>> 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 better still, only posted, to -hackers.
>
> I cross-posted as it's a docs change, but I want to invite the
> critical eye of those who dev'd it.  Okay, so doc patches should go
> exclusively to the -hackers list?  Last time I recall some disparity
> surrounding what I should be doing.

I'm not sure we have any unanimity on what the "right" thing to do
here is, and I guess I don't *really* care, except that I mildly
dislike cross-posting as a general principle.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Sync rep doc corrections

[David Fetter]

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 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.
> >> >
> >> > I don't think it's necessary to cross-post these emails
> >>
> >> I've received conflicting information in the past on this, but I'm
> >> assuming you're suggesting to send this just to the -docs list in
> >> future?
> >
> > 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 better still, only posted, to -hackers.
> 
> I cross-posted as it's a docs change, but I want to invite the
> critical eye of those who dev'd it.  Okay, so doc patches should go
> exclusively to the -hackers list?  Last time I recall some disparity
> surrounding what I should be doing.

"Should" is a word I won't get into on this subject.  I was expressing
and justifying a personal preference :)

Cheers,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Sync rep doc corrections

[Thom Brown]

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 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.
>> >
>> > I don't think it's necessary to cross-post these emails
>>
>> I've received conflicting information in the past on this, but I'm
>> assuming you're suggesting to send this just to the -docs list in
>> future?
>
> 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 better still, only posted, to -hackers.

I cross-posted as it's a docs change, but I want to invite the
critical eye of those who dev'd it.  Okay, so doc patches should go
exclusively to the -hackers list?  Last time I recall some disparity
surrounding what I should be doing.

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Column-level trigger doc typo fix

[Thom Brown]

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 text would help clarify: A column-specific trigger (one
> defined using the UPDATE OF
> column_name syntax) will fire
> when...
>
> I think it would also be worth modifying this page so that the
> definition of event is in the syntax synopsis.
>
> Right now:
>
> rhaas=# \h create trigger
> Command:     CREATE TRIGGER
> Description: define a new trigger
> Syntax:
> CREATE [ CONSTRAINT ] TRIGGER name { BEFORE | AFTER | INSTEAD OF } {
> event [ OR ... ] }
>    ON table
>    [ FROM referenced_table_name ]
>    { NOT DEFERRABLE | [ DEFERRABLE ] { INITIALLY IMMEDIATE |
> INITIALLY DEFERRED } }
>    [ FOR [ EACH ] { ROW | STATEMENT } ]
>    [ WHEN ( condition ) ]
>    EXECUTE PROCEDURE function_name ( arguments )
>
> It should really go on to say... "where event can be one of...", like
> EXPLAIN and COPY do, shouldn't it?  Otherwise it's pretty hard to tell
> what you should put there without looking up the main docs.

Yes, absolutely.  In fact that's what I was looking for when I first
visited that page.

So it would look like this:

where event can be one of:

INSERT [ OF column ]
UPDATE [ OF column ]
DELETE [ OF column ]
TRUNCATE

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Theory of operation of collation patch

[Tom Lane]

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() must necessarily have the same collation
>> property.  Tracking the collation as a separate property of a pathkey
>> is thus a useless activity.  If this conclusion isn't correct, please
>> explain why not.

> I'll have to check into these details, but here is a test case that
> shows that it's doing something with the collation of an index:

[ pokes at it some more... ]  It looks like indcollation is acting as a
substitute for including a CollateClause in the index key expression,
which doesn't seem like a particularly good tradeoff considering all the
overhead you must introduce into the default case.

But more to the point, your examples do *not* work for me.  I can
reproduce both failing to use an index that should work, and selecting
an index that doesn't work:

d1u=# CREATE TABLE test (a text);
CREATE TABLE
d1u=# CREATE INDEX test_1 ON test (a);
CREATE INDEX
d1u=# CREATE INDEX test_d ON test (a COLLATE "de_DE");
CREATE INDEX
d1u=# CREATE INDEX test_e ON test (a COLLATE "es_ES");
CREATE INDEX
d1u=# CREATE INDEX test_f ON test (a COLLATE "fr_FR");
CREATE INDEX
d1u=# CREATE INDEX test_fz ON test ((a||'z') COLLATE "fr_FR");
CREATE INDEX
d1u=# explain select * from test order by a;
   QUERY PLAN   

 Index Scan using test_f on test  (cost=0.00..63.90 rows=1310 width=32)
(1 row)

d1u=# explain select * from test order by a collate "fr_FR";
  QUERY PLAN   
---
 Sort  (cost=90.93..94.20 rows=1310 width=32)
   Sort Key: ((a COLLATE "fr_FR"))
   ->  Seq Scan on test  (cost=0.00..23.10 rows=1310 width=32)
(3 rows)

d1u=# set enable_seqscan TO 0;
SET
d1u=# explain select * from test order by a collate "fr_FR";
QUERY PLAN  
  
--
 Sort  (cost=190.93..194.20 rows=1310 width=32)
   Sort Key: ((a COLLATE "fr_FR"))
   ->  Seq Scan on test  (cost=100.00..123.10 rows=1310 
width=32)
(3 rows)

d1u=# explain select * from test order by a||'z';   
   QUERY PLAN
-
 Index Scan using test_fz on test  (cost=0.00..67.18 rows=1310 width=32)
(1 row)

(This is in a database with encoding utf8 and lc_collate = c)

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Sync rep doc corrections

[David Fetter]

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 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.
> >
> > I don't think it's necessary to cross-post these emails
> 
> I've received conflicting information in the past on this, but I'm
> assuming you're suggesting to send this just to the -docs list in
> future?

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 better still, only posted, to -hackers.

Cheers,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Tom Lane]

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 touched upon this point several times during the development of
> this patch.  The main problem is that you need to distinguish no
> collation from the default collation, so they can't both be OID zero.

Fair enough, but throwing in fmgr_info_collation(DEFAULT_COLLATION)
anytime we have a problem seems to me to introduce the exact same issue.
Who's to say that that's really the appropriate value to use?

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Mark deprecated operators as such in their comments?

[Dimitri Fontaine]

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
pressing.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Peter Eisentraut]

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 times during the development of
this patch.  The main problem is that you need to distinguish no
collation from the default collation, so they can't both be OID zero.
Another problem is that if you assume OID zero means default, finding
bugs in the expression tree analysis would be really hard.  It would be
like saying, oh, we have type OID zero, let's make it text and proceed.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Sync rep doc corrections

[Thom Brown]

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 the main documentation also needed some fixes,
>> so those have been included in this new patch.
>
> I don't think it's necessary to cross-post these emails

I've received conflicting information in the past on this, but I'm
assuming you're suggesting to send this just to the -docs list in
future?

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Theory of operation of collation patch

[Peter Eisentraut]

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 indcollation to identify
> the sort order of an index.  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() must necessarily have the same collation
> property.  Tracking the collation as a separate property of a pathkey
> is thus a useless activity.  If this conclusion isn't correct, please
> explain why not.

I'll have to check into these details, but here is a test case that
shows that it's doing something with the collation of an index:

DROP TABLE test;
CREATE TABLE test (a text);
CREATE INDEX test_1 ON test (a);
CREATE INDEX test_d ON test (a COLLATE "de_DE");
CREATE INDEX test_e ON test (a COLLATE "es_ES");
CREATE INDEX test_f ON test (a COLLATE "fr_FR");
SET enable_seqscan TO off;
SET enable_bitmapscan TO off;
EXPLAIN SELECT * FROM test WHERE a > 'foo';
  QUERY PLAN   
---
 Index Scan using test_1 on test  (cost=0.00..51.90 rows=437 width=32)
   Index Cond: (a > 'foo'::text)
(2 rows)

EXPLAIN SELECT * FROM test WHERE a > 'foo' COLLATE "de_DE";
  QUERY PLAN   
---
 Index Scan using test_d on test  (cost=0.00..51.90 rows=437 width=32)
   Index Cond: (a > ('foo'::text COLLATE "de_DE"))
(2 rows)

EXPLAIN SELECT * FROM test WHERE a > 'foo' COLLATE "es_ES";
  QUERY PLAN   
---
 Index Scan using test_e on test  (cost=0.00..51.90 rows=437 width=32)
   Index Cond: (a > ('foo'::text COLLATE "es_ES"))
(2 rows)

EXPLAIN SELECT * FROM test WHERE a > 'foo' COLLATE "fr_FR";
  QUERY PLAN   
---
 Index Scan using test_f on test  (cost=0.00..51.90 rows=437 width=32)
   Index Cond: (a > ('foo'::text COLLATE "fr_FR"))
(2 rows)



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Column-level trigger doc typo fix

[Robert Haas]

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 (one
defined using the UPDATE OF
column_name syntax) will fire
when...

I think it would also be worth modifying this page so that the
definition of event is in the syntax synopsis.

Right now:

rhaas=# \h create trigger
Command: CREATE TRIGGER
Description: define a new trigger
Syntax:
CREATE [ CONSTRAINT ] TRIGGER name { BEFORE | AFTER | INSTEAD OF } {
event [ OR ... ] }
ON table
[ FROM referenced_table_name ]
{ NOT DEFERRABLE | [ DEFERRABLE ] { INITIALLY IMMEDIATE |
INITIALLY DEFERRED } }
[ FOR [ EACH ] { ROW | STATEMENT } ]
[ WHEN ( condition ) ]
EXECUTE PROCEDURE function_name ( arguments )

It should really go on to say... "where event can be one of...", like
EXPLAIN and COPY do, shouldn't it?  Otherwise it's pretty hard to tell
what you should put there without looking up the main docs.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [DOCS] Sync rep doc corrections

[Robert Haas]

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,
> so those have been included in this new patch.

I don't think it's necessary to cross-post these emails

I've applied all of this but the first hunk, which I don't believe to
be correct.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Mark deprecated operators as such in their comments?

[Tom Lane]

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 an SQL file
>> so that we didn't have to deal with commutator and negator oids and
>> all that, that would save a lot of pain.

> You seem to want to have a completely new way to describe contents of
> pg_proc.h and pg_operator.h, from which the DATA and DESCR lines could
> be generated.  Perhaps that's a worthy goal, not sure.  I'm not sure it
> can be done with SQL though.

We've been around on that before.  It'd probably be possible to reduce
pg_proc.h and pg_operator.h to some minimal set of functions/operators
needed to support the indexes on those catalogs, and then fill in the
rest using a higher-level notation; analogous to the difference in the
way we treat the bootstrap catalogs versus the rest of the catalogs.
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
function or operator; nor have I seen many errors in patches that
I think would have been avoided by a higher-level notation.  (If memory
serves, by far the most common mistake in submissions against pg_proc.h
is failure to think carefully about the function's volatility marking.
A higher-level notation would help that not a whit.)

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Mark deprecated operators as such in their comments?

[Alvaro Herrera]

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 have to deal with commutator and negator oids and
> all that, that would save a lot of pain.

You seem to want to have a completely new way to describe contents of
pg_proc.h and pg_operator.h, from which the DATA and DESCR lines could
be generated.  Perhaps that's a worthy goal, not sure.  I'm not sure it
can be done with SQL though.

-- 
Álvaro Herrera 
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Theory of operation of collation patch

[Tom Lane]

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 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() must necessarily have the same collation
property.  Tracking the collation as a separate property of a pathkey
is thus a useless activity.  If this conclusion isn't correct, please
explain why not.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Alvaro Herrera]

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 master, no acknowledged transaction is lost. I find 
> > that definition a bit confusing.
> 
> Maybe it is - I agree the difference might be small. I'm just trying to 
> make sure we don't use a term that could mislead reasonable people about 
> what we're providing. If we're satisfied that we aren't, then keep it.

I think these terms are used inconsistenly enough across the industry
that what would make the most sense would be to use the common term and
document accurately what we mean by it, rather than relying on some
external entity's definition, which could change (like wikipedia's).

-- 
Álvaro Herrera 
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Andrew Dunstan]

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 are not. And
that's hardly unreasonable. Here for example is what wikipedia says
:

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. Write is not considered complete until
acknowledgement by both local and remote storage.


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 master, no acknowledged transaction is lost. I find 
that definition a bit confusing.


Maybe it is - I agree the difference might be small. I'm just trying to 
make sure we don't use a term that could mislead reasonable people about 
what we're providing. If we're satisfied that we aren't, then keep it.


cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Heikki Linnakangas]

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 example is what wikipedia says
:

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. Write is not considered complete until
acknowledgement by both local and remote storage.


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 master, no acknowledged transaction is lost. I find 
that definition a bit confusing.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Kevin Grittner]

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 storage.
 
OK, *if* we want to live up to this definition, we don't seem to
have that part covered.  Of course, since the connection is broken
during the hypothetical crash, it seems hard to acknowledge it on
recovery, and short of 2PC I don't see how we roll it back.  About
the best we could do is somehow have explicit logging of the
disposition of unacknowledged commit requests upon recovery, and
consider logging of success to be "acknowledgement".  Is this
logging provided by other databases with "synchronous replication"
features?
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Aidan Van Dyk]

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 seen by somoene else even) until you get the
acknowledgement of the commit.

That's already a posibility with a single machine databse.  Adding
replication in it, just increases the perioud that window exists for
(and the possiblity of things making something "Bad" hit that window).

a.


-- 
Aidan Van Dyk                                             Create like a god,
ai...@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Andrew Dunstan]

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 transaction is not successfully
replicated for any reason, including crash, it is rolled back in the master
too. That would require 2PC.


My worry is that the stricter definition is what many people will expect,
without reading the fine print.

They they are either already hosed or already using 2PC.





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 example is what wikipedia says 
:


   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. Write is not considered complete until
   acknowledgement by both local and remote storage.


cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Kevin Grittner]

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 most people would expect full 2PC behavior from
something called "synchronous replication" -- I agree that a
guarantee that a successful commit means it has been written to the
master and at least one replica is sufficient.
 
> you could argue for an even stricter definition, requiring
> atomicity so that if a transaction is not successfully replicated
> for any reason, including crash, it is rolled back in the master
> too. That would require 2PC.
 
I'm not sure you can say it breaks atomicity; if proper procedures
are followed on recovery, all servers will either reflect the
transaction or not, right?  It seems to me what you lose is the
ability to know whether a transaction for which commit was requested
and for which there had not yet been a reply at the time of failure
is going to be in your recovered database.  In this particular
regard it is no different from a standalone or async replication,
and you would need 2PC with a proper transaction manager to do
better.
 
Getting that additional guarantee may not be worth the performance
hit for most people.  We train our users to save (or make) a paper
copy of whet they were entering if a crash occurs (which, of course,
is very rare, but does happen), so they can check the state of it on
recovery.  It is, of course, important for the programmers to use
appropriate database transaction boundaries so that the database is
always in a state with internal integrity and from which users can
determine the state and proceed on their own.
 
I think we should document the issues, of course.
 
If there is really a demand for a stricter "sync rep" feature, I
think it must be built on top of 2PC and some particular transaction
manager, which seems a though that makes it pgfoundry material.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Aidan Van Dyk]

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
>> replicated for any reason, including crash, it is rolled back in the master
>> too. That would require 2PC.
>>
>
> My worry is that the stricter definition is what many people will expect,
> without reading the fine print.

They they are either already hosed or already using 2PC.

a.
-- 
Aidan Van Dyk                                             Create like a god,
ai...@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Andrew Dunstan]

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 better guarantees than a 2PC setup?


The guarantee we have now with synchronous_replication=on is that when 
the server acknowledges a commit to the client (ie. when COMMIT 
command returns), the transaction is safely flushed to disk on the 
master and at least one synchronous standby server.


What you don't get is a guarantee on what happens to transactions that 
were not acknowledged to the client. For example, 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 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 replicated for any reason, including crash, it is 
rolled back in the master too. That would require 2PC.




My worry is that the stricter definition is what many people will 
expect, without reading the fine print.


cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Heikki Linnakangas]

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 have now with synchronous_replication=on is that when 
the server acknowledges a commit to the client (ie. when COMMIT command 
returns), the transaction is safely flushed to disk on the master and at 
least one synchronous standby server.


What you don't get is a guarantee on what happens to transactions that 
were not acknowledged to the client. For example, 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 
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 replicated for any reason, including crash, it is rolled 
back in the master too. That would require 2PC.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Sync Rep v19

[Simon Riggs]

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 pgbench -c 10 -M prepared -T 300 test
> dbsize was -s 50, 1Gbit Ethernet
> 
> 1 async standby
> tps = 2475.285931 (excluding connections establishing)
> 
> 2 async standbys
> tps = 2333.670561 (excluding connections establishing)
> 
> 1 sync standby
> tps = 1277.082753 (excluding connections establishing)
> 
> 1 sync, 1 async standby
> tps = 1273.317386 (excluding connections establishing)
> 
> Hard for me to not revert to superlatives right now! :-)

That looks like good news, thanks.

It shows that sync rep is "fairly fast", but it also shows clearly why
you'd want to mix sync and async replication within an application.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Andrew Dunstan]

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 agreed NOT to call it 
"synchronous

replication".


The discussion on the thread was that its not sync rep unless we have
the strictest guarantees. We have the strictest guarantees, so it
qualifies as sync rep.


What do you mean by "strictes guarantees"?

I don't see allow_synchronous_standby setting in the committed patch. 
I presume you didn't make allow_synchronous_standby=off the default 
behavior. Also, the documentation that describes this as two-safe 
replication and claims that "the only possibility that data can be 
lost is if both the primary and the standby suffer crashes at the same 
time" needs big fat caveats to clarify that this doesn't actually 
achieve those guarantees.


Please change the name.



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?


cheers

andrew


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Sync Rep v19

[Yeb Havinga]

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 Ethernet

1 async standby
tps = 2475.285931 (excluding connections establishing)

2 async standbys
tps = 2333.670561 (excluding connections establishing)

1 sync standby
tps = 1277.082753 (excluding connections establishing)

1 sync, 1 async standby
tps = 1273.317386 (excluding connections establishing)

Hard for me to not revert to superlatives right now! :-)

regards,
Yeb Havinga


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pl/python tracebacks

[Jan Urbański]

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 make it.
>>
>> Um, what?  I didn't find any details about this in this thread, nor a
>> test case.

> So this in fact are three separate things, tracebacks, fix for
> plpy.Fatal and a one-line fix for reporting errors in Python iterators,
> that as I noticed has a side effect of changing the SQLCODE being raised
> :( I think I'll just respin the tracebacks patch as 3 separate ones,
> coming right up.

Respun as three separate patches. Sorry for the confusion. BTW: looks
like plpy.Fatal behaviour has been broken for quite some time now.

Jan
>From 06ac95d62de1aaf40dec020ac2892f20c3879db6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jan=20Urba=C5=84ski?= 
Date: Mon, 7 Mar 2011 14:16:25 +0100
Subject: [PATCH 3/3] Add Python tracebacks to error messages.

For errors originating from Python exceptions add the traceback to the
message context. While at it rework the Python to Postgres error
passing mechanism a bit. A future optimisation might be not splitting
the procedure source each time a traceback is generated, but for now
it's probably not the most important scenario to optimise for.
---
 src/pl/plpython/expected/plpython_do.out   |5 +-
 src/pl/plpython/expected/plpython_error.out|  193 +-
 src/pl/plpython/expected/plpython_error_0.out  |  193 +-
 .../plpython/expected/plpython_subtransaction.out  |   55 +++-
 .../expected/plpython_subtransaction_0.out |   30 ++-
 .../expected/plpython_subtransaction_5.out |   30 ++-
 src/pl/plpython/expected/plpython_test.out |5 +-
 src/pl/plpython/expected/plpython_types.out|5 +-
 src/pl/plpython/expected/plpython_types_3.out  |5 +-
 src/pl/plpython/plpython.c |  287 
 src/pl/plpython/sql/plpython_error.sql |  105 +++
 11 files changed, 821 insertions(+), 92 deletions(-)

diff --git a/src/pl/plpython/expected/plpython_do.out b/src/pl/plpython/expected/plpython_do.out
index a21b088..41b7a51 100644
--- a/src/pl/plpython/expected/plpython_do.out
+++ b/src/pl/plpython/expected/plpython_do.out
@@ -3,4 +3,7 @@ NOTICE:  This is plpythonu.
 CONTEXT:  PL/Python anonymous code block
 DO $$ nonsense $$ LANGUAGE plpythonu;
 ERROR:  NameError: global name 'nonsense' is not defined
-CONTEXT:  PL/Python anonymous code block
+CONTEXT:  Traceback (most recent call last):
+  PL/Python anonymous code block, line 1, in 
+nonsense 
+PL/Python anonymous code block
diff --git a/src/pl/plpython/expected/plpython_error.out b/src/pl/plpython/expected/plpython_error.out
index e38ea60..0b7d87f 100644
--- a/src/pl/plpython/expected/plpython_error.out
+++ b/src/pl/plpython/expected/plpython_error.out
@@ -36,7 +36,10 @@ ERROR:  spiexceptions.SyntaxError: syntax error at or near "syntax"
 LINE 1: syntax error
 ^
 QUERY:  syntax error
-CONTEXT:  PL/Python function "sql_syntax_error"
+CONTEXT:  Traceback (most recent call last):
+  PL/Python function "sql_syntax_error", line 1, in 
+plpy.execute("syntax error")
+PL/Python function "sql_syntax_error"
 /* check the handling of uncaught python exceptions
  */
 CREATE FUNCTION exception_index_invalid(text) RETURNS text
@@ -45,7 +48,10 @@ CREATE FUNCTION exception_index_invalid(text) RETURNS text
 	LANGUAGE plpythonu;
 SELECT exception_index_invalid('test');
 ERROR:  IndexError: list index out of range
-CONTEXT:  PL/Python function "exception_index_invalid"
+CONTEXT:  Traceback (most recent call last):
+  PL/Python function "exception_index_invalid", line 1, in 
+return args[1]
+PL/Python function "exception_index_invalid"
 /* check handling of nested exceptions
  */
 CREATE FUNCTION exception_index_invalid_nested() RETURNS text
@@ -59,7 +65,10 @@ LINE 1: SELECT test5('foo')
^
 HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
 QUERY:  SELECT test5('foo')
-CONTEXT:  PL/Python function "exception_index_invalid_nested"
+CONTEXT:  Traceback (most recent call last):
+  PL/Python function "exception_index_invalid_nested", line 1, in 
+rv = plpy.execute("SELECT test5('foo')")
+PL/Python function "exception_index_invalid_nested"
 /* a typo
  */
 CREATE FUNCTION invalid_type_uncaught(a text) RETURNS text
@@ -75,7 +84,10 @@ return None
 	LANGUAGE plpythonu;
 SELECT invalid_type_uncaught('rick');
 ERROR:  spiexceptions.UndefinedObject: type "test" does not exist
-CONTEXT:  PL/Python function "invalid_type_uncaught"
+CONTEXT:  Traceback (most recent call last):
+  PL/Python function "invalid_type_uncaught", line 3, in 
+SD["plan"] = plpy.prepare(q, [ "test" ])
+PL/Python function "invalid_type_uncaught"
 /* for what i

Re: [HACKERS] pl/python tracebacks

[Jan Urbański]

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 any details about this in this thread, nor a
> test case.

Yes, my fault for sneaking it here without more introduction than this
comment several messages upthread:

"""
While testing I noticed that this broke "raise plpy.Fatal()" behaviour -
it was no longer terminating the backend but just raising an error.
That's fixed in this version. This patch also fixes a place where
ereport is being used to report Python errors, which leads to losing the
original error. Incidentally, this is exactly the issue that made
diagnosing this bug:

http://postgresql.1045698.n5.nabble.com/Bug-in-plpython-s-Python-Generators-td3230402.html

so difficult.
"""

So this in fact are three separate things, tracebacks, fix for
plpy.Fatal and a one-line fix for reporting errors in Python iterators,
that as I noticed has a side effect of changing the SQLCODE being raised
:( I think I'll just respin the tracebacks patch as 3 separate ones,
coming right up.

BTW, it's hard to test if raising plpy.Fatal actually causes a FATAL
elog, because that would terminate the backend running the tests, and I
though pg_regress treats this as an unconditional error (or am I mistaken?).

Jan

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pl/python tracebacks

[Jan Urbański]

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 script part of the regression tests you added?

No, the regression tests are a bit different. Maybe this script should
be part of them as well?

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pl/python tracebacks

[Peter Eisentraut]

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
test case.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pl/python tracebacks

[Peter Eisentraut]

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?


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Tracking latest timeline in standby mode

[Fujii Masao]

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 server track the TLI change that failover causes.
>
> +1 for doing this!

+1

Comments:

+   if (!list_member_int(expectedTLIs,
+(int) 
recoveryTargetTLI))
+   ereport(LOG,
+   (errmsg("new timeline %u is not a child 
of database system timeline %u",

We should check whether recoveryTargetTLI is a member of newExpectedTLIs
instead of expectedTLIs?

>+   /* Switch target */
>
>+   recoveryTargetTLI = newtarget;
>+   expectedTLIs = newExpectedTLIs;
>
> Before "expectedTLIs = newExpectedTLIs", we should call
> list_free_deep(expectedTLIs)?
>
> It's an integer list so list_free(expectedTLIs) is enough, and I doubt that 
> leakage will ever be a problem in practice, but in principle you're right.

True. But I think that it's good habit to fix a leakage no matter how
small it's.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Tracking latest timeline in standby mode

[Magnus Hagander]

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 validate that
 the
 TLI on xlog page header matches ThisTimeLineID during recovery, and
 noticed
 quickly in testing that it doesn't catch all the cases I'd like to catch
 :-(.
>>>
>>> The patch added into the CF hasn't solved this problem yet. Are you
>>> planning
>>> to solve it in 9.1? Or are you planning to just commit the patch for 9.1,
>>> and
>>> postpone the issue to 9.2 or later? I'm OK either way. Of course, the
>>> former
>>> is quite better, though.
>>>
>>> Anyway, you have to add the documentation about this feature.
>>
>> This patch is erroneously marked Needs Review in the CommitFest
>> application, but I think really it's Waiting on Author, and has been
>> for a long time.  I'm thinking we should push this out to 9.2.
>
> 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 server track the TLI change that failover causes.

+1 for doing this!

(haven't had time to look through the actual patch, so obviously don't
do it if it's broken..)

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Column-level trigger doc typo fix

[Thom Brown]

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 list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Fujii Masao]

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
>> users who set synchronous_replication to wait for commit, which
>> then provides strict data integrity guarantees. Design avoids
>> sending and receiving transaction state information so minimises
>> bookkeeping overheads. We synchronize with the highest priority
>> standby that is connected and ready to synchronize. Other standbys
>> can be defined to takeover in case of standby failure.
>>
>> This version has very strict behaviour; more relaxed options
>> may be added at a later date.
>
> Pretty cool! I'd appreciate very much your efforts and contributions.

Here are another comments:

if ((wrote_xlog && XactSyncCommit) || forceSyncCommit || nrels > 0 ||
SyncRepRequested())

Whenever synchronous_replication is TRUE, we disable synchronous_commit.
But, before disabling that, we should check also max_wal_senders and
synchronous_standby_names? Otherwise, synchronous_commit can
be disabled unexpectedly even in non replication case.

-   /* Let the master know that we received some data. */
-   XLogWalRcvSendReply();
-   XLogWalRcvSendHSFeedback();

This change completely eliminates the difference between write_location
and flush_location in pg_stat_replication. If this change is reasoable, we
should get rid of write_location from pg_stat_replication since it's useless.
If not, this change should be reverted. I'm not sure whether monitoring
the difference between write and flush locations is useful. But I guess that
someone thought so and that code was added.

+   /*
+* Current location of the head of the queue. All waiters should have
+* a waitLSN that follows this value, or they are currently being woken
+* to remove themselves from the queue. Protected by SyncRepLock.
+*/
+   XLogRecPtr  lsn;

The comment ", or they are currently being woken to remove themselves
from the queue" is no longer required because the proc is currently removed
by walsender.

I found some typos. The attached patch fixes them.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


sync_rep_typo_fix_v1.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Sync rep doc corrections

[Thom Brown]

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 Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935


sync_rep_doc_fix.v2.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Tracking latest timeline in standby mode

[Heikki Linnakangas]

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 noticed
quickly in testing that it doesn't catch all the cases I'd like to catch
:-(.


The patch added into the CF hasn't solved this problem yet. Are you planning
to solve it in 9.1? Or are you planning to just commit the patch for 9.1, and
postpone the issue to 9.2 or later? I'm OK either way. Of course, the former
is quite better, though.

Anyway, you have to add the documentation about this feature.


This patch is erroneously marked Needs Review in the CommitFest
application, but I think really it's Waiting on Author, and has been
for a long time.  I'm thinking we should push this out to 9.2.


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 server track the TLI change that failover causes.


I wanted to add those extra safeguards, and to support streaming 
replication in addition to restoring from archive, but that's 9.2 
material. However, the original patch 
(http://archives.postgresql.org/message-id/4cc83a50.7070...@enterprisedb.com) 
was non-intrusive and no-one objected. While the extra safeguards 
would've been nice, this patch doesn't make the situation any worse than 
it is already when you restart the standby.


Here's an updated version of that patch, now with a little bit of 
documentation. Barring objections, I'll commit this.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index e30552f..3c98ae6 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -660,7 +660,10 @@ protocol to make nodes agree on a serializable transactional order.
 command file recovery.conf in the standby's cluster data
 directory, and turn on standby_mode. Set
 restore_command to a simple command to copy files from
-the WAL archive.
+the WAL archive. If you plan to have multiple standby servers for high
+availability purposes, set recovery_target_timeline to
+latest, to make the standby server follow the timeline change
+that occurs at failover to another standby.

 

diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml/recovery-config.sgml
index 602fbe2..e9e95ac 100644
--- a/doc/src/sgml/recovery-config.sgml
+++ b/doc/src/sgml/recovery-config.sgml
@@ -240,7 +240,9 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows

 Specifies recovering into a particular timeline.  The default is
 to recover along the same timeline that was current when the
-base backup was taken.  You only need to set this parameter
+base backup was taken. Setting this to latest recovers
+to the latest timeline found in the archive, which is useful in
+a standby server. Other than that you only need to set this parameter
 in complex re-recovery situations, where you need to return to
 a state that itself was reached after a point-in-time recovery.
 See  for discussion.
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index b4eb4ac..d1f69cf 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -214,6 +214,8 @@ static bool recoveryStopAfter;
  *
  * recoveryTargetTLI: the desired timeline that we want to end in.
  *
+ * recoveryTargetIsLatest: was the requested target timeline 'latest'
+ *
  * expectedTLIs: an integer list of recoveryTargetTLI and the TLIs of
  * its known parents, newest first (so recoveryTargetTLI is always the
  * first list member).	Only these TLIs are expected to be seen in the WAL
@@ -227,6 +229,7 @@ static bool recoveryStopAfter;
  * to decrease.
  */
 static TimeLineID recoveryTargetTLI;
+static bool recoveryTargetIsLatest = false;
 static List *expectedTLIs;
 static TimeLineID curFileTLI;
 
@@ -637,6 +640,7 @@ static bool ValidXLOGHeader(XLogPageHeader hdr, int emode);
 static XLogRecord *ReadCheckpointRecord(XLogRecPtr RecPtr, int whichChkpt);
 static List *readTimeLineHistory(TimeLineID targetTLI);
 static bool existsTimeLineHistory(TimeLineID probeTLI);
+static bool rescanLatestTimeLine(void);
 static TimeLineID findNewestTimeLine(TimeLineID startTLI);
 static void writeTimeLineHistory(TimeLineID newTLI, TimeLineID parentTLI,
 	 TimeLineID endTLI,
@@ -4254,6 +4258,61 @@ existsTimeLineHistory(TimeLineID probeTLI)
 }
 
 /*
+ * Scan for new timelines that might have appeared in the archive since we
+ * started recovery.
+ *
+ * If there is any, the function changes recovery targ

[HACKERS] Sync rep doc corrections

[Thom Brown]

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 list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Fujii Masao]

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
>> committed,empty synchronous_standby_names and max_wal_senders = 0
>> settings is no longer unsafe.
>
> Ah, on reload. I plugged the gap only at startup.
>
> I'll fix by changing assign_synchronous_standby_names(), not by changing
> lots of other parts of code and making runtime check each COMMIT.

I don't think that the check of local variable for each COMMIT wastes the
cycle so much. Anyway, the reload of the configuration file should not
cause the server to end unexpectedly. IOW, GUC assign hook should
use GUC_complaint_elevel instead of FATAL, in ereport. The attached
patch fixes that, and includes two typo fixes.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


use_guc_complaint_elevel_v1.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Composite Index Structure

[Heikki Linnakangas]

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

 Rtree root
 / \
  non-leaf ...
   /\  \
  leaf   ..   leaf
| |
  Btree rootBtree root
   / \  /   \
 non-leaf
   /
  leaf

How to create this kind of structure?


A multi-column index is quite similar to that, you should get the same 
performance characteristics. The leading column will determine the 
primary order of the tree, and for rows that have the same value in the 
leading column, the second column will determine the order among them.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Simon Riggs]

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_senders = 0
> settings is no longer unsafe.

Ah, on reload. I plugged the gap only at startup.

I'll fix by changing assign_synchronous_standby_names(), not by changing
lots of other parts of code and making runtime check each COMMIT.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Fujii Masao]

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
>> backend wait for replication even if max_wal_senders = 0. I could produce
>> this problematic situation in my machine. The attached patch fixes this 
>> problem.
>
> There may be a bug, but that's not the fix.
>
> I spotted that issue myself in testing. I put in a protection to stop
> setting synchronous_standby_names if max_wal_senders is zero, with error
> message.
>
> Are you saying the committed version doesn't trigger that ERROR?

I changed synchronous_standby_names after startup and reloaded the
configuration file. So I didn't encounter such an error message.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Composite Index Structure

[Nick Raj]

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.
But i want linkage between location and time tree. I want for each location
i have Btree like

Rtree root
/ \
 non-leaf ...
  /\  \
 leaf   ..   leaf
   | |
 Btree rootBtree root
  / \  /   \
non-leaf
  /
 leaf

How to create this kind of structure?
What are the modification is required for this?

Thanks
Raj
On Mon, Mar 7, 2011 at 12:33 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:

> On 07.03.2011 08:07, Nick Raj wrote:
>
>> I want to construct an "Composite Index Structure" i.e. a combination of
>> gist and btree.
>> What i am thinking is that first creating a Rtree structure that is
>> pointing
>> to another Btree structure.
>> For example, Suppose i want to find vehicles between 2 to 4 pm on
>> 14/2/2011
>> on X road.
>>
>> I am thinking of creating rtree structure for road network and then btree
>> for time. For reaching X road i use Rtree, and from there btree begin i.e.
>> leaf node of rtree contains the pointer to root node of btree ( in this
>> way
>> i have all time belonging to X road)
>>
>> My question is that how to implement this composite index structure in
>> postgres?
>>
>> Let us suppose, if i create mygist index, then i have to write my own
>> operator class?
>> or
>> can i use gist index as it is and btree tree as it is. I mean their
>> operator
>> class and their gist methods but how to establish linkage between them?
>>
>
> It sounds like a use case for a multi-column gist index. See btree_gist
> contrib module. You'll want something like:
>
> CREATE INDEX ... USING gist (coordinates, time)
>
> --
>  Heikki Linnakangas
>  EnterpriseDB   http://www.enterprisedb.com
>

Re: [HACKERS] Downtime for commitfest.postgresql.org

[Magnus Hagander]

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 server still responding but in read-only mode.
> Thus, if you get a read-only error and it doesn't go away in 5
> minutes, you may want to give your DNS resolver a kick..
>
> We'll post more information here as the work progresses.

This migration is now complete. If you get a read-only error, it's
because your DNS hasn't updated. You can temporarily hardcode it in
your hosts file (but as usual, only do this temporarily). The new IP
is 67.192.147.117.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Heikki Linnakangas]

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 see it described in README-SSI and for the
guc default_transaction_deferrable, but I think it needs to be
documented on that ref page as well.. (in fact, the guc docs refer to
the reference page, which doesn't have more info)


I think the attached covers it.


Thanks, applied.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

[Fujii Masao]

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
>> users who set synchronous_replication to wait for commit, which
>> then provides strict data integrity guarantees. Design avoids
>> sending and receiving transaction state information so minimises
>> bookkeeping overheads. We synchronize with the highest priority
>> standby that is connected and ready to synchronize. Other standbys
>> can be defined to takeover in case of standby failure.
>>
>> This version has very strict behaviour; more relaxed options
>> may be added at a later date.
>
> Pretty cool! I'd appreciate very much your efforts and contributions.
>
> And,, I found one bug ;) You seem to have wrongly removed the check
> of max_wal_senders in SyncRepWaitForLSN. This can make the
> backend wait for replication even if max_wal_senders = 0. I could produce
> this problematic situation in my machine. The attached patch fixes this 
> problem.

if (strlen(SyncRepStandbyNames) > 0 && max_wal_senders == 0)
ereport(ERROR,
(errmsg("Synchronous replication requires WAL 
streaming
(max_wal_senders > 0)")));

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_senders = 0
settings is no longer unsafe.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers