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
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!
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
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
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
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
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
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
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
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 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 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 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?
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 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
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 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 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 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
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
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
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
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
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
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
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
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 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
Hi
and queryjumblefuncs.switch.c files.
Regards
Pavel
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
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 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
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 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
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
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 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
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 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 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
--- 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
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...
>
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
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
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"...
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
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 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
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
> 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.
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 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
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
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
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,
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
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
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 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
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 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
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 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 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
> 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 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
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 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
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,
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 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
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
72 matches
Mail list logo
