public.commandprompt.com: Issueshttps://public.commandprompt.com/https://public.commandprompt.com/favicon.ico?16484970162012-09-17T04:13:45Zpublic.commandprompt.com
Redmine pitrtools - Feature #5265 (New): Avoid the need to manually edit postgresql.conf fileshttps://public.commandprompt.com/issues/52652012-09-17T04:13:45ZAlexey Klyukinalexk@commandprompt.com
<p>Right now, we have a bizarre combination of running cmd_archiver from the command line and plugging it in postgresql.conf manually. Given that we already know the location of postgresql.conf, we can edit it to set all necessary options (wal_level, max_wal_senders, archive_mode, archive_command) automatically, leaving only database restart as a task that should be performed manually.</p> pitrtools - Discussion #5263 (New): PITRTools ini configuration files are too complexhttps://public.commandprompt.com/issues/52632012-09-17T04:03:52ZAlexey Klyukinalexk@commandprompt.com
<p>Since we position PITRTools as a tool to simplify WAL-shipping and replication setup, I though I'd count the number of options once needs to set in PIRTools, against pristine PostgresSQL:</p>
<p>PITRTools:<br />Archiver: 15<br />Standby: 31.</p>
<p>Comparing to the pristine PostgreSQL:<br />primary: (wal_level, archive_mode, archive_command, max_wal_senders) - 4.</p>
<p>standby (most of them belong to recovery.conf): (hot_standby, standby_mode, primary_conninfo, restore_command, archive_cleanup_command): 5</p>
<p>We need to rethink PITRTools configuration options. I've made the first step by splitting them into required and uncommon, and put reasonable defaults for the second ones (i.e. assumed ssh and rsync path is fixed, and there is no need to tweak rsync options or set ssh_debug), but to make the tool easier than pristine PostgreSQL we need to put some code to autodetect some of the parameters (i.e. autodetect things like PostgreSQL version, checkpoint_segments value for 8.2 and below, rsync_version, etc.)</p> PL/php - Bug #5225 (New): Unable to build PL/php on OS X (PHP 5.3)https://public.commandprompt.com/issues/52252010-06-29T05:25:59ZAlexey Klyukinalexk@commandprompt.com
<p>On OS X embed is built as a bundle instead of a library, making it impossible to link against it.</p>
<p>I've submitted the problem to the PHP project:<br /><a class="external" href="http://bugs.php.net/bug.php?id=48318">http://bugs.php.net/bug.php?id=48318</a></p>
<p>Still, it's not possible to build PL/php at the moment on this platform.</p> Pggraph - Bug #4952 (New): Help interfacehttps://public.commandprompt.com/issues/49522008-07-21T10:40:30ZAurynn Shawashaw@commandprompt.com
<p>Come up with a mechanism to provide "help" tooltips as needed for various form elements. Decouple from existing templates and code, figure out a mechanism/library to handle it.</p> Pggraph - Bug #4951 (New): Document date range behaviourhttps://public.commandprompt.com/issues/49512008-07-21T10:38:00ZAurynn Shawashaw@commandprompt.com
<p>As title - document how pggraph will function in Date Range mode, as well as out of Date Range mode.</p> Pggraph - Bug #4950 (New): Write unit testshttps://public.commandprompt.com/issues/49502008-07-17T17:02:20ZAurynn Shawashaw@commandprompt.com
<p>This is pretty obvious</p> Pggraph - Bug #4949 (New): Document behaviourhttps://public.commandprompt.com/issues/49492008-07-17T16:59:08ZAurynn Shawashaw@commandprompt.com
<p>When date start and date end are used, it defaults to the range behavior.</p>
<p>When neither are selected, it defaults to the previous behavior, which is now() - interval time.</p> Pggraph - Bug #4948 (New): in pggraph_table, prevent crash if no tables presenthttps://public.commandprompt.com/issues/49482008-07-16T21:42:46ZAurynn Shawashaw@commandprompt.com
<p>If a given database doesn't have any tables, and it is the default in pggraph_table.py, then we need to catch that and switch to a different database/datname.</p> Pggraph - Bug #4947 (New): Do testing of data arrayshttps://public.commandprompt.com/issues/49472008-07-16T21:01:03ZAurynn Shawashaw@commandprompt.com
<p>While generating date range pages, we should test the length of each return set, so that we can trim out offsets that are going to be no-shows.</p>
<p>This is going to be kind of expensive to do for every page refresh, but I feel it's <br />worthwhile.</p>
<p>Alternatively, just have "NO DATA" splayed over the image in the event that there's no data.</p>
<p>How should we approach this?</p> Pggraph - Bug #4945 (New): Force all graphs to abort if non-specific data specifiedhttps://public.commandprompt.com/issues/49452008-07-15T15:32:45ZAurynn Shawashaw@commandprompt.com
<p>For all graphs, prevent date ranges from working if:</p>
<ul>
<li>High-level, multi-graph pages would be generated normally</li>
<li>Non-specific data is passed to the graphing function.
<ul>
<li>For pggraph_database, it REQUIRES a datname</li>
<li>For pggraph_table, it requires a datname, a tablename and a schemaname</li>
<li>For pggraph_index, it requires a datname, an indexname, and a schemaname</li>
</ul></li>
</ul> Pggraph - Bug #4943 (New): Future Planning and Ideashttps://public.commandprompt.com/issues/49432008-07-14T11:32:17ZAurynn Shawashaw@commandprompt.com
<ul>
<li>Javascript+SVG-based graphs, based on example code Darcy showed off a while back. This would allow us to do offset-based graphs (clicking an offset of, say, 5 days scrolls it back in time that far), as well as the ability to do click & drag ala the Google Maps interface.</li>
</ul> Pggraph - Bug #4940 (New): Remove prefixeshttps://public.commandprompt.com/issues/49402008-07-14T11:05:46ZAurynn Shawashaw@commandprompt.com
<p>As we are moving to a schema'd design, remove the prefix additions from the code and all new installations.</p>
<p>This involves a plpgsql function signature change.</p> Pggraph - Bug #4937 (New): Modification of DB Client code for date rangeshttps://public.commandprompt.com/issues/49372008-07-14T10:45:13ZAurynn Shawashaw@commandprompt.com
<p>The client code needs to be modified to take advantage of the new date range function signatures.</p>
<p>This will require:</p>
<ul>
<li>Modification of the functions that call the DB functions.
<ul>
<li>Ideally (and this will be a new ticket) I'd like to write the transparent python->db function mapper (obj.func(arg,arg) gets seamlessly converted to SELECT * FROM func(arg,arg))</li>
</ul></li>
</ul> Pggraph - Bug #4936 (New): Modify averaging functionshttps://public.commandprompt.com/issues/49362008-07-14T10:11:55ZAurynn Shawashaw@commandprompt.com
<p>All plpgsql functions will need two new arguments, and one removed argument:</p>
<p>start DATE, end DATE, and removal of offset INT.</p>
<p>The functions will be altered in the following ways:</p>
<ul>
<li>Determining the length of the WHILE loop from the date ranges, if present, instead of using the interval to calculate it.</li>
<li>Alter the queries to use the start DATE parameter to position the start of the set, and then utilize the WHILE loop to offset from that point, ie, WHERE date = date_start + (interval * iterations)::interval</li>
</ul> PL/php - Feature #4979 (In Progress): Add support for IN/OUT parametershttps://public.commandprompt.com/issues/49792005-12-05T07:37:14ZÁlvaro Herreraalvherre@commandprompt.com
<p>Add support for OUT parameters so that the user can skip specifying a return type explicitely.</p>