On Wed, 2006-08-16 at 17:09 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Wise one: what should my pg_proc look like?
>
> > DATA(insert OID = 2850 ( pg_xlogfile_name_offsetPGNSP PGUID 12 f f t f
> > i 1 2249 "25" "25 25 23" "i o o" _null_ pg_xlogfile_name_offset -
> > _n
Simon Riggs <[EMAIL PROTECTED]> writes:
> Wise one: what should my pg_proc look like?
> 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_ ));
Oh, as far as that goes, the array columns need to
On Wed, 2006-08-16 at 16:51 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > but my initdb fails with
>
> > creating template1 database in a/base/1 ... FATAL: cache lookup failed
> > for type 26
>
> Um ... when did you last "cvs update"? That was the behavior up till I
> fix
Simon Riggs <[EMAIL PROTECTED]> writes:
> but my initdb fails with
> creating template1 database in a/base/1 ... FATAL: cache lookup failed
> for type 26
Um ... when did you last "cvs update"? That was the behavior up till I
fixed array_in for bootstrap mode, yesterday afternoon ...
On Wed, 2006-08-16 at 11:45 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > We want a single row output, with two columns, yes?
> > Presumably:
> > xlogfilenameTEXT
> > offset INTEGER
>
> Sounds right to me. int4 should be wide enough for practical xlog
>
On Wed, 2006-08-16 at 08:51 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2006-08-15 at 18:42 -0400, Tom Lane wrote:
> >> So let's fix pg_xlogfile_name_offset() to have two OUT parameters
> >> instead of returning a smushed-together string.
>
> > I'll do this, but I'
Simon Riggs <[EMAIL PROTECTED]> writes:
> We want a single row output, with two columns, yes?
> Presumably:
> xlogfilenameTEXT
> offset INTEGER
Sounds right to me. int4 should be wide enough for practical xlog
segment sizes.
regards, tom lane
---
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2006-08-15 at 18:42 -0400, Tom Lane wrote:
>> So let's fix pg_xlogfile_name_offset() to have two OUT parameters
>> instead of returning a smushed-together string.
> I'll do this, but I'm conscious that this is a cosmetic change.
Well, it's cosmeti
On Tue, 2006-08-15 at 18:42 -0400, Tom Lane wrote:
> I wrote:
> > It'd definitely be nicer that way, but given the current limitations of
> > bootstrap mode I see no non-kluge way to make a built-in function have
> > OUT parameters. (Hint: array_in doesn't work in bootstrap mode.)
>
> Actually, t
I wrote:
> It'd definitely be nicer that way, but given the current limitations of
> bootstrap mode I see no non-kluge way to make a built-in function have
> OUT parameters. (Hint: array_in doesn't work in bootstrap mode.)
Actually, that turns out not to be so hard to fix as I thought.
array_in o
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> True, but making people parse the output of a function to seperate the
> two fields seems pretty silly. Is there some reason why
> pg_xlogfile_name_offset shouldn't be a SRF, or use two out parameters?
It'd definitely be nicer that way, but given the cu
On Tue, Aug 15, 2006 at 07:11:24PM +0100, Simon Riggs wrote:
> On Tue, 2006-08-15 at 12:13 -0500, Jim C. Nasby wrote:
> > On Tue, Aug 15, 2006 at 06:07:12PM +0100, Simon Riggs wrote:
> > > On Tue, 2006-08-15 at 11:10 -0400, Alvaro Herrera wrote:
> > > > Simon Riggs wrote:
> > > >
> > > >
> > > >
On Tue, 2006-08-15 at 12:13 -0500, Jim C. Nasby wrote:
> On Tue, Aug 15, 2006 at 06:07:12PM +0100, Simon Riggs wrote:
> > On Tue, 2006-08-15 at 11:10 -0400, Alvaro Herrera wrote:
> > > Simon Riggs wrote:
> > >
> > >
> > >
> > > > postgres=# select pg_xlogfile_name_offset(pg_switch_xlog());
> > >
On Tue, Aug 15, 2006 at 06:07:12PM +0100, Simon Riggs wrote:
> On Tue, 2006-08-15 at 11:10 -0400, Alvaro Herrera wrote:
> > Simon Riggs wrote:
> >
> >
> >
> > > postgres=# select pg_xlogfile_name_offset(pg_switch_xlog());
> > > pg_xlogfile_name_offset
> > >
On Tue, 2006-08-15 at 11:10 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
>
>
> > postgres=# select pg_xlogfile_name_offset(pg_switch_xlog());
> > pg_xlogfile_name_offset
> > ---
> > 00010001 16777216
> > (1 row)
>
> > I've not taken
Simon Riggs wrote:
> postgres=# select pg_xlogfile_name_offset(pg_switch_xlog());
> pg_xlogfile_name_offset
> ---
> 00010001 16777216
> (1 row)
> I've not taken up Jim Nasby's suggestion to make this an SRF with
> multiple return rows/colum
On Fri, 2006-08-11 at 08:04 +0100, Simon Riggs wrote:
> On Thu, 2006-08-10 at 08:57 -0400, Tom Lane wrote:
>
> > Anyway, after further thought I've concluded that we really should
> > supply something that returns the Insert pointer, as this would be
> > useful for debugging and system-monitoring
On Sun, 2006-08-13 at 22:50 -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > This issue is closed, right?
>
> We've agreed we need two functions, but it's not done yet. Seems pretty
> trivial though ...
Just back from India. I'll work on this tonight.
--
Simon Riggs
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > This issue is closed, right?
>
> We've agreed we need two functions, but it's not done yet. Seems pretty
> trivial though ...
OK, that's what I was unclear about.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www
Bruce Momjian <[EMAIL PROTECTED]> writes:
> This issue is closed, right?
We've agreed we need two functions, but it's not done yet. Seems pretty
trivial though ...
regards, tom lane
---(end of broadcast)---
TIP 1: if postin
This issue is closed, right?
---
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Something Hannu wrote has just reminded me that
> > pg_current_xlog_location() returns the current Insert pointer rather
> > than
Ühel kenal päeval, L, 2006-08-12 kell 10:59, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Ühel kenal päeval, K, 2006-08-09 kell 10:57, kirjutas Tom Lane:
> >> Insert points to the next byte to be written within the internal WAL
> >> buffers. The byte(s) preceding it haven't n
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ãhel kenal päeval, K, 2006-08-09 kell 10:57, kirjutas Tom Lane:
>> Insert points to the next byte to be written within the internal WAL
>> buffers. The byte(s) preceding it haven't necessarily gotten out of
>> those buffers yet. Write points to the en
Ühel kenal päeval, K, 2006-08-09 kell 10:57, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Ühel kenal päeval, K, 2006-08-09 kell 12:56, kirjutas Simon Riggs:
> >> Methinks it should be the Write pointer all of the time, since I can't
> >> think of a valid reason for wanting to
On Aug 10, 2006, at 7:57 AM, Tom Lane wrote:
Anyway, after further thought I've concluded that we really should
supply something that returns the Insert pointer, as this would be
useful for debugging and system-monitoring purposes. It's clear
however
that we also need something that returns t
On Thu, 2006-08-10 at 08:57 -0400, Tom Lane wrote:
> Anyway, after further thought I've concluded that we really should
> supply something that returns the Insert pointer, as this would be
> useful for debugging and system-monitoring purposes. It's clear however
> that we also need something that
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Wed, 2006-08-09 at 10:04 -0400, Tom Lane wrote:
>> Another option is to have pg_current_xlog_location force a write (but
>> not fsync) as far as the Insert pointer it's about to return. This
>> would eliminate any issues about inconsistency between resu
On Wed, 2006-08-09 at 10:04 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Something Hannu wrote has just reminded me that
> > pg_current_xlog_location() returns the current Insert pointer rather
> > than the current Write pointer.
> > That would not be useful for streaming xl
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ãhel kenal päeval, K, 2006-08-09 kell 12:56, kirjutas Simon Riggs:
>> Methinks it should be the Write pointer all of the time, since I can't
>> think of a valid reason for wanting to know where the Insert pointer is
>> *before* we've written to the xlog
Simon Riggs <[EMAIL PROTECTED]> writes:
> Something Hannu wrote has just reminded me that
> pg_current_xlog_location() returns the current Insert pointer rather
> than the current Write pointer.
> That would not be useful for streaming xlog records would it?
Good point.
> Methinks it should be th
Ühel kenal päeval, K, 2006-08-09 kell 12:56, kirjutas Simon Riggs:
> On Sat, 2006-08-05 at 23:57 -0400, Tom Lane wrote:
>
> > I also made the new user-level functions a bit
> > more orthogonal, so that filenames could be extracted from the
> > existing functions like pg_stop_backup.
>
> Something
On Sat, 2006-08-05 at 23:57 -0400, Tom Lane wrote:
> I also made the new user-level functions a bit
> more orthogonal, so that filenames could be extracted from the
> existing functions like pg_stop_backup.
Something Hannu wrote has just reminded me that
pg_current_xlog_location() returns the cur
Simon Riggs <[EMAIL PROTECTED]> writes:
> Patch included to implement xlog switching, using an xlog record
> "processing instruction" and forcibly moving xlog pointers.
Applied with revisions. I didn't like the extra state you added to
track whether an xlog switch had occurred --- the more bits o
Albe Laurenz wrote:
> Tim Allen wrote:
> >>>Patch included to implement xlog switching, using an xlog record
> >>>"processing instruction" and forcibly moving xlog pointers.
> >>>
> >>>1. Happens automatically on pg_stop_backup()
> >>
> >>
> >> Oh - so it will not be possible to do an online back
Albe Laurenz wrote:
Tim Allen wrote:
Patch included to implement xlog switching, using an xlog record
"processing instruction" and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch
Tim Allen wrote:
>>>Patch included to implement xlog switching, using an xlog record
>>>"processing instruction" and forcibly moving xlog pointers.
>>>
>>>1. Happens automatically on pg_stop_backup()
>>
>>
>> Oh - so it will not be possible to do an online backup
>> _without_ forcing a WAL switch
Albe Laurenz wrote:
Simon Riggs wrote:
Patch included to implement xlog switching, using an xlog record
"processing instruction" and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL swi
Simon Riggs wrote:
> Patch included to implement xlog switching, using an xlog record
> "processing instruction" and forcibly moving xlog pointers.
>
> 1. Happens automatically on pg_stop_backup()
Oh - so it will not be possible to do an online backup
_without_ forcing a WAL switch any more?
Lau
Patch included to implement xlog switching, using an xlog record
"processing instruction" and forcibly moving xlog pointers.
1. Happens automatically on pg_stop_backup()
2. Can happen manually via pg_switch_xlog()
3. Implement range of utility functions:
pg_current_wal_offset()
39 matches
Mail list logo
