On Wed, Mar 15, 2023 at 9:32 AM Masahiko Sawada
wrote:
>
> On Tue, Mar 14, 2023 at 8:27 PM John Naylor
> wrote:
> >
> > I wrote:
> >
> > > > > Since the block-level measurement is likely overestimating quite
a bit, I propose to simply reverse the order of the actions here,
effectively reporting p
On Fri, Mar 17, 2023 at 7:33 AM Peter Geoghegan wrote:
>
> > IIUC, the concern raised so far in this thread is not just on the
> > performance of JOIN queries to get both block info and record level
> > info, but on ease of using pg_walinspect functions. If
> > pg_get_wal_block_info emits the reco
Hi Amit, all
> You can first submit the fix for dropped columns with patches till
> v10. Once that is committed, then you can send the patches for
> generated columns.
>
>
Alright, attaching 2 patches for dropped columns, the names of the files
shows which
versions the patch can be applied to:
v2
On Fri, Mar 17, 2023 at 4:03 PM John Naylor
wrote:
>
> On Wed, Mar 15, 2023 at 9:32 AM Masahiko Sawada wrote:
> >
> > On Tue, Mar 14, 2023 at 8:27 PM John Naylor
> > wrote:
> > >
> > > I wrote:
> > >
> > > > > > Since the block-level measurement is likely overestimating quite a
> > > > > > bit,
On 16.03.23 19:11, Andres Freund wrote:
On 2023-03-16 13:54:29 -0400, Tom Lane wrote:
Andres Freund writes:
On 2023-03-16 12:10:27 -0400, Tom Lane wrote:
It wouldn't be entirely surprising if meson is selecting some -W
switches that the configure script doesn't ... but I don't know
where to c
Hi there,
On Fri, 10 Mar 2023 19:51:14 +0100
Jehan-Guillaume de Rorthais wrote:
> > So I guess the best thing would be to go through these threads, see what
> > the status is, restart the discussion and propose what to do. If you do
> > that, I'm happy to rebase the patches, and maybe see if I c
On Friday, March 17, 2023 3:38 PM Önder Kalacı wrote:
>
> Hi Amit, all
>
> You can first submit the fix for dropped columns with patches till
> v10. Once that is committed, then you can send the patches for
> generated columns.
>
> Alright, attaching 2 patches for dropped columns, the names of
> The documentation lists the modes disabled and random, but I wonder if it's
> worth expanding the docs to mention that "disabled" is pretty much a round
> robin load balancing scheme? It reads a bit odd to present load balancing
> without a mention of round robin balancing given how common it is
On Thu, 16 Mar 2023 at 21:55, Tomas Vondra
wrote:
>
> Hi!
>
> On 3/16/23 08:38, Masahiko Sawada wrote:
> > Hi,
> >
> > On Wed, Mar 15, 2023 at 9:52 PM Tomas Vondra
> > wrote:
> >>
> >>
> >>
> >> On 3/14/23 08:30, John Naylor wrote:
> >>> I tried a couple toy examples with various combinations of
On Fri, Mar 17, 2023 at 5:52 AM Nathan Bossart wrote:
>
> I've attached a minimally-updated patch that doesn't yet address the bigger
> topics under discussion.
>
> On Thu, Mar 16, 2023 at 03:30:37PM +0530, Amit Kapila wrote:
> > On Wed, Feb 1, 2023 at 5:35 AM Nathan Bossart
> > wrote:
> >> On S
On Wed, Mar 15, 2023 at 7:18 PM Etsuro Fujita wrote:
> This would be harmless, so I am planning to apply the patch to HEAD only.
I forgot to mention that this was added in v14. Done that way.
Best regards,
Etsuro Fujita
On 17.03.23 00:47, Nathan Bossart wrote:
Here is a rebased patch in which I've addressed the latest feedback except
for the DropRole() part that is under discussion.
committed
v5 attached is a rebase over the latest changes in xmlserialize (INDENT
output).From 24f045ccf7ac000a509910cb32c54ce4c91e2c33 Mon Sep 17 00:00:00 2001
From: Jim Jones
Date: Fri, 17 Mar 2023 10:23:48 +0100
Subject: [PATCH v5] Add CANONICAL output format to xmlserialize
This patch introduces the C
> On 15 Mar 2023, at 02:03, Andres Freund wrote:
>> Returning a hash seems like a worse option since it will complicate callsites
>> which only want to know success/failure.
>
> Yea. Perhaps it's worth having a separate function for this? ->query_rc() or
> such?
If we are returning a hash then
On Fri, Mar 17, 2023 at 11:58 AM wangw.f...@fujitsu.com
wrote:
>
> On Thu, Mar 16, 2023 at 20:25 PM Amit Kapila wrote:
> >
>
> Thanks for your comments.
>
> > + if (server_version >= 16)
> > + {
> > + appendStringInfo(&cmd, "SELECT DISTINCT N.nspname, C.relname,\n"
> > + " ( SELE
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 clearer.
Thanks. For more clearance change
Hi,
Sharing v17.
Amit Kapila , 17 Mar 2023 Cum, 03:02 tarihinde
şunu yazdı:
> I think to reduce the risk of breakage, let's change the check to
> >=v16. Also, accordingly, update the doc and commit message.
>
Done.
Peter Smith , 17 Mar 2023 Cum, 04:58 tarihinde şunu
yazdı:
> IMO the sentence
After some more testing I realized that v5 was leaking the xmlDocPtr.
Now fixed in v6.
From d04d8fdcbedbd5ed88469bd22e079467c26ab7a4 Mon Sep 17 00:00:00 2001
From: Jim Jones
Date: Fri, 17 Mar 2023 10:23:48 +0100
Subject: [PATCH v6] Add CANONICAL output format to xmlserialize
This patch introduc
Hi,
> On Wed, Mar 8, 2023 at 7:30 PM Himanshu Upadhyaya
> wrote:
> Please find the v11 patch with all these changes.
The patch needed a rebase due to a4f23f9b. PFA v12.
--
Best regards,
Aleksander Alekseev
v12-0001-Implement-HOT-chain-validation-in-verify_heapam.patch
Description: Binary da
On Wed, 15 Mar 2023 at 14:29, Gregory Stark (as CFM)
wrote:
>
> These patches that are "Needs Review" and have received no comments at
> all since before March 1st are these. If your patch is amongst this
> list I would suggest any of:
>
> 1) Move it yourself to the next CF (or withdraw it)
> 2) P
On 2023-03-17 Fr 05:48, Daniel Gustafsson wrote:
On 15 Mar 2023, at 02:03, Andres Freund wrote:
Returning a hash seems like a worse option since it will complicate callsites
which only want to know success/failure.
Yea. Perhaps it's worth having a separate function for this? ->query_rc() or
Hi,
> Again, MSDN claims to use a new API.
TWIMC the patch rotted a bit and now needs to be updated [1].
I changed its status to "Waiting on Author" [2].
[1]: http://cfbot.cputube.org/
[2]: https://commitfest.postgresql.org/42/3893/
--
Best regards,
Aleksander Alekseev
> On 17 Mar 2023, at 14:48, Andrew Dunstan wrote:
> On 2023-03-17 Fr 05:48, Daniel Gustafsson wrote:
>>> On 15 Mar 2023, at 02:03, Andres Freund
>>> wrote:
>>>
Returning a hash seems like a worse option since it will complicate
callsites
which only want to know success/failure.
Peter Eisentraut writes:
> On 16.03.23 19:11, Andres Freund wrote:
>> So I just elected to leave it at the default for meson.
> AFAICT, the default for meson is buildtype=debug, which is -O0. The -O3
> comes from meson.build setting buildtype=release.
> I think a good compromise would be build
Hi Greg,
> > These patches that are "Needs Review" and have received no comments at
> > all since before March 1st are these. If your patch is amongst this
> > list I would suggest any of:
> >
> > 1) Move it yourself to the next CF (or withdraw it)
> > 2) Post to the list with any pending question
Greg Stark writes:
>> These patches that are "Needs Review" and have received no comments at
>> all since before March 1st are these.
Just a couple of comments on ones that caught my eye:
>> * Simplify find_my_exec by using realpath(3)
The problem with this one is that Peter would like it to do
Hi
On Tuesday, March 14, 2023 1:17 PM Ajin Cherian wrote:
> I found out that the option ONLY was not parsed in the "CREATE INDEX"
> command, for eg: CREATE UNIQUE INDEX ... ON ONLY table_name ...
>
> I've fixed this in patch 0002.
FYI, cfbot reports a failure of v80 on linux [1]. Could you pleas
On Wed, Mar 15, 2023 at 02:29:26PM -0400, Gregory Stark (as CFM) wrote:
> 1) Move it yourself to the next CF (or withdraw it)
> 2) Post to the list with any pending questions asking for specific
> feedback -- it's much more likely to get feedback than just a generic
> "here's a patch plz review"...
On Fri, 17 Mar 2023 at 10:39, Tom Lane wrote:
>
> You've listed a lot of small features here that still have time to
> get some love --- it's not like we're hard up against the end of the CF.
> If they'd been in Waiting on Author state for awhile, I'd agree with
> booting them, but not when they'r
Em sex., 17 de mar. de 2023 às 10:58, Aleksander Alekseev <
aleksan...@timescale.com> escreveu:
> Hi,
>
> > Again, MSDN claims to use a new API.
>
> TWIMC the patch rotted a bit and now needs to be updated [1].
> I changed its status to "Waiting on Author" [2].
>
Rebased to latest Head.
best rega
Hi Shi Yu,
Thanks for the review, really appreciate it!
> I couldn't apply
> v2-0001-Ignore-dropped-columns-HEAD-REL_15-REL_14-REL_13.patch
> cleanly in v13 and v14. It looks the patch needs some changes in these
> versions.
>
>
> ```
> Checking patch src/backend/executor/execReplication.c...
>
--- Original Message ---
On Thursday, March 16th, 2023 at 10:20 PM, Tomas Vondra
wrote:
>
>
>
>
> On 3/16/23 18:04, gkokola...@pm.me wrote:
>
> > --- Original Message ---
> > On Tuesday, March 14th, 2023 at 4:32 PM, Tomas Vondra
> > tomas.von...@enterprisedb.com wrote
On 1/24/23 06:38, Ronan Dunklau wrote:
I've taken a look at the patch, and I'm not sure why you keep the restriction
on the Gist operator being of the RTEqualStrategyNumber strategy. I don't
think we have any other place where we expect those strategy numbers to
match. For hash it's different, a
On 2023-03-17 Fr 10:08, Daniel Gustafsson wrote:
A common perl idiom is to start private routine names with an underscore. so
I'd rename wait_connect to _wait_connect;
There are quite a few routines documented as internal in Cluster.pm which don't
start with an underscore. Should we change
On 3/17/23 09:18, Jehan-Guillaume de Rorthais wrote:
> Hi there,
>
> On Fri, 10 Mar 2023 19:51:14 +0100
> Jehan-Guillaume de Rorthais wrote:
>
>>> So I guess the best thing would be to go through these threads, see what
>>> the status is, restart the discussion and propose what to do. If you d
On 3/17/23 16:43, gkokola...@pm.me wrote:
>>
>> ...
>>
>> I agree it's cleaner the way you did it.
>>
>> I was thinking that with each compression function handling error
>> internally, the callers would not need to do that. But I haven't
>> realized there's logic to detect ENOSPC and so on, and we
Julien Rouhaud writes:
> On Thu, Mar 16, 2023 at 08:43:56AM -0400, Tom Lane wrote:
>> I think the odds of that yielding a usable dump are nil, so I don't
>> see why we should bother.
> No objection from me.
OK, pushed with the discussed changes.
regards, tom lane
On 3/17/23 06:53, John Naylor wrote:
> On Wed, Mar 15, 2023 at 7:51 PM Tomas Vondra
> mailto:tomas.von...@enterprisedb.com>>
> wrote:
>>
>>
>>
>> On 3/14/23 08:30, John Naylor wrote:
>> > I tried a couple toy examples with various combinations of use styles.
>> >
>> > Three with "automatic" read
On Wed, 2023-03-15 at 15:18 -0700, Jeff Davis wrote:
> I left out the validation patch for now, and I'm evaluating a
> different
> approach that will attempt to match to the locales retrieved with
> uloc_countAvailable()/uloc_getAvailable().
I like this approach, attached new patch series with tha
Andrew Dunstan writes:
> On 2023-03-17 Fr 10:08, Daniel Gustafsson wrote:
>>> Why is $restart_before_query a package/class level value instead of
>>> an instance value? And why can we only ever set it to 1 but not back
>>> again? Maybe we don't want to, but it looks odd.
>> It was mostly a POC to
On Tue, 2023-03-14 at 08:48 -0700, Jeff Davis wrote:
> Actually, now that I think about it, we could just search all known
> locales using either ucol_getAvailable() or uloc_getAvailable(), and
> see if there's a match. Not very clean, but it should catch most
> problems. I'll look into whether the
On Fri, Mar 17, 2023 at 10:40:06AM +0100, Peter Eisentraut wrote:
> committed
Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Mar 17, 2023 at 12:20 AM Bharath Rupireddy
wrote:
> +1 for pg_get_wal_block_info emitting per-record WAL info too along
> with block info, attached v2 patch does that. IMO, usability wins the
> race here.
I think that this direction makes a lot of sense. Under this scheme,
we still have p
Hi
and queryjumblefuncs.switch.c files.
Regards
Pavel
> On Tue, Feb 21, 2023 at 01:02:35PM +0100, David Geier wrote:
> Hi,
>
> On 1/20/23 09:34, David Geier wrote:
> > EXPLAIN ANALYZE for parallel Bitmap Heap Scans currently only reports
> > the number of heap blocks processed by the leader. It's missing the
> > per-worker stats. The attached patch ad
On Fri, Mar 10, 2023 at 3:49 PM Tom Lane wrote:
> I'm okay with adopting bash's rule, but then it should actually match
> bash --- signal N is reported as 128+N, not -N.
>
128+N is implemented.
Nonzero pclose errors of any kind will now overwrite an existing exit_code.
I didn't write a formal
On 3/17/23 18:55, Tomas Vondra wrote:
>
> ...
>
> This however made me realize the initial sync of sequences may not be
> correct. I mean, the idea of tablesync is syncing the data in REPEATABLE
> READ transaction, and then applying decoded changes. But sequences are
> not transactional in this w
The build-farm was OK for the last 18hrs after this push, except there
was one error on mamba [1] in test-decoding-check.
This patch did change the test_decoding.c file, so it seems an
unlikely coincidence, but OTOH the change was very small and I don't
see yet how it could have caused a problem h
I pushed the libpq changes. I'll leave the pipe2 and accept4 changes
on ice for now, maybe for a later cycle (unlike the committed patches,
they don't currently fix a known problem, they just avoid some
syscalls that are already fairly rare). For the libpq change, the
build farm seems happy so fa
On 2023-03-17 Fr 14:07, Dagfinn Ilmari Mannsåker wrote:
Andrew Dunstan writes:
On 2023-03-17 Fr 10:08, Daniel Gustafsson wrote:
Why is $restart_before_query a package/class level value instead of
an instance value? And why can we only ever set it to 1 but not back
again? Maybe we don't want
On Fri, Jan 27, 2023 at 3:23 PM Corey Huinker wrote:
> This patch adds the n_tup_newpage_upd to all the table stat views.
I think that this is pretty close to being committable already.
I'll move on that early next week, barring any objections.
--
Peter Geoghegan
Hi,
On 2023-03-17 12:25:14 -0400, Andrew Dunstan wrote:
> On 2023-03-17 Fr 10:08, Daniel Gustafsson wrote:
> > > If we are going to keep this as a separate package, then we should put
> > > some code in the constructor to prevent it being called from elsewhere
> > > than the Cluster package. e.g
Hi,
As evidenced by the bug fixed in be504a3e974, vacuum_defer_cleanup_age is not
heavily used - the bug was trivial to hit as soon as vacuum_defer_cleanup_age
is set to a non-toy value. It complicates thinking about visibility horizons
substantially, as vacuum_defer_cleanup_age can make them go b
On Fri, Mar 17, 2023 at 12:36:04PM -0700, Peter Geoghegan wrote:
> I think that this direction makes a lot of sense. Under this scheme,
> we still have pg_get_wal_records_info(), which is more or less an SQL
> interface to the information that pg_waldump presents by default.
> That's important when
On Fri, Mar 17, 2023 at 09:30:32AM +0900, Michael Paquier wrote:
> KRB4 was switched in a159ad3 back in 2005, and KRB5 in 98de86e back in
> 2014 (deprecated in 8.3, so that's even older than creds). So yes,
> that could be removed as well, I guess, falling back to the default
> error message.
Thi
On Sat, Mar 18, 2023 at 12:09 AM Andres Freund wrote:
> Hi,
>
> As evidenced by the bug fixed in be504a3e974, vacuum_defer_cleanup_age is
> not
> heavily used - the bug was trivial to hit as soon as
> vacuum_defer_cleanup_age
> is set to a non-toy value. It complicates thinking about visibility
>
On Thu, Mar 16, 2023 at 11:28 PM wangw.f...@fujitsu.com
wrote:
> Attach the new patch set.
Hi,
I ran into this problem while hacking on [1], so thank you for tackling
it! I have no strong opinions on the implementation itself; I just want
to register a concern that the tests have not kept up wit
On Fri, Mar 17, 2023 at 4:11 PM Michael Paquier wrote:
> FWIW, I am not sure that it is a good idea and that we'd better not
> encourage too much the use of block_info() across a large range of
> WAL, which is what this function will make users eager to do in this
> case as it is possible to apply
Hi,
On 2023-03-17 09:06:05 +0100, Peter Eisentraut wrote:
> AFAICT, the default for meson is buildtype=debug, which is -O0. The -O3
> comes from meson.build setting buildtype=release.
Right - my point about -O3 was just that buildtype=release defaults to it.
> I think a good compromise would b
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_records_info() for many important use cases.
> Why is that a bad thing?
On Fri, Mar 17, 2023 at 09:11:53PM +0100, Pavel Stehule wrote:
> and queryjumblefuncs.switch.c files.
Let me see.. It looks like src/include/nodes/meson.build is just
missing a refresh. Will check and fix, thanks for the report!
--
Michael
signature.asc
Description: PGP signature
On Fri, Mar 17, 2023 at 01:44:12PM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > On Thu, Mar 16, 2023 at 08:43:56AM -0400, Tom Lane wrote:
> >> I think the odds of that yielding a usable dump are nil, so I don't
> >> see why we should bother.
>
> > No objection from me.
>
> OK, pushed with t
On Fri, Mar 17, 2023 at 5:51 PM Michael Paquier wrote:
> Yes. The CPU cost is one thing, but I am also worrying about the
> I/O cost with a tuplestore spilling to disk a large number of FPIs,
> and some workloads can generate WAL so as FPIs is what makes for most
> of the contents stored in the W
On Fri, Mar 17, 2023 at 06:09:05PM -0700, Peter Geoghegan wrote:
>> This said, your point about having rec_blk_ref reported as an empty
>> string rather than NULL if there are no block references does not feel
>> natural to me, either.. Reporting NULL would be better.
>
> You have it backwards. I
Hi Peter,
Thanks for the feedback! I'll work on it during the weekend.
On Thu, Mar 16, 2023 at 6:23 PM Peter Geoghegan wrote:
>
> existence of a "same" routine hints at some confusion about "equality
> versus equivalence" issues.
Hmm...yes, actually, GiST deals with floats routinely. And there
Hi,
Peter Smith has recently reported a BF failure [1]. AFAICS, the call
stack of failure [2] is as follows:
0x1e66644 at postgres
0x1d0143c at postgres
0x1d02534 at postgres
0x1cfb120 at postgres
0x1cfd590 at postgres
0x1cfbfc0 at postgres
0x1ca7b08 at postgres
0x1ca7c74 at postgres
0x1c
Amit Kapila writes:
> Peter Smith has recently reported a BF failure [1]. AFAICS, the call
> stack of failure [2] is as follows:
Note the assertion report a few lines further up:
TRAP: failed Assert("pg_atomic_read_u32(&entry_ref->shared_entry->refcount) ==
0"), File: "pgstat_shmem.c", Line: 56
On Sat, Mar 18, 2023 at 1:06 AM Peter Geoghegan wrote:
>
> On Fri, Mar 17, 2023 at 12:20 AM Bharath Rupireddy
> wrote:
> > +1 for pg_get_wal_block_info emitting per-record WAL info too along
> > with block info, attached v2 patch does that. IMO, usability wins the
> > race here.
>
> I think that
On Sat, Mar 18, 2023 at 5:06 AM Jacob Champion wrote:
>
> On Thu, Mar 16, 2023 at 11:28 PM wangw.f...@fujitsu.com
> wrote:
> > Attach the new patch set.
>
> Hi,
>
> I ran into this problem while hacking on [1], so thank you for tackling
> it! I have no strong opinions on the implementation itself
Hi,
I'm attaching a patch to do $subject in autoprewarm.c and worker_spi
extensions. The way it is right now doesn't hurt anyone, but why to
fail after defining custom GUCs if we aren't loading them via
shared_preload_libraries.
Thoughts?
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Op
so 18. 3. 2023 v 1:58 odesílatel Michael Paquier
napsal:
> On Fri, Mar 17, 2023 at 09:11:53PM +0100, Pavel Stehule wrote:
> > and queryjumblefuncs.switch.c files.
>
> Let me see.. It looks like src/include/nodes/meson.build is just
> missing a refresh. Will check and fix, thanks for the report!
On Sat, Mar 18, 2023 at 3:13 AM Tomas Vondra
wrote:
>
> On 3/17/23 18:55, Tomas Vondra wrote:
> >
> > ...
> >
> > This however made me realize the initial sync of sequences may not be
> > correct. I mean, the idea of tablesync is syncing the data in REPEATABLE
> > READ transaction, and then applyi
72 matches
Mail list logo
