The -isysroot options should only be added if the sysroot resolved to a
nonempty string. This matches the behavior in src/template/darwin (also
documented in installation.sgml).
From 6012fe86627db134aa48ed55f5d9086931b399e0 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 22 Mar 2023
On Tue, Mar 21, 2023 at 09:19:41PM -0500, Justin Pryzby wrote:
> You set this patch to "waiting on author" twice. Would you let me know
> what I could do to help progress the patch? Right now, I have no idea.
My mistake, I've been looking at an incorrect version of the patch.
Thanks for correcti
On Wed, Mar 22, 2023 at 4:59 AM David Rowley wrote:
> On Tue, 21 Mar 2023 at 22:41, Etsuro Fujita wrote:
> > I think that “planner/rewriter” should be parser/rewriter. Attached
> > is a patch for that.
>
> Pushed.
Thanks for picking this up, David! Thanks for looking, Tom and Richard!
Best re
On Wed, 22 Mar 2023 at 20:40, Etsuro Fujita wrote:
> Thanks for picking this up, David! Thanks for looking, Tom and Richard!
And now it just clicked with me why Tom left this. Sorry for stepping
on your toes here.
David
On Wednesday, March 22, 2023 1:16 PM Amit Kapila
wrote:
>
> On Wed, Mar 22, 2023 at 8:29 AM Masahiko Sawada
> wrote:
> >
> > On Tue, Mar 21, 2023 at 8:18 PM Amit Kapila
> wrote:
> > >
> > > On Tue, Mar 21, 2023 at 7:32 AM Euler Taveira wrote:
> > >
> > > > You should
> > > > exclude them remo
On Wed, Mar 22, 2023 2:53 PM Önder Kalacı wrote:
>
> We don't really need to, if you check the first patch, we don't have DROP for
> generated case. I mostly
> wanted to make the test a little more interesting, but it also seems to be a
> little confusing.
>
> Now attaching v2 where we do not
Hi Sergei!
Thank you for your review.
On Tue, 2023-03-21 at 23:18 +0300, Sergei Kornilov wrote:
> -- Don't want this to be available to non-superusers.
> REVOKE ALL ON FUNCTION pg_stat_statements_reset(Oid, Oid, bigint,
> boolean) FROM PUBLIC;
>
> should be added to the upgrade script
Indeed.
Hi,
On 3/22/23 7:44 AM, Drouvot, Bertrand wrote:
Hi,
On 3/22/23 5:45 AM, Michael Paquier wrote:
On Wed, Mar 22, 2023 at 11:37:03AM +0900, Kyotaro Horiguchi wrote:
In the original description, "buffer fetches" appears to be a plural
form of a compound noun and correct, similar to "buffer hits"
On Mon, 20 Mar 2023 at 19:18, Richard Guo wrote:
> It occurred to me that this hasn't been applied. Should we add it to
> the CF to not lose track of it?
I have a git branch with it. That'll work for me personally as a
reminder to come back to it during the v17 cycle.
David
On 21.03.23 18:47, Andres Freund wrote:
On 2023-03-21 18:05:15 +0100, Peter Eisentraut wrote:
On 16.03.23 17:36, Andres Freund wrote:
Maybe a daft question, but why do we need a separate type and typmod for
encrypted columns? Why isn't the fact that the column is encrypted exactly one
new field
On 04.03.23 17:35, Jeff Davis wrote:
On Thu, 2023-03-02 at 09:13 -0500, Dave Cramer wrote:
I'd like to open up this discussion again so that we can
move forward. I prefer the GUC as it is relatively simple and as
Peter mentioned it works, but I'm not married to the idea.
It's not very friendly
On 20.03.23 18:04, Jeff Davis wrote:
2. Easy to confuse psql:
CREATE TABLE a(d date, t timestamptz);
SET format_binary='25,1082,1184';
SELECT * FROM a;
d | t
---+---
! |
(1 row)
You can already send binary data to psql using DECLARE BINARY CURSOR.
It might be sensible t
On 20.03.23 18:04, Jeff Davis wrote:
Also, if we're going to make the binary format more practical to use,
can we document the expectations better? It seems the expecatation is
that the binary format just never changes, and that if it does, that's
a new type name.
I've been thinking that we nee
On 05.10.22 15:59, Tom Lane wrote:
What did you think of the compromise proposal to change only
the paths that pg_config outputs? I've not tried to code that,
but I think it should be feasible.
I don't think I understand what this proposal actually means. What
would be the behavior of pg_con
On Wed, Mar 22, 2023 at 09:20:25AM +0100, Drouvot, Bertrand wrote:
> That said, please find enclosed V2 with "buffers fetched" suggested
> above (and no changes to "buffer hits" to keep consistency with the
> other part of the documentation mentioned up-thread).
Thanks. Applied and backpatched th
On 21.03.23 10:59, Alvaro Herrera wrote:
This led me to suggesting that perhaps we need to be more lenient when
it comes to new contributors. As I said, for seasoned contributors,
it's not a problem to keep up with our requirements, however silly they
are. But people who spend their evenings a
On 21.03.23 18:46, Andres Freund wrote:
FWIW, I think we should consider getting rid of attcacheoff. I doubt it's
worth its weight these days, because deforming via slots starts at the
beginning anyway. The overhead of maintaining it is not insubstantial, and
it's just architecturally ugly to to
> On 18 Mar 2023, at 23:25, Иван Панченко wrote:
>
> Hi,
> PostgreSQL passes bytea arguments to PL/Perl functions as hexadecimal
> strings, which is not only inconvenient, but also memory and time consuming.
> So I decided to propose a simple transform extension to pass bytea as native
> Perl o
On 18.03.23 00:54, Andres Freund wrote:
I think a good compromise would be buildtype=debugoptimized, which is -O2
with debug symbols, which also sort of matches the default in the autoconf
world.
Looks like that'd result in a slightly worse build with msvc, as afaict we
wouldn't end up with /OP
On Wed, Mar 22, 2023 at 9:00 AM shiy.f...@fujitsu.com
wrote:
>
> On Wed Mar 22, 2023 7:29 AM Peter Smith wrote:
> >
> > Thanks for all the patch updates. Patch v19 LGTM.
> >
>
> +1
>
The patch looks mostly good to me. However, I have one
question/comment as follows:
-
+
b
> On 19 Mar 2023, at 23:41, Michael Paquier wrote:
>
> On Fri, Mar 17, 2023 at 12:19:56PM -0300, Ranier Vilela wrote:
>> Rebased to latest Head.
>
> I was looking at this thread, and echoing Daniel's and Alvaro's
> arguments, I don't quite see why this patch is something we need. I
> would reco
On Wed, Mar 22, 2023 at 12:50 PM Peter Smith wrote:
> Here are some review comments for patch code of HEAD_v19-0001
Thanks for your comments.
> ==
> doc/src/sgml/ref/create_publication.sgml
>
> 1.
> +
> + There can be a case where a subscription combines multiple
> +
On Wed, Mar 22, 2023 at 14:32 PM Kuroda, Hayato/黒田 隼人
wrote:
> Dear Wang,
>
> Thank you for updating patch! Following are comments form v19-0001.
Thanks for your comments.
> 01. logical-replication.sgml
>
> I found a following statement in logical-replication.sgml. I think this may
> cause
>
One last ping, hoping someone will have more time now than in january.
Perhaps my test is wrong, but I'd like to know why.
Thanks.
Le mar. 17 janv. 2023 à 16:53, Guillaume Lelarge a
écrit :
> Quick ping, just to make sure someone can get a look at this issue :)
> Thanks.
>
>
> Le ven. 6 janv.
Hi,
On Wed, 15 Mar 2023 at 11:12, Peter Eisentraut
wrote:
>
> On 14.03.23 15:07, Nazir Bilal Yavuz wrote:
> >> I think the uuid side of this is making this way too complicated. I'm
> >> content leaving this as a manual option for now.
> >>
> >> There is much more value in making the ssl option w
On Mon, 20 Mar 2023 17:05:41 +0900 (JST)
Kyotaro Horiguchi wrote:
> I found an error message added by de4d456b406bf502341ef526710d3f764b41e2c8.
>
> When I incorrectly configured the primary_conninfo with the wrong
> user, I received the following message on the server logs of both
> servers invo
> On 22 Mar 2023, at 10:39, Peter Eisentraut
> wrote:
> Personally, if a patch isn't rebased up to the minute doesn't bother me at
> all. It's easy to check out as of when the email was sent (or extra bonus
> points for using git format-patch --base). Now, rebasing every month or so
> is ni
Dear Amit, hackers,
> The patch looks mostly good to me. However, I have one
> question/comment as follows:
>
> -
> +
> binary (boolean)
>
>
> To allow references to the binary option, we add the varlistentry id
> here. It looks slightly odd to me to add id for j
> From: Amit Kapila
> Sent: Wednesday, March 22, 2023 5:16 AM
> To: Masahiko Sawada
> Cc: Euler Taveira ; Kumar, Sachin
> ; Alvaro Herrera ; pgsql-
> hack...@lists.postgresql.org; Jonathan S. Katz
> Subject: RE: [EXTERNAL]Initial Schema Sync for Logical Replication
>
> CAUTION: This email origi
Hi,
On 3/21/23 2:16 PM, Imseih (AWS), Sami wrote:
This indeed feels a bit more natural seen from here, after looking at
the code paths using an Instrumentation in the executor and explain,
for example. At least, this stresses me much less than adding 16
bytes to EState for something restricted t
On Wed, 22 Mar 2023 at 10:42, Peter Eisentraut
wrote:
>
> On 21.03.23 18:46, Andres Freund wrote:
> > FWIW, I think we should consider getting rid of attcacheoff. I doubt it's
> > worth its weight these days, because deforming via slots starts at the
> > beginning anyway. The overhead of maintaini
> On 22 Mar 2023, at 04:19, Hayato Kuroda (Fujitsu)
> wrote:
> I have also grepped to detect another wrong markups, and I think at least
> "PostgreSQL" should be changed. PSA the patch.
I agree with that analysis, this instance should be marked up with
but not the other ones. I'll go ahead wi
On Wed, Mar 22, 2023 at 4:50 PM David Rowley wrote:
> And now it just clicked with me why Tom left this. Sorry for stepping
> on your toes here.
No problem at all.
Best regards,
Etsuro Fujita
On Fri, Feb 17, 2023 at 5:45 PM Etsuro Fujita wrote:
> Here is a small patch to improve the note, which was added by commit
> 97da48246 ("Allow batch insertion during COPY into a foreign table."),
> by adding an explanation about how the actual number of rows
> postgres_fdw inserts at once is dete
> On Fri, Feb 17, 2023 at 5:45 PM Etsuro Fujita wrote:
>> Here is a small patch to improve the note, which was added by commit
>> 97da48246 ("Allow batch insertion during COPY into a foreign table."),
>> by adding an explanation about how the actual number of rows
>> postgres_fdw inserts at once i
> On 22 Mar 2023, at 12:58, Etsuro Fujita wrote:
>
> On Fri, Feb 17, 2023 at 5:45 PM Etsuro Fujita wrote:
>> Here is a small patch to improve the note, which was added by commit
>> 97da48246 ("Allow batch insertion during COPY into a foreign table."),
>> by adding an explanation about how the ac
If there's some extension that offers type "mytype", and perhaps allows
it to be installed in any schema, then it seems that the client library
would know how to parse all instances of "mytype" regardless of the
schema or search_path.
I may be overthinking this.
Dave Cramer
On Tue, 21 Mar 2023
Em qua., 22 de mar. de 2023 às 07:01, Daniel Gustafsson
escreveu:
> > On 19 Mar 2023, at 23:41, Michael Paquier wrote:
> >
> > On Fri, Mar 17, 2023 at 12:19:56PM -0300, Ranier Vilela wrote:
> >> Rebased to latest Head.
> >
> > I was looking at this thread, and echoing Daniel's and Alvaro's
> > a
If I recall the protocol-extension design correctly, such a setting
could only be set at session start, which could be annoying --- at the
very least we'd have to tolerate entries for unrecognized data types,
since clients couldn't be expected to have checked the list against
the current server in
Rebased patch after conflicts with bfc9497ece01c7c45437bc36387cb1ebe346f4d2
v14-0001-libpq-Run-pgindent-after-a9e9a9f32b3.patch
Description: Binary data
v14-0002-Refactor-libpq-to-store-addrinfo-in-a-libpq-owne.patch
Description: Binary data
v14-0003-Support-load-balancing-in-libpq.patch
Desc
> While not the fault of this patch I find it confusing that we mix
> and for marking up "postgres_fdw", the latter seemingly more correct
> (and less commonly used) than .
I think we traditionally use for an extension module (file)
name. It seems the is used when we want to refer to objects
o
Rebased after conflicts with bfc9497ece01c7c45437bc36387cb1ebe346f4d2
Also included the fix for feedback from Daniel on patch 2, which he
had shared in the load balancing thread.
On Wed, 15 Mar 2023 at 09:49, Jelte Fennema wrote:
>
> The rebase was indeed trivial (git handled everything automati
Thanks for the review!
On Tue, 2023-03-21 at 16:32 +0100, Christoph Berg wrote:
> I have some comments:
>
> > This allows EXPLAIN to generate generic plans for parameterized statements
> > (that have parameter placeholders like $1 in the statement text).
>
> > +
> > + GENERIC_PLAN
> > +
On Fri, Mar 17, 2023 at 8:31 AM Aleksander Alekseev
wrote:
> The patch needed a rebase due to a4f23f9b. PFA v12.
I have committed this after tidying up a bunch of things in the test
case file that I found too difficult to understand -- or in some cases
just incorrect, like:
elsif ($offnum =
On 2023-03-17 21:23, torikoshia wrote:
On 2023-03-07 18:09, Daniel Gustafsson wrote:
On 7 Mar 2023, at 09:35, Damir Belyalov wrote:
I felt just logging "Error: %ld" would make people wonder the meaning
of
the %ld. Logging something like ""Error: %ld data type errors were
found" might be cle
On Wed, Mar 22, 2023 at 2:16 PM Amit Kapila wrote:
>
> On Wed, Mar 22, 2023 at 8:29 AM Masahiko Sawada wrote:
> >
> > On Tue, Mar 21, 2023 at 8:18 PM Amit Kapila wrote:
> > >
> > > On Tue, Mar 21, 2023 at 7:32 AM Euler Taveira wrote:
> > >
> > > > You should
> > > > exclude them removing these
On Wed, Mar 22, 2023 at 1:12 AM Andres Freund wrote:
> Patch with the two minimal fixes attached. As we don't know whether it's worth
> changing the strategy, the more minimal fixes seem more appropriate.
LGTM.
--
Robert Haas
EDB: http://www.enterprisedb.com
On 3/22/23 2:48 AM, Michael Paquier wrote:
On Tue, Feb 14, 2023 at 06:16:18PM -0500, Jonathan S. Katz wrote:
I opted for the approach in [2]. v5 contains the branching logic for the
UTF8 only tests, and the corresponding output files. I tested locally on
macOS against both UTF8 + C locales.
I
Hi,
I noticed that the patchset didn't make much progress since February
and decided to give it another round of code review.
> [...]. But in general, end-of-transaction activities should be kept
> simple, especially between the release phases, so I feel that having to
> remember extra resources
On 22.03.23 11:16, Nazir Bilal Yavuz wrote:
Hi,
On Wed, 15 Mar 2023 at 11:12, Peter Eisentraut
wrote:
On 14.03.23 15:07, Nazir Bilal Yavuz wrote:
I think the uuid side of this is making this way too complicated. I'm
content leaving this as a manual option for now.
There is much more value
On Fri, Mar 17, 2023 at 8:51 PM Michael Paquier wrote:
>
> On Fri, Mar 17, 2023 at 04:36:58PM -0700, Peter Geoghegan wrote:
> > I'm sure that they will do that much more than they would have
> > otherwise. Since we'll have made pg_get_wal_block_info() so much more
> > useful than pg_get_wal_record
On 31.01.23 15:00, Onur Tirtir wrote:
We use Valgrind --together with the suppression file provided in
Postgres repo-- to test Citus extension against memory errors.
We replace /bin/postgres executable with a simple bash script that
executes the original postgres executable under Valgrind and
On Wed, Mar 8, 2023 at 2:47 PM Andres Freund wrote:
> Hm - it still feels wrong that we error out in case of failure, despite the
> comment to the function saying:
> * Returns NULL on error and fills the err with palloc'ed error message.
I've amended the comment so that it explains why it's done
>Среда, 22 марта 2023, 12:45 +03:00 от Daniel Gustafsson :
>
>> On 18 Mar 2023, at 23:25, Иван Панченко < w...@mail.ru > wrote:
>>
>> Hi,
>> PostgreSQL passes bytea arguments to PL/Perl functions as hexadecimal
>> strings, which is not only inconvenient, but also memory and time consuming.
On Wed, Mar 22, 2023 at 11:35 AM Melanie Plageman
wrote:
>
> On Fri, Mar 17, 2023 at 8:51 PM Michael Paquier wrote:
> >
> > On Fri, Mar 17, 2023 at 04:36:58PM -0700, Peter Geoghegan wrote:
> > > I'm sure that they will do that much more than they would have
> > > otherwise. Since we'll have made
On Sat, Mar 18, 2023 at 10:33:57AM +0100, Alvaro Herrera wrote:
> On 2023-Mar-17, Andres Freund wrote:
>
> > I started writing a test for vacuum_defer_cleanup_age while working on the
> > fix
> > referenced above, but now I am wondering if said energy would be better
> > spent
> > removing vacuu
Hi,
On 2023-03-22 11:44:20 -0500, Justin Pryzby wrote:
> On Sat, Mar 18, 2023 at 10:33:57AM +0100, Alvaro Herrera wrote:
> > On 2023-Mar-17, Andres Freund wrote:
> >
> > > I started writing a test for vacuum_defer_cleanup_age while working on
> > > the fix
> > > referenced above, but now I am wo
On 2023-03-22 09:58:58 -0400, Robert Haas wrote:
> On Wed, Mar 22, 2023 at 1:12 AM Andres Freund wrote:
> > Patch with the two minimal fixes attached. As we don't know whether it's
> > worth
> > changing the strategy, the more minimal fixes seem more appropriate.
>
> LGTM.
Thanks for checking.
Peter Eisentraut writes:
> This patch looks good to me. It's a very nice simplification of the
> initdb.c code, even without the new feature.
Thanks for looking!
> I found that the addition of
> #include
> didn't appear to be necessary. Maybe it was required before
> guc_value_requires_quot
On Tue, Mar 21, 2023 at 7:59 PM Michael Paquier wrote:
> On Mon, Mar 20, 2023 at 07:56:42AM -0400, Robert Haas wrote:
> > Anyone want to comment on this?
>
> I have not checked the patch in details, but perhaps this needs at
> least one test?
Sure. I was sort of hoping to get feedback on the over
On Mon, Mar 20, 2023 at 7:34 PM Peter Geoghegan wrote:
> On Sun, Mar 19, 2023 at 8:21 PM Kyotaro Horiguchi
> wrote:
> > It is not an issue with this patch, but as I look at this version, I'm
> > starting to feel uneasy about the subtle differences between what
> > GetWALRecordsInfo and GetWALBlo
Hi,
Tom, see below - I wonder if should provide one more piece of infrastructure
around the saved error stuff...
Have you measured whether this has negative performance effects when *NOT*
using the new option?
As-is this does not work with FORMAT BINARY - and converting the binary input
functi
On Tue, Mar 15, 2022 at 4:52 PM Daniel Gustafsson wrote:
> Yeah, that was the previously posted v25 from the author (who adopted it from
> the original author). I took the liberty to quickly poke at the review
> comments you had left as well as the ones that I had found to try and progress
> the
On Wed, 2023-03-22 at 10:21 +0100, Peter Eisentraut wrote:
> I've been thinking that we need some new kind of identifier to allow
> clients to process types in more sophisticated ways.
>
> For example, each type could be (self-)assigned a UUID, which is
> fixed
> for that type no matter in which
> > Yes. Do we have any concrete use case where the subscriber is an older
> > version, in the first place?
> >
>
> As per my understanding, it is mostly due to the reason that it can
> work today. Today, during an off-list discussion with Jonathan on this
> point, he pointed me to a similar incomp
On Wed, 2023-03-22 at 10:12 +0100, Peter Eisentraut wrote:
> Sending type names is kind of useless if what comes back with the
> result
> (RowDescription) are OIDs anyway.
>
> The client would presumably have some code like
>
> if (typeoid == 555)
> parseThatType();
>
> So it already needs
On Tue, 2023-03-21 at 10:35 +0100, Peter Eisentraut wrote:
> [PATCH v6 1/6] Support language tags in older ICU versions (53 and
> earlier).
>
> In pg_import_system_collations(), this is now redundant and can be
> simplified:
>
> - if (!pg_is_ascii(langtag) || !pg_is_ascii(iculocs
In the previous version, I didn't notice (unlike cfbot) the compiler
warning. Fixed in version 6.
-
Pavel Luzanov
From 1b8b5743df23637b70e8d4ad0df0e1f892c595f3 Mon Sep 17 00:00:00 2001
From: Pavel Luzanov
Date: Wed, 22 Mar 2023 20:54:41 +0300
Subject: [PATCH v6] psql: show membership option
On Mon, Mar 20, 2023 at 6:58 AM Drouvot, Bertrand
wrote:
>
> Hi,
>
> On 3/20/23 12:43 AM, Michael Paquier wrote:
> > At the
> > end, documenting both still sounds like the best move to me.
>
> Agree.
>
> Please find attached
> v1-0001-pg_stat_get_xact_blocks_fetched-and_hit-doc.patch doing so.
>
I wrote:
> Peter Eisentraut writes:
>> I would remove the
>> #if DEF_PGPORT != 5432
>> This was in the previous code too, but now if we remove it, then we
>> don't have any more hardcoded 5432 left, which seems like a nice
>> improvement in cleanliness.
> Hm. That'll waste a few cycles during
Jeff Davis writes:
> On Wed, 2023-03-22 at 10:21 +0100, Peter Eisentraut wrote:
>> I've been thinking that we need some new kind of identifier to allow
>> clients to process types in more sophisticated ways.
>> For example, each type could be (self-)assigned a UUID, which is fixed
>> for that ty
On Mon, Mar 20, 2023 at 10:05:21AM +0100, Drouvot, Bertrand wrote:
> Hi,
>
> On 3/20/23 8:32 AM, Michael Paquier wrote:
> >
> > /* Total time previously charged to function, as of function start
> > */
> > - instr_time save_f_total_time;
> > + instr_time save_total
Hi,
On 2023-03-20 10:32:49 -0700, Andres Freund wrote:
> On 2023-03-20 11:58:08 +0100, Peter Eisentraut wrote:
> > Oh, this patch set grew quite quickly. ;-)
>
> Yep :)
Unless somebody sees a reason to wait, I am planning to commit:
meson: add install-{quiet, world} targets
meson: add instal
On Wed, 2023-03-22 at 14:42 -0400, Tom Lane wrote:
> This isn't going to help much unless we change the wire protocol
> so that RowDescription messages carry these UUIDs instead of
> (or in addition to?) the OIDs of the column datatypes. While
> that's not completely out of the question, it's a he
Robert Haas writes:
> I have committed this after tidying up a bunch of things in the test
> case file that I found too difficult to understand -- or in some cases
> just incorrect, like:
My animal mamba doesn't like this one bit.
I suspect the reason is that it's big-endian (PPC) and the endian
> On 22 Mar 2023, at 18:54, Robert Haas wrote:
> Basically, I think 0001 is a good idea -- I'm much more nervous about
> 0002. I think we should get 0001 polished up and committed.
Correct me if I'm wrong, but I believe you commented on v27-0001 of the login
event trigger patch series? Sorry ab
Peter Eisentraut writes:
> On 05.10.22 15:59, Tom Lane wrote:
>> What did you think of the compromise proposal to change only
>> the paths that pg_config outputs? I've not tried to code that,
>> but I think it should be feasible.
> I don't think I understand what this proposal actually means. W
On Wed, 2023-03-22 at 12:16 -0400, Robert Haas wrote:
> If nobody's too unhappy with the idea, I plan to commit this soon,
> both because I think that the feature is useful, and also because I
> think it's an important security improvement.
Is there any chance I can convince you to separate the pr
Hi,
This commit unfortunately broke --wal-segsize. If I use a slightly larger than
the default setting, I get:
initdb --wal-segsize 64 somepath
running bootstrap script ... 2023-03-22 13:06:41.282 PDT [639848] FATAL:
"min_wal_size" must be at least twice "wal_segment_size"
Greetings,
Andres F
Andres Freund writes:
> This commit unfortunately broke --wal-segsize. If I use a slightly larger than
> the default setting, I get:
> initdb --wal-segsize 64 somepath
> running bootstrap script ... 2023-03-22 13:06:41.282 PDT [639848] FATAL:
> "min_wal_size" must be at least twice "wal_segment_
Hi,
On 2023-03-22 09:19:18 -0400, Robert Haas wrote:
> On Fri, Mar 17, 2023 at 8:31 AM Aleksander Alekseev
> wrote:
> > The patch needed a rebase due to a4f23f9b. PFA v12.
>
> I have committed this after tidying up a bunch of things in the test
> case file that I found too difficult to understand
On Wed, Mar 22, 2023 at 1:45 PM Andres Freund wrote:
> At the very least there's missing verification that tids actually exists in
> the
> "Update chain validation" loop, leading to:
> TRAP: failed Assert("ItemIdHasStorage(itemId)"), File:
> "../../../../home/andres/src/postgresql/src/include/st
On Tue, Mar 21, 2023, at 8:18 AM, Amit Kapila wrote:
> Now, how do we avoid these problems even if we have our own version of
> functionality similar to pg_dump for selected objects? I guess we will
> face similar problems. If so, we may need to deny schema sync in any
> such case.
There are 2 appr
Hi,
I have noticed a rather odd behaviour that is not strictly a bug, but is
unexpected.
It is when a immutable (or stable) PG function is returning results in a
record structure a select on these calls the function repeatedly for each
element in the output record.
See below for an example.
Sur
> What about using an uint64 for calls? That seems more appropriate to me (even
> if
> queryDesc->totaltime->calls will be passed (which is int64), but that's
> already
> also the case for the "rows" argument and
> queryDesc->totaltime->rows_processed)
That's fair
> I'm not sure it's worth me
On Wed, Mar 22, 2023 at 2:14 PM Peter Geoghegan wrote:
> > Currently the new verify_heapam() follows ctid chains when XMAX_INVALID is
> > set
> > and expects to find an item it can dereference - but I don't think that's
> > something we can rely on: Afaics HOT pruning can break chains, but doesn'
On Tuesday, March 21, 2023, Eske Rahn wrote:
> Hi,
>
> I have noticed a rather odd behaviour that is not strictly a bug, but is
> unexpected.
>
> It is when a immutable (or stable) PG function is returning results in a
> record structure a select on these calls the function repeatedly for each
>
Hi,
On 2023-03-22 13:45:52 -0700, Andres Freund wrote:
> On 2023-03-22 09:19:18 -0400, Robert Haas wrote:
> > On Fri, Mar 17, 2023 at 8:31 AM Aleksander Alekseev
> > wrote:
> > > The patch needed a rebase due to a4f23f9b. PFA v12.
> >
> > I have committed this after tidying up a bunch of things i
Hi,
On 2023-03-22 14:56:22 -0700, Andres Freund wrote:
> A patch addressing some, but not all, of those is attached. With that I don't
> see any crashes or false-positives anymore.
That patch missed that, as committed, the first if (ItemIdIsRedirected())
check sets lp_valid[n] = true even if the
On Wed, Mar 22, 2023 at 04:37:01PM +0900, Michael Paquier wrote:
> I have noted something.. For the WIN32 case, we have that:
>
> +++ b/src/backend/port/win32_shmem.c
> @@ -327,6 +327,8 @@ retry:
> Sleep(1000);
> continue;
> }
> +
> + huge_pages_active = ((fl
On Wed, Mar 22, 2023 at 05:18:28PM -0500, Justin Pryzby wrote:
> Wow, good point. I think to make it work we'd need put
> huge_pages_active into BackendParameters and handle it in
> save_backend_variables(). If so, that'd be strong argument for using a
> GUC, which already has all the necessary i
On Wed, Mar 22, 2023 at 02:21:12PM -0400, Melanie Plageman wrote:
> Apologies as I know this docs update has already been committed, but
> buffers fetched and blocks fetched both feel weird to me. If you have a
> cache hit, you don't end up really "fetching" anything at all (since
> pgstat_count_bu
On Wed, Mar 22, 2023 at 4:32 PM Eske Rahn wrote:
> Hi,
>
> Thanks for the quick answer *:-D*
>
> That was a nice sideeffect of lateral.
>
> In the example, the calling code also gets simplified:
>
> WITH x AS (
> SELECT clock_timestamp() rowstart, *, clock_timestamp() rowend FROM (
> SELECT
On Wed, Mar 22, 2023 at 4:46 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Wed, Mar 22, 2023 at 4:32 PM Eske Rahn wrote:
>
>> Hi,
>>
>> Thanks for the quick answer *:-D*
>>
>> That was a nice sideeffect of lateral.
>>
>> In the example, the calling code also gets simplified:
>>
>
On Wed, Mar 22, 2023 at 8:35 AM Melanie Plageman
wrote:
> After reading what you said, I was interested to see how substantial the
> I/O cost with non-compressed FPI would be.
>
> Using a patch with a parameter to pg_get_wal_block_info() to skip
> outputting FPI, I found that on a fast local nvme
On Wed, Mar 22, 2023 at 02:52:23PM -0400, Melanie Plageman wrote:
> This comment still has the t_ prefix as does the one for tuples_updated
> and deleted.
>
> otherwise, LGTM.
Good catch. pgstat_count_heap_update() has a t_tuples_hot_updated,
and pgstat_update_heap_dead_tuples() a t_delta_dead_t
On Tue, Mar 21, 2023 at 11:33 PM Michael Paquier wrote:
> > The new pg_get_wal_block_info outputs columns in an order that doesn't
> > seem like the most useful possible order to me. This gives us another
> > reason to have separate GetWALRecordInfo and GetWALBlockInfo utility
> > functions rather
On Fri, Mar 17, 2023 at 3:22 PM Peter Geoghegan wrote:
> I think that this is pretty close to being committable already.
Attached revision has some small tweaks by me. Going to commit this
revised version tomorrow morning.
Changes:
* No more dedicated struct to carry around the type of an updat
On Wed, Mar 22, 2023 at 05:05:10PM -0700, Peter Geoghegan wrote:
> I'd go further than that myself: I haven't had any use for FPIs at
> all. If I was going to do something with FPIs then I'd just use
> pg_waldump, since I'd likely want to get them onto the filesystem for
> analysis anyway. (Just my
On Wed, Mar 22, 2023 at 5:14 PM Michael Paquier wrote:
> On Wed, Mar 22, 2023 at 05:05:10PM -0700, Peter Geoghegan wrote:
> > I'd go further than that myself: I haven't had any use for FPIs at
> > all. If I was going to do something with FPIs then I'd just use
> > pg_waldump, since I'd likely want
1 - 100 of 122 matches
Mail list logo
