On 03/07/2024 06:41, Noah Misch wrote:
On Tue, Jul 02, 2024 at 02:42:50PM +0300, Heikki Linnakangas wrote:
On 02/07/2024 02:24, Noah Misch wrote:
On Tue, Jul 02, 2024 at 12:53:05AM +0300, Heikki Linnakangas wrote:
Fortunately, fsync() on a file that's already flushed to disk is pretty
cheap.
On Tue, Jul 02, 2024 at 02:42:50PM +0300, Heikki Linnakangas wrote:
> On 02/07/2024 02:24, Noah Misch wrote:
> > On Tue, Jul 02, 2024 at 12:53:05AM +0300, Heikki Linnakangas wrote:
> log_newpage_range() loads the pages to the buffer
> cache and dirties them. That kinds of sucks actually, I wish it
On 02/07/2024 02:24, Noah Misch wrote:
On Tue, Jul 02, 2024 at 12:53:05AM +0300, Heikki Linnakangas wrote:
On 01/07/2024 23:52, Noah Misch wrote:
Commit 8af2565 wrote:
--- /dev/null
+++ b/src/backend/storage/smgr/bulk_write.c
+/*
+ * Finish bulk write operation.
+ *
+ * This WAL-logs and fl
On Tue, Jul 02, 2024 at 12:53:05AM +0300, Heikki Linnakangas wrote:
> On 01/07/2024 23:52, Noah Misch wrote:
> > Commit 8af2565 wrote:
> > > --- /dev/null
> > > +++ b/src/backend/storage/smgr/bulk_write.c
> >
> > > +/*
> > > + * Finish bulk write operation.
> > > + *
> > > + * This WAL-logs and fl
Thanks for poking at this!
On 01/07/2024 23:52, Noah Misch wrote:
Commit 8af2565 wrote:
--- /dev/null
+++ b/src/backend/storage/smgr/bulk_write.c
+/*
+ * Finish bulk write operation.
+ *
+ * This WAL-logs and flushes any remaining pending writes to disk, and fsyncs
+ * the relation if needed
On Fri, Feb 23, 2024 at 04:27:34PM +0200, Heikki Linnakangas wrote:
> Committed this. Thanks everyone!
Commit 8af2565 wrote:
> --- /dev/null
> +++ b/src/backend/storage/smgr/bulk_write.c
> +/*
> + * Finish bulk write operation.
> + *
> + * This WAL-logs and flushes any remaining pending writes to
pgsql-hackers ; Melanie Plageman
Objet : Re: Remove AIX Support (was: Re: Relation bulk write facility)
Hi,
On 2024-02-29 10:24:24 +0100, Michael Banck wrote:
> On Thu, Feb 29, 2024 at 12:57:31AM -0800, Andres Freund wrote:
> > On 2024-02-29 09:13:04 +0100, Michael Banck wrote:
> > >
> On 29 Feb 2024, at 10:24, Michael Banck wrote:
> On Thu, Feb 29, 2024 at 12:57:31AM -0800, Andres Freund wrote:
>> Then these users should have paid somebody to actually do maintenance work on
>> the AIX support,o it doesn't regularly stand in the way of implementing
>> various things.
>
> Rig
Hi,
On 2024-02-29 10:24:24 +0100, Michael Banck wrote:
> On Thu, Feb 29, 2024 at 12:57:31AM -0800, Andres Freund wrote:
> > On 2024-02-29 09:13:04 +0100, Michael Banck wrote:
> > > The commit message says there is not a lot of user demand and that might
> > > be right, but contrary to other fringe
Hi,
On Thu, Feb 29, 2024 at 12:57:31AM -0800, Andres Freund wrote:
> On 2024-02-29 09:13:04 +0100, Michael Banck wrote:
> > The commit message says there is not a lot of user demand and that might
> > be right, but contrary to other fringe OSes that got removed like HPPA
> > or Irix, I believe Pos
Hi,
On 2024-02-29 09:13:04 +0100, Michael Banck wrote:
> The commit message says there is not a lot of user demand and that might
> be right, but contrary to other fringe OSes that got removed like HPPA
> or Irix, I believe Postgres on AIX is still used in production and if
> so, probably in a mis
> On 29 Feb 2024, at 09:13, Michael Banck wrote:
> In any case, users will have a couple of years to migrate as usual if
> they upgrade to v16.
As you say, there are many years left of AIX being supported so there is plenty
of runway for planning a migration.
--
Daniel Gustafsson
ice the cliffs to either side.
While I am not against dropping AIX (and certainly won't step up to
maintain it just for fun), I don't think burying this inside some
"Relation bulk write facility" thread is helpful; I have changed the
thread title as a first step.
The commit messag
Heikki Linnakangas writes:
> On 28/02/2024 18:04, Tom Lane wrote:
>> The commit that added that test added a support function
>> "get_columns_length" which is now unused. Should we get rid of that
>> as well?
> I see you just removed it; thanks!
In the no-good-deed-goes-unpunished department: c
On 28/02/2024 18:04, Tom Lane wrote:
Heikki Linnakangas writes:
On 28/02/2024 00:30, Thomas Munro wrote:
I agree, this should be an error, and we should then remove the test.
Done.
The commit that added that test added a support function
"get_columns_length" which is now unused. Should w
Heikki Linnakangas writes:
> On 28/02/2024 00:30, Thomas Munro wrote:
>> I agree, this should be an error, and we should then remove the test.
> Done.
The commit that added that test added a support function
"get_columns_length" which is now unused. Should we get rid of that
as well?
Committed, after fixing the various little things you pointed out:
On 28/02/2024 00:30, Thomas Munro wrote:
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -3401,7 +3401,7 @@ export MANPATH
PostgreSQL can be expected to work on current
versions of thes
Hi,
On 2024-02-27 12:59:14 -0800, Andres Freund wrote:
> On 2024-02-27 15:45:45 -0500, Tom Lane wrote:
> > Heikki Linnakangas writes:
> > With AIX out of the picture, lapwing will be the only remaining
> > animal testing MAXALIGN less than 8. That seems like a single
> > point of failure ... sho
Hi,
On 2024-02-28 00:24:01 +0400, Heikki Linnakangas wrote:
> Here's a patch to fully remove AIX support.
Thomas mentioned to me that cfbot failed with this applied:
https://cirrus-ci.com/task/6348635416297472
https://api.cirrus-ci.com/v1/artifact/task/6348635416297472/log/tmp_install/log/initdb-
On Wed, Feb 28, 2024 at 12:24:01AM +0400, Heikki Linnakangas wrote:
> Here's a patch to fully remove AIX support.
> Subject: [PATCH 1/1] Remove AIX support
>
> There isn't a lot of user demand for AIX support, no one has stepped
> up to the plate to properly maintain it, so it's best to remove it
On Wed, Feb 28, 2024 at 9:24 AM Heikki Linnakangas wrote:
> Here's a patch to fully remove AIX support.
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -3401,7 +3401,7 @@ export MANPATH
PostgreSQL can be expected to work on current
versions of these operat
Hi,
On 2024-02-27 15:45:45 -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> With AIX out of the picture, lapwing will be the only remaining
> animal testing MAXALIGN less than 8. That seems like a single
> point of failure ... should we spin up another couple 32-bit
> animals? I had suppos
Heikki Linnakangas writes:
> What do y'all think of adding a check for
> ALIGNOF_DOUBLE==MAXIMUM_ALIGNOF to configure.ac and meson.build? It's
> not a requirement today, but I believe AIX was the only platform where
> that was not true. With AIX gone, that combination won't be tested, and
> we
On 26/02/2024 06:18, Michael Paquier wrote:
On Mon, Feb 26, 2024 at 09:42:03AM +0530, Robert Haas wrote:
On Mon, Feb 26, 2024 at 1:21 AM Tom Lane wrote:
So, we now need to strip the remnants of AIX support from the code and
docs? I don't see that much of it, but it's misleading to leave it
th
On Mon, Feb 26, 2024 at 09:42:03AM +0530, Robert Haas wrote:
> On Mon, Feb 26, 2024 at 1:21 AM Tom Lane wrote:
>> So, we now need to strip the remnants of AIX support from the code and
>> docs? I don't see that much of it, but it's misleading to leave it
>> there.
>>
>> (BTW, I still want to nuke
On Mon, Feb 26, 2024 at 1:21 AM Tom Lane wrote:
> So, we now need to strip the remnants of AIX support from the code and
> docs? I don't see that much of it, but it's misleading to leave it
> there.
>
> (BTW, I still want to nuke the remaining snippets of HPPA support.
> I don't think it does any
Noah Misch writes:
> On Sun, Feb 25, 2024 at 04:34:47PM +0200, Heikki Linnakangas wrote:
>> I agree with Andres though, that unless someone raises their hand and
>> volunteers to properly maintain the AIX support, we should drop it.
> There's no way forward in which AIX support stops doing net ha
On Sun, Feb 25, 2024 at 04:34:47PM +0200, Heikki Linnakangas wrote:
> I agree with Andres though, that unless someone raises their hand and
> volunteers to properly maintain the AIX support, we should drop it.
There's no way forward in which AIX support stops doing net harm. Even if AIX
enthusias
On 25/02/2024 00:37, Thomas Munro wrote:
On Sun, Feb 25, 2024 at 11:16 AM Thomas Munro wrote:
On Sun, Feb 25, 2024 at 11:06 AM Heikki Linnakangas wrote:
Regarding the issue at hand, perhaps we should define PG_IO_ALIGN_SIZE as 16 on
AIX, if that's the best the linker can do on that platform.
On Sun, Feb 25, 2024 at 11:16 AM Thomas Munro wrote:
> On Sun, Feb 25, 2024 at 11:06 AM Heikki Linnakangas wrote:
> > Regarding the issue at hand, perhaps we should define PG_IO_ALIGN_SIZE as
> > 16 on AIX, if that's the best the linker can do on that platform.
>
> You'll probably get either an
On Sun, Feb 25, 2024 at 11:06 AM Heikki Linnakangas wrote:
> Regarding the issue at hand, perhaps we should define PG_IO_ALIGN_SIZE as 16
> on AIX, if that's the best the linker can do on that platform.
You'll probably get either an error or silently fall back to buffered
I/O, if direct I/O is e
On 24 February 2024 23:29:36 EET, Andres Freund wrote:
>Hi,
>
>On 2024-02-24 11:50:24 -0800, Noah Misch wrote:
>> > We see this happen with both xlc and gcc (new enough to know how to do
>> > this). One idea would be that the AIX *linker* is unable to align it,
>> > as that is the common tool-cha
Hi,
On 2024-02-24 11:50:24 -0800, Noah Misch wrote:
> > We see this happen with both xlc and gcc (new enough to know how to do
> > this). One idea would be that the AIX *linker* is unable to align it,
> > as that is the common tool-chain component here (and unlike stack and
> > heap objects, this
On Sun, Feb 25, 2024 at 09:13:47AM +1300, Thomas Munro wrote:
> On Sun, Feb 25, 2024 at 9:12 AM Thomas Munro wrote:
> > On Sun, Feb 25, 2024 at 8:50 AM Noah Misch wrote:
> > > On GNU/Linux x64, gcc correctly records alignment=2**12 for the associated
> > > section (.rodata for bulk_write.o zero_b
On Sun, Feb 25, 2024 at 9:12 AM Thomas Munro wrote:
> On Sun, Feb 25, 2024 at 8:50 AM Noah Misch wrote:
> > On GNU/Linux x64, gcc correctly records alignment=2**12 for the associated
> > section (.rodata for bulk_write.o zero_buffer, .bss for pg_prewarm.o
> > blockbuffer). If I'm reading this ri
On Sun, Feb 25, 2024 at 8:50 AM Noah Misch wrote:
> On GNU/Linux x64, gcc correctly records alignment=2**12 for the associated
> section (.rodata for bulk_write.o zero_buffer, .bss for pg_prewarm.o
> blockbuffer). If I'm reading this right, neither AIX gcc nor xlc is marking
> the section with su
On Sun, Feb 25, 2024 at 07:52:16AM +1300, Thomas Munro wrote:
> On Sun, Feb 25, 2024 at 6:24 AM Noah Misch wrote:
> > On Fri, Feb 23, 2024 at 04:27:34PM +0200, Heikki Linnakangas wrote:
> > > Committed this. Thanks everyone!
> >
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill&
On Sun, Feb 25, 2024 at 6:24 AM Noah Misch wrote:
> On Fri, Feb 23, 2024 at 04:27:34PM +0200, Heikki Linnakangas wrote:
> > Committed this. Thanks everyone!
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill&dt=2024-02-24%2015%3A13%3A14
> got:
> TRAP: failed Assert("(uintptr_t)
On Fri, Feb 23, 2024 at 04:27:34PM +0200, Heikki Linnakangas wrote:
> Committed this. Thanks everyone!
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill&dt=2024-02-24%2015%3A13%3A14
got:
TRAP: failed Assert("(uintptr_t) buffer == TYPEALIGN(PG_IO_ALIGN_SIZE,
buffer)"), File: "md.c"
Heikki Linnakangas writes:
> Thanks, the error message was clear enough:
>> bulk_write.c:78:3: error: redefinition of typedef 'BulkWriteState' is a C11
>> feature [-Werror,-Wtypedef-redefinition]
>> } BulkWriteState;
> Fixed now, but I'm a bit surprised other buildfarm members nor cirrus CI
> c
On 23/02/2024 17:15, Tom Lane wrote:
Heikki Linnakangas writes:
Buildfarm animals 'sifaka' and 'longfin' are not happy, I will investigate..
Those are mine, let me know if you need local investigation.
Thanks, the error message was clear enough:
bulk_write.c:78:3: error: redefinition of t
Heikki Linnakangas writes:
> Buildfarm animals 'sifaka' and 'longfin' are not happy, I will investigate..
Those are mine, let me know if you need local investigation.
regards, tom lane
On 23/02/2024 16:27, Heikki Linnakangas wrote:
Committed this. Thanks everyone!
Buildfarm animals 'sifaka' and 'longfin' are not happy, I will investigate..
--
Heikki Linnakangas
Neon (https://neon.tech)
Committed this. Thanks everyone!
--
Heikki Linnakangas
Neon (https://neon.tech)
On 10/01/2024 18:17, Robert Haas wrote:
I think we should try to pick prefixes that are one or more words
rather than using word fragments. bulkw is an awkward prefix even for
people whose first language is English, and probably more awkward for
others.
Renamed the 'bulkw' variables to 'bulksta
2024-01 Commitfest.
Hi, This patch has a CF status of "Needs Review" [1], but it seems
there was a CFbot test failure last time it was run [2]. Please have a
look and post an updated version if necessary.
==
[1] https://commitfest.postgresql.org/46/4575/
[2] https://cirrus-ci.com/task/4990764
On Fri, Nov 24, 2023 at 10:22 PM Heikki Linnakangas wrote:
> Yeah, I'm not very happy with this interface. The model is that you get
> a buffer to write to by calling bulkw_alloc_buf(). Later, you hand it
> over to bulkw_write(), which takes ownership of it and frees it later.
> There is no other
On 09/01/2024 08:50, vignesh C wrote:
There are few compilation errors reported by CFBot at [1], patch needs
to be rebased:
Here you go.
--
Heikki Linnakangas
Neon (https://neon.tech)
From b1791303c54da762ecf3d63f1a60d5b93732af57 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Wed, 10
On Sat, 25 Nov 2023 at 06:49, Heikki Linnakangas wrote:
>
> On 19/11/2023 02:04, Andres Freund wrote:
> > On 2023-11-17 11:37:21 +0100, Heikki Linnakangas wrote:
> >> The new facility makes it easier to optimize bulk loading, as the
> >> logic for buffering, WAL-logging, and syncing the relation o
Melanie just reminded about an older thread about this same thing:
https://www.postgresql.org/message-id/CAAKRu_ZQEpk6Q1WtNLgfXBdCmdU5xN_w0boVO6faO_Ax%2Bckjig%40mail.gmail.com.
I had completely forgotten about that.
Melanie's patches in that thread implemented the same optimization of
avoiding
On 19/11/2023 02:04, Andres Freund wrote:
On 2023-11-17 11:37:21 +0100, Heikki Linnakangas wrote:
The new facility makes it easier to optimize bulk loading, as the
logic for buffering, WAL-logging, and syncing the relation only needs
to be implemented once. It's also less error-prone: We have ha
Hi,
On 2023-11-17 11:37:21 +0100, Heikki Linnakangas wrote:
> The new facility makes it easier to optimize bulk loading, as the
> logic for buffering, WAL-logging, and syncing the relation only needs
> to be implemented once. It's also less error-prone: We have had a
> number of bugs in how a rela
On 19/09/2023 17:13, Heikki Linnakangas wrote:
The attached patch centralizes that pattern to a new bulk writing
facility, and changes all those AMs to use it.
Here's a new rebased version of the patch.
This includes fixes to the pageinspect regression test. They were
explained in the commit
Several places bypass the buffer manager and use direct smgrextend()
calls to populate a new relation: Index AM build methods, rewriteheap.c
and RelationCopyStorage(). There's fair amount of duplicated code to
WAL-log the pages, calculate checksums, call smgrextend(), and finally
call smgrimmed
54 matches
Mail list logo
