Clone wiki

ruby-pg / Submitting Tickets

Submitting a Ticket

Before You Submit

1. Make Sure Your Issue is a Driver Issue

If you're using a database library that wraps the pg library (e.g., ActiveRecord, Sequel, etc.), please make sure your issue isn't with that library instead. A good way to do this is to write a minimal test case that doesn't use the top-level library. See "Post A Minimal Test Case" below.

2. Read the READMEs

We've tried to address some of the most common installation problems in the README files. If you have trouble installing, and you post an issue that's in one of the READMEs, we'll probably just close it and ask you to read the READMEs. Here's convenient links to all of the latest versions:

3. Consider Posting to the Mailing List Instead

If you've read the READMEs, and you're still having trouble, but you're not sure what's wrong, consider posting to the mailing list instead. You're likely to get an answer more quickly, and it saves the ticket queue from a bunch of back-and-forth that happens when troubleshooting someone's environment.

When You're Sure

If you're sure you've found a problem with pg, then let's get it fixed! Here are some ways to help us help you:

1. Don't Post Anonymously

If you're serious about getting your bug fixed, please don't post anonymously. Very often, we'll need some additional information to track down the problem, and if you post anonymously, experience has shown that it's highly unlikely that you'll check back to answer follow-up questions. If the issue isn't immediately diagnosable without any additional information, expect that we'll just close it as "Invalid". If you're not willing to spend the time to have a conversation with us about getting your issue addressed, we'll assume that it isn't really all that important.

2. Attach Logs and Backtraces

If there's a legitimate issue with compiling the library, attach the mkmf.log file that's written to the ext/ directory of the gem during setup.

If you see a runtime issue that results in an exception being thrown, attach the backtrace if possible. If you see a segfault, try to run it under gdb to get a backtrace:

$ gdb ruby
(gdb) run -S /path/to/script scriptargs
...segfault happens...
(gdb) bt full   # <- attach the output of this

If you have access to the PostgreSQL server's logs, and it's relevant, please attach a small snippet of that. Other useful diagnostic tools that you might want to post the output of:

  1. Enable 'verbose' errors: conn.set_error_verbosity( PG::PQERRORS_VERBOSE )
  2. Enable 'trace' mode: conn.trace( $stderr )

3. Post A Minimal Test Case

If your issue is a bug in the pg library itself, it would help immensely if you can make a minimal test case to demonstrate it, or at least describe the steps to replicate it.

Here's a template to get you started:

#!/usr/bin/env ruby

require 'pg'

conn = PG.connect( :dbname => 'template1' )
$stderr.puts '---',
	PG.version_string( true ),
	"Server version: #{conn.server_version}",
	"Client version: #{PG.respond_to?( :library_version ) ? PG.library_version : 'unknown'}",

result = conn.exec( "SELECT * from pg_stat_activity" )

$stderr.puts %Q{Expected this to return: ["select * from pg_stat_activity"]}
p result.field_values( 'current_query' )

If it requires certain data in a table, please either include the necessary setup/data insertion in your testcase, or attach an SQL-format dump of the table/s in question:

pg_dump -Fp -t <tablename> <dbname>