On Thu, 2010-08-12 at 01:31 -0400, Tom Lane wrote:
> So the DBA is
> just flying blind as to whether the slave is trustworthy yet. I can't
> prove that that's what burnt the original complainant, but it fits the
> symptoms.
The safest approach is to
1. run pg_start_backup() on master, remember
On Thu, Aug 12, 2010 at 2:31 PM, Tom Lane wrote:
> What was bothering me about the procedure is that it's not clear when
> the new slave has reached consistency, in the sense of having used WAL
> to clean up any out-of-sync conditions in the base backup it was started
> from. So you can't be sure
On Thu, Aug 12, 2010 at 4:18 PM, Simon Riggs wrote:
> The safest approach is to
>
> 1. run pg_start_backup() on master, remember LSN
> 2. copy backup_label from master to standby
> 3. wait for starting LSN to be applied on standby
ISTM we should wait for the latest checkpoint redo location to rea
Hi,
Actually full_page_write being turned off on the master is probably a
problem.
-- Valentine
On Thu, Aug 12, 2010 at 9:43 AM, Fujii Masao wrote:
> On Thu, Aug 12, 2010 at 4:18 PM, Simon Riggs
> wrote:
> > The safest approach is to
> >
> > 1. run pg_start_backup() on master, remember LSN
>
On Wed, Aug 11, 2010 at 5:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> In theory, the optimization Brian wants is possible here, right? I
>> mean, you could replace the functional call with a Param, and pull the
>> Param out and make it an InitPlan. Seems like that would generally be
>> a wi
On Thu, Aug 12, 2010 at 5:33 PM, Valentine Gogichashvili
wrote:
> Hi,
> Actually full_page_write being turned off on the master is probably a
> problem.
Yep. As Simon suggests, we must run pg_start_backup on the master,
to take a backup from the standby safely even if full_page_writes
is disabled
Robert Haas writes:
> On Wed, Aug 11, 2010 at 5:12 PM, Tom Lane wrote:
>> Yeah, possibly. It would probably be difficult for the planner to
>> figure out where the cutover point is to make that worthwhile, though;
>> the point where you'd need to make the transformation is long before we
>> have
Fujii Masao writes:
> On Thu, Aug 12, 2010 at 5:33 PM, Valentine Gogichashvili
> wrote:
>> Actually full_page_write being turned off on the master is probably a
>> problem.
> Yep. As Simon suggests, we must run pg_start_backup on the master,
> to take a backup from the standby safely even if ful
On Thu, Aug 12, 2010 at 10:44 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 11, 2010 at 5:12 PM, Tom Lane wrote:
>>> Yeah, possibly. It would probably be difficult for the planner to
>>> figure out where the cutover point is to make that worthwhile, though;
>>> the point where you'd
Robert Haas writes:
> On Thu, Aug 12, 2010 at 10:44 AM, Tom Lane wrote:
>> Well, I was thinking in terms of doing it when we do the SRF inlining.
>> It might be that we could get away with just having an arbitrary cost
>> limit like 100*cpu_operator_cost, and not think about how many rows
>> woul
The following bug has been logged online:
Bug reference: 5614
Logged by: Mariusz Majer
Email address: mma...@janmedia.com
PostgreSQL version: 8.3.11
Operating system: Debian (Linux 2.6.26-1-686-bigmem #1 SMP i686 GNU/Linux)
Description:Varchar column (with DEFAULT NUL
On Thu, Aug 12, 2010 at 11:15 AM, Tom Lane wrote:
>> I'm not exactly following this. My guess is that the breakeven point
>> is going to be pretty low because I think Param nodes are pretty
>> cheap.
>
> If you have any significant number of executions of the expression, then
> of course converti
"Mariusz Majer" writes:
> There has been a table ecom2_orders for a while (~0.5m records). After
> executing query:
> ALTER TABLE ecom2_orders ADD COLUMN password_pdf character varying(50);
> when new rows are added, column password_pdf is filled with 'UL' value
> rather than null
Works fine he
On Wed, Aug 11, 2010 at 1:41 PM, Scott wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5613
> Logged by: Scott
> Email address: wheels7...@hotmail.com
> PostgreSQL version: 8.4
> Operating system: vista
> Description: cannot delete
> Details:
>
>
The following bug has been logged online:
Bug reference: 5616
Logged by: David E. Wheeler
Email address: da...@kineticode.com
PostgreSQL version: 8.4
Operating system: Mac OS X 10.6.4
Description:psql Doesn't Change Log files on \c
Details:
I have this in my .psqlrc
"David E. Wheeler" writes:
> I have this in my .psqlrc:
> \set HISTFILE ~/.psql_history- :DBNAME
> This is great, except when I change databases in a session:
> % psql foo
> foo % \c bar
> You are now connected to database "bar".
> SELECT true;
> The last statement will be lo
On Thu, Aug 12, 2010 at 11:53 PM, Tom Lane wrote:
>> (based on Simon's suggestion)
>> 1. run pg_start_backup() on master.
>> 2. copy backup_label from master to temporary area.
>> copying backup_label directly to standby would generate another
>> weakness (e.g., what if standby is restarted
17 matches
Mail list logo
