On Mon, Apr 12, 2010 at 3:29 PM, Jaime Casanova
wrote:
> On Mon, Apr 12, 2010 at 1:21 AM, Fujii Masao wrote:
>> Didn't the standby
>> accept connections before executing pgbench?
>>
>
> nop, and last time i try it was in that state for an hour (without
> accepting connections)... after that i exe
On Mon, Apr 12, 2010 at 1:21 AM, Fujii Masao wrote:
> Didn't the standby
> accept connections before executing pgbench?
>
nop, and last time i try it was in that state for an hour (without
accepting connections)... after that i execute on the primary: CREATE
TABLE tt2 AS SELECT generate_series(1,
On Fri, Apr 9, 2010 at 3:39 PM, Jaime Casanova
wrote:
>
> but, my main concern is why it was asking for
> "00010006"? is this normal? is this standby's way of
> saying i'm working but i have nothing to do?
> when that happens after a standby restart, is normal that i have to
> wait
On Sat, Apr 10, 2010 at 5:39 AM, Jaime Casanova
wrote:
> i'm startint to try Hot Standby & Streaming Replication, so i started
> a replication:
Great!
> but, my main concern is why it was asking for
> "00010006"? is this normal?
The standby server tries to replay all of the avai
2010/4/12 Robert Haas :
> On Sun, Apr 11, 2010 at 5:24 AM, Greg Smith wrote:
>> From the rest of your comments, I'm comfortable that you're in sync with the
>> not necessarily obvious risky spots here I wanted to raise awareness of.
>> It's unreasonable to expect we'll have exactly the same prior
Robert Haas wrote:
> On Sun, Apr 11, 2010 at 10:26 AM, Heikki Linnakangas
> wrote:
>> Robert Haas wrote:
>>> 2010/4/10 Andrew Dunstan :
Heikki Linnakangas wrote:
> 1. Keep the materialized view up-to-date when the base tables change.
> This can be further divided into many steps, you
On Sun, Apr 11, 2010 at 5:24 AM, Greg Smith wrote:
> From the rest of your comments, I'm comfortable that you're in sync with the
> not necessarily obvious risky spots here I wanted to raise awareness of.
> It's unreasonable to expect we'll have exactly the same priorities here,
> and I doubt it
On Sun, Apr 11, 2010 at 10:13 PM, Florian G. Pflug wrote:
> If continuous updates prove to be too hard initially, you could instead
> update the view on select if it's outdated. Such a materialized view
> would be a kind of inter-session cache for subselects.
>
> The hard part would probably be to
On 11.04.10 20:47 , Robert Haas wrote:
On Sun, Apr 11, 2010 at 10:26 AM, Heikki Linnakangas
wrote:
Robert Haas wrote:
2010/4/10 Andrew Dunstan:
Heikki Linnakangas wrote:
1. Keep the materialized view up-to-date when the base tables
change. This can be further divided into many steps, you ca
On Sun, Apr 11, 2010 at 10:26 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> 2010/4/10 Andrew Dunstan :
>>> Heikki Linnakangas wrote:
1. Keep the materialized view up-to-date when the base tables change.
This can be further divided into many steps, you can begin by supporting
Robert Haas wrote:
> 2010/4/10 Andrew Dunstan :
>> Heikki Linnakangas wrote:
>>> 1. Keep the materialized view up-to-date when the base tables change.
>>> This can be further divided into many steps, you can begin by supporting
>>> automatic updates only on very simple views with e.g a single table
Robert Haas wrote:
I also think that you're underestimating the number of problems that
will have to be solved to get this done. It's going to take some
significant work - both design work and coding work - to figure out
how this should integrate into the rest of the system. (What should
be the
12 matches
Mail list logo
