Este blog trata sobre la comunidad de PostgreSQL, cómo funciona y cuál es la mejor manera de navegar por ella. Tenga en cuenta que esto es simplemente una descripción general... hay mucha documentación existente.
Visión general de la comunidad, cómo funciona el desarrollo
PostgreSQL es desarrollado y mantenido por una red globalmente dispersa de voluntarios altamente calificados apasionados por la computación de bases de datos relacionales denominados Grupo de Desarrollo Global de PostgreSQL. Un puñado de miembros del equipo central juntos manejan responsabilidades especiales como coordinar actividades de lanzamiento, comunicaciones internas especiales, anuncios de políticas, supervisar privilegios de compromiso y la infraestructura de alojamiento, cuestiones disciplinarias y de liderazgo, así como responsabilidad individual para áreas de contribución de mantenimiento, desarrollo y codificación especializada. . Unas cuarenta personas adicionales se consideran contribuyentes importantes que, como su nombre lo indica, han llevado a cabo actividades integrales de desarrollo o mantenimiento para características significativas de la base de código o proyectos estrechamente relacionados. Y varias docenas de personas más están haciendo activamente otras contribuciones. Aparte de los colaboradores activos, una larga lista de colaboradores anteriores son reconocidos por su trabajo en el proyecto. Son las habilidades y los altos estándares de este equipo lo que ha dado como resultado el rico y sólido conjunto de características de PostgreSQL.
Muchos de los colaboradores tienen trabajos de tiempo completo que se relacionan directamente con PostgreSQL u otro software de código abierto, y el apoyo entusiasta de sus empleadores hace factible su compromiso duradero con la comunidad de PostgreSQL.
Las personas que contribuyen se coordinan mediante herramientas de colaboración como Internet Relay Chat (irc://irc.freenode.net/PostgreSQL) y las listas de correo de la comunidad de PostgreSQL (https://www.PostgreSQL.org/community/lists). Si es nuevo en IRC o en las listas de correo, haga un esfuerzo específico para leer sobre etiqueta y protocolos (aparece un buen artículo en https://fedoramagazine.org/beginners-guide-irc/), y después de unirse, gaste algún tiempo simplemente escuchando las conversaciones en curso y buscando en los archivos preguntas similares anteriores antes de saltar con sus propios problemas.
Tenga en cuenta que el equipo no es estático:cualquiera puede convertirse en colaborador, bueno, contribuyendo... ¡pero se espera que su contribución cumpla con esos mismos altos estándares!
El equipo mantiene una página Wiki (https://wiki.postgresql.org/) que, entre una gran cantidad de información muy detallada y útil como artículos, tutoriales, fragmentos de código y más, presenta una lista TODO de errores de PostgreSQL y solicitudes de características y otras áreas donde el esfuerzo podría ser necesario. Si quieres ser parte del equipo, este es un buen lugar para navegar. Los elementos se agregan solo después de una discusión exhaustiva en la lista de correo del desarrollador.
La comunidad sigue un proceso, visualizado como los pasos en la Figura 1.
Figura 1. Esquema conceptualizado del proceso de desarrollo de PostgreSQL. Es decir, se espera que el valor de cualquier implementación de código nuevo que no sea trivial se discuta primero y se considere (por consenso) deseable. Luego se invierte en diseño:diseño de la interfaz, sintaxis, semántica y comportamientos, y consideración de problemas de compatibilidad con versiones anteriores. Desea obtener la aceptación de la comunidad de desarrolladores sobre cuál es el problema a resolver y qué logrará esta implementación. Definitivamente NO quieres salir y desarrollar algo en el vacío por tu cuenta. Literalmente, hay décadas de experiencia colectiva de muy alta calidad incorporadas en el equipo, y usted quiere, y ellos esperan, tener ideas examinadas temprano.
El código fuente de PostgreSQL se almacena y administra mediante el sistema de control de versiones Git, por lo que se puede obtener una copia local desde https://git.postgresql.org/ para comenzar la implementación. Tenga en cuenta que para una capacidad de mantenimiento duradera, los parches deben combinarse con el código circundante y seguir las convenciones de codificación establecidas (http://developer.postgresql.org/pgdocs/postgres/source.html), por lo que es una buena idea estudiar cualquier código similar. secciones para aprender y emular las convenciones. Generalmente, se utiliza el formato estándar estilo BSD. Además, asegúrese de actualizar la documentación según corresponda.
La prueba implica primero asegurarse de que las pruebas de regresión existentes tengan éxito y de que no haya advertencias del compilador, pero también agregar nuevas pruebas correspondientes para ejercitar las funciones recién implementadas.
Cuando se complete la implementación de la nueva funcionalidad en su repositorio local, use la funcionalidad de diferencia de Git para crear un parche. Los parches se envían por correo electrónico a la lista de correo de pgsql-hackers para su revisión y comentarios, pero no tiene que esperar hasta que su trabajo esté completo... una práctica inteligente sería pedir comentarios de forma incremental. La página Wiki describe las expectativas en cuanto al formato y contexto explicativo útil y cómo mostrar respeto por el tiempo del revisor de código.
Los desarrolladores principales programan periódicamente eventos de confirmación, durante los cuales todos los parches no aplicados acumulados se agregan al repositorio de código fuente por parte de los autores autorizados. Como colaborador, su código se habrá sometido a una revisión rigurosa y es probable que sus propias habilidades de desarrollador sean mejores. Para devolver el favor, se espera que dedique tiempo a revisar parches de otros.
Descargue el documento técnico hoy Administración y automatización de PostgreSQL con ClusterControlObtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar PostgreSQLDescargar el documento técnicoPrincipales sitios web para obtener información o aprender PostgreSQL
| Sitio web de la comunidad:este es el principal punto de partida para la vida con PostgreSQL | https://www.postgresql.org/ |
| Wiki:temas variados relacionados con PostgreSQL | https://wiki.postgresql.org/ |
| Canal IRC - Los desarrolladores son participantes activos aquí | irc://irc.freenode.net/PostgreSQL |
| Repositorio de código fuente | https://git.postgresql.org/ |
| cliente de interfaz gráfica de usuario pgAdmin | https://www.pgadmin.org/ |
| Biografías de miembros significativos de la comunidad | https://www.postgresql.org/community/contributors/ |
| La famosa publicación de Eric Raymond sobre preguntas inteligentes | http://www.catb.org/esr/faqs/smart-questions.html |
| Control de cambio de esquema de base de datos | http://sqitch.org/ |
| Pruebas de unidad de base de datos | http://pgtap.org/ |
Las pocas herramientas sin las que no puede vivir
Las herramientas de línea de comandos fundamentales para trabajar con una base de datos PostgreSQL son parte de la distribución normal. El caballo de batalla es la utilidad de línea de comandos psql, que proporciona una interfaz interactiva con muchas funciones para consultar, mostrar y modificar los metadatos de la base de datos, así como para ejecutar sentencias de definición de datos (DDL) y manipulación de datos (DML).
Otras utilidades destacadas incluidas incluyen pg_basebackup para establecer una línea de base para la copia de seguridad basada en replicación, pg_dump para extraer una base de datos en un archivo de script u otro archivo de almacenamiento, pg_restore para restaurar desde un archivo pg_dump y otros. Todas estas herramientas tienen excelentes páginas de manual, además de estar detalladas en la documentación estándar y numerosos tutoriales en línea.
pgAdmin es una herramienta de interfaz gráfica de usuario muy popular que proporciona una funcionalidad similar a la utilidad de línea de comandos psql, pero con la comodidad de apuntar y hacer clic. La Figura 2 muestra una captura de pantalla de pgAdmin III. A la izquierda hay un panel que muestra todos los objetos de la base de datos en el clúster en el servidor host adjunto. Puede profundizar en la estructura para enumerar todas las bases de datos, esquemas, tablas, vistas, funciones, etc. e incluso abrir tablas y vistas para examinar los datos contenidos. Para cada objeto, la herramienta creará el SQL DML para soltar y volver a crear el objeto también, como se muestra en el panel inferior derecho. Esta es una manera conveniente de hacer modificaciones durante el desarrollo de la base de datos.
Figura 2. La utilidad pgAdmin III. Un par de mis herramientas favoritas para los equipos de desarrollo de aplicaciones son Sqitch (http://sqitch.org/), para el control de cambios en la base de datos, y pgTAP (http://pgtap.org/). Sqitch permite la gestión de cambios independiente y el desarrollo iterativo por medio de scripts escritos en el dialecto SQL nativo de su implementación, no solo de PostgreSQL. Para cada cambio en el diseño de la base de datos, escriba tres secuencias de comandos:una para implementar el cambio, otra para deshacer el cambio en caso de que sea necesario volver a una versión anterior y otra para verificar o probar el cambio. Los scripts y los archivos relacionados se pueden mantener en su sistema de control de revisiones junto con el código de su aplicación. PgTAP es un marco de prueba que incluye un conjunto de funciones para verificar la integridad de la base de datos. Todos los scripts de pgTAP son archivos de texto sin formato que cumplen con los procesos normales de gestión de revisiones y control de cambios. Una vez que comencé a usar estas dos herramientas, me resultó difícil imaginar volver a trabajar sin ellas en una base de datos.
Consejos y trucos
La lista de correo general de PostgreSQL es la más activa de las diversas listas de la comunidad y es la principal interfaz de la comunidad para brindar soporte gratuito a los usuarios. En esta lista aparece una gama bastante amplia de preguntas, que a veces generan largas idas y venidas, pero la mayoría de las veces obtienen respuestas rápidas, informativas y directas.
Al publicar una pregunta relacionada con el uso de PostgreSQL, por lo general desea incluir siempre información general, incluida la versión de PostgreSQL que está utilizando (enumerada por la herramienta de línea de comandos psql con "psql --version"), el sistema operativo en el que se encuentra el servidor. en ejecución, y luego tal vez una descripción del entorno operativo, por ejemplo, si puede ser predominantemente de lectura o escritura, número típico de usuarios y problemas de simultaneidad, cambios que ha realizado desde la configuración predeterminada del servidor (es decir, pg_hba.conf y postgresql.conf), etc. A menudo, una descripción de lo que está tratando de lograr es valiosa, en lugar de una analogía obtusa, ya que es posible que obtenga sugerencias de mejora que ni siquiera había pensado por su cuenta. Además, obtendrá la mejor respuesta si incluye datos reales de DDL, DML y de muestra que ilustren el problema y faciliten a otros recrear lo que está viendo. Sí, la gente realmente ejecutará su código de muestra y trabajará con usted.
Además, si está preguntando sobre cómo mejorar el rendimiento de las consultas, querrá proporcionar el plan de consulta, es decir, la salida EXPLAIN. Esto se genera al ejecutar su consulta sin cambios, excepto por el prefijo literal con la palabra "EXPLICAR", como se muestra en la Figura 3 en la herramienta pgAdmin o la utilidad de línea de comandos psql.
Figura 3. Producción de un plan de consulta con EXPLAIN. En EXPLICAR, en lugar de ejecutar realmente la consulta, el servidor devuelve el plan de consulta, que enumera los resultados detallados de cómo se ejecutará la consulta, incluidos los índices que se utilizarán para optimizar el acceso a los datos, dónde podrían ocurrir los escaneos de tablas y las estimaciones de la costo y cantidad de datos involucrados en cada paso. El tipo de ayuda que obtendrá de los profesionales experimentados que supervisan la lista de correo puede identificar problemas y ayudar a sugerir posibles nuevos índices o cambios en los criterios de filtrado o unión.
Por último, cuando participe en discusiones de listas de correo, hay dos cosas importantes que debe tener en cuenta.
Primero, el servidor de la lista de correo está configurado para enviar mensajes configurados de modo que cuando responda, su software de correo electrónico responderá de forma predeterminada solo al autor del mensaje original. Para asegurarse de que su mensaje vaya a la lista, debe usar la función "responder a todos" de su software de correo, que luego incluirá tanto el autor del mensaje como la dirección de la lista.
En segundo lugar, la convención en las listas de correo de PostgreSQL es responder en línea y NOT TOP POST. Este último punto es una convención de larga data en esta comunidad, y para muchos recién llegados parece lo suficientemente inusual como para que las amables advertencias sean muy comunes. Las opiniones varían en cuanto a la cantidad del mensaje original que se debe conservar como contexto en su respuesta. Algunas personas se irritan por el crecimiento a veces difícil de manejar en el tamaño del mensaje cuando todo el mensaje original se retiene en muchas discusiones de ida y vuelta. A mí personalmente, me gusta eliminar cualquier cosa que no sea relevante a lo que estoy respondiendo específicamente para mantener el mensaje conciso y enfocado. Solo tenga en cuenta que hay décadas de historial de listas de correo retenidas en línea para documentación histórica e investigaciones futuras, por lo que se considera muy importante conservar el contexto y el flujo.
Este artículo te ayuda a comenzar, ¡ahora ve y sumérgete!
