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, that
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 cosmetic, but
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
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'm conscious
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 look like
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
segment
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 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
fixed array_in
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 -
_null_ ));
Oh,
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
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/columns
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 up Jim Nasby's
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 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:
postgres=#
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 current
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
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
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 the
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 3: Have you
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]
EnterpriseDB
Ü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 know where
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 end of
Ü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 necessarily
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
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
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 xlog records
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 results, but
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
Ü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 Hannu
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 the
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 file.
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 of
On Thu, 2006-08-03 at 18:00 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Patch included to implement xlog switching, using an xlog record
processing instruction and forcibly moving xlog pointers.
Just to be clear --- does this fully supersede your draft patch of
27-July,
Simon Riggs [EMAIL PROTECTED] writes:
Patch included to implement xlog switching, using an xlog record
processing instruction and forcibly moving xlog pointers.
Just to be clear --- does this fully supersede your draft patch of
27-July, or is that still on the table too?
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?
Laurenz
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
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 any more?
Well,
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
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
39 matches
Mail list logo
