Re: [HACKERS] Forcing current WAL file to be archived - Mailing list pgsql-patches

From Simon Riggs
Subject Re: [HACKERS] Forcing current WAL file to be archived
Date
Msg-id 1155761232.2649.422.camel@holly
Whole thread Raw
In response to Re: [HACKERS] Forcing current WAL file to be archived  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Forcing current WAL file to be archived
Re: [HACKERS] Forcing current WAL file to be archived
List pgsql-patches
On Wed, 2006-08-16 at 11:45 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > We want a single row output, with two columns, yes?
> > Presumably:
> >     xlogfilename    TEXT
> >     offset        INTEGER
>
> Sounds right to me.  int4 should be wide enough for practical xlog
> segment sizes.

Wise one: what should my pg_proc look like?

I'm the lucky man to break the "_null_ _null_ _null_" rule...

I've tried

DATA(insert OID = 2850 ( pg_xlogfile_name_offset    PGNSP PGUID 12 f f t f
i 1 2249 "25" "25 25 23" "i o o" _null_ pg_xlogfile_name_offset -
_null_ ));

but my initdb fails with

selecting default shared_buffers/max_fsm_pages ... 20000kB/1000000
creating configuration files ... ok
creating template1 database in a/base/1 ... FATAL:  cache lookup failed
for type 26
child process exited with exit code 1
initdb: removing data directory "a"

Thinking this might be an 0-referenced array issue, I also tried "24 24
22" in the above, but that bombs with the same error.

Currently, if I just leave it as it is, then initdb runs but then
hangs/bombs when you invokle the function (as you might expect).

As far as I can tell, the function isn't ever called correctly without
this... copied here for info.

/*
 * Compute an xlog file name and decimal byte offset given a WAL
location,
 * such as is returned by pg_stop_backup() or pg_xlog_switch().
 *
 * Note that a location exactly at a segment boundary is taken to be in
 * the previous segment.  This is usually the right thing, since the
 * expected usage is to determine which xlog file(s) are ready to
archive.
 */
Datum
pg_xlogfile_name_offset(PG_FUNCTION_ARGS)
{
    text       *location = PG_GETARG_TEXT_P(0);
    char       *locationstr;
    unsigned int uxlogid;
    unsigned int uxrecoff;
    uint32        xlogid;
    uint32        xlogseg;
    uint32        xrecoff;
    XLogRecPtr    locationpoint;
    char        xlogfilename[MAXFNAMELEN];
    TupleDesc   returnTupleDesc;
    Datum       values[2];
    bool        isnull[2];
    HeapTuple   returnHeapTuple;
    Datum        result;

    /*
     * Read input and parse
     */
    locationstr = DatumGetCString(DirectFunctionCall1(textout,
                                                PointerGetDatum(location)));

    if (sscanf(locationstr, "%X/%X", &uxlogid, &uxrecoff) != 2)
        ereport(ERROR,
                (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
                 errmsg("could not parse xlog location \"%s\"",
                        locationstr)));

    locationpoint.xlogid = uxlogid;
    locationpoint.xrecoff = uxrecoff;

    /* Construct a tuple descriptor for the result rows. */
    returnTupleDesc = CreateTemplateTupleDesc(2, false);
    TupleDescInitEntry(returnTupleDesc, (AttrNumber) 1, "xlogfilename",
                       TEXTOID, -1, 0);
    TupleDescInitEntry(returnTupleDesc, (AttrNumber) 2, "offset",
                       INT4OID, -1, 0);

    returnTupleDesc = BlessTupleDesc(returnTupleDesc);

    /*
     * xlogfilename
     */
    XLByteToPrevSeg(locationpoint, xlogid, xlogseg);

    XLogFileName(xlogfilename, ThisTimeLineID, xlogid, xlogseg);

    values[0] = PointerGetDatum(xlogfilename);
    isnull[0] = false;

    /*
     * offset
     */
    xrecoff = locationpoint.xrecoff - xlogseg * XLogSegSize;

    values[1] = UInt32GetDatum(xrecoff);
    isnull[1] = false;

    /*
     * Tuple jam: Having first prepared your Datums, then squash
together
     */
    returnHeapTuple = heap_form_tuple(returnTupleDesc, values, isnull);

    result = HeapTupleGetDatum(returnHeapTuple);

    PG_RETURN_DATUM(result);
}

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com


pgsql-patches by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Forcing current WAL file to be archived
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Forcing current WAL file to be archived