Re: [HACKERS] Problem with streaming replication, backups, and recovery (9.0.x)

On Wed, Mar 30, 2011 at 11:39 AM, Fujii Masao wrote: > On Wed, Mar 30, 2011 at 12:54 AM, Heikki Linnakangas > wrote: >> Hmm, why did we change that? > > I'm not sure, but I guess that's because I missed the case where crash > recovery starts from the backup :( > >> It seems like a mistake, the da

Re: [HACKERS] Typos

On 30.03.2011 08:34, Fujii Masao wrote: The attached patch fixes two typos. Thanks, applied. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.o

Re: [HACKERS] pg_last_xlog_receive_location()

On Wed, Mar 30, 2011 at 11:45 AM, Tatsuo Ishii wrote: >>> BTW, is there any reliable way to know a standby is promoting to >>> primary? >> >> You can know that from the server log. But there is no way to do that >> via SQL, I think. > > Ok. It seems I need to patch PostgreSQL. Why is that feature

[HACKERS] Typos

Hi, The attached patch fixes two typos. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center typos_v1.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Additional options for Sync Replication

On Tue, Mar 29, 2011 at 8:57 PM, Robert Haas wrote: > On Tue, Mar 29, 2011 at 3:49 AM, Dimitri Fontaine > wrote: >>> It would be better to just support it (recv|fsync|apply), >>> or no syncrep at all. Syncrep is incomplete without it. >> >> Agreed. > > I have trouble viewing the idea that it woul

Re: [HACKERS] crash-safe visibility map, take four

Hi, Should we do full-page write for visibilitymap all the time? Now, when clear visiblitymap, there is no full-page write for vm since we don't save buffer info in insert/update/delete's log. The full-page write is used to protect pages from disk failure. Without it, 1) set vm: the vm bits that

Re: [HACKERS] pg_last_xlog_receive_location()

On Tue, Mar 29, 2011 at 9:08 PM, Tatsuo Ishii wrote: >> In the primary server which was brought up from the standby, >> pg_last_xlog_receive_location() returns non-NULL. > > Thanks. > > BTW, is there any reliable way to know a standby is promoting to > primary? if you know the server was a standb

Re: [HACKERS] Another swing at JSON

Excerpts from Joseph Adams's message of mar mar 29 22:15:11 -0300 2011: > On Tue, Mar 29, 2011 at 4:02 PM, Dimitri Fontaine > wrote: > > Here's the ugly trick from ip4r, that's used by more extension: > > > > PREFIX_PGVER = $(shell echo $(VERSION) | awk -F. '{ print $$1*100+$$2 }') > > Thanks. I

Re: [HACKERS] pg_last_xlog_receive_location()

>> BTW, is there any reliable way to know a standby is promoting to >> primary? > > You can know that from the server log. But there is no way to do that > via SQL, I think. Ok. It seems I need to patch PostgreSQL. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php

Re: [HACKERS] pg_last_xlog_receive_location()

On Wed, Mar 30, 2011 at 11:08 AM, Tatsuo Ishii wrote: > BTW, is there any reliable way to know a standby is promoting to > primary? You can know that from the server log. But there is no way to do that via SQL, I think. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Ope

Re: [HACKERS] Problem with streaming replication, backups, and recovery (9.0.x)

On Wed, Mar 30, 2011 at 12:54 AM, Heikki Linnakangas wrote: > Hmm, why did we change that? I'm not sure, but I guess that's because I missed the case where crash recovery starts from the backup :( > It seems like a mistake, the database is not > consistent until you reach the backup stop locatio

Re: [HACKERS] pg_last_xlog_receive_location()

> In the primary server which was brought up from the standby, > pg_last_xlog_receive_location() returns non-NULL. Thanks. BTW, is there any reliable way to know a standby is promoting to primary? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://w

Re: [HACKERS] pg_last_xlog_receive_location()

On Wed, Mar 30, 2011 at 10:13 AM, Tatsuo Ishii wrote: > In my understanding pg_last_xlog_receive_location() returns NULL if > applied to non standby server: > > Get last transaction log location received and synced to disk by > streaming replication. While streaming replication is in progress this

Re: [HACKERS] Triggers on system catalog

* Robert Haas (robertmh...@gmail.com) wrote: > I do think we need some kind way of capturing DDL events, though. I wonder if > the object-access-hook stuff KaiGai and I did to support SE-PostgreSQL could > be extended to meet this need... My inclination would be 'probably', but it's not likely t

Re: [HACKERS] Replication server timeout patch

On Wed, Mar 30, 2011 at 1:04 AM, Robert Haas wrote: >> COMMERROR exists to keep us from trying to send an error report down a >> failed socket.  I would assume (perhaps wrongly) that >> walsender/walreceiver don't try to push error reports across the socket >> anyway, only to the postmaster log.  

Re: [HACKERS] PostgreSQL sourcecode

On 03/29/2011 09:21 PM, aaronenabs wrote: what c compiler would you suggest i use please Building on Windows can be difficult. See for alternatives. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] PostgreSQL sourcecode

On 03/29/2011 09:03 PM, Josh Berkus wrote: On 3/29/11 5:53 PM, aaronenabs wrote: Hi all i have been trying to compile the sourcecode for postgresql but keep getting an error message when running it in cygwin. I don't believe that Cygwin is supported at this point. Of course it is. I go to

Re: [HACKERS] PostgreSQL sourcecode

what c compiler would you suggest i use please thanks -- View this message in context: http://postgresql.1045698.n5.nabble.com/PostgreSQL-sourcecode-tp4270534p4270566.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hacke

Re: [HACKERS] Another swing at JSON

On Tue, Mar 29, 2011 at 4:02 PM, Dimitri Fontaine wrote: > Here's the ugly trick from ip4r, that's used by more extension: > > PREFIX_PGVER = $(shell echo $(VERSION) | awk -F. '{ print $$1*100+$$2 }') Thanks. I applied a minor variation of this trick to the JSON module, so now it builds/installs

[HACKERS] pg_last_xlog_receive_location()

In my understanding pg_last_xlog_receive_location() returns NULL if applied to non standby server: Get last transaction log location received and synced to disk by streaming replication. While streaming replication is in progress this will increase monotonically. But when streaming replication is

Re: [HACKERS] Problem with pg_upgrade?

On Tue, 2011-03-29 at 21:43 -0300, Alvaro Herrera wrote: > I think it would be better to have > some sort of option to disable autovacuum completely which would be used > only during pg_upgrade. Sounds reasonable to me. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] pg_dumpall

Aaron, > I have been having problems using the pg_dumpall function. I am trying to > dump all the information on my database onto a file or view it. Actually > what am trying to achieve is by using the pg_dumpall i can view dead rows > once the db has been dumped into a file. I had a look online a

Re: [HACKERS] PostgreSQL sourcecode

On 3/29/11 5:53 PM, aaronenabs wrote: > Hi all i have been trying to compile the sourcecode for postgresql but keep > getting an error message when running it in cygwin. I don't believe that Cygwin is supported at this point. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent

[HACKERS] pg_dumpall

Hi there, I have been having problems using the pg_dumpall function. I am trying to dump all the information on my database onto a file or view it. Actually what am trying to achieve is by using the pg_dumpall i can view dead rows once the db has been dumped into a file. I had a look online and tr

[HACKERS] PostgreSQL sourcecode

Hi all i have been trying to compile the sourcecode for postgresql but keep getting an error message when running it in cygwin. it states: dllwrap: gcc exited with status 1 make[3]: *** [cygpq.dll] Error 1 make[3]: Leaving directory `/postgresql-9.0.3/postgresql-9.0.3/src/interfaces/li bpq' make

Re: [HACKERS] Problem with pg_upgrade?

Excerpts from Jeff Davis's message of mar mar 29 21:27:34 -0300 2011: > On Tue, 2011-03-29 at 15:52 -0400, Bruce Momjian wrote: > > Does anyone have any other suggestions on how to make sure autovacuum > > does not run in freeze mode? > > Can you run in single user mode? I asked the same thing.

Re: [HACKERS] Problem with pg_upgrade?

On Tue, 2011-03-29 at 15:52 -0400, Bruce Momjian wrote: > Does anyone have any other suggestions on how to make sure autovacuum > does not run in freeze mode? Can you run in single user mode? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To m

Re: [HACKERS] Triggers on system catalog

On Mar 29, 2011, at 2:17 PM, Christopher Browne wrote: > A proposal to adding triggers to system catalog tables won't be > terribly popular. Well, I'd support it if I thought it had any chance of actually working, but I don't. I do think we need some kind way of capturing DDL events, though. I

Re: [HACKERS] Another swing at JSON

On Tue, Mar 29, 2011 at 02:56:52PM -0400, Joseph Adams wrote: > On Tue, Mar 29, 2011 at 2:42 PM, Dimitri Fontaine > wrote: > >> Also, should uninstall_json.sql be named something else, like > >> json--uninstall--0.1.sql ? > > > > You don't need no uninstall script no more, try DROP EXTENSION json;

Re: [HACKERS] Additional options for Sync Replication

On Tue, Mar 29, 2011 at 7:48 PM, Josh Berkus wrote: >> Writing such long emails seems to be just filibustering to me. I doubt >> anyone has read and considered every word, there are just too many. A >> form of disrespect. > > Simon, Robert has been nothing but respectful to you.  You can't accuse

Re: [HACKERS] Additional options for Sync Replication

On Tue, Mar 29, 2011 at 7:48 PM, Josh Berkus wrote: > On 3/29/11 7:48 AM, Dimitri Fontaine wrote: >> I don't want a release as soon as possible, I want the best we are able >> to provide, and I think adding in current $subject patch helps reaching >> this goal.   > > There will *always* be more wo

[HACKERS] pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE

I took a look at the open item concerning typed tables and pg_upgrade: http://archives.postgresql.org/pgsql-hackers/2011-03/msg00767.php "pg_dump --binary-upgrade" emits commands to recreate the dropped-column situation of the database, and it does not currently understand that it must alter the p

[HACKERS] Process local hint bit cache

In a previous thread (http://postgresql.1045698.n5.nabble.com/Set-hint-bits-upon-eviction-from-BufMgr-td4264323.html) I was playing with the idea of granting the bgwriter the ability to due last chance hint bit setting before evicting the page out. I still think might be a good idea, and it might b

[HACKERS] gcc 4.6 warnings -Wunused-but-set-variable

As you might have heard, GCC 4.6 was released the other day. It generates a bunch of new warnings with the PostgreSQL source code, most of which belong to the new warning scenario -Wunused-but-set-variable, which is included in -Wall. Attached is a patch that gets rid of most of these. As you ca

Re: [HACKERS] Additional options for Sync Replication

On Tue, Mar 29, 2011 at 2:48 PM, Josh Berkus wrote: >> Writing such long emails seems to be just filibustering to me. I doubt >> anyone has read and considered every word, there are just too many. A >> form of disrespect. > > Simon, Robert has been nothing but respectful to you.  You can't accuse

Re: [HACKERS] Another swing at JSON

Joseph Adams writes: > would be needlessly error-prone. I'm thinking the pg_config utility > should either make PG_VERSION_NUM (e.g. 90100) available, or it should > define something indicating the presence of the new extension system. Here's the ugly trick from ip4r, that's used by more extensi

[HACKERS] Problem with pg_upgrade?

I have gotten two reports via IRC that months after using 9.0 pg_upgrade, some of the clog files have been removed while there is still data in the table needing those clog files. These reports came to me through Rhodiumtoad who analyzed the systems. Looking at pg_upgrade, I am concerned that som

Re: [HACKERS] Another swing at JSON

On Tue, Mar 29, 2011 at 2:42 PM, Dimitri Fontaine wrote: > Joseph Adams writes: >> It would be nice if I could make a Makefile conditional that skips the >> relocatable test and loads init-pre9.1.sql if the new extension >> interface isn't available.  Is there a Makefile variable or something >>

Re: [HACKERS] Another swing at JSON

On Tue, Mar 29, 2011 at 2:42 PM, Dimitri Fontaine wrote: >> Also, should uninstall_json.sql be named something else, like >> json--uninstall--0.1.sql ? > > You don't need no uninstall script no more, try DROP EXTENSION json; and > DROP EXTENSION json CASCADE; It's there for pre-9.1, where DROP EX

Re: [HACKERS] Additional options for Sync Replication

On 3/29/11 7:48 AM, Dimitri Fontaine wrote: > I don't want a release as soon as possible, I want the best we are able > to provide, and I think adding in current $subject patch helps reaching > this goal. There will *always* be more work we can do on sync rep. If we hold the release until we're

Re: [HACKERS] Another swing at JSON

Joseph Adams writes: > It would be nice if I could make a Makefile conditional that skips the > relocatable test and loads init-pre9.1.sql if the new extension > interface isn't available. Is there a Makefile variable or something > I can use to do this? You can use VERSION and MAJORVERSION vari

Re: [HACKERS] deadlock_timeout at < PGC_SIGHUP?

On Tue, Mar 29, 2011 at 08:26:44AM -0400, Robert Haas wrote: > I'd be inclined to think that PGC_SUSET is plenty. Agreed. A superuser who would have liked PGC_USERSET can always provide a SECURITY DEFINER function. > It's actually not > clear to me what the user could usefully do other than tryi

Re: [HACKERS] Triggers on system catalog

On Mon, Mar 28, 2011 at 10:19 AM, Shridhar Polas wrote: > Hi, > Is there a way to create triggers on system catalog tables like > pg_class, pg_attribute etc...? No, this isn't supported, and, since the normal alterations of the schema involve manipulating these tables, such an addition would be f

Re: [HACKERS] Triggers on system catalog

Yes, you'd need to hack Postgres to add that capabilty, but that's too darned difficult since Postgres internally does not use SQL to perform the DML operations on system catalog. I'd suggest searching for past discussions on -hackers around this topic. Regards, On Tue, Mar 29, 2011 at 5:37 AM, S

[HACKERS] SHMEM_INDEX_SIZE exceeded on startup

I doubt that this is going to matter much, and should only have a trivial impact on shared space calculations and postmaster and connection startup time, but just as a matter of principle we might want to set SHMEM_INDEX_SIZE at least as large as the number of entries in ShmemIndex. At startup tha

Re: [HACKERS] Additional options for Sync Replication

On Tue, Mar 29, 2011 at 5:40 PM, Robert Haas wrote: > On Tue, Mar 29, 2011 at 10:48 AM, Dimitri Fontaine > wrote: >> So the rules are not the same for commiter patches and contributor >> patches, and there's no good in trying to have them the same or >> pretending they are.  In particular, only c

Re: [HACKERS] Additional options for Sync Replication

On Tue, Mar 29, 2011 at 10:48 AM, Dimitri Fontaine wrote: > So the rules are not the same for commiter patches and contributor > patches, and there's no good in trying to have them the same or > pretending they are.  In particular, only commiters are able to finish > and polish the work between th

Re: [HACKERS] Additional options for Sync Replication

On Tue, Mar 29, 2011 at 12:57 PM, Robert Haas wrote: > However, we also > bumped MANY patches to 9.2 because they weren't in sufficiently good > shape soon enough.  If we accept this patch now because a bunch of > people say they really, really want it, isn't that unfair to the > people to whom w

[HACKERS] Alpha 5 is now available for testing

The fifth alpha release for PostgreSQL version 9.1, 9.1alpha5, is now available. There are no new major features in this alpha release as compared to 9.1alpha4, but there are many minor bug fixes and improvements to features added in 9.1alpha4 and earlier alpha releases. It is expected that no

Re: [HACKERS] Replication server timeout patch

On Tue, Mar 29, 2011 at 9:24 AM, Tom Lane wrote: > Fujii Masao writes: >> On Mon, Mar 28, 2011 at 7:49 PM, Heikki Linnakangas >>> Should we use COMMERROR instead of ERROR if we fail to put the socket in the >>> right mode? > >> Maybe. > > COMMERROR exists to keep us from trying to send an error r

Re: [HACKERS] Problem with streaming replication, backups, and recovery (9.0.x)

On 29.03.2011 14:27, Fujii Masao wrote: On Tue, Mar 29, 2011 at 6:46 PM, hubert depesz lubaczewski wrote: Did you use recovery.conf to start standalone PostgreSQL? If not, recovery doesn't check whether it reaches the recovery ending position or not. So I guess no problem didn't happen. no,

Re: [HACKERS] Additional options for Sync Replication

Robert Haas writes: > If we accept this patch now because a bunch of > people say they really, really want it, isn't that unfair to the > people to whom we've already said "sorry, the deadline has passed"? No, because each time we're talking procedures we're forgetting about a simple fact. Comm

Re: [HACKERS] Another swing at JSON

Joseph Adams writes: > Done. The new extension interface isn't exactly compatible with the > old, so I dropped support for PostgreSQL 8.4 from the module. I > suppose I could maintain a back-ported json module separately. In fact it is, but there's some history hiding the fact. I'm overdue to

Re: [HACKERS] deadlock_timeout at < PGC_SIGHUP?

Excerpts from Greg Stark's message of mar mar 29 11:15:50 -0300 2011: > Alternatively we could have the deadlock timer reset all the time and > fire repeatedly. Then we could just have all backends ignore the > deadlock if they're not the lowest priority session in the cycle. But > this depends on

Re: [HACKERS] deadlock_timeout at < PGC_SIGHUP?

On Tue, Mar 29, 2011 at 2:20 PM, Tom Lane wrote: >  IIRC, the > current deadlock detector always kills the process that detected the > deadlock, but I *think* that's just a random choice and not an essential > feature.  If so, it'd be pretty easy to instead kill the lowest-priority > xact among th

Re: [HACKERS] Problem with streaming replication, backups, and recovery (9.0.x)

hubert depesz lubaczewski wrote: > it worked. now the slave2 is working as stand alone. > > what does it tell us? will any work happening after checkpoint > break it anyway? I'm less sure about what will put it into a bad state again than I was that an immediate checkpoint would put you into

Re: [HACKERS] SSI bug?

YAMAMOTO Takashi wrote: >>> [no residual SIReadLock] > > i read it as there are many (7057) SIReadLocks somehow leaked. > am i wrong? No, I am. Could you send the full SELECT * of pg_locks when this is manifest? (Probably best to do that off-list.) -Kevin -- Sent via pgsql-hackers maili

Re: [HACKERS] Replication server timeout patch

Fujii Masao writes: > On Mon, Mar 28, 2011 at 7:49 PM, Heikki Linnakangas >> Should we use COMMERROR instead of ERROR if we fail to put the socket in the >> right mode? > Maybe. COMMERROR exists to keep us from trying to send an error report down a failed socket. I would assume (perhaps wrongly

Re: [HACKERS] deadlock_timeout at < PGC_SIGHUP?

Robert Haas writes: > On Tue, Mar 29, 2011 at 1:38 AM, Noah Misch wrote: >> What is notable/surprising about the behavior when two backends have >> different >> values for deadlock_timeout? > I'd be inclined to think that PGC_SUSET is plenty. It's actually not > clear to me what the user could

Re: [HACKERS] deadlock_timeout at < PGC_SIGHUP?

On Tue, Mar 29, 2011 at 1:26 PM, Robert Haas wrote: > Is it worth thinking about having an explicit setting for deadlock > priority?  That'd be more work, of course, and I'm not sure it it's > worth it, but it'd also provide stronger guarantees than you can get > with this proposal. Priority mak

Re: [HACKERS] deadlock_timeout at < PGC_SIGHUP?

On Tue, Mar 29, 2011 at 1:38 AM, Noah Misch wrote: > A few years ago, this list had a brief conversation on $SUBJECT: > http://archives.postgresql.org/message-id/1215443493.4051.600.ca...@ebony.site > > What is notable/surprising about the behavior when two backends have different > values for dea

Re: [HACKERS] Additional options for Sync Replication

On Tue, Mar 29, 2011 at 3:49 AM, Dimitri Fontaine wrote: >> It would be better to just support it (recv|fsync|apply), >> or no syncrep at all. Syncrep is incomplete without it. > > Agreed. I have trouble viewing the idea that it would be better not to ship sync rep at all than to add more feature

Re: [HACKERS] Problem with streaming replication, backups, and recovery (9.0.x)

On Tue, Mar 29, 2011 at 6:46 PM, hubert depesz lubaczewski wrote: >> Did you use recovery.conf to start standalone PostgreSQL? If not, >> recovery doesn't check whether it reaches the recovery ending position >> or not. So I guess no problem didn't happen. > > no, i don't use. > > hmm .. i am near

Re: [HACKERS] Problem with streaming replication, backups, and recovery (9.0.x)

On Tue, Mar 29, 2011 at 11:13:07AM +0900, Fujii Masao wrote: > Yes, it's intentional. In streaming replication, at first the master must > stream > a backup history file to the standby in order to let it know the recovery > ending > position. But streaming replication doesn't have ability to send

Re: [HACKERS] Problem with streaming replication, backups, and recovery (9.0.x)

On Tue, Mar 29, 2011 at 11:20:48AM +0900, Fujii Masao wrote: > On Tue, Mar 29, 2011 at 12:11 AM, hubert depesz lubaczewski > wrote: > > On Mon, Mar 28, 2011 at 01:48:13PM +0900, Fujii Masao wrote: > >> In 9.0, recovery doesn't read a backup history file. That FATAL error > >> happens > >> if reco

Re: [HACKERS] Problem with streaming replication, backups, and recovery (9.0.x)

On Mon, Mar 28, 2011 at 05:29:22PM -0500, Kevin Grittner wrote: > I have a theory. Can you try it in what would be the failure case, > but run an explicit a CHECKPOINT on the master, wait for > pg_controldata to show that checkpoint on the slave, and (as soon as > you see that) try to trigger the

Re: [HACKERS] Additional options for Sync Replication

Yeb Havinga writes: > The dba interface for recv|fsync|apply seems to be pretty stable, so > supporting that for years should be without risk. How it works under the > hood - the beta period seems like *the* opportunity to attrach mayor testing > from all people waiting to get their hands on syncr

Re: [HACKERS] SSI bug?

hi, >> [no residual SIReadLock] i read it as there are many (7057) SIReadLocks somehow leaked. am i wrong? YAMAMOTO Takashi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers