On Mon, Nov 13, 2023 at 02:12:12PM -0500, Bruce Momjian wrote:
> On Mon, Nov 13, 2023 at 09:49:53AM -0800, Andres Freund wrote:
> > Hi,
> >
> > On 2023-11-13 12:14:57 -0500, Bruce Momjian wrote:
> > > +SELECT *
> > > +FROM (values ('0/16ff'), ('0/1700'), ('0/1701')) as t(lsn),
> > > +
On Mon, Nov 13, 2023 at 09:49:53AM -0800, Andres Freund wrote:
> Hi,
>
> On 2023-11-13 12:14:57 -0500, Bruce Momjian wrote:
> > +SELECT *
> > +FROM (values ('0/16ff'), ('0/1700'), ('0/1701')) as t(lsn),
> > + LATERAL pg_walfile_name_offset(lsn::pg_lsn),
> > + LATERAL
Hi,
On 2023-11-13 12:14:57 -0500, Bruce Momjian wrote:
> +SELECT *
> +FROM (values ('0/16ff'), ('0/1700'), ('0/1701')) as t(lsn),
> + LATERAL pg_walfile_name_offset(lsn::pg_lsn),
> + LATERAL pg_walfile_name(lsn::pg_lsn);
> +lsn |file_name | file_offset
On Fri, Nov 10, 2023 at 07:59:43PM -0800, Andres Freund wrote:
> Hi,
>
> On 2023-11-09 16:14:07 -0500, Bruce Momjian wrote:
> > On Thu, Nov 9, 2023 at 09:49:48PM +0100, Matthias van de Meent wrote:
> > > Either way, I think fix #1 is most correct (as was attached in
> > > offset2.diff, and
On Fri, Nov 10, 2023 at 07:59:43PM -0800, Andres Freund wrote:
> I think this needs to add tests "documenting" the changed behaviour and
> perhaps also for a few other edge cases. You could e.g. test
> SELECT * FROM pg_walfile_name_offset('0/0')
> which today returns bogus values, and which is
Hi,
On 2023-11-09 16:14:07 -0500, Bruce Momjian wrote:
> On Thu, Nov 9, 2023 at 09:49:48PM +0100, Matthias van de Meent wrote:
> > Either way, I think fix #1 is most correct (as was attached in
> > offset2.diff, and quoted verbatim here), because that has no chance of
> > having surprising
On Fri, Nov 10, 2023 at 08:25:35AM +0900, Michael Paquier wrote:
> On Thu, Nov 09, 2023 at 04:14:07PM -0500, Bruce Momjian wrote:
> > Attached is the full patch that changes pg_walfile_name_offset() and
> > pg_walfile_name(). There is no need for doc changes. We need to
> > document this as
On Thu, Nov 09, 2023 at 04:14:07PM -0500, Bruce Momjian wrote:
> Attached is the full patch that changes pg_walfile_name_offset() and
> pg_walfile_name(). There is no need for doc changes. We need to
> document this as incompatible in case users are realying on the old
> behavior for WAL
On Thu, Nov 9, 2023 at 09:49:48PM +0100, Matthias van de Meent wrote:
> > I have attached fix #1 as offset1.diff and fix #2 as offset2.diff.
>
> I believe you got the references wrong; fix #1 looks like the output
> of offset2's changes, and fix #2 looks like the result of offset1's
> changes.
On Thu, 9 Nov 2023 at 20:22, Bruce Momjian wrote:
> I know this bug report is four years old, but it is still a
> pg_walfile_name_offset() bug. Here is the bug:
>
> SELECT *
> FROM (VALUES ('0/16ff'), ('0/1700'), ('0/1701')) AS
> t(lsn),
> LATERAL
On Fri, Jul 26, 2019 at 11:30:19AM +0200, Jehan-Guillaume de Rorthais wrote:
> On Fri, 26 Jul 2019 17:21:20 +0900 (Tokyo Standard Time)
> Kyotaro Horiguchi wrote:
>
> > Hello.
> >
> > While looking [1], I noticed that pg_walfile_name_offset behaves
> > somewhat oddly at segment boundary.
> >
>
On Fri, 26 Jul 2019 17:21:20 +0900 (Tokyo Standard Time)
Kyotaro Horiguchi wrote:
> Hello.
>
> While looking [1], I noticed that pg_walfile_name_offset behaves
> somewhat oddly at segment boundary.
>
> select * from (values ('0/16ff'), ('0/1700'), ('0/1701')) as
> t(lsn), lateral
Hello.
While looking [1], I noticed that pg_walfile_name_offset behaves
somewhat oddly at segment boundary.
select * from (values ('0/16ff'), ('0/1700'), ('0/1701')) as
t(lsn), lateral pg_walfile_name_offset(lsn::pg_lsn);
lsn |file_name | file_offset
13 matches
Mail list logo
