Thomas Munro writes:
> Yeah. I wasn't too sure if that was mostly about "recent" or mostly
> about "all distributions" but it wasn't doing much. Thanks, pushed.
While we're here ...
+ Code support exists for M68K, M88K, M32R, and SuperH, but these
architectures are not known to have
On Mon, Jul 11, 2022 at 6:49 PM Tom Lane wrote:
> SuperH might be twitching a bit less feebly than these three,
> but it seems to be a legacy architecture as well. Not much
> has happened there since the early 2000's AFAICS.
It looks like there's an sh3el package for PostgreSQL on NetBSD here,
On Tue, 7 Jun 2022 at 03:09, Ranier Vilela wrote:
>
> Let's restart this, to simplify the review and commit work.
The patchset fails to apply. Could you send an updated version that
applies to the current master branch?
> Regarding the patches now, we have:
> 1)
On 7/8/22 03:07, Tom Lane wrote:
Andrey Lepikhov writes:
On 12/8/21 04:26, Tomas Vondra wrote:
I wonder if we should teach clauselist_selectivity about UNIQUE indexes,
and improve the cardinality estimates directly, not just costing for
index scans.
I tried to implement this in different
On Sat, Jul 9, 2022 at 8:11 PM vignesh C wrote:
>
Thanks, a few more comments on v30_0002*
1.
+/*
+ * Represents whether copy_data parameter is specified with off, on or force.
A comma is required after on.
2.
qsort(subrel_local_oids, list_length(subrel_states),
sizeof(Oid), oid_cmp);
+
On 2022-Jul-07, Thomas Munro wrote:
> On Thu, Jul 7, 2022 at 9:05 AM Thomas Munro wrote:
> > On Thu, Jul 7, 2022 at 9:03 AM Andres Freund wrote:
> > > On 2022-07-07 08:56:33 +1200, Thomas Munro wrote:
> > > > On Thu, Jul 7, 2022 at 8:39 AM Andres Freund wrote:
> > > > > So I think we need: 1)
Hi hackers,
> > Here is a patch updated according to all the recent feedback, except
> > for two suggestions:
>
> In v4 I forgot to list possible arguments for STORAGE in
> alter_table.sgml, similarly as it is done for other subcommands. Here
> is a corrected patch.
Here is the rebased patch.
At Mon, 11 Jul 2022 01:45:16 -0400, Tom Lane wrote in
> [ cc'ing Thomas, whose code this seems to be ]
>
> Kyotaro Horiguchi writes:
> > At Sat, 9 Jul 2022 21:53:31 -0300, Ranier Vilela
> > wrote in
> >> 528 |entry = (PendingUnlinkEntry *) lfirst(cell);
>
> > Actually, I already see
On Sun, Jul 10, 2022 at 9:31 PM Michael Paquier wrote:
> Hmm. That would mean that the more LOs a cluster has, the more bloat
> there will be in the new cluster once the upgrade is done. That could
> be quite a few gigs worth of data laying around depending on the data
> inserted in the source
On Mon, Jul 11, 2022 at 5:03 PM Amit Kapila wrote:
>
> On Sat, Jul 9, 2022 at 8:11 PM vignesh C wrote:
> >
>
> Thanks, a few more comments on v30_0002*
> 1.
> +/*
> + * Represents whether copy_data parameter is specified with off, on or force.
>
> A comma is required after on.
Modified
> 2.
>
On Tue, Jul 12, 2022 at 7:55 AM Kyotaro Horiguchi
wrote:
>
> At Mon, 11 Jul 2022 13:51:12 -0400, Robert Haas wrote
> in
> > On Fri, Jul 8, 2022 at 1:59 AM Kyotaro Horiguchi
> > wrote:
> > > The function CreateAndCopyRelationData exists since before b0a55e4329
> > > but renamed since it takes
В письме от понедельник, 11 июля 2022 г. 23:03:55 MSK пользователь Jeff Davis
написал:
> > For index access methods "amoptions" member function that preformed
> > option
> > processing, were replaced with "amreloptspecset" member function that
> > provided
> > an SpecSet for reloptions for this
On Mon, 11 Jul 2022 at 20:48, Matthias van de Meent
wrote:
> > 2) v1-002-generation-reduces-memory-consumption.patch
> > Reduces memory used by struct GenerationBlock, by minus 8 bits,
>
> That seems fairly straight-forward -- 8 bytes saved on each page isn't
> a lot, but it's something.
I think
Peter Eisentraut writes:
> On 10.07.22 00:20, Tom Lane wrote:
>> We've long avoided building I/O support for utility-statement node
>> types, mainly because it didn't seem worth the trouble to write and
>> maintain such code by hand.
k
> This is also needed to be able to store utility statements
Hi hackers,
> OK, I see your point now. And I think this is a very good point.
> Basing "Compression dictionaries" on the API provided by "pluggable
> TOASTer" can also be less hacky than what I'm currently doing with
> `typmod` argument. I'm going to switch the implementation at some
> point,
Peter Eisentraut writes:
> On 11.07.22 01:09, Tom Lane wrote:
>> Andres Freund writes:
> I was just rebasing meson ontop of this and was wondering whether the input
> filenames were in a particular order:
> First, things used by later files need to be found in earlier files. So
> that
On Sat, Jul 9, 2022 at 08:19:41PM -0700, Noah Misch wrote:
> > I think you would need to say "previous behavior" since people might be
> > upgrading from releases before PG 14. I also would change "In existing
>
> I felt "previous behavior" was mildly ambiguous. I've changed it to "the
>
On Tue, Jul 12, 2022 8:49 AM Masahiko Sawada wrote:
>
> I've attached an updated patch.
>
> While trying this idea, I noticed there is no API to get the length of
> dlist, as we discussed offlist. Alternative idea was to use List
> (T_XidList) but I'm not sure it's a great idea since deleting
On Tue, Jul 12, 2022 at 3:26 AM Andres Freund wrote:
>
> On 2022-07-07 10:50:27 +0900, Masahiko Sawada wrote:
> > Right, it's more robust. I've updated the patch accordingly.
>
> Do others have thoughts about backpatching this to 15 or not?
>
I am not against backpatching this but OTOH it
On Tue, Jul 12, 2022 at 8:43 AM vignesh C wrote:
>
> On Mon, Jul 11, 2022 at 9:11 AM Peter Smith wrote:
> >
> > Here are my review comments for the v30* patches:
> >
> >
> > v30-0001
> >
> >
> > 1.1
> >
> > I was wondering if it is better to implement a new defGetOrigin method
On Fri, 3 Jun 2022 at 16:03, John Naylor wrote:
>
> On Fri, Jun 3, 2022 at 10:14 AM David Rowley wrote:
> > 4. As I just demonstrated in [1], if anyone is caught by this and has
> > a problem, the work_mem size increase required seems very small to get
> > performance back to better than in
On 14.06.22 20:57, Tom Lane wrote:
Hence, the patch below removes trailing newlines from all of
pg_upgrade's message strings, and teaches its logging infrastructure
to print them where appropriate. As in logging.c, there's now an
Assert that no format string passed to pg_log() et al ends with
On Mon, Jul 11, 2022 at 1:57 PM Tom Lane wrote:
> More generally, I'm having second thoughts about the wisdom of
> auto-generating the NodeTag enum at all. With the current setup,
> I am absolutely petrified about the risk of silent ABI breakage
> thanks to the enum order changing. In
Hi,
On 2022-07-11 13:57:38 -0400, Tom Lane wrote:
> More generally, I'm having second thoughts about the wisdom of
> auto-generating the NodeTag enum at all. With the current setup,
> I am absolutely petrified about the risk of silent ABI breakage
> thanks to the enum order changing. In
On Mon, Jul 11, 2022 at 2:57 PM Andres Freund wrote:
> ISTM that we should redefine pg_class_tblspc_relfilenode_index to only cover
> relfilenode - afaics there's no real connection to the tablespace
> anymore. That'd a) reduce the size of the index b) guarantee uniqueness across
> tablespaces.
Hi,
On 2022-07-11 15:08:57 -0400, Robert Haas wrote:
> On Mon, Jul 11, 2022 at 2:57 PM Andres Freund wrote:
> > I don't know where we could fit a sanity check that connects to all
> > databases
> > and detects duplicates across all the pg_class instances. Perhaps
> > pg_amcheck?
>
> Unless
I wrote:
> Andres Freund writes:
>> Additionally, I think we've had to add tags to the enum in minor releases
>> before and I'm afraid this now would end up looking even more awkward?
> Peter and I already had a discussion about that upthread --- we figured
> that if there's a way to manually
Hi,
On 2022-07-07 17:58:10 +1200, Thomas Munro wrote:
> Even if we go with this approach now, I think it's plausible that we
> might want to reconsider this yet again one day, perhaps allocating
> memory with some future asynchronous infrastructure while still
> processing interrupts. It's not
On Fri, Jul 8, 2022 at 1:59 AM Kyotaro Horiguchi
wrote:
> I thought for a moment that "Relation" sounded better but that naming
> is confusing in bufmgr.c, where functions take Relation and those take
> RelFileLocator exist together. So the (second) attached introduces
> "RelFile" to represent
Em qui., 7 de jul. de 2022 às 14:01, Ranier Vilela
escreveu:
> Attached the v1 of your patch.
> I think that all is safe to switch MemSet by {0}.
>
Here the rebased patch v2, against latest head.
regards,
Ranier Vilela
v2-0001-WIP-Replace-MemSet-calls-with-struct-initialization.patch
On Mon, Jul 11, 2022 at 3:34 PM Andres Freund wrote:
> Seems pretty simple to do. Have write_relmapper_file() write to a .tmp file
> first (likely adding O_TRUNC to flags), use durable_rename() to rename it into
> place. The tempfile should probably be written out before the XLogInsert(),
> the
Andres Freund writes:
> On 2022-07-11 15:54:22 -0400, Tom Lane wrote:
>> We can't simply move the file list into gen_node_support.pl, because
>> (a) the build system has to know about the dependencies involved
> Meson has builtin support for tools like gen_node_support.pl reporting which
> files
On Mon, Jul 11, 2022 at 01:25:33PM -0700, Andres Freund wrote:
> On 2022-04-08 13:18:57 -0700, Nathan Bossart wrote:
>> @@ -1035,32 +1036,9 @@ ParseConfigDirectory(const char *includedir,
>>
>> join_path_components(filename, directory, de->d_name);
>>
On Tue, May 10, 2022 at 11:41:08PM -0400, Bruce Momjian wrote:
> On Tue, May 10, 2022 at 08:31:17PM -0500, Justin Pryzby wrote:
> > | Store server-level statistics in shared memory (Kyotaro Horiguchi, Andres
> > Freund, Melanie Plageman)
> >
> > Should this be called "cumulative" statistics?
On Fri, Jul 8, 2022 at 10:07 PM Tom Lane wrote:
> Uh ... if such caching behavior is at all competently implemented,
> it will be transparent because the cache will notice and respond to
> events that should change its outputs.
Well, that assumes that we emit appropriate invalidations in every
On Mon, Jul 11, 2022 at 12:39:23PM -0500, Justin Pryzby wrote:
> On Tue, May 10, 2022 at 11:41:08PM -0400, Bruce Momjian wrote:
> > On Tue, May 10, 2022 at 08:31:17PM -0500, Justin Pryzby wrote:
>
> > > | Store server-level statistics in shared memory (Kyotaro Horiguchi,
> > > Andres Freund,
Hi,
On 2022-07-07 13:26:29 -0400, Robert Haas wrote:
> We're trying to create a system where the relfilenumber counter is
> always ahead of all the relfilenumbers used on disk, but the coupling
> between the relfilenumber-advancement machinery and the
> make-files-on-disk machinery is pretty
> On 11 Jul 2022, at 18:31, Alvaro Herrera wrote:
> A viable option would be to backpatch the addition of
> .git-blame-ignore-revs to all live branches. Would that bother anyone?
I wouldn't mind having it backpatched.
--
Daniel Gustafsson https://vmware.com/
On Mon, Jul 11, 2022 at 12:36 PM Tom Lane wrote:
> Only if we had to update all those copies all the time. But
> I'm guessing we wouldn't need a branch's copy to be newer than
> the last pgindent run affecting that branch?
I wouldn't care very much if the file itself was empty in the
Robert Haas writes:
> On Mon, Jul 11, 2022 at 1:57 PM Tom Lane wrote:
>> More generally, I'm having second thoughts about the wisdom of
>> auto-generating the NodeTag enum at all. With the current setup,
>> I am absolutely petrified about the risk of silent ABI breakage
>> thanks to the enum
On Mon, 2022-02-14 at 00:43 +0300, Nikolay Shaplov wrote:
> For index access methods "amoptions" member function that preformed
> option
> processing, were replaced with "amreloptspecset" member function that
> provided
> an SpecSet for reloptions for this AM, so caller can trigger option
>
Andres Freund writes:
> Additionally, I think we've had to add tags to the enum in minor releases
> before and I'm afraid this now would end up looking even more awkward?
Peter and I already had a discussion about that upthread --- we figured
that if there's a way to manually assign a nodetag's
I wrote:
>> Andres Freund writes:
>>> I was just rebasing meson ontop of this and was wondering whether the input
>>> filenames were in a particular order:
Pushed a patch to make that a bit less random-looking.
> +1 for sorting alphabetically. I experimented with that and it's a
> really
> On 11 Jul 2022, at 15:07, Matthias van de Meent
> wrote:
> No objections, but this adds another item to the implicit commitfest
> app user manual, that to the best of my knowledge seems to be mostly
> implicit institutional knowledge plus bits of information spread
> around the mailing lists.
Alvaro Herrera writes:
> A viable option would be to backpatch the addition of
> .git-blame-ignore-revs to all live branches. Would that bother anyone?
Only if we had to update all those copies all the time. But
I'm guessing we wouldn't need a branch's copy to be newer than
the last pgindent
Hi,
On 2022-07-11 16:17:28 -0400, Robert Haas wrote:
> On Mon, Jul 11, 2022 at 3:54 PM Tom Lane wrote:
> > We can't simply move the file list into gen_node_support.pl, because
> > (a) the build system has to know about the dependencies involved, and
> > (b) gen_node_support.pl wouldn't know what
Andres Freund writes:
> On 2022-07-11 16:17:28 -0400, Robert Haas wrote:
>> Sorry if I'm being dense, but why do we have to duplicate the list of
>> files instead of having gen_node_support.pl just sort whatever list
>> the build system provides to it?
> Because right now there's two
On Fri, 8 Jul 2022 at 13:09, James Vanns wrote:
>
> It does seem to smell of an alignment, padding, buffer overrun, parsing kind
> of error.
It does I think you may need to bust out a debugger and see what
array_recv is actually seeing...
--
greg
Hi,
On 2022-07-11 11:53:26 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I wonder if we can't abstract this at least a bit better. If we go that
> > route
> > a bit further, then add another arch, this code will be pretty much
> > unreadable.
>
> IMO, it's pretty unreadable *now*, for lack
I wrote:
> Peter Eisentraut writes:
>> could not handle type "ScanDirection" in struct "IndexScan" field
>> "indexorderdir"
> Ah, I see. Still, we could also handle that with
> push @enum_types, qw(ScanDirection);
I tried that, and it does work. The only other input file we could
get rid of
On Sat, Jul 9, 2022 at 1:27 AM Robert Haas wrote:
> On Tue, Jul 5, 2022 at 8:04 AM Robert Haas wrote:
> > On Sun, Jul 3, 2022 at 1:17 PM Nathan Bossart
> wrote:
> > > If by "bolder" you mean "mark [NO]INHERIT as
> deprecated-and-to-be-removed
> > > and begin emitting WARNINGs when it and WITH
Thomas Munro writes:
> On Mon, Jul 11, 2022 at 6:49 PM Tom Lane wrote:
>> SuperH might be twitching a bit less feebly than these three,
>> but it seems to be a legacy architecture as well. Not much
>> has happened there since the early 2000's AFAICS.
> It looks like there's an sh3el package
I like the ignore-revs file, but I run into a problem with my setup:
because I keep checkouts of all branches as worktrees, then all branches
share the same .git/config file. So if I put the recommended stanza for
[blame] in it, then 'git blame' complains in branches older than 13,
since those
On Mon, Jul 11, 2022 at 12:30 PM Alvaro Herrera wrote:
> Anybody has any idea how to handle this better?
>
> A viable option would be to backpatch the addition of
> .git-blame-ignore-revs to all live branches. Would that bother anyone?
+1. I was thinking of suggesting the same thing myself, for
> On 11 Jul 2022, at 21:35, Tom Lane wrote:
>
> Alvaro Herrera writes:
>> A viable option would be to backpatch the addition of
>> .git-blame-ignore-revs to all live branches. Would that bother anyone?
>
> Only if we had to update all those copies all the time. But
> I'm guessing we wouldn't
On Mon, Jul 11, 2022 at 3:54 PM Tom Lane wrote:
> We can't simply move the file list into gen_node_support.pl, because
> (a) the build system has to know about the dependencies involved, and
> (b) gen_node_support.pl wouldn't know what to do in VPATH situations.
> However, we could have
Hi,
On 2022-07-11 15:54:22 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jul 11, 2022 at 1:57 PM Tom Lane wrote:
> >> More generally, I'm having second thoughts about the wisdom of
> >> auto-generating the NodeTag enum at all. With the current setup,
> >> I am absolutely petrified
Hi,
On 2022-04-08 13:18:57 -0700, Nathan Bossart wrote:
> @@ -1035,32 +1036,9 @@ ParseConfigDirectory(const char *includedir,
>
> join_path_components(filename, directory, de->d_name);
> canonicalize_path(filename);
> - if (stat(filename, ) == 0)
> +
Hi,
I'm sending this to pgsql-hackers because Vik Fearing (xocolatl), the reviewer
of https://commitfest.postgresql.org/30/2316 also has a repository with a pgsql
implementation of said functionalities: https://github.com/xocolatl/periods.
I have stumbled upon a probable issue
Robert Haas writes:
> On Mon, Jul 11, 2022 at 2:49 AM Tom Lane wrote:
>> I think it'd be pretty reasonable to disclaim support for
>> any architecture that doesn't have a representative in our
>> buildfarm, which would lead to dropping all four of these.
>> If you don't like it, step up and run
On Wed, Jul 6, 2022 at 3:01 PM Amit Kapila wrote:
>
> On Wed, Jul 6, 2022 at 7:38 AM Masahiko Sawada wrote:
> >
> > I'll post a new version patch in the next email with replying to other
> > comments.
> >
>
> Okay, thanks for working on this. Few comments/suggestions on
>
On 11.07.22 01:09, Tom Lane wrote:
Andres Freund writes:
I was just rebasing meson ontop of this and was wondering whether the input
filenames were in a particular order:
First, things used by later files need to be found in earlier files. So
that constrains the order a bit.
Second, the
Hi,
On 2022-07-11 12:07:09 -0400, Tom Lane wrote:
> I wrote:
> > Peter Eisentraut writes:
> >> could not handle type "ScanDirection" in struct "IndexScan" field
> >> "indexorderdir"
>
> > Ah, I see. Still, we could also handle that with
> > push @enum_types, qw(ScanDirection);
>
> I tried that,
On Mon, Jul 11, 2022 at 12:48 PM tushar wrote:
> One scenario where the syntax is created in pg_dumpall is wrong
>
> postgres=# create user u1;
> postgres=# create group g1 with user u1;
> postgres=# grant g1 to u1 with admin option, inherit false;
>
> Perform pg_dumpall
>
> GRANT g1 TO u1 WITH
On 10.07.22 00:20, Tom Lane wrote:
We've long avoided building I/O support for utility-statement node
types, mainly because it didn't seem worth the trouble to write and
maintain such code by hand. Now that the automatic node-support-code
generation patch is in, that argument is gone, and it's
Hi,
On 2022-07-06 15:58:44 +0700, John Naylor wrote:
> From 82e13b6bebd85a152ededcfd75495c0c0f642354 Mon Sep 17 00:00:00 2001
> From: John Naylor
> Date: Wed, 6 Jul 2022 15:50:09 +0700
> Subject: [PATCH v4 4/4] Use vectorized lookahead in json_lex_string on x86
>
> ---
> src/common/jsonapi.c |
On Sat, Jul 9, 2022 at 9:46 PM Thomas Munro wrote:
> The pwritev/preadv functions are unfortunately not standardised by
> POSIX (I dunno why, it's the obvious combination of the p* and *v
> functions) despite every OS in the list having them except for Solaris
> and old macOS. Oh well.
I don't
Hello,
thanks for the helpful review. I have incorporated most of the
suggestions into the patch. I have also rebased and tested the patch
on top of the current master (2cd2569c72b89200).
> + int64 active_time_diff = 0;
> + int64 transaction_idle_time_diff = 0;
>
On Fri, Jul 8, 2022 at 11:18 PM Bruce Momjian wrote:
> I found two places where a singular "row" would be better, doc patch
> attached.
+1.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Jul 11, 2022 at 2:49 AM Tom Lane wrote:
> While we're here ...
>
> + Code support exists for M68K, M88K, M32R, and SuperH, but these
> architectures are not known to have been tested recently.
>
> I think it'd be pretty reasonable to disclaim support for
> any architecture that
On 07.07.22 13:16, Alvaro Herrera wrote:
On 2022-Jul-07, Peter Eisentraut wrote:
diff --git a/src/bin/pg_basebackup/pg_basebackup.c
b/src/bin/pg_basebackup/pg_basebackup.c
index 4445a86aee..79b23fa7d7 100644
--- a/src/bin/pg_basebackup/pg_basebackup.c
+++
Peter Eisentraut writes:
> On 10.07.22 01:50, Tom Lane wrote:
>> As committed, gen_node_support.pl excludes CallContext and InlineCodeBlock
>> from getting unneeded support functions via some very ad-hoc code.
> Couldn't we just enable those support functions? I think they were just
> excluded
Hi Bruce,
> I was not happy with putting this in the Transaction Isolation section.
> I rewrote it and put it in the INSERT secion, right before ON CONFLICT;
> patch attached.
Looks good.
--
Best regards,
Aleksander Alekseev
Peter Eisentraut writes:
> On 11.07.22 01:09, Tom Lane wrote:
>> The rest could probably be alphabetical. I was also wondering if
>> all of them really need to be read at all --- I'm unclear on what
>> access/sdir.h is contributing, for example.
> could not handle type "ScanDirection" in struct
Hi hackers,
> I invite anyone interested to join this effort as a co-author!
Here is v5. Same as v4 but with a fixed compiler warning (thanks,
cfbot). Sorry for the noise.
--
Best regards,
Aleksander Alekseev
v5-0001-Compression-dictionaries-for-JSONB.patch
Description: Binary data
On Mon, Jul 11, 2022 at 7:39 AM Dilip Kumar wrote:
> > buf_init.c:119:4: error: implicit truncation from 'int' to bit-field
> > changes value from -1 to 255 [-Werror,-Wbitfield-constant-conversion]
> > CLEAR_BUFFERTAG(buf->tag);
> >
On 11.07.22 11:27, Aleksander Alekseev wrote:
Here is a patch updated according to all the recent feedback, except
for two suggestions:
In v4 I forgot to list possible arguments for STORAGE in
alter_table.sgml, similarly as it is done for other subcommands. Here
is a corrected patch.
Here is
On Fri, 8 Jul 2022, 23:41 Jacob Champion, wrote:
>
> On 3/31/22 07:37, Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, Mar 31, 2022 at 10:11 AM Tom Lane wrote:
... Would it be feasible or reasonable
to drop reviewers if they've not commented in the thread in X amount
of time?
On 08.07.22 20:39, Jacob Champion wrote:
I also added an optional 0002 that bubbles the error info up to the
final ereport(ERROR), using errdetail() and errhint(). I can squash it
into 0001 if you like it, or drop it if you don't. (This approach
could be adapted to the client, too.)
I
On 10.07.22 01:50, Tom Lane wrote:
As committed, gen_node_support.pl excludes CallContext and InlineCodeBlock
from getting unneeded support functions via some very ad-hoc code.
Couldn't we just enable those support functions? I think they were just
excluded because they didn't have any
Em seg., 11 de jul. de 2022 às 09:25, Ranier Vilela
escreveu:
> Hi,
> Thanks for take a look.
>
> Em seg., 11 de jul. de 2022 às 05:48, Matthias van de Meent <
> boekewurm+postg...@gmail.com> escreveu:
>
>> On Tue, 7 Jun 2022 at 03:09, Ranier Vilela wrote:
>> >
>> > Let's restart this, to
Andres Freund writes:
> I wonder if we can't abstract this at least a bit better. If we go that route
> a bit further, then add another arch, this code will be pretty much
> unreadable.
IMO, it's pretty unreadable *now*, for lack of comments about what it's
doing and why.
Hi,
On 2022-07-11 16:38:05 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-07-11 15:54:22 -0400, Tom Lane wrote:
> >> We can't simply move the file list into gen_node_support.pl, because
> >> (a) the build system has to know about the dependencies involved
>
> > Meson has builtin
On 2022-07-07 10:50:27 +0900, Masahiko Sawada wrote:
> Right, it's more robust. I've updated the patch accordingly.
Do others have thoughts about backpatching this to 15 or not?
On 2022-07-11 18:39:44 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'm not entirely sure how well either the existing or the sketch above works
> > when doing a VPATH build using tarball sources, and updating the files.
>
> Seems like an awful lot of effort to avoid having multiple copies
On Fri, Jul 8, 2022 at 8:20 PM Masahiko Sawada wrote:
>
> On Fri, Jul 8, 2022 at 5:59 PM Amit Kapila wrote:
> >
> > On Fri, Jul 8, 2022 at 12:46 PM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, Jul 8, 2022 at 3:27 PM Amit Kapila
> > > wrote:
> > > >
> > >
> > > > 1.
> > > > In
At Mon, 11 Jul 2022 13:51:12 -0400, Robert Haas wrote
in
> On Fri, Jul 8, 2022 at 1:59 AM Kyotaro Horiguchi
> wrote:
> > The function CreateAndCopyRelationData exists since before b0a55e4329
> > but renamed since it takes RelFileLocators.
>
> I'm not very sold on this. I think that the places
Andres Freund writes:
> I don't think it's worth worrying about this not working reliably for non
> --enable-depend builds, there's a lot more broken than this.
Well, *I* care about that, and I won't stand for making the
non-enable-depend case significantly more broken than it is now.
In
Andres Freund writes:
> I'm not entirely sure how well either the existing or the sketch above works
> when doing a VPATH build using tarball sources, and updating the files.
Seems like an awful lot of effort to avoid having multiple copies
of the file list. I think we should just do what I
On Tue, Jul 12, 2022 at 10:30 AM Tom Lane wrote:
> Thomas Munro writes:
> > Here's a patch to remove all of these.
>
> Looks sane by eyeball --- I didn't grep for other references, though.
Thanks, pushed.
> > I didn't originally suggest that because of some kind of (mostly
> > vicarious)
On Tue, Jul 12, 2022 at 9:48 AM Masahiko Sawada wrote:
>
> On Fri, Jul 8, 2022 at 8:20 PM Masahiko Sawada wrote:
> >
> > On Fri, Jul 8, 2022 at 5:59 PM Amit Kapila wrote:
> > >
> > > On Fri, Jul 8, 2022 at 12:46 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Fri, Jul 8, 2022 at 3:27 PM
On Tue, Jul 12, 2022 at 7:24 AM Tom Lane wrote:
> Thomas Munro writes:
> > It's funny to think that you probably could run modern PostgreSQL on
> > the Sun 3 boxes the project started on in 1986 (based on clues from
> > the papers in our history section) if you put NetBSD on them, but
> > you'd
On 2022-07-11 16:11:53 -0400, Robert Haas wrote:
> On Mon, Jul 11, 2022 at 3:34 PM Andres Freund wrote:
> > Seems pretty simple to do. Have write_relmapper_file() write to a .tmp file
> > first (likely adding O_TRUNC to flags), use durable_rename() to rename it
> > into
> > place. The tempfile
On 2022/07/08 17:13, Ian Lawrence Barwick wrote:
If we want to add such prevention, we will need similar checks for
INSERT/DELETE/UPDATE not only TRUNCATE. However, I think such fix is independent
from this and it can be proposed as another patch.
Ah OK, makes sense from that point of view.
On Fri, Jul 8, 2022 at 3:43 PM John Naylor wrote:
>
> On Fri, Jul 8, 2022 at 9:10 AM Masahiko Sawada wrote:
>
> > I guess that the tree height is affected by where garbages are, right?
> > For example, even if all garbage in the table is concentrated in
> > 0.5GB, if they exist between 2^17 and
Hi,
In the attached patch set, I've added in missing IO operations for
certain IO Paths as well as enumerating in the commit message which IO
Paths and IO Operations are not currently counted and or not possible.
There is a TODO in HandleWalWriterInterrupts() about removing
pgstat_report_wal()
Hi,
On 2022-07-11 18:09:15 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I don't think it's worth worrying about this not working reliably for non
> > --enable-depend builds, there's a lot more broken than this.
>
> Well, *I* care about that, and I won't stand for making the
>
Thomas Munro writes:
> Here's a patch to remove all of these.
Looks sane by eyeball --- I didn't grep for other references, though.
> I didn't originally suggest that because of some kind of (mostly
> vicarious) nostalgia. I wonder if we should allow ourselves a
> paragraph where we remember
I wrote:
> Peter Eisentraut writes:
>> On 10.07.22 01:50, Tom Lane wrote:
>>> As committed, gen_node_support.pl excludes CallContext and InlineCodeBlock
>>> from getting unneeded support functions via some very ad-hoc code.
>> Couldn't we just enable those support functions? I think they were
On Tue, Jul 12, 2022 at 4:46 AM Robert Haas wrote:
> I don't think that 0001 is buying us a whole lot, really. I prefer the
> style where we have PG-specific functions that behave differently on
> different platforms to the one where we call something that looks like
> a native OS function call
1 - 100 of 103 matches
Mail list logo
