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: