Re: [BUGS] BUG #8192: On very large tables the concurrent update with vacuum lag the hot_standby replica
On Thursday, May 30, 2013, wrote: > The following bug has been logged on the website: > > Bug reference: 8192 > Logged by: Federico Campoli > Email address: feder...@brandwatch.com > PostgreSQL version: 9.2.4 > Operating system: Debian 6.0 > Description: > > /* > > Description: > > It seems on very large tables the concurrent update with vacuum (or > autovacuum), > when the slave is in hot standby mode, generates long loops in read on a > single wal segment during the recovery process. > > This have two nasty effects. > A massive read IO peak and the replay lag increasing as the recovery > process > hangs for long periods on a pointless loop. > Are you observing a loop, and if so how are you observing it? What is it that is looping? > SET client_min_messages='debug2'; > SET trace_sort='on'; > Are these settings useful? What are they showing you? > > --in a new session and start an huge table update > UPDATE t_vacuum set ts_time=now() WHERE i_id_row<2000; > > --then vacuum the table > VACUUM VERBOSE t_vacuum; > Are you running the update and vacuum concurrently or serially? > > --at some point the startup process will stuck recovering one single wal > file and > --the DISK READ column will show a huge IO for a while. > What is huge? I don't know if I can reproduce this or not. I certainly get spiky lag, but I see no reason to think it is anything other than IO congestion, occurring during stretches of WAL records where compact records describe a larger amount of work that needs to be done in terms of poorly-cached IO. Perhaps the kernel's read-ahead mechanism is not working as well as it theoretically could be. Also the standby isn't using a ring-buffer strategy, but I see no reason to think it would help were it to do so. The DISK READ column is not what I would call huge during this, often 10-15 MB/S, because much of the IO is scattered rather than sequential. The IO wait % on the other hand is maxed out. It is hard to consider it as a bug that the performance is not as high as one might wish it to be. Is this behavior a regression from some earlier version? What if hot-standby is turned off? Cheers, Jeff
Re: [BUGS] BUG #8192: On very large tables the concurrent update with vacuum lag the hot_standby replica
On 30 May 2013 17:43, wrote: > It seems on very large tables the concurrent update with vacuum (or > autovacuum), > when the slave is in hot standby mode, generates long loops in read on a > single wal segment during the recovery process. Not all aspects of hot standby are optimally tuned, as yet. Some room for improvement exists. In some cases, conscious choices were made to keep processing on master fast at the expense of speed on the standby. There doesn't seem to be anything which is in itself an error here. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] [BUGS] COPY .... (FORMAT binary) syntax doesn't work
On 27 May 2013 15:31, Tom Lane wrote: > Simon Riggs writes: >> On 26 May 2013 17:10, Tom Lane wrote: >>> More readable would be to invent an intermediate nonterminal falling >>> between ColId and ColLabel, whose expansion would be "IDENT | >>> unreserved_keyword | col_name_keyword | type_func_name_keyword", and >>> then replace ColId_or_Sconst with whatever-we-call-that_or_Sconst. >>> Any thoughts about a name for that new nonterminal? > >> Do you think complicating the parser in that way is worth the trouble >> for this case? Could that slow down parsing? > > It makes the grammar tables a bit larger (1% or so IIRC). There would > be some distributed penalty for that, but probably not much. Of course > there's always the slippery-slope argument about that. > >> We don't actually have to fix it; clearly not too many people are >> bothered, since no complaints in 3 years. Documenting 'binary' seems >> better. > > Well, my thought is there are other cases. For instance: > > regression=# create role binary; > ERROR: syntax error at or near "binary" > LINE 1: create role binary; > ^ > regression=# create user cross; > ERROR: syntax error at or near "cross" > LINE 1: create user cross; > ^ > > If we don't have to treat type_func_name_keywords as reserved in these > situations, shouldn't we avoid doing so? Seems reasonable argument, so +1. Sorry for delayed reply. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- 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 #8197: Error Message When trying to install PS8.1
Michael Paquier wrote: > wrote: > >> initdb: removing contents of data directory "C:/Program Files >> (x86)/PostgreSQL/8.1/data" > > Only Postgres 8.1 is not supported anymore by the community for a > couple of years. More than that. Note that this seems to be on Windows. While support of 8.1 was ended five years after its 2005 release, support was terminated earlier on Windows because of bugs on that platform which were fixed in 8.2 in a way which was too intrusive to back-patch. So it has been out of support on Windows for roughly six years now. > You should use a newer version. Most definitely. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #8193: A few cosmetic misspell fixes.
* Michael Paquier (michael.paqu...@gmail.com) wrote: > Please attach patches directly with the mails you send. +1. > For the patch, yes OK there are some spell mistakes. However this patch > should only apply on master branch, and not 9.2 as referenced above. Agreed. > Also, > changing the structure name to Extension does not look to be appropriate as > it is a generic name... Took a simpler approach and just renamed it to CoverExt, that should also avoid any confusion with actual extensions. Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] BUG #8197: Error Message When trying to install PS8.1
On Sat, Jun 1, 2013 at 3:34 AM, wrote: > initdb: removing contents of data directory "C:/Program Files > (x86)/PostgreSQL/8.1/data" > Only Postgres 8.1 is not supported anymore by the community for a couple of years. You should use a newer version. -- Michael
Re: [BUGS] BUG #8193: A few cosmetic misspell fixes.
On Fri, May 31, 2013 at 1:51 AM, wrote: > The following bug has been logged on the website: > > Bug reference: 8193 > Logged by: Lajos Veres > Email address: vla...@gmail.com > PostgreSQL version: 9.2.4 > Operating system: Linux > Description: > > Found a few small misspell with this: > https://github.com/vlajos/misspell_fixer > > I created a small patch here: > http://www.pastebin.ca/2385261 > Referring a patch with an external link is bad practice as the external service you use could disappear, making this patch lost at the same time. Please attach patches directly with the mails you send. For the patch, yes OK there are some spell mistakes. However this patch should only apply on master branch, and not 9.2 as referenced above. Also, changing the structure name to Extension does not look to be appropriate as it is a generic name... -- Michael
