Re: [HACKERS] max_standby_delay considered harmful

[Simon Riggs]

On Tue, 2010-05-11 at 14:01 +0900, Fujii Masao wrote:
 On Mon, May 10, 2010 at 3:27 PM, Simon Riggs si...@2ndquadrant.com wrote:
  I already explained that killing the startup process first is a bad idea
  for many reasons when shutdown was discussed. Can't remember who added
  the new standby shutdown code recently, but it sounds like their design
  was pretty poor if it didn't include shutting down properly with HS. I
  hope they fix the bug they have introduced. HS was never designed to
  work that way, so there is no flaw there; it certainly worked when
  committed.
 
 New smart shutdown during recovery doesn't kill the startup process until
 all of the read only backends have gone away. So it works fine with HS.

Yes, I thought some more about what Robert said. HS works identically to
normal running in this regard, so there's no hint of a bug or design
flaw on that for either of us to worry about.

-- 
 Simon Riggs   www.2ndQuadrant.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] HS starting snapshot corrections

[Simon Riggs]

Tom pointed out two errors that could effect the HS startup code, which
is fairly subtle.

Attached patch is small with these changes
* adds new section comment as posted to hackers earlier
* adds comments to other functions
* makes minor corrections to a few existing comments
* fixes the two bugs observed by Tom so that snapshotOldestActiveXid no
longer exists, xids are tracked as soon as (standbyState =
STANDBY_INITIALIZED) and ProcArrayApplyRecoveryInfo() is substantially
re-written with comments at every stage
* fixes an old bug that set xmax incorrectly in initial snapshot, though
would normally have been corrected soon afterwards as recovery continues
* fixes a simple bug introduced in recent sorted knownassignedxids patch
that would give incorrect snapshots
* minor refactoring of xact_redo_abort() and
ExpireTreeKnownAssignedTransactionIds()
* new debug message for when in STANDBY_SNAPSHOT_PENDING and we fail to
move to STANDBY_SNAPSHOT_READY

I have avoided adding a new WAL record as I mentioned was required
earlier, deciding that it wasn't any easier to understand that way.

I will apply tomorrow in the absence of review objections.

-- 
 Simon Riggs   www.2ndQuadrant.com
*** a/src/backend/access/transam/xact.c
--- b/src/backend/access/transam/xact.c
***
*** 4378,4384  xact_redo_commit(xl_xact_commit *xlrec, TransactionId xid, XLogRecPtr lsn)
  		LWLockRelease(XidGenLock);
  	}
  
! 	if (!InHotStandby)
  	{
  		/*
  		 * Mark the transaction committed in pg_clog.
--- 4378,4384 
  		LWLockRelease(XidGenLock);
  	}
  
! 	if (standbyState == STANDBY_DISABLED)
  	{
  		/*
  		 * Mark the transaction committed in pg_clog.
***
*** 4412,4423  xact_redo_commit(xl_xact_commit *xlrec, TransactionId xid, XLogRecPtr lsn)
  		/*
  		 * We must mark clog before we update the ProcArray.
  		 */
! 		ExpireTreeKnownAssignedTransactionIds(xid, xlrec-nsubxacts, sub_xids);
  
  		/*
  		 * Send any cache invalidations attached to the commit. We must
  		 * maintain the same order of invalidation then release locks as
! 		 * occurs in	 .
  		 */
  		ProcessCommittedInvalidationMessages(inval_msgs, xlrec-nmsgs,
    XactCompletionRelcacheInitFileInval(xlrec),
--- 4412,4423 
  		/*
  		 * We must mark clog before we update the ProcArray.
  		 */
! 		ExpireTreeKnownAssignedTransactionIds(xid, xlrec-nsubxacts, sub_xids, max_xid);
  
  		/*
  		 * Send any cache invalidations attached to the commit. We must
  		 * maintain the same order of invalidation then release locks as
! 		 * occurs in CommitTransaction().
  		 */
  		ProcessCommittedInvalidationMessages(inval_msgs, xlrec-nmsgs,
    XactCompletionRelcacheInitFileInval(xlrec),
***
*** 4499,4505  xact_redo_abort(xl_xact_abort *xlrec, TransactionId xid)
  		LWLockRelease(XidGenLock);
  	}
  
! 	if (InHotStandby)
  	{
  		/*
  		 * If a transaction completion record arrives that has as-yet
--- 4499,4510 
  		LWLockRelease(XidGenLock);
  	}
  
! 	if (standbyState == STANDBY_DISABLED)
! 	{
! 		/* Mark the transaction aborted in pg_clog, no need for async stuff */
! 		TransactionIdAbortTree(xid, xlrec-nsubxacts, sub_xids);
! 	}
! 	else
  	{
  		/*
  		 * If a transaction completion record arrives that has as-yet
***
*** 4511,4527  xact_redo_abort(xl_xact_abort *xlrec, TransactionId xid)
  		 * already. Leave it in.
  		 */
  		RecordKnownAssignedTransactionIds(max_xid);
- 	}
  
! 	/* Mark the transaction aborted in pg_clog, no need for async stuff */
! 	TransactionIdAbortTree(xid, xlrec-nsubxacts, sub_xids);
  
- 	if (InHotStandby)
- 	{
  		/*
! 		 * We must mark clog before we update the ProcArray.
  		 */
! 		ExpireTreeKnownAssignedTransactionIds(xid, xlrec-nsubxacts, sub_xids);
  
  		/*
  		 * There are no flat files that need updating, nor invalidation
--- 4516,4529 
  		 * already. Leave it in.
  		 */
  		RecordKnownAssignedTransactionIds(max_xid);
  
! 		/* Mark the transaction aborted in pg_clog, no need for async stuff */
! 		TransactionIdAbortTree(xid, xlrec-nsubxacts, sub_xids);
  
  		/*
! 		 * We must update the ProcArray after we have marked clog.
  		 */
! 		ExpireTreeKnownAssignedTransactionIds(xid, xlrec-nsubxacts, sub_xids, max_xid);
  
  		/*
  		 * There are no flat files that need updating, nor invalidation
***
*** 4596,4602  xact_redo(XLogRecPtr lsn, XLogRecord *record)
  	{
  		xl_xact_assignment *xlrec = (xl_xact_assignment *) XLogRecGetData(record);
  
! 		if (InHotStandby)
  			ProcArrayApplyXidAssignment(xlrec-xtop,
  		xlrec-nsubxacts, xlrec-xsub);
  	}
--- 4598,4604 
  	{
  		xl_xact_assignment *xlrec = (xl_xact_assignment *) XLogRecGetData(record);
  
! 		if (standbyState = STANDBY_INITIALIZED)
  			ProcArrayApplyXidAssignment(xlrec-xtop,
  		xlrec-nsubxacts, xlrec-xsub);
  	}
*** a/src/backend/access/transam/xlog.c
--- b/src/backend/access/transam/xlog.c
***
*** 5995,6000  

[HACKERS] Bug-fix and new feature of pg_lesslog is released

[Koichi Suzuki]

It is an announcement that long-waited bug-fix of pg_lesslog is now
released.   This includes the following.

1. Error in calculation of GiST-related WAL record length was fixed.
2. pg_compresslog now has an option to print WAL segment analysis.
3. New test script is added which analyzes what WAL record was
generated and if all the recovery was done successfully.

2 and 3 are added to ensure the tools run correctly.

Because 8.4 has additional WAL records, I made release material
separate for each PG version.   You may visit the project page
http://pgfoundry.org/frs/?group_id=1000310
to download materials.

I acknowledge PG hackers who gave valuable comments/advices.
Especially Oleg Bartunov, Teodor Sigaev and Alvaro Herrera gave very
helpful information how to generate specific type of WAL records.

As Bruce suggested, this can be included in PostgreSQL test suits and
could be included in contrib module if it is ported to PostgreSQL 9.1.

Best Regards;
--
Koichi Suzuki

# pg_lesslog is a project to compress large WAL segments when they're
stored and restore then for recovery.

-- 
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] max_standby_delay considered harmful

[Robert Haas]

On Wed, May 12, 2010 at 2:50 AM, Simon Riggs si...@2ndquadrant.com wrote:
 On Tue, 2010-05-11 at 14:01 +0900, Fujii Masao wrote:
 On Mon, May 10, 2010 at 3:27 PM, Simon Riggs si...@2ndquadrant.com wrote:
  I already explained that killing the startup process first is a bad idea
  for many reasons when shutdown was discussed. Can't remember who added
  the new standby shutdown code recently, but it sounds like their design
  was pretty poor if it didn't include shutting down properly with HS. I
  hope they fix the bug they have introduced. HS was never designed to
  work that way, so there is no flaw there; it certainly worked when
  committed.

 New smart shutdown during recovery doesn't kill the startup process until
 all of the read only backends have gone away. So it works fine with HS.

 Yes, I thought some more about what Robert said. HS works identically to
 normal running in this regard, so there's no hint of a bug or design
 flaw on that for either of us to worry about.

I'm not sure what to make of this.  Sometimes not shutting down
doesn't sound like a feature to me.

http://archives.postgresql.org/pgsql-hackers/2010-05/msg00098.php
http://archives.postgresql.org/pgsql-hackers/2010-05/msg00103.php

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres 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] max_standby_delay considered harmful

[Simon Riggs]

On Wed, 2010-05-12 at 07:10 -0400, Robert Haas wrote:

 I'm not sure what to make of this.  Sometimes not shutting down
 doesn't sound like a feature to me.

It acts exactly the same in recovery as in normal running. It is not a
special feature of recovery at all, bug or otherwise.

You may think its a strange feature generally and I would agree. I would
welcome you changing that in 9.1+, as long as your change works in both
recovery and normal running.

-- 
 Simon Riggs   www.2ndQuadrant.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] max_standby_delay considered harmful

[Greg Stark]

On Wed, May 12, 2010 at 12:26 PM, Simon Riggs si...@2ndquadrant.com wrote:
 On Wed, 2010-05-12 at 07:10 -0400, Robert Haas wrote:

 I'm not sure what to make of this.  Sometimes not shutting down
 doesn't sound like a feature to me.

 It acts exactly the same in recovery as in normal running. It is not a
 special feature of recovery at all, bug or otherwise.

I admit I've sometimes been surprised that smart shutdown was waiting
when I didn't expect it to.

It would be good to give the shutdown more feedback. If it explicitly
shows Waiting for n sessions with active transactions to commit or
Waiting for n sessions to disconnect then the user would at least
understand why it was waiting and what would be necessary to get it to
continue.


-- 
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] max_standby_delay considered harmful

[Robert Haas]

On Wed, May 12, 2010 at 7:26 AM, Simon Riggs si...@2ndquadrant.com wrote:
 On Wed, 2010-05-12 at 07:10 -0400, Robert Haas wrote:

 I'm not sure what to make of this.  Sometimes not shutting down
 doesn't sound like a feature to me.

 It acts exactly the same in recovery as in normal running. It is not a
 special feature of recovery at all, bug or otherwise.

Simon, that doesn't make any sense.  We are talking about a backend
getting stuck forever on an exclusive lock that is held by the startup
process and which will never be released (for example, because the
master has shut down and no more WAL can be obtained for replay).  The
startup process does not hold locks in normal operation.

There are other things we might want to change about the shutdown
behavior (for example, switching from smart to fast automatically
after N seconds) which could apply to both the primary and the standby
and which might also be workarounds for this problem, but this
particular issue is specific to Hot Standby mode and pretending
otherwise is just sticking your head in the sand.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres 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] max_standby_delay considered harmful

[Simon Riggs]

On Wed, 2010-05-12 at 08:52 -0400, Robert Haas wrote:
 On Wed, May 12, 2010 at 7:26 AM, Simon Riggs si...@2ndquadrant.com wrote:
  On Wed, 2010-05-12 at 07:10 -0400, Robert Haas wrote:
 
  I'm not sure what to make of this.  Sometimes not shutting down
  doesn't sound like a feature to me.
 
  It acts exactly the same in recovery as in normal running. It is not a
  special feature of recovery at all, bug or otherwise.
 
 Simon, that doesn't make any sense.  We are talking about a backend
 getting stuck forever on an exclusive lock that is held by the startup
 process and which will never be released (for example, because the
 master has shut down and no more WAL can be obtained for replay).  The
 startup process does not hold locks in normal operation.

When I test it, startup process holding a lock does not prevent shutdown
of a standby. 

I'd be happy to see your test case showing a bug exists and that the
behaviour differs from normal running.

-- 
 Simon Riggs   www.2ndQuadrant.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] max_standby_delay considered harmful

[Stefan Kaltenbrunner]

Simon Riggs wrote:

On Wed, 2010-05-12 at 08:52 -0400, Robert Haas wrote:

On Wed, May 12, 2010 at 7:26 AM, Simon Riggs si...@2ndquadrant.com wrote:

On Wed, 2010-05-12 at 07:10 -0400, Robert Haas wrote:


I'm not sure what to make of this.  Sometimes not shutting down
doesn't sound like a feature to me.

It acts exactly the same in recovery as in normal running. It is not a
special feature of recovery at all, bug or otherwise.

Simon, that doesn't make any sense.  We are talking about a backend
getting stuck forever on an exclusive lock that is held by the startup
process and which will never be released (for example, because the
master has shut down and no more WAL can be obtained for replay).  The
startup process does not hold locks in normal operation.


When I test it, startup process holding a lock does not prevent shutdown
of a standby. 


I'd be happy to see your test case showing a bug exists and that the
behaviour differs from normal running.


In my testing the postmaster simply does not shut down even with no 
clients connected any more once in a while - most of the time it works 
just fine but in like 1 out of 10 cases it get's stuck - my testcase (as 
detailed in the related thread) is simply doing an interval load on the 
master (pgbench -T 120  sleep 30  pgbench -T 120 - rinse and repeat 
as needed) and pgbench -S  pg_ctl restart  pgbench -S in a lop on 
the standby. once in a while the standby will simply not shut down 
(forever - not only by eceeding the default timeout of pgctl which seems 
to get triggered much more often on the standby than on the master - 
have not looked into that yet in detail)



Stefan

--
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] List traffic

[Marc G. Fournier]

On Tue, 11 May 2010, Alvaro Herrera wrote:


Excerpts from Marc G. Fournier's message of mar may 11 09:58:34 -0400 2010:


If list traffic, especially on -hackers, is getting so large, should we
look at maybe splitting it?  I could easily enough split things such that
I duplicate the subscriber list, so nobody would have to subscribe, but it
would make it easier for ppl to filter their incoming ... ?


Maybe we could create a separate list where people would send patches,
and keep patchless discussion on -hackers?

Just a thought ;-)


The thing is, it seems to me, especially now that we have such strong 
commit fests, that we should have a seperate form for 'design phase' then 
for 'reivew discusions' ... *shrug*


There may be some that are interested in what is being implemented, but 
don't really care about how it was implemented ...



Marc G. FournierHub.Org Hosting Solutions S.A.
scra...@hub.org http://www.hub.org

Yahoo:yscrappySkype: hub.orgICQ:7615664MSN:scra...@hub.org

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

[HACKERS] multibyte charater set in levenshtein function

[Alexander Korotkov]

Hackers,

The current version of levenshtein function in fuzzystrmatch contrib modulte
doesn't work properly with multibyte charater sets.

test=# select levenshtein('фыва','аыва');
 levenshtein
-
   2
(1 row)

My patch make this function works properly with multibyte charater sets.

test=# select levenshtein('фыва','аыва');
 levenshtein
-
   1
(1 row)

Also it avoids text_to_cstring call.

Regards,
Alexander Korotkov.


fuzzystrmatch.diff.gz
Description: GNU Zip compressed 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] List traffic

[Alvaro Herrera]

Excerpts from Marc G. Fournier's message of mar may 11 09:58:34 -0400 2010:

 If list traffic, especially on -hackers, is getting so large, should we 
 look at maybe splitting it?  I could easily enough split things such that 
 I duplicate the subscriber list, so nobody would have to subscribe, but it 
 would make it easier for ppl to filter their incoming ... ?

Maybe we could create a separate list where people would send patches,
and keep patchless discussion on -hackers?

Just a thought ;-)
-- 

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

[HACKERS] Query execution plan from 8.3 - 8.4

[Brendan Hill]

Getting significantly lower performance on a specific query after upgrading
from 8.3 - 8.4 (windows). I'm not expecting a quick fix from the mail
lists, but I would appreciate any indications as to where else I could look
or what tools I could employ to investigae further. Details below.

 

-Brendan

 

 

 

Upgraded Windows installation on the weekend from 8.3 to 8.4 - database
schema  indexes etc are identical, reindex, analyze and cluster all
performed yesterday. Most of the performance settings in postgres.conf were
*increased* ie. memory allocations etc an server is generally running fine.
default_statistics_target went from 10-100. 

 

The following query went from 5-10 second in 8.3 (same for master and
slave), to 45-60 seconds in 8.4 (same for master and slave):

 

SELECT Note_ID, Notes.Note_Type_ID, Note_Types.Description as
Note_Type_Description, Notes.Note_Priority_ID, Note_Priorities.Description
as Note_Priority_Description, Note_Date, Text, User_Name,
Notes.Date_Created, datediff_hh( Notes.Date_Created, GETDATE()) as Hours_Old

FROM Notes 

INNER JOIN jbAccounts ON Notes.Created_By = jbAccounts.jbAccount_ID 

LEFT OUTER JOIN Note_Types ON Notes.Note_Type_ID = Note_Types.Note_Type_ID 

LEFT OUTER JOIN Note_Priorities ON Notes.Note_Priority_ID =
Note_Priorities.Note_Priority_ID 

WHERE Notes.Person_ID IN (4315565) AND Notes.Person_ID IN (SELECT
ISNULL(Personnel.Person_ID, Businesses.Main_Person_ID) FROM Businesses LEFT
OUTER JOIN Personnel ON Businesses.Business_ID = Personnel.Business_ID WHERE
( Businesses.Admin_Office_ID IN (1, 4, 8, 5, 9, 6, 7, 2, 3, 10)))

ORDER BY Notes.Date_Created;

 

(Note - it employs sub-queries for automatic application of security,
changing this is possible but a major restructure of the software. Improving
the query execution planning should be possible as it was fine in 8.3)

 

 

 

Query planner went from:

 

Sort  (cost=4583.19..4583.27 rows=30 width=146)

  Sort Key: notes.date_created

  -  Nested Loop  (cost=0.00..4582.45 rows=30 width=146)

-  Nested Loop Left Join  (cost=0.00..4485.29 rows=30 width=145)

  -  Nested Loop Semi Join  (cost=0.00..4470.89 rows=30
width=133)

-  Nested Loop Left Join  (cost=0.00..61.15 rows=30
width=137)

  -  Index Scan using notes_person_id on notes
(cost=0.00..46.75 rows=30 width=131)

Index Cond: (person_id = 4315565)

  -  Index Scan using note_priorities_pkey on
note_priorities  (cost=0.00..0.47 rows=1 width=10)

Index Cond: (notes.note_priority_id =
note_priorities.note_priority_id)

-  Subquery Scan ANY_subquery  (cost=0.00..23735.89
rows=322 width=4)

  Filter: (ANY_subquery.isnull = 4315565)

  -  Merge Left Join  (cost=0.00..22930.02
rows=64470 width=8)

Merge Cond: (businesses.business_id =
personnel.business_id)

-  Index Scan using businesses_pkey on
businesses  (cost=0.00..5546.18 rows=64470 width=8)

  Filter: (admin_office_id = ANY
('{1,4,8,5,9,6,7,2,3,10}'::integer[]))

-  Index Scan using personnel_business_id
on personnel  (cost=0.00..781.32 rows=25907 width=8)

  -  Index Scan using note_types_pkey on note_types
(cost=0.00..0.47 rows=1 width=16)

Index Cond: (notes.note_type_id =
note_types.note_type_id)

-  Index Scan using jbaccounts_pkey on jbaccounts
(cost=0.00..3.20 rows=1 width=9)

  Index Cond: (jbaccounts.jbaccount_id = notes.created_by)

 

 

To:

 

Sort  (cost=28558.95..28560.74 rows=714 width=146)

  Sort Key: notes.date_created

  -  Nested Loop IN Join  (cost=26636.50..28525.11 rows=714 width=146)

-  Hash Left Join  (cost=337.30..2193.78 rows=714 width=150)

  Hash Cond: (notes.note_type_id = note_types.note_type_id)

  -  Hash Left Join  (cost=335.91..2188.03 rows=714
width=138)

Hash Cond: (notes.note_priority_id =
note_priorities.note_priority_id)

-  Hash Join  (cost=334.82..2183.62 rows=714
width=132)

  Hash Cond: (notes.created_by =
jbaccounts.jbaccount_id)

  -  Index Scan using notes_person_id on notes
(cost=0.00..1834.48 rows=718 width=130)

Index Cond: (person_id = 4315565)

  -  Hash  (cost=258.81..258.81 rows=6081
width=10)

-  Seq Scan on jbaccounts
(cost=0.00..258.81 rows=6081 width=10)

-  Hash  (cost=1.04..1.04 rows=4 width=10)

  -  Seq Scan on note_priorities  (cost=0.00..1.04
rows=4 width=10)

  -  Hash  (cost=1.17..1.17 rows=17 width=16)

-  Seq Scan on note_types  (cost=0.00..1.17 rows=17

Re: [HACKERS] Query execution plan from 8.3 - 8.4

[Stephen Frost]

Brendan,

* Brendan Hill (brend...@jims.net) wrote:
 Getting significantly lower performance on a specific query after upgrading
 from 8.3 - 8.4 (windows). I'm not expecting a quick fix from the mail
 lists, but I would appreciate any indications as to where else I could look
 or what tools I could employ to investigae further. Details below.

For starters, this probably should go to -perform instead of -hackers,
and it would be much more useful to have EXPLAIN ANALYZE results rather
than just EXPLAIN.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Query execution plan from 8.3 - 8.4

[Kevin Grittner]

Brendan Hill brend...@jims.net wrote:
 
 AND Notes.Person_ID IN (SELECT
 ISNULL(Personnel.Person_ID, Businesses.Main_Person_ID)
 
You might try switching this to an EXISTS test.
 
If you post on this topic again, really it should be on the -perform
list, as Stephen mentioned, and review this page for ideas on other
information (like hardware and the postgresql.conf file) which might
help people better understand the problem:
 
http://wiki.postgresql.org/wiki/SlowQueryQuestions
 
-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] max_standby_delay considered harmful

[Simon Riggs]

On Wed, 2010-05-12 at 16:03 +0200, Stefan Kaltenbrunner wrote:
 Simon Riggs wrote:
  On Wed, 2010-05-12 at 08:52 -0400, Robert Haas wrote:
  On Wed, May 12, 2010 at 7:26 AM, Simon Riggs si...@2ndquadrant.com wrote:
  On Wed, 2010-05-12 at 07:10 -0400, Robert Haas wrote:
 
  I'm not sure what to make of this.  Sometimes not shutting down
  doesn't sound like a feature to me.
  It acts exactly the same in recovery as in normal running. It is not a
  special feature of recovery at all, bug or otherwise.
  Simon, that doesn't make any sense.  We are talking about a backend
  getting stuck forever on an exclusive lock that is held by the startup
  process and which will never be released (for example, because the
  master has shut down and no more WAL can be obtained for replay).  The
  startup process does not hold locks in normal operation.
  
  When I test it, startup process holding a lock does not prevent shutdown
  of a standby. 
  
  I'd be happy to see your test case showing a bug exists and that the
  behaviour differs from normal running.
 
 In my testing the postmaster simply does not shut down even with no 
 clients connected any more once in a while - most of the time it works 
 just fine but in like 1 out of 10 cases it get's stuck - my testcase (as 
 detailed in the related thread) is simply doing an interval load on the 
 master (pgbench -T 120  sleep 30  pgbench -T 120 - rinse and repeat 
 as needed) and pgbench -S  pg_ctl restart  pgbench -S in a lop on 
 the standby. once in a while the standby will simply not shut down 
 (forever - not only by eceeding the default timeout of pgctl which seems 
 to get triggered much more often on the standby than on the master - 
 have not looked into that yet in detail)

If you could recreate that on a server in debug mode we can see what's
happening. If you can attach to the server and get a back trace that
would help. I've not seen that behaviour at all during testing and if
the issue is sporadic its not likely to help much trying to recreate
myself.

This could be an issue with SR, or an issue with the shutdown code
itself.

-- 
 Simon Riggs   www.2ndQuadrant.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] hot update doesn't work?

[Pavel Stehule]

Hello

I would to repeatably update non indexed column of temp table. I
expected cheap operation, but it isn't true.

p ostgres=# create temp table x(a int primary key, b int);
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
x_pkey for table x
CREATE TABLE
Time: 363,339 ms
postgres=# insert into x values(1,0);
INSERT 0 1
Time: 11,676 ms
postgres=# create or replace function s1() returns void as $$ begin
for i in 1..10 loop update x set b = i where a = 1; end loop;
return; end; $$ language plpgsql;
CREATE FUNCTION
Time: 113,052 ms
postgres=# select s1();
 s1


(1 row)

Time: 255223,249 ms
postgres=# select pg_total_relation_size('x');
 pg_total_relation_size

3686400
(1 row)

the size of table was significantly increased :(.

what I doing wrong?

Regards
Pavel Stehule

-- 
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] max_standby_delay considered harmful

[Simon Riggs]

On Wed, 2010-05-12 at 14:18 +0100, Simon Riggs wrote:
 On Wed, 2010-05-12 at 08:52 -0400, Robert Haas wrote:
  On Wed, May 12, 2010 at 7:26 AM, Simon Riggs si...@2ndquadrant.com wrote:
   On Wed, 2010-05-12 at 07:10 -0400, Robert Haas wrote:
  
   I'm not sure what to make of this.  Sometimes not shutting down
   doesn't sound like a feature to me.
  
   It acts exactly the same in recovery as in normal running. It is not a
   special feature of recovery at all, bug or otherwise.
  
  Simon, that doesn't make any sense.  We are talking about a backend
  getting stuck forever on an exclusive lock that is held by the startup
  process and which will never be released (for example, because the
  master has shut down and no more WAL can be obtained for replay).  The
  startup process does not hold locks in normal operation.
 
 When I test it, startup process holding a lock does not prevent shutdown
 of a standby. 
 
 I'd be happy to see your test case showing a bug exists and that the
 behaviour differs from normal running.

Let me put this differently: I accept that Stefan has reported a
problem. Neither Tom nor myself can reproduce the problem. I've re-run
Stefan's test case and restarted the server more than 400 times now
without any issue.

I re-read your post where you gave what you yourself called uninformed
speculation. There's no real polite way to say it, but yes your
speculation does appear to be uninformed, since it is incorrect. Reasons
would be not least that Stefan's tests don't actually send any locks to
the standby anyway (!), but even if they did your speculation as to the
cause is still all wrong, as explained.

There is no evidence to link this behaviour with HS, as yet, and you
should be considering the possibility the problem lies elsewhere,
especially since it could be code you committed that is at fault.

-- 
 Simon Riggs   www.2ndQuadrant.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] hot update doesn't work?

[Kevin Grittner]

Pavel Stehule pavel.steh...@gmail.com wrote:
 
 I would to repeatably update non indexed column of temp table. I
 expected cheap operation, but it isn't true.
 
You're updating the row 10 times within a single transaction.  I
don't *think* HOT will reclaim a version of a row until the
transaction which completed it is done and no other transactions can
see that version any longer.  It does raise the question, though --
couldn't a HOT update of a tuple *which was written by the same
transaction* do an update in place?  I mean, the updating
transaction doesn't need to see the old row after this, and other
transactions shouldn't see it either.
 
I suspect that somewhere in the subtransaction or referential
integrity areas there may be some issues with that, but it would be
a clever optimization if it could be pulled off.
 
-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] hot update doesn't work?

[Merlin Moncure]

On Wed, May 12, 2010 at 11:34 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
 Pavel Stehule pavel.steh...@gmail.com wrote:

 I would to repeatably update non indexed column of temp table. I
 expected cheap operation, but it isn't true.

 You're updating the row 10 times within a single transaction.  I
 don't *think* HOT will reclaim a version of a row until the
 transaction which completed it is done and no other transactions can
 see that version any longer.  It does raise the question, though --
 couldn't a HOT update of a tuple *which was written by the same
 transaction* do an update in place?  I mean, the updating
 transaction doesn't need to see the old row after this, and other
 transactions shouldn't see it either.

 I suspect that somewhere in the subtransaction or referential
 integrity areas there may be some issues with that, but it would be
 a clever optimization if it could be pulled off.

scripting this outside of transaction does not exhibit the behavior --
 even with autovac off relation size tops out arond 57k.  vacuuming as
it goes seems to top out around 200 row versions before hot catches
them.  I guess a good way to think of hot is a page level vacuum.

merlin

-- 
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] hot update doesn't work?

[Tom Lane]

Kevin Grittner kevin.gritt...@wicourts.gov writes:
 You're updating the row 10 times within a single transaction.  I
 don't *think* HOT will reclaim a version of a row until the
 transaction which completed it is done and no other transactions can
 see that version any longer.  It does raise the question, though --
 couldn't a HOT update of a tuple *which was written by the same
 transaction* do an update in place?

Well ... in the first place there is not, ever, any such thing as
update in place.  The correct question to ask is whether we could
vacuum away the older elements of the HOT chain on the grounds that they
are no longer of interest.  What we would see is tuples with xmin equal
to xmax and cmin different from cmax.  The problem then is to determine
whether there are any live snapshots with curcid between cmin and cmax.
There is 0 hope of doing that from outside the originating backend.
Now if heap_page_prune() is being run by the same backend that generated
the in-doubt tuples, which I will agree is likely in a case like this,
in principle we could do it.  Not sure if it's really worth the trouble
and nonorthogonal behavior.

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] [COMMITTERS] pgsql: Add PGFILEDESC description to Makefiles for all /contrib

[Tom Lane]

momj...@postgresql.org (Bruce Momjian) writes:
 Add PGAPPICON to all executable makefiles.

Is it really a good idea to have done that to the server, in particular?
I can't imagine it being a good idea to launch the postmaster from a
GUI, which is what I suppose this is good for.

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] hot update doesn't work?

[Heikki Linnakangas]

Tom Lane wrote:
 The correct question to ask is whether we could
 vacuum away the older elements of the HOT chain on the grounds that they
 are no longer of interest.  What we would see is tuples with xmin equal
 to xmax and cmin different from cmax.  The problem then is to determine
 whether there are any live snapshots with curcid between cmin and cmax.
 There is 0 hope of doing that from outside the originating backend.
 Now if heap_page_prune() is being run by the same backend that generated
 the in-doubt tuples, which I will agree is likely in a case like this,
 in principle we could do it.

There's an extra hurdle in the way: If you remove tuples in the middle
of an update chain (not necessarily a HOT update chain), the latest
tuple becomes inaccessible to other transactions running in read
committed mode that might need to find the latest version of the row by
following the ctid pointers.

That's not an issue if the row was created in the same transaction too,
but we don't know that in HeapTupleSatisfiesVacuum.

-- 
  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] hot update doesn't work?

[Merlin Moncure]

On Wed, May 12, 2010 at 11:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Kevin Grittner kevin.gritt...@wicourts.gov writes:
 You're updating the row 10 times within a single transaction.  I
 don't *think* HOT will reclaim a version of a row until the
 transaction which completed it is done and no other transactions can
 see that version any longer.  It does raise the question, though --
 couldn't a HOT update of a tuple *which was written by the same
 transaction* do an update in place?

 Well ... in the first place there is not, ever, any such thing as
 update in place.  The correct question to ask is whether we could
 vacuum away the older elements of the HOT chain on the grounds that they
 are no longer of interest.  What we would see is tuples with xmin equal
 to xmax and cmin different from cmax.  The problem then is to determine
 whether there are any live snapshots with curcid between cmin and cmax.
 There is 0 hope of doing that from outside the originating backend.
 Now if heap_page_prune() is being run by the same backend that generated
 the in-doubt tuples, which I will agree is likely in a case like this,
 in principle we could do it.  Not sure if it's really worth the trouble
 and nonorthogonal behavior.

update of same row in a single transaction is not going to come up
that much and there are a number of simple work arounds to get better
performance.

isn't it possible to skip the snapshot check for temp tables though?

merlin

-- 
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] hot update doesn't work?

[Tom Lane]

Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
 Tom Lane wrote:
 The correct question to ask is whether we could
 vacuum away the older elements of the HOT chain on the grounds that they
 are no longer of interest.  What we would see is tuples with xmin equal
 to xmax and cmin different from cmax.  The problem then is to determine
 whether there are any live snapshots with curcid between cmin and cmax.
 There is 0 hope of doing that from outside the originating backend.
 Now if heap_page_prune() is being run by the same backend that generated
 the in-doubt tuples, which I will agree is likely in a case like this,
 in principle we could do it.

 There's an extra hurdle in the way: If you remove tuples in the middle
 of an update chain (not necessarily a HOT update chain), the latest
 tuple becomes inaccessible to other transactions running in read
 committed mode that might need to find the latest version of the row by
 following the ctid pointers.

Hm, right.  In the normal vacuum case this isn't an issue because all
older versions of the row must be dead too, and so there can't be anyone
trying to chase up to the chain end from those versions.  But a rule
such as I suggested above could try to remove tuples whose ancestor is
still live (to somebody).

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] hot update doesn't work?

[Tom Lane]

Merlin Moncure mmonc...@gmail.com writes:
 isn't it possible to skip the snapshot check for temp tables though?

No, it's no different from the regular-table case.  There could be
snapshots that could see the older tuple versions --- consider
functions inside queries, etc.

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] max_standby_delay considered harmful

[Robert Haas]

On Wed, May 12, 2010 at 11:28 AM, Simon Riggs si...@2ndquadrant.com wrote:
 On Wed, 2010-05-12 at 14:18 +0100, Simon Riggs wrote:
 On Wed, 2010-05-12 at 08:52 -0400, Robert Haas wrote:
  On Wed, May 12, 2010 at 7:26 AM, Simon Riggs si...@2ndquadrant.com wrote:
   On Wed, 2010-05-12 at 07:10 -0400, Robert Haas wrote:
  
   I'm not sure what to make of this.  Sometimes not shutting down
   doesn't sound like a feature to me.
  
   It acts exactly the same in recovery as in normal running. It is not a
   special feature of recovery at all, bug or otherwise.
 
  Simon, that doesn't make any sense.  We are talking about a backend
  getting stuck forever on an exclusive lock that is held by the startup
  process and which will never be released (for example, because the
  master has shut down and no more WAL can be obtained for replay).  The
  startup process does not hold locks in normal operation.

 When I test it, startup process holding a lock does not prevent shutdown
 of a standby.

 I'd be happy to see your test case showing a bug exists and that the
 behaviour differs from normal running.

 Let me put this differently: I accept that Stefan has reported a
 problem. Neither Tom nor myself can reproduce the problem. I've re-run
 Stefan's test case and restarted the server more than 400 times now
 without any issue.

OK, I'm glad to hear you've been testing this.  I wasn't aware of that.

 I re-read your post where you gave what you yourself called uninformed
 speculation. There's no real polite way to say it, but yes your
 speculation does appear to be uninformed, since it is incorrect. Reasons
 would be not least that Stefan's tests don't actually send any locks to
 the standby anyway (!),

Hmm.  Well, assuming you're correct, that does seem to be a, uh,
slight problem with my theory.

 but even if they did your speculation as to the
 cause is still all wrong, as explained.

You lost me.  I don't understand why the problem that I'm referring to
couldn't happen, even if it's not what's happening here.

 There is no evidence to link this behaviour with HS, as yet, and you
 should be considering the possibility the problem lies elsewhere,
 especially since it could be code you committed that is at fault.

Huh?? The evidence that this bug is linked with HS is that it occurs
on a server running in HS mode, and not otherwise.  As for whether the
bug is code I committed, that's certainly possible, but keep in mind
it didn't work at all before IN HOT STANDBY MODE - and that will be
code you committed.

I'm going to go test this and see if I can figure out what's going on.
 I hope you will keep at it also - as you point out, your knowledge of
this code far exceeds mine.

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

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

[HACKERS] primary/secondary/master/slave/standby

[Peter Eisentraut]

The server's messages and the documentation uses all of these terms in
mixed ways.  Maybe we could decide on some preferred terminology and
adjust the existing texts.  Ideas?


-- 
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] primary/secondary/master/slave/standby

[David Fetter]

On Wed, May 12, 2010 at 07:33:53PM +0300, Peter Eisentraut wrote:
 The server's messages and the documentation uses all of these terms in
 mixed ways.  Maybe we could decide on some preferred terminology and
 adjust the existing texts.  Ideas?

How about origin/subscriber?  More descriptive than primary/secondary,
and less tied to a particular model of interaction.

Cheers,
David.
-- 
David Fetter da...@fetter.org 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] primary/secondary/master/slave/standby

[Tom Lane]

Peter Eisentraut pete...@gmx.net writes:
 The server's messages and the documentation uses all of these terms in
 mixed ways.  Maybe we could decide on some preferred terminology and
 adjust the existing texts.  Ideas?

Primary/secondary seem like a poor choice because they're such generic
terms.  Master/slave is the common terminology for this, I think,
though some might object on grounds of political incorrectness.
If so, master/standby would probably 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] primary/secondary/master/slave/standby

[Kevin Grittner]

David Fetter da...@fetter.org wrote:
 
 How about origin/subscriber?
 
Seems like a mixed metaphor.  Publisher normally goes with
subscriber.  I've heard and used origin and replica.
 
Are we planning to support a subscriber which also publishes (to
randomly pick one for purposes of discussion)?  If so, that should
be considered in our choice of terminology.
 
-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] max_standby_delay considered harmful

[Simon Riggs]

On Wed, 2010-05-12 at 12:04 -0400, Robert Haas wrote:

 Huh?? The evidence that this bug is linked with HS is that it occurs
 on a server running in HS mode, and not otherwise.  As for whether the
 bug is code I committed, that's certainly possible, but keep in mind
 it didn't work at all before IN HOT STANDBY MODE - and that will be
 code you committed.

I'll say it now, so its plain. I'm not going to investigate every bug
that occurs on Postgres, just because someone was in HS when they found
it. Any more than all bugs on Postgres in normal running are MVCC bugs.
There needs to be reasonable evidence or a conjecture by someone that
knows something about the code. If HS were the only thing changed in
recovery in this release, that might not seem reasonable, but since we
have much new code and I am not the only developer, it is.

Normal shutdown didn't work on a standby before HS was committed and it
didn't work afterwards either. Use all the capitals you like but if you
use poor arguments and combine that with no evidence then we'll not get
very far, either in working together or in solving the actual bugs.
Please don't continue to make wild speculations about things related to
HS and recovery, so that issues do not become confused; there is no need
to comment on every thread.

-- 
 Simon Riggs   www.2ndQuadrant.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] max_standby_delay considered harmful

[Greg Stark]

On Wed, May 12, 2010 at 5:49 PM, Simon Riggs si...@2ndquadrant.com wrote:
 On Wed, 2010-05-12 at 12:04 -0400, Robert Haas wrote:

 Huh?? The evidence that this bug is linked with HS is that it occurs
 on a server running in HS mode, and not otherwise.  As for whether the
 bug is code I committed, that's certainly possible, but keep in mind
 it didn't work at all before IN HOT STANDBY MODE - and that will be
 code you committed.

 I'll say it now, so its plain. I'm not going to investigate every bug
 that occurs on Postgres, just because someone was in HS when they found
 it.

Fair enough, though your help debugging is always appreciated
regardless of whether a problem is HS related or not. Nobody's
obligated to work on anything in Postgres after all.

I'm not sure who to blame for the shouting match over whose commit
introduced the bug -- it doesn't seem like a relevant or useful thing
to argue about, please both stop.

  there is no need
 to comment on every thread.

This is out of line.

-- 
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] max_standby_delay considered harmful

[Simon Riggs]

On Wed, 2010-05-12 at 18:05 +0100, Greg Stark wrote:

 I'm not sure who to blame for the shouting match over whose commit
 introduced the bug -- it doesn't seem like a relevant or useful thing
 to argue about, please both stop.

I haven't blamed Robert's code, merely asked him to consider that it is
something other HS, since we have no evidence either way at present
because the issue is sporadic and has not been replicated as yet, with
no specific detail leading to any section of code.

   there is no need
  to comment on every thread.
 
 This is out of line.

Quoted out of context, it is. My full comment is Please don't continue
to make wild speculations about things related to HS and recovery, so
that issues do not become confused; there is no need to comment on every
thread. ... by which I mean threads related to HS and recovery. I
respect everybody's right to free speech here, but I would say the same
to anyone if they do it repeatedly. I'm not the first to make such a
comment on hackers either.

-- 
 Simon Riggs   www.2ndQuadrant.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: Add PGFILEDESC description to Makefiles for all /contrib

[Bruce Momjian]

Tom Lane wrote:
 momj...@postgresql.org (Bruce Momjian) writes:
  Add PGAPPICON to all executable makefiles.
 
 Is it really a good idea to have done that to the server, in particular?
 I can't imagine it being a good idea to launch the postmaster from a
 GUI, which is what I suppose this is good for.

Well, I assume this was the icon, which I assumed should match for all
the binaries, as compared to config files, for example.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://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: Add PGFILEDESC description to Makefiles for all /contrib

[Tom Lane]

Bruce Momjian br...@momjian.us writes:
 Tom Lane wrote:
 momj...@postgresql.org (Bruce Momjian) writes:
 Add PGAPPICON to all executable makefiles.
 
 Is it really a good idea to have done that to the server, in particular?
 I can't imagine it being a good idea to launch the postmaster from a
 GUI, which is what I suppose this is good for.

 Well, I assume this was the icon, which I assumed should match for all
 the binaries, as compared to config files, for example.

Er... why are you committing undiscussed patches if you just assume
they will work, or indeed do anything useful at all?  You should not
have touched this if you don't know exactly what it will do and why
changing it is a good thing.

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] primary/secondary/master/slave/standby

[Joshua D. Drake]

On Wed, 2010-05-12 at 09:37 -0700, David Fetter wrote:
 On Wed, May 12, 2010 at 07:33:53PM +0300, Peter Eisentraut wrote:
  The server's messages and the documentation uses all of these terms in
  mixed ways.  Maybe we could decide on some preferred terminology and
  adjust the existing texts.  Ideas?
 
 How about origin/subscriber?  More descriptive than primary/secondary,
 and less tied to a particular model of interaction.

Yes but completely out of scope within the market. Master/Slave or
Master/Standby is probably where it needs to be.

Joshua D. Drake



-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering



-- 
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] max_standby_delay considered harmful

[Joshua D. Drake]

On Wed, 2010-05-12 at 17:49 +0100, Simon Riggs wrote:
 On Wed, 2010-05-12 at 12:04 -0400, Robert Haas wrote:

 Normal shutdown didn't work on a standby before HS was committed and it
 didn't work afterwards either. Use all the capitals you like but if you
 use poor arguments and combine that with no evidence then we'll not get
 very far, either in working together or in solving the actual bugs.
 Please don't continue to make wild speculations about things related to
 HS and recovery, so that issues do not become confused; there is no need
 to comment on every thread.
 

Simon,

People are very passionate about this feature. This feature has the
ability to show us as moving forward in a fashion that will allow us to
directly compete with the big boys in the big installs, although we
are still probably 2-3 releases from that.

It also has the ability to make us look like a bunch of yahoos (no pun
intended) who are better served beating up on that database that Oracle
just bought, versus Oracle itself.

Patience is a virtue for all when it comes to the this feature.

Joshua D. Drake


-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering



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

[HACKERS] pg_upgrade versus MSVC build scripts

[Tom Lane]

A look at the MSVC buildfarm members shows that they are not building
most of the files added to contrib/pg_upgrade.  The reason seems to be
that that module tries to build both an executable program *and* a
shared library, which it does by dint of setting both PROGRAM and
MODULES in its Makefile.  Now that is a dirty hack that is nowhere
documented to work, and in fact the pgxs documentation explicitly says
not to do that.  It accidentally fails to fail, at the moment, because
of the way pgxs.mk is set up, and because the OBJS variable is only
needed for one of these targets.  But the MSVC build scripts aren't
expecting this and evidently disregard PROGRAM after they see MODULES.

We could try to make this a supported build arrangement, but I'm
inclined to think that a cleaner solution is to split out the loadable
module as a separate contrib subdirectory.  Thoughts?

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

[HACKERS] Tags missing from GIT mirror?

[Florian Pflug]

Hi

I just tried to checkout REL9_0_BETA1 from my local clone of the GIT repository 
at git.postgresql.org and discovered that none of the tags from CVS seem to 
exist in there. For alpha1 to alpha1 each tag is accompanied by a corresponding 
brach, and those *do* exist on the GIT mirror. For beta1, however, no branch 
seems to exist, and hence there is no trace of it on the GIT mirror.

Why is there a branch plus a tag for alphas, but only a tag for betas? I'd have 
assumed that both would just be tags, but obviously I'm missing something 
there...

best regards,
Florian Pflug


-- 
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] max_standby_delay considered harmful

[Robert Haas]

On Wed, May 12, 2010 at 1:21 PM, Simon Riggs si...@2ndquadrant.com wrote:
 On Wed, 2010-05-12 at 18:05 +0100, Greg Stark wrote:

 I'm not sure who to blame for the shouting match over whose commit
 introduced the bug -- it doesn't seem like a relevant or useful thing
 to argue about, please both stop.

 I haven't blamed Robert's code, merely asked him to consider that it is
 something other HS, since we have no evidence either way at present
 because the issue is sporadic and has not been replicated as yet, with
 no specific detail leading to any section of code.

I'm not really sure what we're arguing about here.  I feel like I'm
being accused either of (a) introducing the bug (which is possible) or
(b) saying that Simon introduced the bug (which presumably is also
possible, although it's not really my point).  I ventured an
uninformed guess at what the problem might be; Simon thinks my guess
is wrong, and it may well be: but either way there's a bug buried in
here somewhere and it would be nice to fix it.  I thought that it
would be a good idea for Simon to look at it because, on the surface,
it APPEARS to have something to do with Hot Standby, since that's what
Stefan was testing when he found it.  Sure, the investigation might
lead somewhere else; I completely admit that.

Now, Simon just said he HAS looked at it and can't reproduce the
problem.  So now I'm even less sure what we're arguing about.  I'm
glad he looked at it.  It's interesting that he wasn't able to
reproduce the problem.  I hope that he or someone else will find
something that helps us move forward.  I am having difficulty
reproducing Stefan's test environment and perhaps for that reason I
can't reproduce it either, though I've encountered several other
problems about which, I suppose, I will post separate emails.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres 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] Tags missing from GIT mirror?

[Magnus Hagander]

On Wed, May 12, 2010 at 8:27 PM, Florian Pflug f...@phlo.org wrote:
 Hi

 I just tried to checkout REL9_0_BETA1 from my local clone of the GIT 
 repository at git.postgresql.org and discovered that none of the tags from 
 CVS seem to exist in there. For alpha1 to alpha1 each tag is accompanied by a 
 corresponding brach, and those *do* exist on the GIT mirror. For beta1, 
 however, no branch seems to exist, and hence there is no trace of it on the 
 GIT mirror.

 Why is there a branch plus a tag for alphas, but only a tag for betas? I'd 
 have assumed that both would just be tags, but obviously I'm missing 
 something there...

I think we branched the alphas so we could version-stamp them while
keeping HEAD as 9.0devel. But when we switch to beta, we don't have
a devel tree anymore, it's just beta and backbranches.


-- 
 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] weird hang while running in HS mode

[Robert Haas]

While fooling around with Hot Standby today, I did this on the master:

rhaas=# begin work;
BEGIN
rhaas=# lock table pgbench_accounts;
LOCK TABLE

Then on slave I did this:

rhaas=# select * from pgbench_accounts;
ERROR:  canceling statement due to conflict with recovery
DETAIL:  User query might have needed to see row versions that must be removed.

The error message appeared immediately, although max_standby_delay is
set to 30s and both servers are running on the same machine.  IMHO,
that's a good example of why max_standby_delay in its current form is
not a good thing, but that's a topic for another thread.  I then did
this on the master:

rhaas=# rollback;
ROLLBACK

So at this point, one would think that there are no locks hanging
around anywhere.  Back to the standby:

rhaas=# select * from pgbench_accounts;
really long hang

I did this from another session on the standby:

rhaas=# select * from pg_stat_activity;
 datid | datname | procpid | usesysid | usename | application_name |
client_addr | client_port | backend_start |
xact_start   |  query_start  | waiting |
   current_query
---+-+-+--+-+--+-+-+---+---+---+-+-
 16384 | rhaas   |6706 |   10 | rhaas   | psql |
  |  -1 | 2010-05-12 14:07:21.73227-04  | 2010-05-12
14:08:02.657664-04 | 2010-05-12 14:08:02.657664-04 | t   | select
* from pgbench_accounts;
 16384 | rhaas   |6719 |   10 | rhaas   | psql |
  |  -1 | 2010-05-12 14:10:15.916115-04 | 2010-05-12
14:10:24.18013-04  | 2010-05-12 14:10:24.18013-04  | f   | select
* from pg_stat_activity;
(2 rows)

OK, so it's blocked on a lock.  Let's find out more.

[rhaas ~]$ gdb -p 6709
GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2) (Fri Mar  5
04:43:10 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as x86_64-apple-darwin.
/Users/rhaas/6709: No such file or directory
Unable to access task for process-id 6709: (os/kern) failure.
(gdb) q
[rhaas ~]$ gdb -p 6706
GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2) (Fri Mar  5
04:43:10 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as x86_64-apple-darwin.
/Users/rhaas/6706: No such file or directory
Attaching to process 6706.
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
0x7fff838d014e in semop ()
(gdb) bt
#0  0x7fff838d014e in semop ()
#1  0x0001001ba1af in PGSemaphoreLock (sema=0x100d4db08,
interruptOK=1 '\001') at pg_sema.c:420
#2  0x0001001f8782 in ProcSleep (locallock=0x1010d9568,
lockMethodTable=value temporarily unavailable, due to optimizations)
at proc.c:971
#3  0x0001001f4c31 in WaitOnLock (locallock=0x1010d9568,
owner=0x101060628) at lock.c:1217
#4  0x0001001f6254 in LockAcquireExtended (locktag=0x7fff5fbfdf00,
lockmode=1, sessionLock=value temporarily unavailable, due to
optimizations, dontWait=0 '\0', reportMemoryError=1 '\001') at
lock.c:836
#5  0x0001001f36bf in LockRelationOid (relid=16420, lockmode=1) at lmgr.c:79
#6  0x0001000242ba in relation_open (relationId=16420, lockmode=1)
at heapam.c:899
#7  0x0001000244ac in try_heap_openrv (relation=value temporarily
unavailable, due to optimizations, lockmode=value temporarily
unavailable, due to optimizations) at heapam.c:1127
#8  0x0001000c7f14 in parserOpenTable (pstate=0x101041c68,
relation=0x101041a38, lockmode=1) at parse_relation.c:829
#9  0x0001000c8141 in addRangeTableEntry (pstate=0x101041c68,
relation=0x101041a38, alias=0x0, inh=1 '\001', inFromCl=1 '\001') at
parse_relation.c:895
#10 0x0001000b8927 in transformTableEntry [inlined] () at
/Users/rhaas/pgsql/src/backend/parser/parse_clause.c:444
#11 0x0001000b8927 in transformFromClauseItem (pstate=0x101041c68,
n=0x101041a38, top_rte=0x7fff5fbfe1b0, top_rti=0x7fff5fbfe1bc,
relnamespace=0x7fff5fbfe1a8, containedRels=0x7fff5fbfe1a0) at
parse_clause.c:676
#12 0x0001000b939a in transformFromClause (pstate=0x101041c68,
frmList=value temporarily unavailable, due to optimizations) at
parse_clause.c:128
#13 0x00010009eccb in transformSelectStmt [inlined] () at
/Users/rhaas/pgsql/src/backend/parser/analyze.c:800
#14 

Re: [HACKERS] primary/secondary/master/slave/standby

[Heikki Linnakangas]

Tom Lane wrote:
 If so, master/standby would probably work.

+1 for master/standby.

It's worth remembering that a standby server might not be actively
connected to a master server. A server that's reading WAL from an
archive backup, for example, can be put to standby mode. Standby
covers that case too, better than slave.

-- 
  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] primary/secondary/master/slave/standby

[Simon Riggs]

On Wed, 2010-05-12 at 19:33 +0300, Peter Eisentraut wrote:
 The server's messages and the documentation uses all of these terms in
 mixed ways.  Maybe we could decide on some preferred terminology and
 adjust the existing texts.  Ideas?

Never user the term secondary myself.

I deliberately use standby rather than slave, to differentiate
between an exact replica and a synchronised copy (respectively).

I use the terms primary and master more freely but generally try to
use primary/standby and master/slave together. If you wanted to move to
just one, it would be master, though we'd need to have a good
explanation of primary in the index.

-- 
 Simon Riggs   www.2ndQuadrant.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] multibyte charater set in levenshtein function

[Alvaro Herrera]

Excerpts from Alexander Korotkov's message of lun may 10 11:35:02 -0400 2010:
 Hackers,
 
 The current version of levenshtein function in fuzzystrmatch contrib modulte
 doesn't work properly with multibyte charater sets.

 My patch make this function works properly with multibyte charater sets.

Great.  Please add it to the next commitfest:
http://commitfest.postgresql.org

On a quick look, I didn't like the way you separated the 
pg_database_encoding_max_length()  1 cases.  There seem to be too
much common code.  Can that be refactored a bit better?
-- 

-- 
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] max_standby_delay considered harmful

[Stefan Kaltenbrunner]

On 05/12/2010 05:28 PM, Simon Riggs wrote:

On Wed, 2010-05-12 at 14:18 +0100, Simon Riggs wrote:

On Wed, 2010-05-12 at 08:52 -0400, Robert Haas wrote:

On Wed, May 12, 2010 at 7:26 AM, Simon Riggssi...@2ndquadrant.com  wrote:

On Wed, 2010-05-12 at 07:10 -0400, Robert Haas wrote:


I'm not sure what to make of this.  Sometimes not shutting down
doesn't sound like a feature to me.


It acts exactly the same in recovery as in normal running. It is not a
special feature of recovery at all, bug or otherwise.


Simon, that doesn't make any sense.  We are talking about a backend
getting stuck forever on an exclusive lock that is held by the startup
process and which will never be released (for example, because the
master has shut down and no more WAL can be obtained for replay).  The
startup process does not hold locks in normal operation.


When I test it, startup process holding a lock does not prevent shutdown
of a standby.

I'd be happy to see your test case showing a bug exists and that the
behaviour differs from normal running.


Let me put this differently: I accept that Stefan has reported a
problem. Neither Tom nor myself can reproduce the problem. I've re-run
Stefan's test case and restarted the server more than 400 times now
without any issue.

I re-read your post where you gave what you yourself called uninformed
speculation. There's no real polite way to say it, but yes your
speculation does appear to be uninformed, since it is incorrect. Reasons
would be not least that Stefan's tests don't actually send any locks to
the standby anyway (!), but even if they did your speculation as to the
cause is still all wrong, as explained.

There is no evidence to link this behaviour with HS, as yet, and you
should be considering the possibility the problem lies elsewhere,
especially since it could be code you committed that is at fault.


Well I'm not sure why people seem to have that hard a time reproducing 
that issue - it seems that I can provoke it really trivially(in this 
case no loops, no pgbench, no tricks). A few minutes ago I logged into 
my test standby (which is idle except for the odd connect to template1 
caused by nagios - the master is idle as well and has been for days):


postg...@soldata005:~$ psql
psql (9.0beta1)
Type help for help.

postgres=# select 1;
 ?column?
--
1
(1 row)

postgres=# \q
postg...@soldata005:~$ pg_ctl -D /var/lib/postgresql/9.0b1/main/ restart
waiting for server to shut down done
server stopped
server starting
postg...@soldata005:~$ pg_ctl -D /var/lib/postgresql/9.0b1/main/ restart
waiting for server to shut down done
server stopped
server starting
postg...@soldata005:~$ pg_ctl -D /var/lib/postgresql/9.0b1/main/ restart
waiting for server to shut 
down... failed

pg_ctl: server does not shut down


the server log for that is as follows:

2010-05-12 20:36:18.166 CEST,,, LOG:  received smart shutdown request
2010-05-12 20:36:18.167 CEST,,, FATAL:  terminating walreceiver 
process due to administrator command

2010-05-12 20:36:18.174 CEST,,, LOG:  shutting down
2010-05-12 20:36:18.251 CEST,,, LOG:  database system is shut down
2010-05-12 20:36:19.706 CEST,,, LOG:  database system was interrupted 
while in recovery at log time 2010-05-06 17:36:05 CEST
2010-05-12 20:36:19.706 CEST,,, HINT:  If this has occurred more than 
once some data might be corrupted and you might need to choose an 
earlier recovery target.

2010-05-12 20:36:19.706 CEST,,, LOG:  entering standby mode
2010-05-12 20:36:19.721 CEST,,, LOG:  consistent recovery state 
reached at 1/1278

2010-05-12 20:36:19.721 CEST,,, LOG:  invalid record length at 1/1278
2010-05-12 20:36:19.723 CEST,,, LOG:  database system is ready to 
accept read only connections
2010-05-12 20:36:19.737 CEST,,, LOG:  streaming replication 
successfully connected to primary

2010-05-12 20:36:19.918 CEST,,, LOG:  received smart shutdown request
2010-05-12 20:36:19.919 CEST,,, FATAL:  terminating walreceiver 
process due to administrator command

2010-05-12 20:36:19.922 CEST,,, LOG:  shutting down
2010-05-12 20:36:19.937 CEST,,, LOG:  database system is shut down
2010-05-12 20:36:21.433 CEST,,, LOG:  database system was interrupted 
while in recovery at log time 2010-05-06 17:36:05 CEST
2010-05-12 20:36:21.433 CEST,,, HINT:  If this has occurred more than 
once some data might be corrupted and you might need to choose an 
earlier recovery target.

2010-05-12 20:36:21.433 CEST,,, LOG:  entering standby mode
2010-05-12 20:36:21.482 CEST,,, LOG:  received smart shutdown request
2010-05-12 20:36:21.504 CEST,,, LOG:  consistent recovery state 
reached at 1/1278

2010-05-12 20:36:21.504 CEST,,, LOG:  invalid record length at 1/1278
2010-05-12 20:36:21.505 CEST,,, LOG:  database system is ready to 
accept read only connections
2010-05-12 20:36:21.516 CEST,,, LOG:  streaming replication 
successfully connected to primary


so it restarted two times 

Re: [HACKERS] pg_upgrade versus MSVC build scripts

[Alvaro Herrera]

Excerpts from Tom Lane's message of mié may 12 14:07:13 -0400 2010:

 We could try to make this a supported build arrangement, but I'm
 inclined to think that a cleaner solution is to split out the loadable
 module as a separate contrib subdirectory.  Thoughts?

Do you mean contrib/pg_upgrade/somelib?  If so, +1.  If you instead mean
putting the library in contrib/somelib, I'm not so sure that it's
cleaner than trying to support executable+shared lib in a single contrib
module.
-- 

-- 
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] pg_upgrade versus MSVC build scripts

[Tom Lane]

Alvaro Herrera alvhe...@alvh.no-ip.org writes:
 Excerpts from Tom Lane's message of mié may 12 14:07:13 -0400 2010:
 We could try to make this a supported build arrangement, but I'm
 inclined to think that a cleaner solution is to split out the loadable
 module as a separate contrib subdirectory.  Thoughts?

 Do you mean contrib/pg_upgrade/somelib?  If so, +1.

Hmm.  I had been thinking the other way, but I'll see if that can 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] Tags missing from GIT mirror?

[David Christensen]

On May 12, 2010, at 1:43 PM, Magnus Hagander wrote:

 On Wed, May 12, 2010 at 8:27 PM, Florian Pflug f...@phlo.org wrote:
 Hi
 
 I just tried to checkout REL9_0_BETA1 from my local clone of the GIT 
 repository at git.postgresql.org and discovered that none of the tags from 
 CVS seem to exist in there. For alpha1 to alpha1 each tag is accompanied by 
 a corresponding brach, and those *do* exist on the GIT mirror. For beta1, 
 however, no branch seems to exist, and hence there is no trace of it on the 
 GIT mirror.
 
 Why is there a branch plus a tag for alphas, but only a tag for betas? I'd 
 have assumed that both would just be tags, but obviously I'm missing 
 something there...
 
 I think we branched the alphas so we could version-stamp them while
 keeping HEAD as 9.0devel. But when we switch to beta, we don't have
 a devel tree anymore, it's just beta and backbranches.


Is there anything to do about the missing tags in git?  I've wished for those 
to be available as well.

Regards,

David
--
David Christensen
End Point Corporation
da...@endpoint.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] comment needs to be updated for HS?

[Robert Haas]

postmaster.c contains the following comment just above the definition
of PMState.  It appears to be out of date:

 * After reaching a consistent point in WAL redo, startup process signals
 * us again, and we switch to PM_RECOVERY_CONSISTENT state. There's currently
 * no difference between PM_RECOVERY and PM_RECOVERY_CONSISTENT, but we
 * could start accepting connections to perform read-only queries at this
 * point, if we had the infrastructure to do that.

The next paragraph has what I believe to be the correct information:

 * Normal child backends can only be launched when we are in PM_RUN or
 * PM_RECOVERY_CONSISTENT state.  (We also allow launch of normal

I am happy to fix this but thought SImon or Heikki or Tom might like
to either (a) jump in and do it themselves or (b) tell me if I've
misunderstood the situation.  If neither of those is the case then I
will go ahead and fix it.

Thanks,

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres 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] pg_upgrade versus MSVC build scripts

[Andrew Dunstan]

Tom Lane wrote:

Alvaro Herrera alvhe...@alvh.no-ip.org writes:
  

Excerpts from Tom Lane's message of mié may 12 14:07:13 -0400 2010:


We could try to make this a supported build arrangement, but I'm
inclined to think that a cleaner solution is to split out the loadable
module as a separate contrib subdirectory.  Thoughts?
  


  

Do you mean contrib/pg_upgrade/somelib?  If so, +1.



Hmm.  I had been thinking the other way, but I'll see if that can be
made to work.


  


Not sure this will work on its own with the MSVC build system - I don't 
think it's set up for sub-modules. But we can finessee that if 
necessary, just as we make special provision for pgcrypto.


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] primary/secondary/master/slave/standby

[Robert Haas]

On Wed, May 12, 2010 at 3:01 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
 Tom Lane wrote:
 If so, master/standby would probably work.

 +1 for master/standby.

 It's worth remembering that a standby server might not be actively
 connected to a master server. A server that's reading WAL from an
 archive backup, for example, can be put to standby mode. Standby
 covers that case too, better than slave.

So does this mean we should rename primary_conninfo?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres 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] max_standby_delay considered harmful

[Simon Riggs]

On Wed, 2010-05-12 at 21:10 +0200, Stefan Kaltenbrunner wrote:

  There is no evidence to link this behaviour with HS, as yet, and you
  should be considering the possibility the problem lies elsewhere,
  especially since it could be code you committed that is at fault.
 
 Well I'm not sure why people seem to have that hard a time reproducing 
 that issue - it seems that I can provoke it really trivially(in this 
 case no loops, no pgbench, no tricks). A few minutes ago I logged into 
 my test standby (which is idle except for the odd connect to template1 
 caused by nagios - the master is idle as well and has been for days):

Thanks, good report.

 so it restarted two times successfully - however if one looks at the 
 third time one can see that it received the smart shutdown request 
 BEFORE it reached a consistent recovery state - yet it continued to 
 enable HS and reenabled SR as well.
 
 The database is now sitting there doing nothing and it more or less 
 broken because you cannot connect to it in the current state:
 
 ~$ psql
 psql: FATAL:  the database system is shutting down
 
 the startup process has the following backtrace:
 
 (gdb) bt
 #0  0x7fbe24cb2c83 in select () from /lib/libc.so.6
 #1  0x006e811a in pg_usleep ()
 #2  0x0048c333 in XLogPageRead ()
 #3  0x0048c967 in ReadRecord ()
 #4  0x00493ab6 in StartupXLOG ()
 #5  0x00495a88 in StartupProcessMain ()
 #6  0x004ab25e in AuxiliaryProcessMain ()
 #7  0x005d4a7d in StartChildProcess ()
 #8  0x005d70c2 in PostmasterMain ()
 #9  0x0057d898 in main ()

Well, its waiting for new info from primary. Nothing to do with locking,
but that's not an indication that its an SR issue though either. ;-)

I'll put some waits into that part of the code and see if I can induce
the failure. Maybe its just a simple lack of a CHECK_FOR_INTERRUPTS().

-- 
 Simon Riggs   www.2ndQuadrant.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] pg_upgrade versus MSVC build scripts

[Tom Lane]

Andrew Dunstan and...@dunslane.net writes:
 Tom Lane wrote:
 Alvaro Herrera alvhe...@alvh.no-ip.org writes:
 Do you mean contrib/pg_upgrade/somelib?  If so, +1.
 
 Hmm.  I had been thinking the other way, but I'll see if that can be
 made to work.

 Not sure this will work on its own with the MSVC build system - I don't 
 think it's set up for sub-modules.

Oh, right.  Since the entire point here is to *not* require new
buildsystem infrastructure for pg_upgrade, I'm back to thinking that
a separate contrib module is the way to go.

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] max_standby_delay considered harmful

[Alvaro Herrera]

Excerpts from Stefan Kaltenbrunner's message of mié may 12 15:10:28 -0400 2010:

 the startup process has the following backtrace:
 
 (gdb) bt
 #0  0x7fbe24cb2c83 in select () from /lib/libc.so.6
 #1  0x006e811a in pg_usleep ()
 #2  0x0048c333 in XLogPageRead ()
 #3  0x0048c967 in ReadRecord ()
 #4  0x00493ab6 in StartupXLOG ()
 #5  0x00495a88 in StartupProcessMain ()
 #6  0x004ab25e in AuxiliaryProcessMain ()
 #7  0x005d4a7d in StartChildProcess ()
 #8  0x005d70c2 in PostmasterMain ()
 #9  0x0057d898 in main ()

I just noticed that we have some code assigning the return value of
time() to a pg_time_t variable.  Is this supposed to work reliably?
(xlog.c lines 9267ff)
-- 

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

[HACKERS] pg_dump should not try CREATE OR REPLACE LANGUAGE 9.0

[Greg Sabino Mullane]

Subject line kind of says it all: LANGUAGE replacement was 
introduced in 9.0, but pg_dump is trying it on all versions.

-- 
Greg Sabino Mullane g...@turnstep.com
End Point Corporation
PGP Key: 0x14964AC8 201005121537
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 2431d71..c8f231c 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -7601,9 +7601,14 @@ dumpProcLang(Archive *fout, ProcLangInfo *plang)
 * is a pg_pltemplate entry, and if there is one, the existing 
entry
 * must match it too.
 */
-   appendPQExpBuffer(defqry, CREATE OR REPLACE PROCEDURAL 
LANGUAGE %s,
- qlanname);
+   if (g_fout-remoteVersion  9)
+   appendPQExpBuffer(defqry, CREATE PROCEDURAL LANGUAGE 
%s,
+ qlanname);
+   else
+   appendPQExpBuffer(defqry, CREATE OR REPLACE PROCEDURAL 
LANGUAGE %s,
+ qlanname);
}
+
appendPQExpBuffer(defqry, ;\n);
 
ArchiveEntry(fout, plang-dobj.catId, plang-dobj.dumpId,


pgpvIlb6dEdnL.pgp
Description: PGP signature

Re: [HACKERS] max_standby_delay considered harmful

[Simon Riggs]

On Wed, 2010-05-12 at 15:36 -0400, Alvaro Herrera wrote:
 I just noticed that we have some code assigning the return value of
 time() to a pg_time_t variable.  Is this supposed to work reliably?
 (xlog.c lines 9267ff)

Code's used that for a while now. Checkpoints and everywhere.

-- 
 Simon Riggs   www.2ndQuadrant.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] List traffic

[Robert Haas]

On Tue, May 11, 2010 at 1:32 PM, Marc G. Fournier scra...@hub.org wrote:
 On Tue, 11 May 2010, Alvaro Herrera wrote:

 Excerpts from Marc G. Fournier's message of mar may 11 09:58:34 -0400
 2010:

 If list traffic, especially on -hackers, is getting so large, should we
 look at maybe splitting it?  I could easily enough split things such that
 I duplicate the subscriber list, so nobody would have to subscribe, but
 it
 would make it easier for ppl to filter their incoming ... ?

 Maybe we could create a separate list where people would send patches,
 and keep patchless discussion on -hackers?

 Just a thought ;-)

 The thing is, it seems to me, especially now that we have such strong commit
 fests, that we should have a seperate form for 'design phase' then for
 'reivew discusions' ... *shrug*

 There may be some that are interested in what is being implemented, but
 don't really care about how it was implemented ...

The difference between discussing a patch and discussing an idea that
might lead to a patch is fairly fine.  Exactly how far people go with
the design discussion before reducing it to code varies from person to
person and project to project.  I think the way to satisfy the people
who want to know what but not how is through vehicles like PWN and
blog postings.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres 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] max_standby_delay considered harmful

[Robert Haas]

On Wed, May 12, 2010 at 3:36 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote:
 Excerpts from Stefan Kaltenbrunner's message of mié may 12 15:10:28 -0400 
 2010:

 the startup process has the following backtrace:

 (gdb) bt
 #0  0x7fbe24cb2c83 in select () from /lib/libc.so.6
 #1  0x006e811a in pg_usleep ()
 #2  0x0048c333 in XLogPageRead ()
 #3  0x0048c967 in ReadRecord ()
 #4  0x00493ab6 in StartupXLOG ()
 #5  0x00495a88 in StartupProcessMain ()
 #6  0x004ab25e in AuxiliaryProcessMain ()
 #7  0x005d4a7d in StartChildProcess ()
 #8  0x005d70c2 in PostmasterMain ()
 #9  0x0057d898 in main ()

 I just noticed that we have some code assigning the return value of
 time() to a pg_time_t variable.  Is this supposed to work reliably?
 (xlog.c lines 9267ff)

I'

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres 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] Tags missing from GIT mirror?

[Andrew Dunstan]

David Christensen wrote:


Is there anything to do about the missing tags in git?  I've wished for those 
to be available as well.


  


Sure, fix fromcvs  to emit them. How is your ruby?

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

[HACKERS] Re: [COMMITTERS] pgsql: Add PGFILEDESC description to Makefiles for all /contrib

[Bruce Momjian]

Tom Lane wrote:
 Bruce Momjian br...@momjian.us writes:
  Tom Lane wrote:
  momj...@postgresql.org (Bruce Momjian) writes:
  Add PGAPPICON to all executable makefiles.
  
  Is it really a good idea to have done that to the server, in particular?
  I can't imagine it being a good idea to launch the postmaster from a
  GUI, which is what I suppose this is good for.
 
  Well, I assume this was the icon, which I assumed should match for all
  the binaries, as compared to config files, for example.
 
 Er... why are you committing undiscussed patches if you just assume
 they will work, or indeed do anything useful at all?  You should not
 have touched this if you don't know exactly what it will do and why
 changing it is a good thing.

All other binaries had such a designation, and all /contrib binaries
were missing them.  I assume I was doing cleanup.  You want the icon
removed from the backend makefile?  I can easily do it.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://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] max_standby_delay considered harmful

[Robert Haas]

On Wed, May 12, 2010 at 3:51 PM, Robert Haas robertmh...@gmail.com wrote:
 On Wed, May 12, 2010 at 3:36 PM, Alvaro Herrera alvhe...@alvh.no-ip.org 
 wrote:
 Excerpts from Stefan Kaltenbrunner's message of mié may 12 15:10:28 -0400 
 2010:

 the startup process has the following backtrace:

 (gdb) bt
 #0  0x7fbe24cb2c83 in select () from /lib/libc.so.6
 #1  0x006e811a in pg_usleep ()
 #2  0x0048c333 in XLogPageRead ()
 #3  0x0048c967 in ReadRecord ()
 #4  0x00493ab6 in StartupXLOG ()
 #5  0x00495a88 in StartupProcessMain ()
 #6  0x004ab25e in AuxiliaryProcessMain ()
 #7  0x005d4a7d in StartChildProcess ()
 #8  0x005d70c2 in PostmasterMain ()
 #9  0x0057d898 in main ()

 I just noticed that we have some code assigning the return value of
 time() to a pg_time_t variable.  Is this supposed to work reliably?
 (xlog.c lines 9267ff)

 I'

I have a love-hate relationship with GMail, sorry.

I am wondering if we are not correctly handling the case where we get
a shutdown request while we are still in the PM_STARTUP state.  It
looks like we might go ahead and switch to PM_RECOVERY and then
PM_RECOVERY_CONSISTENT without noticing the shutdown.  There is some
logic to handle the shutdown when the startup process exits, but if
the startup process never exits it looks like we might get stuck.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres 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] [COMMITTERS] pgsql: Add PGFILEDESC description to Makefiles for all /contrib

[Tom Lane]

Bruce Momjian br...@momjian.us writes:
 All other binaries had such a designation, and all /contrib binaries
 were missing them.  I assume I was doing cleanup.  You want the icon
 removed from the backend makefile?

Yes.  I'm prepared to believe that not having the icons set on the
contrib executables was an oversight.  I'm much less prepared to assume
that not marking the postgres executable was an oversight.  Again,
unless you *know* that this change is needed and appropriate, now is
not the time to be making it, and especially not without discussion.

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] Tags missing from GIT mirror?

[Florian Pflug]

On May 12, 2010, at 21:52 , Andrew Dunstan wrote:
 David Christensen wrote:
 
 Is there anything to do about the missing tags in git?  I've wished for 
 those to be available as well.
 
 
 Sure, fix fromcvs  to emit them. How is your ruby?


Where does one find the version of fromcvs used to feed git.postgresql.org? I 
might give it a shot.

I can't promise anything, though - my ruby-fu is OK, but my cvs-fu is badly 
lacking...

best regards,
Florian Pflug


-- 
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] Tags missing from GIT mirror?

[Tom Lane]

Andrew Dunstan and...@dunslane.net writes:
 David Christensen wrote:
 Is there anything to do about the missing tags in git?  I've wished for 
 those to be available as well.

 Sure, fix fromcvs  to emit them. How is your ruby?

Per Magnus' comment, there isn't anything missing.  We don't make
branches for beta releases.  (Personally I'm thinking that having stub
branches for the alphas was a mistake too --- obviously, it's leading to
confusion.)

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] pg_dump should not try CREATE OR REPLACE LANGUAGE 9.0

[Tom Lane]

Greg Sabino Mullane g...@turnstep.com writes:
 Subject line kind of says it all: LANGUAGE replacement was 
 introduced in 9.0, but pg_dump is trying it on all versions.

So?  pg_dump output is never promised to load into older server
versions.

The proposed patch is quite wrong anyway, because it is looking at
the source server version, not the (unknowable) target version.

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] Tags missing from GIT mirror?

[Andrew Dunstan]

Florian Pflug wrote:

On May 12, 2010, at 21:52 , Andrew Dunstan wrote:
  

David Christensen wrote:


Is there anything to do about the missing tags in git?  I've wished for those 
to be available as well.

  

Sure, fix fromcvs  to emit them. How is your ruby?




Where does one find the version of fromcvs used to feed git.postgresql.org? I 
might give it a shot.

I can't promise anything, though - my ruby-fu is OK, but my cvs-fu is badly 
lacking...


  


Fix the tip version. You'll need fromcvs and rcsparse from 
http://ww2.fs.ei.tum.de/~corecode/hg. We already know that the version 
used on the community repo is broken. The version I am using on my 
github mirror is holding up OK. There is a recipe for setting up a 
mirror on my blog: 
http://people.planetpostgresql.org/andrew/index.php?/archives/74-Gory-details.html. 
Of course, we might also find some other brokenness if we try to import 
all the tags. Also, be aware of this (from 
http://cvs2svn.tigris.org/cvs2git.html):


   Differences between CVS and git branch/tag models: CVS allows a
   branch or tag to be created from arbitrary combinations of source
   revisions from multiple source branches. It even allows file
   revisions that were never contemporaneous to be added to a single
   branch/tag. Git, on the other hand, only allows the full source
   tree, as it existed at some instant in the history, to be branched
   or tagged as a unit. Moreover, the ancestry of a git revision makes
   implications about the contents of that revision. This difference
   means that it is fundamentally impossible to represent an arbitrary
   CVS history in a git repository 100% faithfully. 



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] Tags missing from GIT mirror?

[Florian Pflug]

On May 12, 2010, at 22:03 , Tom Lane wrote:
 Andrew Dunstan and...@dunslane.net writes:
 David Christensen wrote:
 Is there anything to do about the missing tags in git?  I've wished for 
 those to be available as well.
 
 Sure, fix fromcvs  to emit them. How is your ruby?
 
 Per Magnus' comment, there isn't anything missing.  We don't make
 branches for beta releases.  (Personally I'm thinking that having stub
 branches for the alphas was a mistake too --- obviously, it's leading to
 confusion.)

Yeah, but CVS has tags for the alphas and betas. Those are missing from the GIT 
mirror as the CVS-to-GIT converter apparently ignores tags completely :-(. 
Since there are no branches for the betas, this leaves the GIT repository 
without any trace that beta1 exists at all...

So there is nothing wrong with the CVS, but on the GIT side there is certainly 
room for improvement.

best regards,
Florian Pflug


-- 
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] Tags missing from GIT mirror?

[Tom Lane]

Florian Pflug f...@phlo.org writes:
 Yeah, but CVS has tags for the alphas and betas. Those are missing from the 
 GIT mirror as the CVS-to-GIT converter apparently ignores tags completely 
 :-(. Since there are no branches for the betas, this leaves the GIT 
 repository without any trace that beta1 exists at all...

Really?  Then it wouldn't know about any past point-releases either :-(

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] Tags missing from GIT mirror?

[Andrew Dunstan]

Tom Lane wrote:

Andrew Dunstan and...@dunslane.net writes:
  

David Christensen wrote:


Is there anything to do about the missing tags in git?  I've wished for those 
to be available as well.
  


  

Sure, fix fromcvs  to emit them. How is your ruby?



Per Magnus' comment, there isn't anything missing.  We don't make
branches for beta releases.  (Personally I'm thinking that having stub
branches for the alphas was a mistake too --- obviously, it's leading to
confusion.)


  


What's missing is a non branch tag. It's there in CVS and not in the git 
repos.


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] Tags missing from GIT mirror?

[Andrew Dunstan]

Tom Lane wrote:

Florian Pflug f...@phlo.org writes:
  

Yeah, but CVS has tags for the alphas and betas. Those are missing from the GIT 
mirror as the CVS-to-GIT converter apparently ignores tags completely :-(. 
Since there are no branches for the betas, this leaves the GIT repository 
without any trace that beta1 exists at all...



Really?  Then it wouldn't know about any past point-releases either :-(


  


Presumably when we cut over to git properly, we will use some other tool 
that does import non-branch tags.  But for now fromcvs is effectively 
the only game in town for incremental mirroring. Of course, if someone 
fixed it to handle tags that would be cool ...


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

[HACKERS] Re: [ANNOUNCE] Bug-fix and new feature of pg_lesslog is released

[Bruce Momjian]

Koichi Suzuki wrote:
 It is an announcement that long-waited bug-fix of pg_lesslog is now
 released.   This includes the following.
 
 1. Error in calculation of GiST-related WAL record length was fixed.
 2. pg_compresslog now has an option to print WAL segment analysis.
 3. New test script is added which analyzes what WAL record was
 generated and if all the recovery was done successfully.
 
 2 and 3 are added to ensure the tools run correctly.
 
 Because 8.4 has additional WAL records, I made release material
 separate for each PG version.   You may visit the project page
 http://pgfoundry.org/frs/?group_id=1000310
 to download materials.
 
 I acknowledge PG hackers who gave valuable comments/advices.
 Especially Oleg Bartunov, Teodor Sigaev and Alvaro Herrera gave very
 helpful information how to generate specific type of WAL records.
 
 As Bruce suggested, this can be included in PostgreSQL test suits and
 could be included in contrib module if it is ported to PostgreSQL 9.1.

[ email to hackers list only ]

Yes, I would love to get this into /contrib for PG 9.1!

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://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] Tags missing from GIT mirror?

[Florian Pflug]

On 12.05.2010, at 22:22, Tom Lane t...@sss.pgh.pa.us wrote:


Florian Pflug f...@phlo.org writes:
Yeah, but CVS has tags for the alphas and betas. Those are missing  
from the GIT mirror as the CVS-to-GIT converter apparently ignores  
tags completely :-(. Since there are no branches for the betas,  
this leaves the GIT repository without any trace that beta1 exists  
at all...


Really?  Then it wouldn't know about any past point-releases  
either :-(


It doesn't :-(

Best regards
Florian Pflug


--
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: [ANNOUNCE] Bug-fix and new feature of pg_lesslog is released

[Tom Lane]

Bruce Momjian br...@momjian.us writes:
 Yes, I would love to get this into /contrib for PG 9.1!

How much are people really going to care about pg_lesslog now that
we've got streaming replication?  There might be some small use-case
still left, but it's hard to believe that it would be worth carrying
it in contrib.

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: [ANNOUNCE] Bug-fix and new feature of pg_lesslog is released

[Magnus Hagander]

On Wed, May 12, 2010 at 11:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Bruce Momjian br...@momjian.us writes:
 Yes, I would love to get this into /contrib for PG 9.1!

 How much are people really going to care about pg_lesslog now that
 we've got streaming replication?  There might be some small use-case
 still left, but it's hard to believe that it would be worth carrying
 it in contrib.

Until we have a tool to use streaming replication to actually archive
backups, there's still a fairly large usecase for it...


-- 
 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: [ANNOUNCE] Bug-fix and new feature of pg_lesslog is released

[Joshua D. Drake]

On Wed, 2010-05-12 at 23:09 +0200, Magnus Hagander wrote:
 On Wed, May 12, 2010 at 11:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
  Bruce Momjian br...@momjian.us writes:
  Yes, I would love to get this into /contrib for PG 9.1!
 
  How much are people really going to care about pg_lesslog now that
  we've got streaming replication?  There might be some small use-case
  still left, but it's hard to believe that it would be worth carrying
  it in contrib.
 
 Until we have a tool to use streaming replication to actually archive
 backups, there's still a fairly large usecase for it...

Not to mention, WAN based standby, timed standby etc...


Joshua D. Drake

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


-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering



-- 
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: [ANNOUNCE] Bug-fix and new feature of pg_lesslog is released

[Josh Berkus]

 Until we have a tool to use streaming replication to actually archive
 backups, there's still a fairly large usecase for it...

yes, pglesslog is for PITR.  We have a client who keeps 3 days of log
files a time for forensic reasons, and I doubt they're the only one.

-- 
  -- 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] max_standby_delay considered harmful

[Simon Riggs]

On Wed, 2010-05-12 at 14:43 -0400, Robert Haas wrote:

 I thought that it
 would be a good idea for Simon to look at it because, on the surface,
 it APPEARS to have something to do with Hot Standby, since that's what
 Stefan was testing when he found it.

He was also testing SR, yet you haven't breathed a word about that for
some strange reason. It didn't APPEAR like it was HS at all, not from
basic logic or from technical knowledge. So you'll have to forgive me if
I don't leap into action when you say something is an HS problem in the
future.

-- 
 Simon Riggs   www.2ndQuadrant.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] max_standby_delay considered harmful

[Josh Berkus]

Simon, Robert,

 He was also testing SR, yet you haven't breathed a word about that for
 some strange reason. It didn't APPEAR like it was HS at all, not from
 basic logic or from technical knowledge. So you'll have to forgive me if
 I don't leap into action when you say something is an HS problem in the
 future.

Can we please chill out on this some?  Especially since we now have an
actual reproduceable bug?

Simon, it's natural for people to come to you because you are
knowledgeable and responsive.  You should take it as a compliment.

-- 
  -- 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] max_standby_delay considered harmful

[Joshua D. Drake]

On Wed, 2010-05-12 at 22:34 +0100, Simon Riggs wrote:
 On Wed, 2010-05-12 at 14:43 -0400, Robert Haas wrote:
 
  I thought that it
  would be a good idea for Simon to look at it because, on the surface,
  it APPEARS to have something to do with Hot Standby, since that's what
  Stefan was testing when he found it.
 
 He was also testing SR, yet you haven't breathed a word about that for
 some strange reason. It didn't APPEAR like it was HS at all, not from
 basic logic or from technical knowledge. So you'll have to forgive me if
 I don't leap into action when you say something is an HS problem in the
 future.

Simon, with respect -- knock it off. 

Robert gave a very reasonable response. He is just trying to help. Relax
man.

Joshua Drake



-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering



-- 
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: Add PGFILEDESC description to Makefiles for all /contrib

[Bruce Momjian]

Tom Lane wrote:
 Bruce Momjian br...@momjian.us writes:
  All other binaries had such a designation, and all /contrib binaries
  were missing them.  I assume I was doing cleanup.  You want the icon
  removed from the backend makefile?
 
 Yes.  I'm prepared to believe that not having the icons set on the
 contrib executables was an oversight.  I'm much less prepared to assume
 that not marking the postgres executable was an oversight.  Again,
 unless you *know* that this change is needed and appropriate, now is
 not the time to be making it, and especially not without discussion.

OK, done with attached patch, and I added a comment about why it is not
labeled.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com
Index: src/backend/Makefile
===
RCS file: /cvsroot/pgsql/src/backend/Makefile,v
retrieving revision 1.142
diff -c -c -r1.142 Makefile
*** src/backend/Makefile	12 May 2010 11:33:09 -	1.142
--- src/backend/Makefile	12 May 2010 21:41:14 -
***
*** 10,16 
  #-
  
  PGFILEDESC = PostgreSQL Server
! PGAPPICON=win32
  
  subdir = src/backend
  top_builddir = ../..
--- 10,17 
  #-
  
  PGFILEDESC = PostgreSQL Server
! # it is unclear that this should be labeled as an executable
! #PGAPPICON=win32
  
  subdir = src/backend
  top_builddir = ../..

-- 
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] primary/secondary/master/slave/standby

[Bruce Momjian]

Tom Lane wrote:
 Peter Eisentraut pete...@gmx.net writes:
  The server's messages and the documentation uses all of these terms in
  mixed ways.  Maybe we could decide on some preferred terminology and
  adjust the existing texts.  Ideas?
 
 Primary/secondary seem like a poor choice because they're such generic
 terms.  Master/slave is the common terminology for this, I think,
 though some might object on grounds of political incorrectness.
 If so, master/standby would probably work.

I have always been unclear if a slave indicates it accepts read-only
queries, i.e. are slave and standby interchangable?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://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] pg_upgrade versus MSVC build scripts

[Bruce Momjian]

Tom Lane wrote:
 A look at the MSVC buildfarm members shows that they are not building
 most of the files added to contrib/pg_upgrade.  The reason seems to be
 that that module tries to build both an executable program *and* a
 shared library, which it does by dint of setting both PROGRAM and
 MODULES in its Makefile.  Now that is a dirty hack that is nowhere
 documented to work, and in fact the pgxs documentation explicitly says
 not to do that.  It accidentally fails to fail, at the moment, because
 of the way pgxs.mk is set up, and because the OBJS variable is only
 needed for one of these targets.  But the MSVC build scripts aren't
 expecting this and evidently disregard PROGRAM after they see MODULES.

Yeah, I was stumped by the problem of creating an executable and shared
object and didn't find any usage of this case.  Leave it me to find a
loop-hole.  ;-)

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://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] pg_upgrade versus MSVC build scripts

[Bruce Momjian]

Tom Lane wrote:
 Andrew Dunstan and...@dunslane.net writes:
  Tom Lane wrote:
  Alvaro Herrera alvhe...@alvh.no-ip.org writes:
  Do you mean contrib/pg_upgrade/somelib?  If so, +1.
  
  Hmm.  I had been thinking the other way, but I'll see if that can be
  made to work.
 
  Not sure this will work on its own with the MSVC build system - I don't 
  think it's set up for sub-modules.
 
 Oh, right.  Since the entire point here is to *not* require new
 buildsystem infrastructure for pg_upgrade, I'm back to thinking that
 a separate contrib module is the way to go.

Uh, if you do 'make install' in the pg_upgrade directory, would it also
install the shared lib contrib?  If not, it seems kind of complicated
from a user perspective.  Can't we pass a 'make' down into a
subdirectory and have a separate Makefile just run?  pg_migrator had
this rule:

all install installdirs uninstall distprep clean distclean 
maintainer-clean:
$(MAKE) -C src $@
$(MAKE) -C func $@


-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://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] pg_upgrade versus MSVC build scripts

[Tom Lane]

Bruce Momjian br...@momjian.us writes:
 Uh, if you do 'make install' in the pg_upgrade directory, would it also
 install the shared lib contrib?  If not, it seems kind of complicated
 from a user perspective.  Can't we pass a 'make' down into a
 subdirectory and have a separate Makefile just run?

No.  You're still failing to consider the MSVC build case.

I think that anyone who can cope with building pg_upgrade from source
can deal with building pg_upgrade_sysoids in addition, especially if
the documentation tells him to.  In practice, 99% of users just build
(or install) all of contrib/ at once, I think, so it's unlikely to
affect them much anyway.

I understand your desire to save one step in the build process, but
I don't think it's worth contorting our build system for --- especially
since pg_migrator isn't likely to stay in contrib indefinitely.

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] pg_upgrade versus MSVC build scripts

[Andrew Dunstan]

Bruce Momjian wrote:

Can't we pass a 'make' down into a
subdirectory and have a separate Makefile just run?  pg_migrator had
this rule:

all install installdirs uninstall distprep clean distclean 
maintainer-clean:
$(MAKE) -C src $@
$(MAKE) -C func $@

  


Yes, you can on Unix, of course. But I'm pretty sure it won't work with 
the MSVC build system.


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] pg_upgrade versus MSVC build scripts

[Bruce Momjian]

Tom Lane wrote:
 Bruce Momjian br...@momjian.us writes:
  Uh, if you do 'make install' in the pg_upgrade directory, would it also
  install the shared lib contrib?  If not, it seems kind of complicated
  from a user perspective.  Can't we pass a 'make' down into a
  subdirectory and have a separate Makefile just run?
 
 No.  You're still failing to consider the MSVC build case.
 
 I think that anyone who can cope with building pg_upgrade from source
 can deal with building pg_upgrade_sysoids in addition, especially if
 the documentation tells him to.  In practice, 99% of users just build
 (or install) all of contrib/ at once, I think, so it's unlikely to
 affect them much anyway.

If we make it /contrib/pg_upgrade_shlibs, will it need a documentation
page?  Can I built multiple shared libs in there if needed?  If we put
it under /contrib/pg_upgrade, can it still be a separate build step? 
Would that work?

 I understand your desire to save one step in the build process, but
 I don't think it's worth contorting our build system for --- especially
 since pg_migrator isn't likely to stay in contrib indefinitely.

OK.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://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] pg_upgrade versus MSVC build scripts

[Tom Lane]

Bruce Momjian br...@momjian.us writes:
 If we make it /contrib/pg_upgrade_shlibs, will it need a documentation
 page?

I don't see a need for that.  Also, why would you make the directory
name different from the name of the shlib it's building --- or are
you having second thoughts about the present name?

 Can I built multiple shared libs in there if needed?

No, but why would you need more than one?  What you might need
(and can't have with the present hack) is more than one .o file
getting built into the shared library.

 If we put
 it under /contrib/pg_upgrade, can it still be a separate build step? 
 Would that work?

Isn't that the same idea you just proposed?

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] max_standby_delay considered harmful

[Robert Haas]

On Wed, May 12, 2010 at 5:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
 On Wed, 2010-05-12 at 14:43 -0400, Robert Haas wrote:

 I thought that it
 would be a good idea for Simon to look at it because, on the surface,
 it APPEARS to have something to do with Hot Standby, since that's what
 Stefan was testing when he found it.

 He was also testing SR, yet you haven't breathed a word about that for
 some strange reason. It didn't APPEAR like it was HS at all, not from
 basic logic or from technical knowledge. So you'll have to forgive me if
 I don't leap into action when you say something is an HS problem in the
 future.

Well, the original subject line of the report had mentioned SR only,
but I had a specific theory about what might be happening that was
related to the operation of HS.  You've said that you think my guess
is incorrect, and that's very possible, but until we actually find and
fix the bug we're all just guessing.  I wasn't intending to cast
aspersions on your code.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres 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] pg_upgrade versus MSVC build scripts

[Bruce Momjian]

Tom Lane wrote:
 Bruce Momjian br...@momjian.us writes:
  If we make it /contrib/pg_upgrade_shlibs, will it need a documentation
  page?
 
 I don't see a need for that.  Also, why would you make the directory
 name different from the name of the shlib it's building --- or are
 you having second thoughts about the present name?

Well, previously I needed separate shared objects because I didn't know
what _new_ backend version I would be linking to and the symbols could
be different.  I actually dynamically linked in different SO's for
different major versions.

Now that it only targets the packaged version, I can do with a single
shared object, but maybe it needs to be more generic, like
pg_upgrade_tools.so or something like that.

  Can I built multiple shared libs in there if needed?
 
 No, but why would you need more than one?  What you might need
 (and can't have with the present hack) is more than one .o file
 getting built into the shared library.

Again, I used to need this, but I don't now.

  If we put
  it under /contrib/pg_upgrade, can it still be a separate build step? 
  Would that work?
 
 Isn't that the same idea you just proposed?

I realize we need a separate pgxs makefile for the executable and shared
libraries.  My question was whether the shared library directory should
be under /contrib or under /contrib/pg_upgrade.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://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] pg_upgrade versus MSVC build scripts

[Tom Lane]

Bruce Momjian br...@momjian.us writes:
 Now that it only targets the packaged version, I can do with a single
 shared object, but maybe it needs to be more generic, like
 pg_upgrade_tools.so or something like that.

+1 for pg_upgrade_tools or pg_upgrade_support or some such name.

 I realize we need a separate pgxs makefile for the executable and shared
 libraries.  My question was whether the shared library directory should
 be under /contrib or under /contrib/pg_upgrade.

It has to be directly under /contrib, because the MSVC build scripts
only look there for contrib modules to build.

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] pg_upgrade versus MSVC build scripts

[Bruce Momjian]

Tom Lane wrote:
 Bruce Momjian br...@momjian.us writes:
  Now that it only targets the packaged version, I can do with a single
  shared object, but maybe it needs to be more generic, like
  pg_upgrade_tools.so or something like that.
 
 +1 for pg_upgrade_tools or pg_upgrade_support or some such name.

I like 'pg_upgrade_support'.  I could also do 'pg_upgrade_funcs'.

  I realize we need a separate pgxs makefile for the executable and shared
  libraries.  My question was whether the shared library directory should
  be under /contrib or under /contrib/pg_upgrade.
 
 It has to be directly under /contrib, because the MSVC build scripts
 only look there for contrib modules to build.

OK.  Should I get started?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://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] pg_upgrade versus MSVC build scripts

[David E. Wheeler]

On May 12, 2010, at 4:07 PM, Bruce Momjian wrote:

 I like 'pg_upgrade_support'.  I could also do 'pg_upgrade_funcs'.

I misread the second one at a glance, so I recommend the first.

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

[HACKERS] Re: [COMMITTERS] pgsql: Add PGFILEDESC description to Makefiles for all /contrib

[Bruce Momjian]

bruce wrote:
 Tom Lane wrote:
  Bruce Momjian br...@momjian.us writes:
   All other binaries had such a designation, and all /contrib binaries
   were missing them.  I assume I was doing cleanup.  You want the icon
   removed from the backend makefile?
  
  Yes.  I'm prepared to believe that not having the icons set on the
  contrib executables was an oversight.  I'm much less prepared to assume
  that not marking the postgres executable was an oversight.  Again,
  unless you *know* that this change is needed and appropriate, now is
  not the time to be making it, and especially not without discussion.
 
 OK, done with attached patch, and I added a comment about why it is not
 labeled.

I did some research on PGFILEDESC and it does what I thought it does ---
in embeds the 'ico' file into the executable in
/pg/tools/msvc/Project.pm, and the image looks like the attached JPEG.
The image is of a blue elephant head.

So, currently, every binary uses that icon, except for the postmaster.
Is that what we want?  You could make the argument that a daemon, like
the postmaster, shouldn't have one, which I think is Tom's point.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com
inline: /rtmp/mime.9550/win32.jpg
-- 
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] pg_upgrade versus MSVC build scripts

[Bruce Momjian]

Bruce Momjian wrote:
 Tom Lane wrote:
  Bruce Momjian br...@momjian.us writes:
   If we make it /contrib/pg_upgrade_shlibs, will it need a documentation
   page?
  
  I don't see a need for that.  Also, why would you make the directory
  name different from the name of the shlib it's building --- or are
  you having second thoughts about the present name?
 
 Well, previously I needed separate shared objects because I didn't know
 what _new_ backend version I would be linking to and the symbols could
 be different.  I actually dynamically linked in different SO's for
 different major versions.
 
 Now that it only targets the packaged version, I can do with a single
 shared object, but maybe it needs to be more generic, like
 pg_upgrade_tools.so or something like that.

FYI, to be more explicit, with the pgFoundry code, I didn't know what
target major PG version I would be linking to, so I needed different
shared object files because there were some symbols that would only
resolve to specific backend versions.  I would probe the target major
version and link in the matching shared object file.  This was
particularly common for Win32 binaries.

That is no longer an issue with /contrib.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://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] List traffic

[Marc G. Fournier]

On Wed, 12 May 2010, Greg Stark wrote:

I'm thinking I'll move -general (and the useless -novice) to another 
folder. But I'm left wondering what to do with -admin and -performance. 
They're a random mix of user content and developer content. I'll 
probably move them along with -general but that means I won't be likely 
to see any development discussion on them in the future


There shouldn't be any dev discussions on them as it is ... that isn't 
their mandate ... those are/were meant to be end-user lists, not 
developer ones ...



Marc G. FournierHub.Org Hosting Solutions S.A.
scra...@hub.org http://www.hub.org

Yahoo:yscrappySkype: hub.orgICQ:7615664MSN:scra...@hub.org

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

[HACKERS] How to know killed by pg_terminate_backend

[Tatsuo Ishii]

Hi,

If a backend killed by pg_terminate_backend(), the backend returns
57P01 which is identical to the one when it's killed by postmaster.

Problem is, pgpool-II needs to trigger failover if postmaster goes
down because apparently pgpool-II cannot use the PostgreSQL server
anymore.

On the otherhand, pg_terminate_backend() just terminates a backend. So
triggering failover is overkill.

Maybe we could make PostgreSQL a little bit smarter so that it returns
a different code than 57P01 when killed by pg_terminate_backend().

Comments?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

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

[HACKERS] Stefan's bug (was: max_standby_delay considered harmful)

[Robert Haas]

On Wed, May 12, 2010 at 3:55 PM, Robert Haas robertmh...@gmail.com wrote:
 I am wondering if we are not correctly handling the case where we get
 a shutdown request while we are still in the PM_STARTUP state.  It
 looks like we might go ahead and switch to PM_RECOVERY and then
 PM_RECOVERY_CONSISTENT without noticing the shutdown.  There is some
 logic to handle the shutdown when the startup process exits, but if
 the startup process never exits it looks like we might get stuck.

I can reproduce the behavior Stefan is seeing consistently using the
attached patch.

W1: postgres -D ~/pgslave
W2: pg_ctl -D ~/pgslave stop

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


breakit.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] primary/secondary/master/slave/standby

[Robert Haas]

On Wed, May 12, 2010 at 5:44 PM, Bruce Momjian br...@momjian.us wrote:
 Tom Lane wrote:
 Peter Eisentraut pete...@gmx.net writes:
  The server's messages and the documentation uses all of these terms in
  mixed ways.  Maybe we could decide on some preferred terminology and
  adjust the existing texts.  Ideas?

 Primary/secondary seem like a poor choice because they're such generic
 terms.  Master/slave is the common terminology for this, I think,
 though some might object on grounds of political incorrectness.
 If so, master/standby would probably work.

 I have always been unclear if a slave indicates it accepts read-only
 queries, i.e. are slave and standby interchangable?

We had a long discussion of this topic last summer:

http://archives.postgresql.org/pgsql-hackers/2009-08/msg00870.php

I still think Peter's right, but there were contrary opinions.  Still,
the discussion is an interesting read.

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

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