Re: [BUGS] BUG #8192: On very large tables the concurrent update with vacuum lag the hot_standby replica

2013-06-07 Thread Federico Campoli

On 06/06/13 21:22, Jeff Janes wrote:

On Tue, Jun 4, 2013 at 8:36 AM, Federico Campoli
feder...@brandwatch.com mailto:feder...@brandwatch.com wrote:


This is the gprof output for the profile.


This looks to me like the gprof of a process that is either idle, or
completely IO bound.

I'd probably approach this with a combination of strace -T -ttt -p
PID and lsof -p PID on the PID of the start-up process, to see
which file descriptors it is waiting for read or writes on, and what the
underlying names of the files for those file descriptors are.

Cheers,

Jeff


I've generated a strace from the startup process a new profile report 
and a new log file.


It's quite big so you can download here

http://d01.megashares.com/dl/BqZLh5H/HS_data_lag.tar

I've monitored the startup process lsof  and the only files accessed are 
the recovering wal and the relation affected by the master's activity.


Regarding the warm standby, I've repeated the test on my sandbox with 
the slave in warm standby and I've noticed a replication lag spike.


This does not affect the production,same database version and 
architecture from debian package.


If I turn on the hot standby on the failover in 30 minutes accumulates a 
several Gigabytes lag. When I switch off the lag disappear.


I can just guess in WS the lag have less impact as the random read 
resumes quicker than the HS.


Many thanks
Federico

--
Federico Campoli
Database Administrator brandwatch.com


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] BUG #8216: TO_DATE does not support th format provided

2013-06-07 Thread Tom Lane
sunitha.mudu...@blss.com.au writes:
 To_date does not throw an error when an invalid date is provided to it
 select to_date('10-30-2012','dd-MM-');

That's not a bug; it's operating as designed.  If you want more error
checking, don't use to_date() --- just cast the string to date.

regression=# show datestyle;
 DateStyle 
---
 ISO, MDY
(1 row)

regression=# select '10-30-2012'::date;
date

 2012-10-30
(1 row)

regression=# set datestyle = dmy;
SET
regression=# select '10-30-2012'::date;
ERROR:  date/time field value out of range: 10-30-2012
LINE 1: select '10-30-2012'::date;
   ^
HINT:  Perhaps you need a different datestyle setting.

regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] BUG #8215: pg_dump includes table out of order in SQL dump

2013-06-07 Thread Isaac Morland

On Thu, 6 Jun 2013, Tom Lane wrote:


ijmor...@uwaterloo.ca writes:

My understanding is that pg_dump is supposed to include tables in SQL dumps
in alphabetical order by table name.


That's the default behavior as long as there are no ordering constraints
that would dictate doing something else.  You haven't provided enough
info to tell whether there's such a constraint in your case ...


Thanks, I wanted to establish that before digging up more detail (more 
recently, I noticed that the 8.0 Release Notes advertise the use of 
alphabetical order as new, although I can't find an indication in the 
actual pg_dump documentation that it tries to use alphabetical order).


What I have is a dev instance which is was created by running a psql 
script file.  I also have a prod instance which was originally created by 
running an older version of the script but has had some changes applied.


When I pg_dump the two instances (using --schema-only), I get files that 
are identical, except that one table is out of place in the dump from 
prod, both in the part where it puts the table definitions and further 
down where it grants permissions.


When I load the pg_dump outputs, and then dump the resulting schemas, 
those dumps are identical to each other and almost identical to the 
original dev dump (although different from the original dev dump by the 
addition of extra ::text type specifiers in a few view definitions).


So, the difference between dev and prod is nothing that shows up in 
pg_dump output.


I thought of different foreign key references to the table having crept in 
somehow, but a \d+ on both the dev and prod version of the problem table 
gives the same results - both versions of the table are referenced by the 
same 3 corresponding tables.


I should also add that I'm not clear on when alphabetical order for tables 
would not work - with all constraints being added on at the end after all 
tables have been created (and populated, in the case of a data dump, which 
is not my case), is there ever a time when tables have to be in a 
different order?  I think views have to be in an order determined by their 
dependencies, but not tables.


One final thought I had was to start digging around in the system tables 
to find the difference (in principle, the difference *has* to be there, 
right?).  So I looked at the pg_class records for my problem table as 
compared to other tables, and I don't see any suspicious differences.  I 
suppose next I might start digging into other related pg_* tables to see 
if I can find anything.


Obviously, this is still not enough to debug pg_dump (even assuming there 
actually is a problem there, which isn't exactly my default explanation). 
However, I'm hoping it provides enough detail for you to be able to say 
whether there is a chance of this being a real bug.


Isaac Morland   CSCF Web Guru
DC 2554C, x36650WWW Software Specialist


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs