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
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
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
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
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
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
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.
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/
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"
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
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
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.
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
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
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
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
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
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
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
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
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;
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
48 matches
Mail list logo
