Re: [HACKERS] How to avoid base backup in automated failover

2012-10-16 Thread Amit Kapila
On Wednesday, October 17, 2012 11:22 AM chinnaobi wrote: > Hey Haas, > > What does the standby server have to wait for replication to catch up > before > promoting ?? Is there any parameter to configure this ?? > > Few more questions on this part > > 1. How could we ensure the standby has receiv

Re: [HACKERS] [RFC] CREATE QUEUE (log-only table) for londiste/pgQ ccompatibility

2012-10-16 Thread Simon Riggs
On 16 October 2012 23:03, Josh Berkus wrote: > Can you explain in more detail how this would be used on the receiving > side? I'm unable to picture it from your description. This will allow implementation of pgq in core, as discussed many times at cluster hackers meetings. > I'm also a bit rel

Re: [HACKERS] How to avoid base backup in automated failover

2012-10-16 Thread chinnaobi
Hey Haas, What does the standby server have to wait for replication to catch up before promoting ?? Is there any parameter to configure this ?? Few more questions on this part 1. How could we ensure the standby has received all transactions sent by primary till the point primary server is dead

Re: [HACKERS] How to avoid base backup in automated failover

2012-10-16 Thread chinnaobi
Hey Haas,What does the standby server have to wait for replication to catch up before promoting ?? Is there any parameter to configure this ??Few more questions on this part 1. How could we ensure the standby has received all transactions sent by primary till the point primary server is dead. (Mean

Re: [HACKERS] WebSphere Application Server support for postgres

2012-10-16 Thread Florent Guillaume
On Mon, Oct 15, 2012 at 10:28 AM, Dave Page wrote: > [Removing all lists except -hackers. Please do not cross-post to every > list again!] > > On Mon, Oct 15, 2012 at 9:22 AM, John Nash > wrote: >> Hi, >> >> Our IT Company systems architecture is based on IBM Websphere >> Application Server, we w

[HACKERS] Doc patch "only relevant" -> "relevant only"

2012-10-16 Thread Karl O. Pinc
Hi, As long as I'm sending in trivial fixes to the docs here's a bit of wording that's been bugging me. In a number of places the docs read "only relevant", this patch reverses this to read "relevant only". I believe this reads better because it quickly answers the question "is what?" with "is r

[HACKERS] Doc patch, put commas in the right place in pg_restore docs

2012-10-16 Thread Karl O. Pinc
Hi, Simple punctuation change to pg_restore docs. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein diff --git a/doc/src/sgml/ref/pg_restore.sgml b/doc/src/sgml/ref/pg_restore.sgml index b276da6..e3520c0 100644 --- a/doc/src/sgml/ref/pg_restore.

Re: [HACKERS] Suggestion for --truncate-tables to pg_restore

2012-10-16 Thread Karl O. Pinc
Hi, Attached is version 3. The convention seems to be to leave the operator at the end of the line when breaking long lines, so do that. Add extra () -- make operator precedence explicit and have indentation reflect operator precedence. On 09/23/2012 08:52:07 PM, Karl O. Pinc wrote: > On 09/23/

Re: [HACKERS] [RFC] CREATE QUEUE (log-only table) for londiste/pgQ ccompatibility

2012-10-16 Thread Josh Berkus
Hannu, Can you explain in more detail how this would be used on the receiving side? I'm unable to picture it from your description. I'm also a bit reluctant to call this a "message queue", since it lacks the features required for it to be used as an application-level queue. "REPLICATION MESSAGE"

Re: [HACKERS] change in LOCK behavior

2012-10-16 Thread Ants Aasma
On Thu, Oct 11, 2012 at 7:53 PM, Tom Lane wrote: > Maybe what we really need is to find a way to make taking a snapshot a > lot cheaper, such that the whole need for this patch goes away. We're > not going to get far with the idea of making SnapshotNow MVCC-safe > unless it becomes a lot cheaper

Re: [HACKERS] tuplesort memory usage: grow_memtuples

2012-10-16 Thread Peter Geoghegan
On 16 October 2012 22:18, Greg Stark wrote: > That's assuming my committer bits haven't lapsed and people are ok > with me stepping back into things? I personally have no objections. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services

Re: [HACKERS] tuplesort memory usage: grow_memtuples

2012-10-16 Thread Greg Stark
On Tue, Oct 16, 2012 at 9:47 PM, Peter Geoghegan wrote: > The patch will now been marked "ready for committer". Does this need > doc changes, in light of what is arguably a behavioural difference? > You only mentioned release notes. I'm happy to look at this one, probably next week at pgconf.eu.

Re: [HACKERS] tuplesort memory usage: grow_memtuples

2012-10-16 Thread Peter Geoghegan
On 16 October 2012 14:24, Simon Riggs wrote: > If you describe in detail that it is a heuristic and why that is > proposed over other approaches that should be sufficient for future > generations to read and understand. I've done so, in the attached revision. Things have been simplified somewhat

Re: [HACKERS] proposal - assign result of query to psql variable

2012-10-16 Thread Pavel Stehule
2012/10/16 Shigeru HANADA : > Hi Pavel, > > On Tue, Oct 16, 2012 at 6:59 AM, Pavel Stehule > wrote: >> here is updated patch, I moved lot of code from lexer to command.com, >> and now more \gset doesn't disable other backslash commands on same >> line. > > * lexer changes > IIUC, new function psql

Re: [HACKERS] proposal - assign result of query to psql variable

2012-10-16 Thread Pavel Stehule
Hello here is updated patch, I moved lot of code from lexer to command.com, and now more \gset doesn't disable other backslash commands on same line. Regards Pavel 2012/10/15 Pavel Stehule : > 2012/10/15 Pavel Stehule : >> 2012/10/15 Shigeru HANADA : >>> Hi Pavel, >>> >>> First of all, I'm sorr

Re: [HACKERS] smgrsettransient mechanism is full of bugs

2012-10-16 Thread Alvaro Herrera
Tom Lane wrote: > After further review, I have become convinced that in fact it's > completely broken and needs to be redone from scratch. The temp-file > marking at the fd.c level can easily get out of sync with the marking > at the smgr level, and that marking isn't too consistent with reality

Re: [HACKERS] Truncate if exists

2012-10-16 Thread Stafford, David x78061
On Mon, 15 Oct 2012 10:21:18 -0700, Robert Haas wrote: > Yeah, I think the functionality that we need is pretty much there > already today. What we need to do is to get the syntax to a point > where people can write the code they want to write without getting > tangled up by it. > > I think the

Re: [HACKERS] proposal - assign result of query to psql variable

2012-10-16 Thread Shigeru HANADA
Hi Pavel, On Tue, Oct 16, 2012 at 6:59 AM, Pavel Stehule wrote: > here is updated patch, I moved lot of code from lexer to command.com, > and now more \gset doesn't disable other backslash commands on same > line. * lexer changes IIUC, new function psql_scan_varlist_varname scans input and retur

Re: [HACKERS] Global Sequences

2012-10-16 Thread Tom Lane
Simon Riggs writes: > On 16 October 2012 17:15, Tom Lane wrote: >> So I fully >> expect that we're going to need something different from bog-standard >> CREATE SEQUENCE. > There's no point in that at all, as explained. It's sequences that > need to work. We can already call my_nextval() rather

Re: [HACKERS] Global Sequences

2012-10-16 Thread Simon Riggs
On 16 October 2012 17:17, Peter Eisentraut wrote: > On 10/16/12 9:20 AM, Simon Riggs wrote: >> I've proposed a plugin for the allocation only. So the allocation >> looks like anything you want. > > Are you planning to provide a reference implementation of some kind? I'll provide hooks and a stub

Re: [HACKERS] Global Sequences

2012-10-16 Thread Simon Riggs
On 16 October 2012 17:15, Tom Lane wrote: > Simon Riggs writes: >> On 16 October 2012 15:15, Tom Lane wrote: >>> I think this is a fundamentally wrong way to go about doing what you >>> want to do. It presumes that DDL-level manipulation of global sequences >>> is exactly like local sequences;

Re: [HACKERS] Global Sequences

2012-10-16 Thread Daniel Farina
On Tue, Oct 16, 2012 at 5:54 AM, Peter Eisentraut wrote: > On 10/15/12 5:33 PM, Simon Riggs wrote: >> There are a few options >> 1) Manual separation of the value space, so that N1 has 50% of >> possible values and N2 has 50%. That has problems when we reconfigure >> the cluster, and requires comp

Re: [HACKERS] Fix for log_line_prefix and session display

2012-10-16 Thread Bruce Momjian
Applied. --- On Mon, Oct 15, 2012 at 02:22:33PM -0400, Bruce Momjian wrote: > On Mon, Oct 15, 2012 at 10:01:29AM +0200, Albe Laurenz wrote: > > Bruce Momjian wrote: > > > Currently, our session id, displayed by log_line_pref

Re: [HACKERS] Global Sequences

2012-10-16 Thread Peter Eisentraut
On 10/16/12 9:20 AM, Simon Riggs wrote: > I've proposed a plugin for the allocation only. So the allocation > looks like anything you want. Are you planning to provide a reference implementation of some kind? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Global Sequences

2012-10-16 Thread Tom Lane
Simon Riggs writes: > On 16 October 2012 15:15, Tom Lane wrote: >> I think this is a fundamentally wrong way to go about doing what you >> want to do. It presumes that DDL-level manipulation of global sequences >> is exactly like local sequences; an assumption that is obviously false. > The mes

[HACKERS] Bugs in planner's equivalence-class processing

2012-10-16 Thread Tom Lane
I looked into the problem reported in bug #7604 (Bill MacArthur was kind enough to send me a reproducer off-list). The error can be demonstrated by this example in the regression test database: select f1, unique2, case when unique2 is null then f1 else 0 end from int4_tbl a left join tenk1 b on

Re: [HACKERS] pg_stat_lwlocks view - lwlocks statistics, round 2

2012-10-16 Thread Satoshi Nagayasu
2012/10/16 2:40, Jeff Janes wrote: On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane wrote: Satoshi Nagayasu writes: (2012/10/14 13:26), Fujii Masao wrote: The tracing lwlock usage seems to still cause a small performance overhead even if reporting is disabled. I believe some users would prefer to a

Re: [HACKERS] [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)

2012-10-16 Thread Jan Wieck
On 10/15/2012 3:25 PM, Andres Freund wrote: On Monday, October 15, 2012 09:18:57 PM Peter Geoghegan wrote: On 15 October 2012 19:19, Bruce Momjian wrote: > I think Robert is right that if Slony can't use the API, it is unlikely > any other replication system could use it. I don't accept that.

Re: [HACKERS] Global Sequences

2012-10-16 Thread Simon Riggs
On 16 October 2012 15:15, Tom Lane wrote: > Simon Riggs writes: >> So, proposal is to allow nextval() allocation to access a plugin, >> rather than simply write a WAL record and increment. If the plugin is >> loaded all sequences call it (not OIDs). > > I think this is a fundamentally wrong way t

Re: [HACKERS] Bug in -c CLI option of pg_dump/pg_restore

2012-10-16 Thread Guillaume Lelarge
On Sat, 2012-10-13 at 16:47 +0200, Guillaume Lelarge wrote: > Hi, > > One of my colleagues, Jehan-Guillaume de Rorthais, found a weird > behaviour of the "-c" command line option in the pg_restore tool while > doing a training. Here is the following steps he followed: > > createdb foo > > pg_dum

Re: [HACKERS] [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)

2012-10-16 Thread Jan Wieck
On 10/15/2012 4:43 PM, Simon Riggs wrote: Jan spoke at length at PgCon, for all to hear, that what we are building is a much better way than the trigger logging approach Slony uses. I don't take that as carte blanche for approval of everything being done, but its going in the right direction with

Re: [HACKERS] Global Sequences

2012-10-16 Thread Tom Lane
Simon Riggs writes: > So, proposal is to allow nextval() allocation to access a plugin, > rather than simply write a WAL record and increment. If the plugin is > loaded all sequences call it (not OIDs). I think this is a fundamentally wrong way to go about doing what you want to do. It presumes

Re: [HACKERS] tuplesort memory usage: grow_memtuples

2012-10-16 Thread Simon Riggs
On 16 October 2012 13:42, Peter Geoghegan wrote: > On 14 October 2012 09:19, Simon Riggs wrote: >> This is a very useful optimisation, for both the low and the high end. > > Well, I'm about ready to mark this one "ready for committer". There is > this outstanding issue in my revision of August 17

Re: [HACKERS] Global Sequences

2012-10-16 Thread Simon Riggs
On 16 October 2012 13:54, Peter Eisentraut wrote: > On 10/15/12 5:33 PM, Simon Riggs wrote: >> There are a few options >> 1) Manual separation of the value space, so that N1 has 50% of >> possible values and N2 has 50%. That has problems when we reconfigure >> the cluster, and requires complex man

Re: [HACKERS] Global Sequences

2012-10-16 Thread Andres Freund
On Tuesday, October 16, 2012 02:58:11 PM Andrew Dunstan wrote: > On 10/16/2012 08:54 AM, Peter Eisentraut wrote: > > Option 4 is of course to use UUIDs. > > Yeah, I was wondering what this would really solve that using UUIDs > wouldn't solve. Large indexes over random values perform notably worse

Re: [HACKERS] Global Sequences

2012-10-16 Thread Andrew Dunstan
On 10/16/2012 08:54 AM, Peter Eisentraut wrote: Option 4 is of course to use UUIDs. Yeah, I was wondering what this would really solve that using UUIDs wouldn't solve. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscrip

Re: [HACKERS] Global Sequences

2012-10-16 Thread Peter Eisentraut
On 10/15/12 5:33 PM, Simon Riggs wrote: > There are a few options > 1) Manual separation of the value space, so that N1 has 50% of > possible values and N2 has 50%. That has problems when we reconfigure > the cluster, and requires complex manual reallocation of values. So it > starts good but ends

Re: [HACKERS] [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown

2012-10-16 Thread Heikki Linnakangas
On 15.10.2012 19:31, Fujii Masao wrote: On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas wrote: On 15.10.2012 13:13, Heikki Linnakangas wrote: Oh, I didn't remember that we've documented the specific structs that we pass around. It's quite bogus anyway to explain the messages the way we

Re: [HACKERS] tuplesort memory usage: grow_memtuples

2012-10-16 Thread Peter Geoghegan
On 14 October 2012 09:19, Simon Riggs wrote: > This is a very useful optimisation, for both the low and the high end. Well, I'm about ready to mark this one "ready for committer". There is this outstanding issue in my revision of August 17th, though: + /* +* XXX: Th

Re: [HACKERS] Global Sequences

2012-10-16 Thread Simon Riggs
On 16 October 2012 13:26, Markus Wanner wrote: > Why does a "Global Sequences" API necessarily hook at the nextval() and > setval() level? That sounds like it yields an awkward amount of > duplicate work. Reading this thread, so far it looks like we agree that > option 3) is the most feasible opt

Re: [HACKERS] Global Sequences

2012-10-16 Thread Markus Wanner
On 10/16/2012 12:47 AM, Josh Berkus wrote: > I'd also love to hear from the PostgresXC folks on whether this solution > works for them. Postgres-R too. In Postgres-R, option 3) is implemented. Though, by default sequences work just like on a single machine, giving you monotonically increasing seq

[HACKERS] First draft of snapshot snapshot building design document

2012-10-16 Thread Andres Freund
Hi All, On Thursday, October 11, 2012 01:02:26 AM Peter Geoghegan wrote: > The design document [2] really just explains the problem (which is the > need for catalog metadata at a point in time to make sense of heap > tuples), without describing the solution that this patch offers with > any degree

Re: [HACKERS] [RFC] CREATE QUEUE (log-only table) for londiste/pgQ ccompatibility

2012-10-16 Thread Hannu Krosing
On 10/16/2012 11:29 AM, Hannu Krosing wrote: On 10/16/2012 11:18 AM, Simon Riggs wrote: On 16 October 2012 09:56, Hannu Krosing wrote: Hallo postgresql and replication hackers This mail is an additional RFC which proposes a simple way to extend the new logical replication feature so it can

Re: [HACKERS] [RFC] CREATE QUEUE (log-only table) for londiste/pgQ ccompatibility

2012-10-16 Thread Simon Riggs
On 16 October 2012 10:29, Hannu Krosing wrote: > I would like this to be very similar to a table, so it would be > > CREATE MESSAGE QUEUE(fieldname type, ...) foo; > > perhaps even allowing defaults and constraints. again, this > depends on how complecxt the implementation would be. Presumably j

Re: [HACKERS] [RFC] CREATE QUEUE (log-only table) for londiste/pgQ ccompatibility

2012-10-16 Thread Hannu Krosing
On 10/16/2012 11:18 AM, Simon Riggs wrote: On 16 October 2012 09:56, Hannu Krosing wrote: Hallo postgresql and replication hackers This mail is an additional RFC which proposes a simple way to extend the new logical replication feature so it can cover most usages of skytools/pgq/londiste Whil

Re: [HACKERS] [RFC] CREATE QUEUE (log-only table) for londiste/pgQ ccompatibility

2012-10-16 Thread Simon Riggs
On 16 October 2012 09:56, Hannu Krosing wrote: > Hallo postgresql and replication hackers > > This mail is an additional RFC which proposes a simple way to extend the > new logical replication feature so it can cover most usages of > skytools/pgq/londiste > > While the current work for BDR/LCR (bi

[HACKERS] [RFC] CREATE QUEUE (log-only table) for londiste/pgQ ccompatibility

2012-10-16 Thread Hannu Krosing
Hallo postgresql and replication hackers This mail is an additional RFC which proposes a simple way to extend the new logical replication feature so it can cover most usages of skytools/pgq/londiste While the current work for BDR/LCR (bi-directional replication/logical replication) using WAL

Re: [HACKERS] Global Sequences

2012-10-16 Thread Yeb Havinga
On 2012-10-15 23:33, Simon Riggs wrote: So, proposal is to allow nextval() allocation to access a plugin, rather than simply write a WAL record and increment. If the plugin is loaded all sequences call it (not OIDs). +1. It is currently impossible to alter nextvals behaviour, without making chan