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,
s
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 wa
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) v1-001-aset-reduces-memory-consum
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.
--
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) b
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 the
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);
+
Hi!
We have branch with incremental commits worm where patches were generated
with format-patch -
https://github.com/postgrespro/postgres/tree/toasterapi_clean
I'll clean up commits from garbage files asap, sorry, haven't noticed them
while moving changes.
Best regards,
Nikita Malakhov
On Fri, Ju
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 simplify the review and commit work.
>
> The patchset fails to apply. Could you sen
On Fri, 8 Jul 2022 at 21:35, David Zhang wrote:
>
> Hi,
>
> I tried to apply this patch v5 to current master branch but it complains,
> "git apply --check
> v5-0001-Add-protections-in-xlog-record-APIs-against-large.patch
> error: patch failed: src/include/access/xloginsert.h:43
> error: src/includ
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 squashed
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 cl
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 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
+++ b/src/bin/pg_basebackup/pg_basebacku
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
> poc_remember_last_runni
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 j
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 before
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
(https://github.c
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 o
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
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 i
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 simpli
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
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;
>
>
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, unl
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 constrai
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
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 |
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.
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 t
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
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 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 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 doesn
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
> behavi
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 t
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 I
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 a
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 AD
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? As
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 ve
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 Rel
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 trivia
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
pl
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 particular
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, Mela
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 particul
> 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.
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 loose
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
Descripti
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.
S
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 for
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 don
> 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/
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 we'
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 ru
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 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
backbranche
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 ord
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
> proce
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 n
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 d
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 gen_node_s
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 ab
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, &st) == 0)
> +
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 buildsystems
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 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
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 ass
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);
>> canonicalize_path(f
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 supp
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?
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 particul
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 p
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
> non-enable-dep
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 th
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 sket
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
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 ju
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) nostal
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 s
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 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 ReorderBufferG
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 on
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 2
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 Ami
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() si
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
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 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 an
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 doesn't
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 Re
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
В письме от понедельник, 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 A
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 PG14.
1 - 100 of 106 matches
Mail list logo
