Archive for the ‘Postgres’ Category

PGAN proposal

Postgres | Posted by cbbrowne
Jan 11 2010

David Wheeler has recently published a proposal for PGAN which is essentially like like a CPAN for PostgreSQL.

It combines:

  • The use of PGXS to enable building C-based extensions
  • Standardized metadata about any given module

It assumes the use of some specific technologies, which probably warrants some further discussion (because people are sure to have vigorous disagreement about some of them, not because his choices are bad, but because people are a problem!):

  • PGXS, which is a given that seems entirely apropos
  • JSON as a data format for the metadata
  • A choice of pg_regress or pgTAP regression tests.
    (Aficionados of other test frameworks may think differently!)
  • HTML documentation
    It’s worth observing that PostgreSQL contrib material has been trending towards use of DocBook.
    Other analogous structures like CPAN have developed formats such as POD that enable multi-format output, as well as the notion of transforming documentation into deployable man pages.

None of the possible differences are forcibly objectionable; they’re just different options that may be worth considering.

See also…  David Wheeler’s Blog

    More Slony work

    Slony-I | Posted by cbbrowne
    Nov 28 2009

    I have been way way too busy to do substantial Slony work in a while. Very very engaged on internal (infernal?) DB apps work.

    At long last I reached a certain degree of completion that allowed me a breather, and a little time to look at Slony 2.0 issues.

    I have been experimenting with Git lately, in several contexts, so pulled the PostgreSQL Git repo, with a view to using that as my “PostgreSQL HEAD” for testing. While the “official” PG version for our apps is 8.3, I usually do my builds/tests on either 8.4 or CVS HEAD, or, I guess, now, Git “master” ;-) .

    After checking out Git master, I found problems with both the internal app (minor thing in accessing information_Schema) and, alas, Slony :-( . A function now has 3 arguments (and, in the Klingon tradition, always wins them!), thus needing a bit of autoconf remediation. I hate autoconf… But absent some substantial Tilbrook contributions, that won’t be changing soon! :-(

    I surely hope I can run through a set of regression tests this coming week so as to get 2.0.3 released!

    Preparing for PostgreSQL Conference

    Postgres, Slony-I | Posted by cbbrowne
    Mar 25 2008

    It’s time to start walking through my presentation on Slony-I: Evolution of a Replication System to be presented at PostgreSQL Conference East 08.

    I’m looking forward to seeing PostgreSQL community members there!

    Slony-I bug fixing…

    Slony-I | Posted by cbbrowne
    Mar 06 2008

    More little items, leading gradually towards 1.2.14…

    Schema day…

    Postgres | Posted by cbbrowne
    Mar 05 2008

    One of those “clean” moments; we’re looking to redo a ‘contact database,’ and make sure it’s open to adding quite a bit of further extra functionality. I have been spending a considerable portion of the day simply writing DDL.

    Now, for one regret: it looks like something in PostgreSQL Autodoc”, and in the most regrettable place.

    Every time it tries evaluating a foreign key, it hits the following complaint:
    DBD::Pg::st execute failed: ERROR: invalid input syntax for integer: "ARRAY(0x84a5584)" has broken.

    I think I need to bug Mr. Taylor…

    Slony-I DDL problem

    Slony-I | Posted by cbbrowne
    Feb 29 2008

    Yay, I figured out the nature of the problem with the running of per-node DDL scripts on v2.0.

    It’s fairly deep; there is something about the semantics of “local” execution that’s wrong.   Gonna need to pass this upstream to Jan for more input…

    Slony-I 2.0 fixes…

    Slony-I | Posted by cbbrowne
    Feb 28 2008

    Apparently, it’s a good day to CVS COMMIT…

    I was able to get fixes in to

    • fix testpartition
      The partitioning functions were still modelled on the “old” way that Slony-I 1.2 and earlier handled triggers on functions,  where they had to get dropped/re-added each time you run DDL.  Need to use New Scheme.
    • fix multipaths
      This code exercised code paths that showed off that there were a number of references left in the code to storenode_int(int,text,boolean), where, in 2.0, we’re dropping the boolean flag that was intended to indicate that the node was to be used as a log shipping source.

    There are several tests that are not working, at present, in the 2.0 branch, notably (but possibly not “only”), that will be the targets of further work:

    • testddl
    • testlogship

    Slony-I 2.0 Testing

    Slony-I | Posted by cbbrowne
    Feb 28 2008

    The “CVS HEAD” branch of Slony-I has been open for rather a while, and has rather a lot of changes in it.  ‘Tis time, now, to validate that it is generally working, so that we can, with some confidence, let it out and allow others to start criticizing any remaining issues that would prevent a release.

    Today’s extra entertainment: I have added a bit of code to my test script that publishes to Twitter each time I run a test…

    Slony-I Cancel Subscription

    Slony-I | Posted by cbbrowne
    Feb 27 2008

    Well, I have a preliminary spec out, now, for CANCEL SUBSCRIPTION, as part of http://www.slony.info/bugzilla/show_bug.cgi?id=10

    Doubtless it will merit some discussion before leaping into implementation.

    My Next Slony-I trick…

    Slony-I | Posted by cbbrowne
    Feb 27 2008

    I’m working on a “CANCEL SUBSCRIPTION” feature that has been talked about for rather a long time.  (It’s on the bug list:  http://www.slony.info/bugzilla/show_bug.cgi?id=10).

    The notion is that if you have a subscription that keeps failing for some reason, we should have a way of dropping the subscription request without being forced to throw away the entire cluster configuration.  The special thing about CANCEL SUBSCRIPTION is that it needs to be able to come in and take action against events EARLIER in the event stream than itself.

    In analyzing the environment of data available to CANCEL SUBSCRIPTION, it looks like it’s pretty highly constrained.  There are quite a number of cases where it should fail to do anything.