Re: [BUGS] BUG #7533: Client is not able to connect cascade standby incase basebackup is taken from hot standby
On 12.09.2012 22:03, Fujii Masao wrote: On Wed, Sep 12, 2012 at 8:47 PM, wrote: The following bug has been logged on the website: Bug reference: 7533 Logged by: Amit Kapila Email address: amit.kap...@huawei.com PostgreSQL version: 9.2.0 Operating system: Suse Description: M host is primary, S host is standby and CS host is cascaded standby. 1.Set up postgresql-9.2beta2/RC1 on all hosts. 2.Execute command initdb on host M to create fresh database. 3.Modify the configure file postgresql.conf on host M like this： listen_addresses = 'M' port = 15210 wal_level = hot_standby max_wal_senders = 4 hot_standby = on 4.modify the configure file pg_hba.conf on host M like this： host replication repl M/24md5 5.Start the server on host M as primary. 6.Connect one client to primary server and create a user ‘repl’ Create user repl superuser password '123'; 7.Use the command pg_basebackup on the host S to retrieve database of primary host pg_basebackup -D /opt/t38917/data -F p -x fetch -c fast -l repl_backup -P -v -h M -p 15210 -U repl –W 8. Copy one recovery.conf.sample from share folder of package to database folder of the host S. Then rename this file to recovery.conf 9.Modify the file recovery.conf on host S as below: standby_mode = on primary_conninfo = 'host=M port=15210 user=repl password=123' 10. Modify the file postgresql.conf on host S as follow: listen_addresses = 'S' 11.Start the server on host S as standby server. 12.Use the command pg_basebackup on the host CS to retrieve database of standby host pg_basebackup -D /opt/t38917/data -F p -x fetch -c fast -l repl_backup -P -v -h M -p 15210 -U repl –W 13.Modify the file recovery.conf on host CS as below: standby_mode = on primary_conninfo = 'host=S port=15210 user=repl password=123' 14. Modify the file postgresql.conf on host S as follow: listen_addresses = 'CS' 15.Start the server on host CS as Cascaded standby server node. 16. Try to connect a client to host CS but it gives error as: FATAL: the database system is starting up This procedures didn't reproduce the problem in HEAD. But when I restarted the master server between the step 11 and 12, I was able to reproduce the problem. Observations related to bug -- In the above scenario it is observed that Start-up process has read all data (in our defect scenario minRecoveryPoint is 5016220) till the position 5016220 and then it goes and check for recovery consistency by following condition in function CheckRecoveryConsistency: if (!reachedConsistency&& XLByteLE(minRecoveryPoint, EndRecPtr)&& XLogRecPtrIsInvalid(ControlFile->backupStartPoint)) At this point first two conditions are true but last condition is not true because still redo has not been applied and hence backupStartPoint has not been reset. So it does not signal postmaster regarding consistent stage. After this it goes and applies the redo and then reset backupStartPoint and then it goes to read next set of record. Since all records have been already read, so it starts waiting for the new record from the Standby node. But since there is no new record from Standby node coming so it keeps waiting for that and it does not get chance to recheck the recovery consistent level. And hence client connection does not get allowed. If cascaded standby starts a recovery at a normal checkpoint record, this problem will not happen. Because if wal_level is set to hot_standby, XLOG_RUNNING_XACTS WAL record always follows after the normal checkpont record. So while XLOG_RUNNING_XACTS record is being replayed, ControlFile->backupStartPoint can be reset, and then cascaded standby can pass through the consistency test. The problem happens when cascaded standby starts a recovery at a shutdown checkpoint record. In this case, no WAL record might follow the checkpoint one yet. So, after replaying the shutdown checkpoint record, cascaded standby needs to wait for new WAL record to appear before reaching the code block for resetting ControlFile->backupStartPoint. The cascaded standby cannot reach a consistent state and a client cannot connect to the cascaded standby until new WAL has arrived. Attached patch will fix the problem. In this patch, if recovery is beginning at a shutdown checkpoint record, any ControlFile fields (like backupStartPoint) required for checking that an end-of-backup is reached are not set at first. IOW, cascaded standby thinks that the database is consistent from the beginning. This is safe because a shutdown checkpoint record means that there is no running database activity at that point and the database is in consistent state. Hmm, I think the CheckRecoveryConsistency() call in the redo loop is misplaced. It's called after we got a record from ReadRecord, but *before* replaying it (rm_redo). Even if replaying record X makes the sy
Re: [BUGS] BUG #7533: Client is not able to connect cascade standby incase basebackup is taken from hot standby
On Thursday, September 13, 2012 5:52 PM Heikki Linnakangas wrote: On 12.09.2012 22:03, Fujii Masao wrote: > On Wed, Sep 12, 2012 at 8:47 PM, wrote: >> The following bug has been logged on the website: >> >>> Bug reference: 7533 >>> Logged by: Amit Kapila >>> Email address: amit.kap...@huawei.com >>> PostgreSQL version: 9.2.0 >>> Operating system: Suse >>> Description: >> >>> M host is primary, S host is standby and CS host is cascaded standby. >> >Hmm, I think the CheckRecoveryConsistency() call in the redo loop is >misplaced. It's called after we got a record from > ReadRecord, but *before* replaying it (rm_redo). Even if replaying record X > makes the system consistent, we won't check > and notice that until we have fetched record X+1. In this particular test > case, record X is a shutdown checkpoint > record, but it could as well be a running-xacts record, or the record that > reaches minRecoveryPoint. > Does the problem go away if you just move the CheckRecoveryConsistency() call > *after* rm_redo (attached)? This will resolve the problem I have reported but moving down might create another problem as due to function recoveryPauseHere(), the recovery might get paused and in current code a client might be able to connect even in that state as CheckRecoveryConsistency() is done before that. However after suggested change it might happen that Client will not be able to connect. If you see any problem in what I explain then can we think of calling CheckRecoveryConsistency() both at current place and the place you have proposes. If my description doesn't make any sense (as that is only my suspicion) then we can move the function down and fix the defect. Thank you for giving so quick response about the defect. With Regards, Amit Kapila. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
Alvaro Herrera writes: > Well, what I saw was that both the table and its SERIAL-generated > sequence got an DEPENDENCY_EXTENSION row in pg_depend, which is exactly > what (IMV) causes the problem. One of my proposals is to tweak the code > to avoid that row (but if we do that, then we need to do something about > databases that contain such rows today). Ah yes, indeed. I think we shouldn't change the content of pg_depend lightly here, and that we should rather specialize AlterObjectNamespace_oid() to skip caring about sequences. The other objects that get moved by AlterTableNamepace other than the table itself and its sequences are Indexes and Constraints. Owned Sequence (serial) will get cared of by the extension dependency walking code. I'm going to have a try at that. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case)
On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis wrote: > This bug seems particularly troublesome because the right fix would be > to include the relpersistence in the WAL records that need it. But that > can't be backported (right?). No, because if a WAL record was written at all, then by definition the table is RELPERSISTENCE_PERMANENT. So there's probably a localized fix. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6704: ALTER EXTENSION postgis SET SCHEMA leaves dangling relations
Dimitri Fontaine writes:
> I think we shouldn't change the content of pg_depend lightly here, and
So here's a patch following that idea.
Even for TIP I don't want us to change how pg_depend tracking is done,
because I want to propose a fix for the pg_dump bug wrt sequences and
pg_extension_config_dump() wherein you can actually register a sequence
(owned by a table or not) but then pg_dump fails to dump it (see report
from Marko Kreen)
http://archives.postgresql.org/message-id/cacmqxcjjauc9jpa64vxskrn67byjuymodz-mgy-_aoz6erg...@mail.gmail.com
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
*** a/src/backend/commands/alter.c
--- b/src/backend/commands/alter.c
***
*** 18,23
--- 18,24
#include "catalog/dependency.h"
#include "catalog/indexing.h"
#include "catalog/namespace.h"
+ #include "catalog/pg_constraint.h"
#include "catalog/pg_largeobject.h"
#include "catalog/pg_namespace.h"
#include "commands/alter.h"
***
*** 268,278 AlterObjectNamespace_oid(Oid classId, Oid objid, Oid nspOid)
classRel = heap_open(RelationRelationId, RowExclusiveLock);
! AlterRelationNamespaceInternal(classRel,
! objid,
! oldNspOid,
! nspOid,
! true);
heap_close(classRel, RowExclusiveLock);
--- 269,282
classRel = heap_open(RelationRelationId, RowExclusiveLock);
! AlterRelationNamespace_oid(rel,
! classRel,
! objid,
! oldNspOid,
! nspOid,
! true,
! false,
! NULL);
heap_close(classRel, RowExclusiveLock);
*** a/src/backend/commands/tablecmds.c
--- b/src/backend/commands/tablecmds.c
***
*** 260,267 static void StoreCatalogInheritance(Oid relationId, List *supers);
static void StoreCatalogInheritance1(Oid relationId, Oid parentOid,
int16 seqNumber, Relation inhRelation);
static int findAttrByName(const char *attributeName, List *schema);
- static void AlterIndexNamespaces(Relation classRel, Relation rel,
- Oid oldNspOid, Oid newNspOid);
static void AlterSeqNamespaces(Relation classRel, Relation rel,
Oid oldNspOid, Oid newNspOid,
const char *newNspName, LOCKMODE lockmode);
--- 260,265
***
*** 9755,9761 AlterTableNamespace(AlterObjectSchemaStmt *stmt)
/* OK, modify the pg_class row and pg_depend entry */
classRel = heap_open(RelationRelationId, RowExclusiveLock);
! AlterRelationNamespaceInternal(classRel, relid, oldNspOid, nspOid, true);
/* Fix the table's row type too */
AlterTypeNamespaceInternal(rel->rd_rel->reltype, nspOid, false, false);
--- 9753,9789
/* OK, modify the pg_class row and pg_depend entry */
classRel = heap_open(RelationRelationId, RowExclusiveLock);
! AlterRelationNamespace_oid(rel,
! classRel,
! relid,
! oldNspOid,
! nspOid,
! true,
! true,
! stmt->newschema);
!
! heap_close(classRel, RowExclusiveLock);
!
! /* close rel, but keep lock until commit */
! relation_close(rel, NoLock);
! }
!
! /*
! * Relocating a relation to another namespace, and its related objects too.
! *
! * Extensions track both the main table and its owned sequences so it's not
! * necessary to alter the namespace of those sequences when doing ALTER
! * EXTENSION ... SET SCHEMA. alterSeqNamespaces is then false and newschema is
! * NULL.
! */
! void
! AlterRelationNamespace_oid(Relation rel, Relation classRel, Oid relOid,
! Oid oldNspOid, Oid nspOid,
! bool hasDependEntry,
! bool alterSeqNamespaces,
! char *newschema)
! {
! AlterRelationNamespaceInternal(classRel, relOid, oldNspOid, nspOid, true);
/* Fix the table's row type too */
AlterTypeNamespaceInternal(rel->rd_rel->reltype, nspOid, false, false);
***
*** 9764,9778 AlterTableNamespace(AlterObjectSchemaStmt *stmt)
if (rel->rd_rel->relkind == RELKIND_RELATION)
{
AlterIndexNamespaces(classRel, rel, oldNspOid, nspOid);
- AlterSeqNamespaces(classRel, rel, oldNspOid, nspOid, stmt->newschema,
- AccessExclusiveLock);
- AlterConstraintNamespaces(relid, oldNspOid, nspOid, false);
- }
-
- heap_close(classRel, RowExclusiveLock);
! /* close rel, but keep lock until commit */
! relation_close(rel, NoLock);
}
/*
--- 9792,9804
if (rel->rd_rel->relkind == RELKIND_RELATION)
{
AlterIndexNamespaces(classRel, rel, oldNspOid, nspOid);
! if (alterSeqNamespaces)
! AlterSeqNamespaces(classRel, rel, oldNspOid, nspOid,
! newschema,
! AccessExclusiveLock);
! AlterConstraintNamespaces(relOid, oldNspOid, nspOid, false);
! }
}
/*
***
*** 9826,9832 AlterRelationNamespaceInternal(Relation classRel, Oid relOid,
* Note: we assume adequate permission checking
Re: [BUGS] BUG #7533: Client is not able to connect cascade standby incase basebackup is taken from hot standby
On Thu, Sep 13, 2012 at 9:21 PM, Heikki Linnakangas wrote: > On 12.09.2012 22:03, Fujii Masao wrote: >> >> On Wed, Sep 12, 2012 at 8:47 PM, wrote: >>> >>> The following bug has been logged on the website: >>> >>> Bug reference: 7533 >>> Logged by: Amit Kapila >>> Email address: amit.kap...@huawei.com >>> PostgreSQL version: 9.2.0 >>> Operating system: Suse >>> Description: >>> >>> M host is primary, S host is standby and CS host is cascaded standby. >>> >>> 1.Set up postgresql-9.2beta2/RC1 on all hosts. >>> 2.Execute command initdb on host M to create fresh database. >>> 3.Modify the configure file postgresql.conf on host M like this： >>> listen_addresses = 'M' >>> port = 15210 >>> wal_level = hot_standby >>> max_wal_senders = 4 >>> hot_standby = on >>> 4.modify the configure file pg_hba.conf on host M like this： >>> host replication repl M/24md5 >>> 5.Start the server on host M as primary. >>> 6.Connect one client to primary server and create a user ‘repl’ >>>Create user repl superuser password '123'; >>> 7.Use the command pg_basebackup on the host S to retrieve database of >>> primary host >>> pg_basebackup -D /opt/t38917/data -F p -x fetch -c fast -l repl_backup >>> -P >>> -v -h M -p 15210 -U repl –W >>> 8. Copy one recovery.conf.sample from share folder of package to database >>> folder of the host S. Then rename this file to recovery.conf >>> 9.Modify the file recovery.conf on host S as below: >>> standby_mode = on >>> primary_conninfo = 'host=M port=15210 user=repl >>> password=123' >>> 10. Modify the file postgresql.conf on host S as follow: >>> listen_addresses = 'S' >>> 11.Start the server on host S as standby server. >>> 12.Use the command pg_basebackup on the host CS to retrieve database of >>> standby host >>> pg_basebackup -D /opt/t38917/data -F p -x fetch -c fast -l repl_backup >>> -P >>> -v -h M -p 15210 -U repl –W >>> 13.Modify the file recovery.conf on host CS as below: >>> standby_mode = on >>> primary_conninfo = 'host=S port=15210 user=repl password=123' >>> 14. Modify the file postgresql.conf on host S as follow: >>> listen_addresses = 'CS' >>> 15.Start the server on host CS as Cascaded standby server node. >>> 16. Try to connect a client to host CS but it gives error as: >>> FATAL: the database system is starting up >> >> >> This procedures didn't reproduce the problem in HEAD. But when I restarted >> the master server between the step 11 and 12, I was able to reproduce the >> problem. >> >>> Observations related to bug >>> -- >>> In the above scenario it is observed that Start-up process has read all >>> data >>> (in our defect scenario minRecoveryPoint is 5016220) till the position >>> 5016220 and then it goes and check for recovery consistency by following >>> condition in function CheckRecoveryConsistency: >>> if (!reachedConsistency&& >>> XLByteLE(minRecoveryPoint, EndRecPtr)&& >>> XLogRecPtrIsInvalid(ControlFile->backupStartPoint)) >>> >>> At this point first two conditions are true but last condition is not >>> true >>> because still redo has not been applied and hence backupStartPoint has >>> not >>> been reset. So it does not signal postmaster regarding consistent stage. >>> After this it goes and applies the redo and then reset backupStartPoint >>> and >>> then it goes to read next set of record. Since all records have been >>> already >>> read, so it starts waiting for the new record from the Standby node. But >>> since there is no new record from Standby node coming so it keeps waiting >>> for that and it does not get chance to recheck the recovery consistent >>> level. And hence client connection does not get allowed. >> >> >> If cascaded standby starts a recovery at a normal checkpoint record, >> this problem will not happen. Because if wal_level is set to hot_standby, >> XLOG_RUNNING_XACTS WAL record always follows after the normal >> checkpont record. So while XLOG_RUNNING_XACTS record is being replayed, >> ControlFile->backupStartPoint can be reset, and then cascaded standby >> can pass through the consistency test. >> >> The problem happens when cascaded standby starts a recovery at a >> shutdown checkpoint record. In this case, no WAL record might follow >> the checkpoint one yet. So, after replaying the shutdown checkpoint >> record, cascaded standby needs to wait for new WAL record to appear >> before reaching the code block for resetting >> ControlFile->backupStartPoint. >> The cascaded standby cannot reach a consistent state and a client cannot >> connect to the cascaded standby until new WAL has arrived. >> >> Attached patch will fix the problem. In this patch, if recovery is >> beginning at a shutdown checkpoint record, any ControlFile fields >> (like backupStartPoint) required for checking that an end-of-backup is >> reached are not set at first. IOW, c
[BUGS] BUG #7536: run arbitrary -c setup command before interaction [wishlist]
The following bug has been logged on the website: Bug reference: 7536 Logged by: Brad Bowman Email address: b...@bereft.net PostgreSQL version: 9.1.5 Operating system: linux Description: I'd like a -c (or -f) option that doesn't exit immediately. In my case, I'd like to setup an environment based on dynamic information (search_path, prompt, temp views, info displayed) and envisage doing it with a -c or similar. I haven't been able to find other ways to do this. PGOPTIONS and the new (9.2) PSQLRC would cover some of my needs. There is a related TODO item ( http://wiki.postgresql.org/wiki/Todo#psql ) Allow processing of multiple -f (file) options Perhaps allowing multiple -f -c and a fully interactive -f - would do psql -f setup.sql -c '..info' -f - -c '..summary' Thanks, hope this isn't just noise, Brad -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case)
On Thu, 2012-09-13 at 12:39 -0400, Robert Haas wrote: > On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis wrote: > > This bug seems particularly troublesome because the right fix would be > > to include the relpersistence in the WAL records that need it. But that > > can't be backported (right?). > > No, because if a WAL record was written at all, then by definition the > table is RELPERSISTENCE_PERMANENT. So there's probably a localized > fix. Oh, of course (I was worried there for some reason). I suppose we just need to set the relpersistence to permanent in CreateFakeRelcacheEntry, kind of like ReadBufferWithoutRelcache. And we should probably assert that both functions are only called during recovery (though perhaps redundant for CreateFakeRelcacheEntry, which is in xlogutils.c). Trivial patch attached. Regards, Jeff Davis fakerelcache.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
On Thu, Sep 13, 2012 at 1:22 PM, Amit Kapila wrote: > On Wednesday, September 12, 2012 10:15 PM Fujii Masao > On Wed, Sep 12, 2012 at 8:54 PM, wrote: >>> The following bug has been logged on the website: >>> >>> Bug reference: 7534 >>> Logged by: Amit Kapila >>> Email address: amit.kap...@huawei.com >>> PostgreSQL version: 9.2.0 >>> Operating system: Suse 10 >>> Description: >> >>> 1. Both master and standby machine are connected normally, >>> 2. then you use the command: ifconfig ip down; make the network card of >>> master and standby down, >> >>> Observation >>> master can detect connect abnormal, but the standby can't detect connect >>> abnormal and show a connected channel long time. > >> What about setting keepalives_xxx libpq parameters? >> > http://www.postgresql.org/docs/devel/static/libpq-connect.html#LIBPQ-PARAMKE > YWORDS > >> Keepalives are not a perfect solution for the termination of connection, > but >> it would help to a certain extent. > > We have tried by enabling keepalive, but it didn't worked maybe because > walreceiver is trying to send reveiver status. > It fails in sending that after many attempts of same. > >> If you need something like walreceiver-version of replication_timeout, > such feature has not been implemented yet. >> Please feel free to implement that! > > I would like to implement such feature for walreceiver, but there is one > confusion that whether to use > same configuration parameter(replication_timeout) for walrecevier as for > master or introduce a new > configuration parameter (receiver_replication_timeout). I like the latter. I believe some users want to set the different timeout values, for example, in the case where the master and standby servers are placed in the same room, but cascaded standby is placed in other continent. Regards, -- Fujii Masao -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7516: PL/Perl crash
Marko Tiikkaja writes: > On 9/12/12 1:50 AM, Tom Lane wrote: >> Marko Tiikkaja writes: >>> Joel Jacobson managed to narrow it down to this test case, which crashes >>> consistently on Ubuntu 12.04 both with and without your patch. I, >>> however, wasn't able to reproduce the problem on my OS X Mountain Lion. >> Doesn't reproduce for me either ... > Ok, I can reproduce it on my Ubuntu virtual machine. Hm, I wonder if it's Ubuntu-specific? What Perl version is that exactly? > What happens is that free_plperl_function() for some reason gets called > with the prodesc of func0003. Later on, func0003 wants to get rid of > his prodesc and I get a crash. What's weird about this is that > current_call_data->prodesc actually points to the correct prodesc (the > one of func0005), but still somehow something different is passed to > free_plperl_function(). The only theory that comes to mind is that current_call_data is somehow getting aliased (free'd and realloc'd). I don't see how that could happen, but it occurs to me that it's kinda dumb to be palloc'ing it in the first place. Its lifetime is exactly that of the call, so it would be simpler and more foolproof to make it a local variable. I've pushed a HEAD patch to do that, and I wonder if you could check whether it changes anything. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7516: PL/Perl crash
On 13/09/2012 19:48, Tom Lane wrote: Marko Tiikkaja writes: On 9/12/12 1:50 AM, Tom Lane wrote: Hm, I wonder if it's Ubuntu-specific? What Perl version is that exactly? We've reproduced it on both 5.14.2 and 5.16.1. What happens is that free_plperl_function() for some reason gets called with the prodesc of func0003. Later on, func0003 wants to get rid of his prodesc and I get a crash. What's weird about this is that current_call_data->prodesc actually points to the correct prodesc (the one of func0005), but still somehow something different is passed to free_plperl_function(). The only theory that comes to mind is that current_call_data is somehow getting aliased (free'd and realloc'd). I don't see how that could happen, but it occurs to me that it's kinda dumb to be palloc'ing it in the first place. Its lifetime is exactly that of the call, so it would be simpler and more foolproof to make it a local variable. I've pushed a HEAD patch to do that, and I wonder if you could check whether it changes anything. Will look at that tomorrow, thanks. Regards, Marko Tiikkaja -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] initdb.exe changes --locale option
Sandeep, can you look into this and respond on list please? The thread started here: http://archives.postgresql.org/pgsql-bugs/2012-09/msg00083.php It sounds to me like the OS is at fault for not accepting the name it gives to a locale as input, and that the change to the installer would be a workaround rather than a fix - but I haven't had time to dig into it. Thanks. On Wed, Sep 12, 2012 at 4:53 PM, Mike Toews wrote: > I've found a general solution: with the locale string, replace the > first ", " (comma space) with "_". > > Around line 33 of initcluster.vbs, add: > > strLocale = Replace(strLocale,", ","_",1,1) > > I think it is fine to show "English, New Zealand" in the drop-down > menu for the GUI installer, but initcluster.vbs needs to do the > replacement to "English_New Zealand" in order to fulfil the correct > initialisation. > > My testing was conducted using a Python script http://pastebin.com/9epyWz7x > which produces a tab delimited table of input locales, and the locale > chosen by initdb.exe, as well as the default language for text search > configuration. > > The results from 200 locales shows some significant problems with > locale detection, such that most "Language, Country" are substituted > with only one country (you will pick up the pattern if you look at the > data). Secondly, there are cases that are completely off: "Tamazight > (Latin), Algeria" : "English_United Kingdom.1252", which is corrected > to "Tamazight (Latin)_Algeria.1252" with the proper substitution. > > However, there are three corner cases (of 200) that either sort-of > breaks things, or doesn't resolve anything: > > Original: Chinese (Traditional), Macao S.A.R. : Chinese > (Traditional)_Taiwan.950 > Replaced: Chinese (Traditional)_Macao S.A.R. : English_United Kingdom.1252 > > Original: Lao, Lao P.D.R. : Lao_Lao P.D.R..1252 > Replaced: Lao_Lao P.D.R. : English_United Kingdom.1252 > > Original: Norwegian (Bokmål), Norway : English_United Kingdom.1252 > Replaced: Norwegian (Bokmål)_Norway : English_United Kingdom.1252 > > (Note: I'm testing on a Windows Vista computer from the UK) > > Lastly, I had a look at the source code initdb.c, which appears to > assume only POSIX locale of the format: > [language[_territory][.codeset][@modifier]] > > E.g., see find_matching_ts_config, which assumes this locale format: > http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/initdb/initdb.c;h=824c7fa7e4c76e0a3b8204ce0cdd21564f23d5df;hb=HEAD#l886 > > It should probably handle the WIN32 logic separately from POSIX > locales, but that's a deeper matter. > > -Mike > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7516: PL/Perl crash
Marko Tiikkaja writes:
> On 13/09/2012 19:48, Tom Lane wrote:
>> Hm, I wonder if it's Ubuntu-specific? What Perl version is that exactly?
> We've reproduced it on both 5.14.2 and 5.16.1.
Meh. I've managed to reproduce it on the fifth system I tried. I don't
think it's got anything to do with the Perl version, but with the gcc
version (which is 4.7.0 on this machine). Apparently, very recent gcc
versions are willing to throw away this line of code:
PG_CATCH();
{
-> current_call_data = save_call_data;
activate_interpreter(oldinterp);
PG_RE_THROW();
}
PG_END_TRY();
current_call_data = save_call_data;
activate_interpreter(oldinterp);
return retval;
Apparently the reasoning is that current_call_data is a static and
therefore the compiler can see everything that can happen to it and
therefore this store into current_call_data is dead code, since the
store six lines below will replace it. Sigh. I shall file a bug,
but I've found that the current crop of gcc maintainers are quite
likely to reject such reports.
We could fix the immediate problem by marking current_call_data volatile
(I've tested that this makes the problem go away on F17), but I think
what we'd better do instead is mark pg_re_throw() as noreturn.
Hopefully that will also prevent this misoptimization, as well as
similar ones that might be happening elsewhere.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7516: PL/Perl crash
I wrote: > Apparently the reasoning is that current_call_data is a static and > therefore the compiler can see everything that can happen to it and > therefore this store into current_call_data is dead code, since the > store six lines below will replace it. Sigh. I shall file a bug, > but I've found that the current crop of gcc maintainers are quite > likely to reject such reports. Filed at https://bugzilla.redhat.com/show_bug.cgi?id=857236 On the good side: developing a minimal test case showed me that the code is incorrectly compiled only if perl.h has been included. (WTF? No, I don't know why.) So at least this gcc bug should only be affecting plperl.c and not the rest of postgres. > We could fix the immediate problem by marking current_call_data volatile > (I've tested that this makes the problem go away on F17), but I think > what we'd better do instead is mark pg_re_throw() as noreturn. > Hopefully that will also prevent this misoptimization, as well as > similar ones that might be happening elsewhere. But, of course, pg_re_throw() already is marked noreturn. A probably less costly solution than marking current_call_data volatile is just to make it not-static. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7516: PL/Perl crash
I wrote: > A probably less costly solution than marking current_call_data volatile > is just to make it not-static. And on still further investigation, the patch I just applied to HEAD seems to make it go away too. Bizarre as can be. If that holds up for you, I think back-patching that change is less ugly than making the variable non-static. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] how to proccess record returning null
Hi all, I am new to postgresql and I am trying to write a function which uses record (r) to select from table and then proccess that record value. CREATE OR REPLACE FUNCTION clean() RETURNS integer AS $$ DECLARE r record; result integer:= 0; BEGIN FOR r in select distinct(id) from temp loop IF r.id is null or r.id ='' THEN result := 555; else result := 999; end if; end loop; RETURN result; END; $$ LANGUAGE plpgsql; The problem here is 'r' is returning no records and I want to set result to 555 if r.id is null. The function is created successfully but the result select clean() is always '0'. I am unable to spot the problem. May be this is trivial but I am struggling for it. Can anybody suggest anything? -- View this message in context: http://postgresql.1045698.n5.nabble.com/how-to-proccess-record-returning-null-tp5723932.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] how to proccess record returning null
On 09/13/12 12:17 PM, te wrote: FOR r in select distinct(id) from temp select clean() what is this selecting records from? what is "temp" ? -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7537: Server will not start up from Windows Service Manager
The following bug has been logged on the website: Bug reference: 7537 Logged by: Owen Sleep Email address: dfisupp...@docfocus.ca PostgreSQL version: 9.0.8 Operating system: Windows Server 2003 Service Pack 2 Description: PostgreSQL service was running successfully for a month now. Restarted the machine and then the service will not start up from the service manager. I get the message "Timed out waiting for server startup" in the Windows event log. There is no log in the pg_log folder so unfortunately I have no starting point for troubleshooting. I have checked the permissions on the folders and the postgres user has no restrictions whatsoever with access to all data and postgresql folders. Any other questions, feel free to email. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7533: Client is not able to connect cascade standby incase basebackup is taken from hot standby
On Thursday, September 13, 2012 10:32 PM Fujii Masao wrote: On Thu, Sep 13, 2012 at 9:21 PM, Heikki Linnakangas wrote: > On 12.09.2012 22:03, Fujii Masao wrote: >> >> On Wed, Sep 12, 2012 at 8:47 PM, wrote: >>> >>> The following bug has been logged on the website: >>> >>> Bug reference: 7533 >>> Logged by: Amit Kapila >>> Email address: amit.kap...@huawei.com >>> PostgreSQL version: 9.2.0 >>> Operating system: Suse >>> Description: >>> >>> M host is primary, S host is standby and CS host is cascaded standby. >>> > >> Hmm, I think the CheckRecoveryConsistency() call in the redo loop is >> misplaced. It's called after we got a record from ReadRecord, but *before* >> replaying it (rm_redo). Even if replaying record X makes the system >> consistent, we won't check and notice that until we have fetched record X+1. >> In this particular test case, record X is a shutdown checkpoint record, but >> it could as well be a running-xacts record, or the record that reaches >> minRecoveryPoint. > >> Does the problem go away if you just move the CheckRecoveryConsistency() >> call *after* rm_redo (attached)? > No, at least in my case. When recovery starts at shutdown checkpoint record > and > there is no record following the shutdown checkpoint, recovery gets in > wait state > before entering the main redo apply loop. That is, recovery starts waiting for > new WAL record to arrive, in ReadRecord just before the redo loop. So moving > the CheckRecoveryConsistency() call after rm_redo cannot fix the problem which >I reported. To fix the problem, we need to make the recovery reach the > consistent > point before the redo loop, i.e., in the CheckRecoveryConsistency() > just before the redo loop. I think may be in that case we need both the fixes, as the problem I have reported can be fixed with Heikki's patch. With Regards, Amit Kapila. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
