The file_no of the socket IO can change while connecting.
This can happen when alternative hosts are tried,
while GSS authentication
and when falling back to unencrypted in sslmode:prefer .
Therefore expire the socket IO at each connect_poll and reset_poll call.
Caching the IO previosly led to occasional errors kind of:
Errno::EBADF: Bad file descriptor
With the recreation of an IO object per connect_poll the fileno can change in the TcpGateScheduler when running on Windows.
I didn't dig deeper why this happens, but it fails in spec
"with a Fiber scheduler connects several times concurrently"
and sometimes in other specs.
administrative tasks.
These have all been fairly well battle-tested and are in production use
at $DAYJOB, though they were cleaned up for addition to the Ruby-PG
repo.
See the top comments in each script for additional information, or the
--help flag on any of them for usage.
- disk_usage_report
Quick reporting on the heaviest disk consumers for a database.
Nice for cronned/email reporting.
- pg_statistics
Continuous polled statistics for a database. Suitable for
graphing with gnuplot (example included.)
- replication_monitor
A command-line monitor for slave replication lag. Works for
both streaming replication and WAL shipping. You should be able
to use it as a base to plug into your preferred monitoring system.
- wal_shipper
A smart WAL file transfer script, similar to PITRTools.
- warehouse_partitions
An automated tablespace migrator for older, date-based
partitioned tables.
* Cleaned up the sample directory somewhat. It's still out of
date, though.
--HG--
extra : convert_revision : svn%3A992085b8-0825-40d1-94e8-bec087603414/ruby-pg/trunk%40119
into separate parts of the repository. They will be
maintained separately, and be released as separate
gems from this point forward.
One reason for this change is because we need separate
gems. If we distribute both modules as one gem, the
documentation is not properly generated due to class name
conflicts.
Another reason is to reduce confusion between the two
modules.
Also, I don't plan on making many improvements (aside
from bugfixes and portability issues) to the old
'postgres' code. I'd like to get it to a stable state,
and leave it alone. Meanwhile, the 'pg' module can be
developed on a faster timeline.
--HG--
extra : convert_revision : svn%3A992085b8-0825-40d1-94e8-bec087603414/ruby-pg/trunk%4063
Lars Kanis