Re: [HACKERS] huge tlb support
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: Also, I was under the impression that recent Linux kernels use hugepages automatically if they can, so I wonder exactly what Andres was testing on ... if you mean the trasparent hugepage feature, iirc it doesn't affect MAP_SHARED mappings like this. Oh! That would explain some things. It seems like a pretty nasty restriction though ... do you know why they did that? 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] huge tlb support
On Mon, Jul 09, 2012 at 02:11:00AM -0400, Tom Lane wrote: y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: Also, I was under the impression that recent Linux kernels use hugepages automatically if they can, so I wonder exactly what Andres was testing on ... if you mean the trasparent hugepage feature, iirc it doesn't affect MAP_SHARED mappings like this. Oh! That would explain some things. It seems like a pretty nasty restriction though ... do you know why they did that? It doesn't say explicitly in the documentation (found at http://lwn.net/Articles/423592/ aka transhuge.txt) but reading between the lines I'm guessing it's due to the fact that huge pages must be aligned to 2 or 4MB and when dealing with a shared mapping you probably need to require it to be aligned is all address spaces. However, it seems it should work for SysV shared memory, see: http://lwn.net/Articles/375096/ . The same page suggests shared mappings should work fine. However, this page refers to the non-transparent feature. If you think about it, it must work since huge pages are inherited through fork(). Have a nice day, -- Martijn van Oosterhout klep...@svana.org http://svana.org/kleptog/ He who writes carelessly confesses thereby at the very outset that he does not attach much importance to his own thoughts. -- Arthur Schopenhauer signature.asc Description: Digital signature
Re: [HACKERS] [PATCH] Allow breaking out of hung connection attempts
Hi Ryan, On Mon, Jun 25, 2012 at 9:00 PM, Ryan Kelly rpkell...@gmail.com wrote: Connection attempt by \connect command could be also canceled by pressing Ctrl+C on psql prompt. In addition, I tried setting PGCONNECT_TIMEOUT to 0 (infinite), but psql gave up after few seconds, for both start-up and re-connect. Is this intentional behavior? A timeout of 0 (infinite) means to keep trying until we succeed or fail, not keep trying forever. As you mentioned above, your connection attempts error out after a few seconds. This is what is happening. In my environment no such error occurs and as a result psql continues to attempt to connect for as long as I let it. For handy testing, I wrote simple TCP server which accepts connection and blocks until client gives up connection attempt (or forever). When I tested your patch with setting PGCONNECT_TIMEOUT=0, I found that psql's CPU usage goes up to almost 100% (10~ usr + 80~ sys) while connection attempt by \c command is undergoing. After reading code for a while, I found that FD_ZERO was not called. This makes select() to return immediately in the loop every time and caused busy loop. # Maybe you've forgotten adding FD_ZERO when you were merging Heikki's v2 patch. - Checking status by calling PQstatus just after PQconnectStartParams is necessary. Yes, I agree. Checked. - Copying only select() part of pqSocketPoll seems not enough, should we use poll(2) if it is supported? I did not think the additional complexity was worth it in this case. Unless you see some reason to use poll(2) that I do not. I checked where select() is used in PG, and noticed that poll is used at only few places. Agreed to use only select() here. - Don't we need to clear error message stored in PGconn after PQconnectPoll returns OK status, like connectDBComplete? I do not believe there is a client interface for clearing the error message. Additionally, the documentation states that PQerrorMessage Returns the error message most recently generated by an operation on the connection. This seems to indicate that the error message should be cleared as this behavior is part of the contract of PQerrorMessage. My comment was pointless. Sorry for noise. Here is my additional comments for v5 patch: - Using static array for fixed-length connection parameters was suggested in comments for another CF item, using fallback_application_name for some command line tools, and IMO this approach would also suit for this patch. http://archives.postgresql.org/message-id/CA+TgmoYZiayts=fjsytzqlg7rewlwkdkey5f+fhp5v5_nu_...@mail.gmail.com - Some comments go past 80 columns, and opening brace in line 1572 should go on next line. Please refer coding conventions written in PostgreSQL wiki. http://www.postgresql.org/docs/devel/static/source-format.html Once the issues above are fixed, IMO this patch can be marked as Ready for committer. Regards, -- Shigeru Hanada * 不明 - 自動検出 * 英語 * 日本語 * 英語 * 日本語 javascript:void(0); -- 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] huge tlb support
On Monday, July 09, 2012 08:11:00 AM Tom Lane wrote: y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: Also, I was under the impression that recent Linux kernels use hugepages automatically if they can, so I wonder exactly what Andres was testing on ... if you mean the trasparent hugepage feature, iirc it doesn't affect MAP_SHARED mappings like this. Oh! That would explain some things. It seems like a pretty nasty restriction though ... do you know why they did that? Looking a bit deeper they explicitly only work on private memory. The reason apparently being that its too hard to update the page table entries in multiple processes at once without introducing locking problems/scalability issues. To be sure one can check /proc/$pid_of_pg_proccess/smaps and look for the mapping to /dev/zero or the biggest mapping ;). Its not counted as Anonymous memory and it doesn't have transparent hugepages. I was confused before because there is quite some (400mb here) huge pages allocated for postgres during a pgbench run but thats just all the local memory... Greetings, Andres PS: The important #define is in mm/huge_memory.c: #define VM_NO_THP (VM_SPECIAL|VM_INSERTPAGE|VM_MIXEDMAP|VM_SAO| \ VM_HUGETLB|VM_SHARED|VM_MAYSHARE) -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] huge tlb support
Robert Haas robertmh...@gmail.com writes: On Fri, Jun 29, 2012 at 3:52 PM, Andres Freund and...@2ndquadrant.com wrote: In a *very* quick patch I tested using huge pages/MAP_HUGETLB for the mmap'ed memory. So, considering that there is required setup, it seems that the obvious thing to do here is add a GUC: huge_tlb_pages (boolean). The other alternative is to try with MAP_HUGETLB and, if it fails, try again without MAP_HUGETLB. +1 for not making people configure this manually. Also, I was under the impression that recent Linux kernels use hugepages automatically if they can, so I wonder exactly what Andres was testing on ... if you mean the trasparent hugepage feature, iirc it doesn't affect MAP_SHARED mappings like this. YAMAMOTO Takashi 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 -- 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] huge tlb support
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: Also, I was under the impression that recent Linux kernels use hugepages automatically if they can, so I wonder exactly what Andres was testing on ... if you mean the trasparent hugepage feature, iirc it doesn't affect MAP_SHARED mappings like this. Oh! That would explain some things. It seems like a pretty nasty restriction though ... do you know why they did that? i don't know. simply because it wasn't trivial, i guess. the feature was implemented for kvm's guest memory, which is non-shared anonymous memory from POV of host kernel. YAMAMOTO Takashi 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 2 defects that should get fixed
Few days back, I have worked on 2 bugs and sent the reason why that defect is occurring. According to me those defects should be fixed as they have been introduced in some recent versions. Defect -1 Bug reference: 6712 http://archives.postgresql.org/pgsql-bugs/2012-07/msg1.php Defect -2 http://archives.postgresql.org/pgsql-bugs/2012-06/msg00127.php Any comments? With Regards, Amit Kapila.
[HACKERS] several problems in pg_receivexlog
Hi, I found several problems in pg_receivexlog, e.g., memory leaks, file-descripter leaks, ..etc. The attached patch fixes these problems. ISTM there are still some other problems in pg_receivexlog, so I'll read it deeply later. Regards, -- Fujii Masao fix_pgreceivexlog_problems_v1.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug tracker tool we need
Hackers, So I want to repeat this because I think we are conflating several uses for a bug tracker which aren't the same, and which really need to be dealt with seperately. -- Better CF App: to track feature submissions, discussion, revisions and reviews. -- Bug Submitter: easy-access way for users to submit bugs and check on their status later. -- Fix-Bug-Later Bug Tracker: a place to track bugs which are not immediately fixable due to complexity/breakage/external dependancies/priority. -- Fix Tracker: way for users to search if a particular issue was fixed, and what release it was fixed in. -- Testing Tracker: tool for user-testers to submit test reports for development and beta releases. The above are 5 different tasks with different requirements, and it's far from clear that we want a new tool for all of them (or even want all of them). -- Josh Berkus PostgreSQL Experts Inc. http://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] Bug tracker tool we need
On 07/09/2012 12:02 PM, Josh Berkus wrote: Hackers, So I want to repeat this because I think we are conflating several uses for a bug tracker which aren't the same, and which really need to be dealt with seperately. -- Better CF App: to track feature submissions, discussion, revisions and reviews. -- Bug Submitter: easy-access way for users to submit bugs and check on their status later. === -- Fix-Bug-Later Bug Tracker: a place to track bugs which are not immediately fixable due to complexity/breakage/external dependancies/priority. -- Fix Tracker: way for users to search if a particular issue was fixed, and what release it was fixed in. === These two should be able to be the same piece of sotware. -- Testing Tracker: tool for user-testers to submit test reports for development and beta releases. This might be able to be the same piece as fix-bug-later... with a different front end. The above are 5 different tasks with different requirements, and it's far from clear that we want a new tool for all of them (or even want all of them). Not sure how to handle the first two. Bug submission is always a pita and although we could use the fix-bug-later app, it would clutter it as we were trying to determine real bugs vs user error. Sincerely, jD -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development The PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579 -- 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] Btree or not btree? That is the question
I've expanded my searching a bit, to see if I can find any other correlations. One thing that seems to happen about 10 times a day is an error of this sort: ERROR: could not open relation with OID 1554847326 In this case, the OID in question always exists, and corresponds to one of a handful of particularly busy tables. Sometimes the query does not even touch the OID mentioned directly: in the above example, the SQL was an update to table A that had a FK to table B, and the OID above is for table B. The queries themselves vary: I've not found any common factor yet. These errors have been happening a long time, and obviously don't cause the same database-hosed-must-restart issue the btree does, but it is still a little disconcerting. Although 10 times out of 20 million transactions per day is at least an extremely rare event :) It is definitely NOT correlated to system table reindexing, but does seem to be roughly correlated to how busy things are in general. We've not been able to duplicate on a non-prod test system yet either, which points to either hardware or (more likely) a failure to completely simulate the high activity level of prod. No idea if this related to the relatively recent btree errors, but figured I would get it out there. There is also an even rarer sprinkling of: ERROR: relation with OID 3924107573 does not exist but I figured that was probably a variant of the first error. -- Greg Sabino Mullane g...@endpoint.com End Point Corporation PGP Key: 0x14964AC8 pgpmh4I30bBvW.pgp Description: PGP signature
Re: [HACKERS] Bug tracker tool we need
On Mon, Jul 9, 2012 at 3:26 PM, Joshua D. Drake j...@commandprompt.com wrote: On 07/09/2012 12:02 PM, Josh Berkus wrote: Hackers, So I want to repeat this because I think we are conflating several uses for a bug tracker which aren't the same, and which really need to be dealt with seperately. -- Better CF App: to track feature submissions, discussion, revisions and reviews. -- Bug Submitter: easy-access way for users to submit bugs and check on their status later. Not sure how to handle the first two. Bug submission is always a pita and although we could use the fix-bug-later app, it would clutter it as we were trying to determine real bugs vs user error. And whatever you/we do, be *VERY* aware of the pile-of-...-in-the-bugtracker problem. I just happend to have Joel Spolsky's post come through my RSS reader, where he talked about about bugtrackers, and suggested: - Do not allow more than two weeks (in fix time) of bugs to get into the bug database. - If you have more than that, stop and fix bugs until you feel like you’re fixing stupid bugs. Then close as “won’t fix” everything left in the bug database. Don’t worry, the severe bugs will come back. The biggest problem of whatever tool is used for anything, is making sure tool is useful enough to people that need to use it to make it worth their while. A tracker (of any type) that is even *insanely* useful for users, but that doesn't give *developpers* (note, that's developpers, not managers, or cat-herders, or cheer-leaders) any extra value is bound to fill and soon become un-usefull for even uses.. If you want the develops to use it, it has to be worth their time *to them* to use it. Witness the hundreds of graves that are he thousands bugzilla bugs out there filed against even active open-source projects. a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Btree or not btree? That is the question
Greg Sabino Mullane g...@endpoint.com writes: I've expanded my searching a bit, to see if I can find any other correlations. One thing that seems to happen about 10 times a day is an error of this sort: ERROR: could not open relation with OID 1554847326 Is that the *entire* message? No details? Could you crank up the log verbosity so we can get file and line number, at least? 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] Btree or not btree? That is the question
ERROR: could not open relation with OID 1554847326 Is that the *entire* message? No details? Could you crank up the log verbosity so we can get file and line number, at least? Yes, that's the entire thing, other than the statement line after it. In this particular case: STATEMENT: UPDATE mytable SET foobar = 'T' WHERE id IN ($1,$2,$3,$4) I'll start the wheels rolling for upping the verbosity. -- Greg Sabino Mullane g...@endpoint.com End Point Corporation PGP Key: 0x14964AC8 pgp1V3duXPAQS.pgp Description: PGP signature
[HACKERS] Synchronous Standalone Master Redoux
Hey everyone, Upon doing some usability tests with PostgreSQL 9.1 recently, I ran across this discussion: http://archives.postgresql.org/pgsql-hackers/2011-12/msg01224.php And after reading the entire thing, I found it odd that the overriding pushback was because nobody could think of a use case. The argument was: if you don't care if the slave dies, why not just use asynchronous replication? I'd like to introduce all of you to DRBD. DRBD is, for those who aren't familiar, distributed (network) block-level replication. Right now, this is what we're using, and will use in the future, to ensure a stable synchronous PostgreSQL copy on our backup node. I was excited to read about synchronous replication, because with it, came the possibility we could have two readable nodes with the servers we already have. You can't do that with DRBD; secondary nodes can't even mount the device. So here's your use case: 1. Slave wants to be synchronous with master. Master wants replication on at least one slave. They have this, and are happy. 2. For whatever reason, slave crashes or becomes unavailable. 3. Master notices no more slaves are available, and operates in standalone mode, accumulating WAL files until a suitable slave appears. 4. Slave finishes rebooting/rebuilding/upgrading/whatever, and re-subscribes to the feed. 5. Slave stays in degraded sync (asynchronous) mode until it is caught up, and then switches to synchronous. This makes both master and slave happy, because *intent* of synchronous replication is fulfilled. PostgreSQL's implementation means the master will block until someone/something notices and tells it to stop waiting, or the slave comes back. For pretty much any high-availability environment, this is not viable. Based on that alone, I can't imagine a scenario where synchronous replication would be considered beneficial. The current setup doubles unplanned system outage scenarios in such a way I'd never use it in a production environment. Right now, we only care if the master server dies. With sync rep, we'd have to watch both servers like a hawk and be ready to tell the master to disable sync rep, lest our 10k TPS system come to an absolute halt because the slave died. With DRBD, when a slave node goes offline, the master operates in standalone until the secondary re-appears, after which it re-synchronizes missing data, and then operates in sync mode afterwards. Just because the data is temporarily out of sync does *not* mean we want asynchronous replication. I think you'd be hard pressed to find many users taking advantage of DRBD's async mode. Just because data is temporarily catching up, doesn't mean it will remain in that state. I would *love* to have the functionality discussed in the patch. If I can make a case for it, I might even be able to convince my company to sponsor its addition, provided someone has time to integrate it. Right now, we're using DRBD so we can have a very short outage window while the offline node gets promoted, and it works, but that means a basically idle server at all times. I'd gladly accept a 10-20% performance hit for sync rep if it meant that other server could reliably act as a read slave. That's currently impossible because async replication is too slow, and sync is too fragile for reasons stated above. Am I totally off-base, here? I was shocked when I actually read the documentation on how sync rep worked, and saw that no servers would function properly until at least two were online. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604 312-444-8534 stho...@optionshouse.com __ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- 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] Btree or not btree? That is the question
Could you crank up the log verbosity so we can get file and line number, at least? First hit since the change: ERROR: XX000: could not open relation with OID 1554847444 LOCATION: relation_open, heapam.c:879 STATEMENT: SELECT ... Will leave the verbosity up and see if it occurs in the same place. -- Greg Sabino Mullane g...@endpoint.com End Point Corporation PGP Key: 0x14964AC8 pgpSmpP1G2bZT.pgp Description: PGP signature
Re: [HACKERS] several problems in pg_receivexlog
On Mon, Jul 9, 2012 at 8:23 PM, Fujii Masao masao.fu...@gmail.com wrote: Hi, I found several problems in pg_receivexlog, e.g., memory leaks, file-descripter leaks, ..etc. The attached patch fixes these problems. While I don't doubt that what you've found are real problems, would you mind explaining exactly what they are, so we don't have to reverse-engineer the patch to figure that out? -- 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] Bug tracker tool we need
-- Bug Submitter: easy-access way for users to submit bugs and check on their status later. Not sure how to handle the first two. Bug submission is always a pita and although we could use the fix-bug-later app, it would clutter it as we were trying to determine real bugs vs user error. And whatever you/we do, be *VERY* aware of the pile-of-...-in-the-bugtracker problem. I just happend to have Joel Spolsky's post come through my RSS reader, where he talked about about bugtrackers, and suggested: Well, frankly, I don't think we really want to make it easier for the *general public* to submit bugs than it already is. We're already getting enough quality bug reports to keep us busy. And I'm all-too-familiar with the failings of a bug-losing system; check the number of bugs I have filed against Thunderbird sometime. Where bug submission is broken that we care about is in two areas: 1. it's very difficult for the existing bug submitters to check status of their bugs after submission, or even find out if they went anywhere (if using the webform). 2. we don't have an API for downstream projects and products to submit bugs, which makes those projects think we don't care about bugs. Note that both of the above could be solved without having a public bugzilla instance. -- Josh Berkus PostgreSQL Experts Inc. http://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] Synchronous Standalone Master Redoux
Shaun, PostgreSQL's implementation means the master will block until someone/something notices and tells it to stop waiting, or the slave comes back. For pretty much any high-availability environment, this is not viable. Based on that alone, I can't imagine a scenario where synchronous replication would be considered beneficial. So there's an issue with the definition of synchronous. What synchronous in synchronous replication means is guarantee zero data loss or fail the transaction. It does NOT mean master and slave have the same transactional data at the same time, as much as that would be great to have. There are, indeed, systems where you'd rather shut down the system than accept writes which were not replicated, or we wouldn't have the feature. That just doesn't happen to fit your needs (nor, indeed, the needs of most people who think they want SR). Total-consistency replication is what I think you want, that is, to guarantee that at any given time a read query on the master will return the same results as a read query on the standby. Heck, *most* people would like to have that. You would also be advancing database science in general if you could come up with a way to implement it. slave. That's currently impossible because async replication is too slow, and sync is too fragile for reasons stated above. So I'm unclear on why sync rep would be faster than async rep given that they use exactly the same mechanism. Explain? -- Josh Berkus PostgreSQL Experts Inc. http://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
[HACKERS] has_language_privilege returns incorrect answer for non-superuser
I noticed today that has_language_privilege() returns incorrect answer
for non-superuser, e.g.:
8---
select has_language_privilege('nobody',
'plperlu',
'usage');
has_language_privilege
t
(1 row)
test1=# \c - nobody
You are now connected to database test1 as user nobody.
create function f() returns text as $$ $$ language plperlu;
ERROR: permission denied for language plperlu
8---
I verified this behavior on head as well as 9.1 (didn't bother looking
any further back). Looks like the reason is that CreateFunction()
correctly checks lanpltrusted, whereas pg_language_aclmask() does not.
Seems like a bug to me -- opinions?
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Use of rsync for data directory copying
Rsync is popular with Postgres users, but I don't understand how they are using the default check mode (file size, modification time) to synchronize shut-down data directories? It seems they would have to use --checksum because it is too easy for files to change in the same second, and for a backend to write into the middle of a file. Is everyone who is using rsync with Postgres also using --checksum mode? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Use of rsync for data directory copying
On Jul 9, 2012, at 7:48 PM, Bruce Momjian wrote:
Rsync is popular with Postgres users, but I don't understand how they
are using the default check mode (file size, modification time) to
synchronize shut-down data directories? It seems they would have to use
--checksum because it is too easy for files to change in the same
second, and for a backend to write into the middle of a file.
Is everyone who is using rsync with Postgres also using --checksum mode?
I must be missing something, if they're shut down you can't write to them. =)
I do use rsync though for resyncing my mirror's, it's been working great so
far. I assume
that the WAL fixes anything that gets goofed up in the copy. (hopefully I've
been assuming correctly.)
---
#!/bin/ksh
SOURCE=masterdbserver
. /etc/sysconfig/pgsql/postgresql-9.1
export PGDATA
export PGPORT
rm -f $PGDATA/failover
pg_ctl stop -D $PGDATA -m immediate
psql -h $SOURCE -p $PGPORT EOD
checkpoint;
select pg_start_backup('mirror');
EOD
rsync -avv --delete-delay \
--exclude postgresql.conf \
--exclude pg_hba.conf \
--exclude server.conf \
--exclude archive.conf \
--exclude recovery.conf \
--exclude recovery.done \
--exclude pg_ident.conf \
--exclude failover \
--exclude pg_xlog \
--exclude postmaster.pid \
$SOURCE:$PGDATA/ $PGDATA
psql -h $SOURCE -p $PGPORT -c select pg_stop_backup()
cp $PGDATA/recovery.done $PGDATA/recovery.conf
pg_ctl start -D $PGDATA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
