Hi,
On 3/9/23 1:34 AM, Andres Freund wrote:
Hi,
On 2023-03-08 12:55:34 +0100, Drouvot, Bertrand wrote:
On 3/7/23 7:47 PM, Andres Freund wrote:
On 2023-03-07 13:43:28 -0500, Melanie Plageman wrote:
No, I don't think we can do that. It can be enabled on a per-session basis.
Oh right. So it's
Hi,
On Thu, Mar 09, 2023 at 12:05:36PM +0530, Amit Kapila wrote:
> On Wed, Mar 8, 2023 at 12:26 PM Julien Rouhaud wrote:
> >
> > Is there something that can be done for pg16? I was thinking that having a
> > fix for the normal and easy case could be acceptable: only allowing
> > pg_upgrade to opt
On 28.02.23 06:57, Jeff Davis wrote:
On Mon, 2023-02-20 at 15:23 -0800, Jeff Davis wrote:
New patch attached. The new patch also includes a GUC that (when
enabled) validates that the collator is actually found.
New patch attached.
Now it always preserves the exact locale string during pg_upg
On 08.03.23 10:37, Daniel Gustafsson wrote:
The comment in question was missed in 55fe26a4b58, but I agree that it's a
false claim given the OpenSSL implementation so removing or at least mimicking
the comments in cryptohash_openssl.c would be better.
I have fixed these comments to match crypto
On 2023-Jan-22, Karl O. Pinc wrote:
> Actually, this CSS, added to doc/src/sgml/stylesheet.css,
> makes the column spacing look pretty good:
>
> /* Adequate spacing between columns in a simplelist non-inline table */
> .simplelist td { padding-left: 2em; padding-right: 2em; }
Okay, this looks go
At Thu, 9 Mar 2023 11:00:46 +0530, Amit Kapila wrote
in
> On Wed, Mar 8, 2023 at 9:20 AM Masahiko Sawada wrote:
> >
> > On Wed, Mar 8, 2023 at 3:30 AM Nathan Bossart
> > wrote:
> > >
> >
> > > IMO the current set of
> > > trade-offs (e.g., unavoidable bloat and WAL buildup) would make this
>
On 08.03.23 06:55, Jeff Davis wrote:
On Fri, 2023-03-03 at 21:45 -0800, Jeff Davis wrote:
0002: update template0 in new cluster (as described above)
I think 0002 is about ready and I plan to commit it soon unless someone
has more comments.
0002 seems fine to me.
I'm holding off on 0001
On Thu, Mar 9, 2023 at 2:56 PM Kyotaro Horiguchi
wrote:
>
> At Thu, 9 Mar 2023 11:00:46 +0530, Amit Kapila
> wrote in
> > On Wed, Mar 8, 2023 at 9:20 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Mar 8, 2023 at 3:30 AM Nathan Bossart
> > > wrote:
> > > >
> > >
> > > > IMO the current se
On 20.02.23 23:58, Nathan Bossart wrote:
Similarly -- this is an existing issue but we might as well look at it -- in
something like
must be superuser or a role with privileges of the
pg_write_server_files role
the phrase "a role with the privileges of that other role" seems ambiguous
Hi Peter,
> 1.
> In my previous review [1] (comment #1) I wrote that only some of the
> "should" were misleading and gave examples where to change. But I
> didn't say that *every* usage of that word was wrong, so your global
> replace of "should" to "must" has modified a couple of places in
> un
Hi Vignesh C,
> > Hmm, can you please elaborate more on this? The declaration
> > and assignment are already on different lines.
> >
> > ps: pgindent changed this line a bit. Does that look better?
>
> I thought of changing it to something like below:
> bool isUsableIndex;
> Oid idxoid = lfirst_o
Hi Amit, all
> >
>
> This new test takes ~9s on my machine whereas most other tests in
> subscription/t take roughly 2-5s. I feel we should try to reduce the
> test timing without sacrificing much of the functionality or code
> coverage.
Alright, that is reasonable.
> I think if possible we s
On Thur, Mar 9, 2023 10:27 AM Wang, Wei/王 威
> On Mon, Mar 6, 2023 18:17 PM Wang, Wei/王 威
> wrote:
> > On Mon, Mar 6, 2023 14:34 AM Ajin Cherian wrote:
> > > Changes are in patch 1 and patch 2
> >
> > Thanks for updating the patch set.
> >
> > Here are some comments:
>
> Here are some more comme
> On 9 Mar 2023, at 08:09, Michael Paquier wrote:
>
> On Wed, Mar 08, 2023 at 05:21:20PM +0900, Michael Paquier wrote:
>> On Wed, Mar 08, 2023 at 09:07:36AM +0100, Daniel Gustafsson wrote:
>>> AFAIK a TAP test with psql_interactive is the only way to do this so that's
>>> what I've implemented.
>
On 08.03.23 19:25, Jeff Davis wrote:
Why is "unicode" only provided for the UTF-8 encoding? For "ucs_basic"
that makes some sense, because the implementation only works in UTF-8.
But here we are using ICU, and the "und" locale should work for any
ICU-supported encoding. I suggest that we use coll
On Thu, Mar 09, 2023 at 10:01:14AM +0100, Peter Eisentraut wrote:
> I have fixed these comments to match cryptohash_openssl.c.
Missed that, thanks for the fix.
--
Michael
signature.asc
Description: PGP signature
I didn't like very much this business of setting the perminfoindex
directly to '2' and '1'. It looks ugly with no explanation. What do
you think of creating the as we go along and set each index
correspondingly, as in the attached?
--
Álvaro Herrera 48°01'N 7°57'E — https://www.
On 2023-Jan-27, Andres Freund wrote:
> On 2023-01-27 20:39:04 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > Tom, is there a reason we run the various sanity tests early-ish in the
> > > schedule? It does seem to reduce their effectiveness a bit...
> >
> > Originally, those tests were ma
Hi Alvaro,
On Thu, Mar 9, 2023 at 7:39 PM Alvaro Herrera wrote:
> I didn't like very much this business of setting the perminfoindex
> directly to '2' and '1'. It looks ugly with no explanation. What do
> you think of creating the as we go along and set each index
> correspondingly, as in the a
On Thu, Mar 9, 2023 at 3:26 PM Önder Kalacı wrote:
>
>>
>> 4.
>> +# Testcase start: SUBSCRIPTION BEHAVIOR WITH ENABLE_INDEXSCAN
>>
>> As we have removed enable_indexscan check, you should remove this test.
>
>
> Hmm, I think my rebase problems are causing confusion here, which v38 fixes.
>
I thin
On Thu, Mar 9, 2023 at 4:50 PM Amit Kapila wrote:
>
> On Thu, Mar 9, 2023 at 3:26 PM Önder Kalacı wrote:
> >
> >
> > So, I changed the first one to SUBSCRIPTION USES INDEX WITH MULTIPLE ROWS
> > AND COLUMNS
> > and dropped the second one. Let me know if it does not make sense to you.
> > If I t
Hi,
Amit Kapila , 8 Mar 2023 Çar, 14:42 tarihinde şunu
yazdı:
> On Wed, Mar 8, 2023 at 4:51 PM Önder Kalacı wrote:
> >
> >
> >>
> >> I just share this case and then we
> >> can discuss should we pick the index which only contain the extra
> columns on the
> >> subscriber.
> >>
> >
> > I think it
Hi Amit,
> >
> >>
> >> 4.
> >> +# Testcase start: SUBSCRIPTION BEHAVIOR WITH ENABLE_INDEXSCAN
> >>
> >> As we have removed enable_indexscan check, you should remove this test.
> >
> >
> > Hmm, I think my rebase problems are causing confusion here, which v38
> fixes.
> >
>
> I think it is still no
Hi,
On 2/28/23 4:30 PM, Bharath Rupireddy wrote:
Hi,
Most of the multiplexed SIGUSR1 handlers are setting latch explicitly
when the procsignal_sigusr1_handler() can do that for them at the end.
Right.
These multiplexed handlers are currently being used as SIGUSR1
handlers, not as independen
On Tue, Mar 07, 2023 at 10:18:44AM -0800, Andres Freund wrote:
> Hi,
>
> On 2023-03-06 15:21:14 -0500, Melanie Plageman wrote:
> > Good point. Attached is what you suggested. I committed the transaction
> > before the drop table so that the statistics would be visible when we
> > queried pg_stat_i
Hi,
There was a warning while applying the patch, v5 is attached.
Regards,
Nazir Bilal Yavuz
Microsoft
From dcd49e48a0784a95b8731df1c6ee7c3a612a8529 Mon Sep 17 00:00:00 2001
From: Nazir Bilal Yavuz
Date: Thu, 9 Mar 2023 15:35:38 +0300
Subject: [PATCH v5] Refactor instr_time calculations
In inst
On 08.03.23 22:40, Andrew Dunstan wrote:
There are probably some fairly easy opportunities to reduce the number
of non-terminals introduced here (e.g. I think json_aggregate_func could
possibly be expanded in place without introducing
json_object_aggregate_constructor and json_array_aggregate_c
On Thu, Mar 9, 2023 at 4:47 PM John Naylor wrote:
>
>
> On Thu, Mar 9, 2023 at 12:42 AM Jim Nasby wrote:
> >
> > Doesn't the dead tuple space grow as needed? Last I looked we don't
> > allocate up to 1GB right off the bat.
>
> Incorrect.
>
> > Of course, if the patch that eliminates the 1GB vacu
On Wed, Mar 8, 2023 at 2:23 PM Andres Freund wrote:
>
> On 2023-03-08 13:44:32 -0500, Melanie Plageman wrote:
> > However, I am concerned that, while unlikely, this could be flakey.
> > Something could happen to force all of those blocks out of shared
> > buffers (even though they were just read i
On 2023-03-08 We 17:23, Andrew Dunstan wrote:
On 2023-03-08 We 14:22, Andres Freund wrote:
Hi,
On 2023-03-02 17:35:26 -0500, Andrew Dunstan wrote:
On 2023-03-02 Th 17:06, Andres Freund wrote:
Hi
On 2023-03-02 17:00:47 -0500, Andrew Dunstan wrote:
On 2023-03-01 We 16:32, Andres Freund wro
On 03.03.23 11:01, Nazir Bilal Yavuz wrote:
On Fri, 3 Mar 2023 at 12:16, Peter Eisentraut
wrote:
On 02.03.23 11:41, Nazir Bilal Yavuz wrote:
I am kind of confused. I added these checks for considering other SSL
implementations in the future, for this reason I have two nested if
checks. The to
> On 9 Mar 2023, at 14:45, Peter Eisentraut
> wrote:
> How about we just hardcode "openssl" here instead? We could build that array
> dynamically, of course, but maybe we leave that until we actually have a need?
At least for 16 keeping it hardcoded is an entirely safe bet so +1 for leaving
a
Hi,
On Thu, 9 Mar 2023 at 16:54, Daniel Gustafsson wrote:
>
> > On 9 Mar 2023, at 14:45, Peter Eisentraut
> > wrote:
>
> > How about we just hardcode "openssl" here instead? We could build that
> > array dynamically, of course, but maybe we leave that until we actually
> > have a need?
>
> A
On Wed, Mar 8, 2023 at 5:44 PM Jacob Champion wrote:
>
> On Wed, Mar 8, 2023 at 11:40 AM Robert Haas wrote:
> > On Wed, Mar 8, 2023 at 2:30 PM Jacob Champion
> > wrote:
> > > I don't think I necessarily like that option better than SASL-style,
> > > but hopefully that clarifies it somewhat?
> >
> On 9 Mar 2023, at 15:12, Nazir Bilal Yavuz wrote:
>
> Hi,
>
> On Thu, 9 Mar 2023 at 16:54, Daniel Gustafsson wrote:
>>
>>> On 9 Mar 2023, at 14:45, Peter Eisentraut
>>> wrote:
>>
>>> How about we just hardcode "openssl" here instead? We could build that
>>> array dynamically, of course,
On Wed, Mar 8, 2023 at 5:44 PM Jacob Champion wrote:
> Sure. I don't see a way for the proxy to figure that out by itself,
> though, going back to my asymmetry argument from before. Only the
> server truly knows, at time of HBA processing, whether the proxy
> itself has authority. If the proxy kne
On 09.03.23 15:12, Nazir Bilal Yavuz wrote:
Hi,
On Thu, 9 Mar 2023 at 16:54, Daniel Gustafsson wrote:
On 9 Mar 2023, at 14:45, Peter Eisentraut
wrote:
How about we just hardcode "openssl" here instead? We could build that array
dynamically, of course, but maybe we leave that until we
> >>> Now I've a second thought: what do you think about resetting the related
> >>> number
> >>> of operations and *_time fields when enabling/disabling track_io_timing?
> >>> (And mention it in the doc).
> >>>
> >>> That way it'd prevent bad interpretation (at least as far the time per
> >>> o
Greetings,
* Nathan Bossart (nathandboss...@gmail.com) wrote:
> On Wed, Feb 15, 2023 at 10:13:17AM -0800, Nathan Bossart wrote:
> > On Tue, Feb 14, 2023 at 07:32:56PM -0600, Justin Pryzby wrote:
> >> On Mon, Feb 13, 2023 at 08:18:52PM -0800, Nathan Bossart wrote:
> >>> I'm curious why you chose to
Hi,
On Thu, 9 Mar 2023 at 17:18, Peter Eisentraut
wrote:
>
> On 09.03.23 15:12, Nazir Bilal Yavuz wrote:
> > Hi,
> >
> > On Thu, 9 Mar 2023 at 16:54, Daniel Gustafsson wrote:
> >>
> >>> On 9 Mar 2023, at 14:45, Peter Eisentraut
> >>> wrote:
> >>
> >>> How about we just hardcode "openssl" here
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Fri, Feb 17, 2023 at 09:01:43AM -0800, Jacob Champion wrote:
> > On Thu, Feb 16, 2023 at 10:59 PM Michael Paquier
> > wrote:
> >> I am adding Stephen Frost
> >> in CC to see if he has any comments about all this part of the logic
> >
Hi,
> 1. Use internal 64 bit page numbers in SLRUs without changing segments naming.
> 2. Use the larger segment file names in async.c, to lift the current 8
> GB limit on the max number of pending notifications.
> [...]
>
> Where our main focus for PG16 is going to be 1 and 2, and we may try
> to
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 25 February 2023 00:50:30 EET, Stephen Frost wrote:
> >Thanks for reviewing! Comments added and updated the commit message.
> >
> >Unless there's anything else, I'll push this early next week.
>
> s/capture portal/captive portal/. Ot
On Wed, Mar 8, 2023 at 7:30 PM Himanshu Upadhyaya <
upadhyaya.himan...@gmail.com> wrote:
Please find the v11 patch with all these changes.
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
From f2b262e95fe07dddfec994f20a6d2e76bc12b410 Mon Sep 17 00:00:00 2001
From: Himanshu
Hi,
On 3/9/23 2:23 PM, Melanie Plageman wrote:
On Wed, Mar 8, 2023 at 2:23 PM Andres Freund wrote:
On 2023-03-08 13:44:32 -0500, Melanie Plageman wrote:
However, I am concerned that, while unlikely, this could be flakey.
Something could happen to force all of those blocks out of shared
buffe
Stephen Frost writes:
> Push, thanks again!
Why'd you only change HEAD? Isn't the test equally fragile in the
back branches?
regards, tom lane
On Wed, Mar 01, 2023 at 05:39:54PM +0100, Tomas Vondra wrote:
> On 2/27/23 05:49, Justin Pryzby wrote:
> > On Sat, Feb 25, 2023 at 08:05:53AM -0600, Justin Pryzby wrote:
> >> On Fri, Feb 24, 2023 at 11:02:14PM -0600, Justin Pryzby wrote:
> >>> I have some fixes (attached) and questions while polish
On Thu, Mar 09, 2023 at 09:34:10AM -0500, Stephen Frost wrote:
> Greetings,
>
> * Nathan Bossart (nathandboss...@gmail.com) wrote:
> > On Wed, Feb 15, 2023 at 10:13:17AM -0800, Nathan Bossart wrote:
> > > On Tue, Feb 14, 2023 at 07:32:56PM -0600, Justin Pryzby wrote:
> > >> On Mon, Feb 13, 2023 at
Hi, v4 attached addresses these review comments.
On Tue, Mar 7, 2023 at 1:39 PM Andres Freund wrote:
> On 2023-03-06 11:30:13 -0500, Melanie Plageman wrote:
> > > As pgstat_bktype_io_stats_valid() is called only in Assert(), I think
> > > that would be a good idea
> > > to also check that if cou
While reviewing this patch, I started to wonder why we don't eliminate
the maintenance hassle of xml_1.out by putting in a short-circuit
at the top of the test, similar to those in some other scripts:
/* skip test if XML support not compiled in */
SELECT 'one'::xml;
\if :ERROR
\quit
\endif
(and I
Hi Joseph,
Thanks for working on the patch. Sorry for taking so long to review
this patch. But here's it finally, review of code changes
static pg_tz *FetchDynamicTimeZone(TimeZoneAbbrevTable *tbl, const datetkn *tp,
- DateTimeErrorExtra *extra);
+
On 2023-Mar-09, Justin Pryzby wrote:
> On Thu, Mar 09, 2023 at 09:34:10AM -0500, Stephen Frost wrote:
> > > +Reports whether huge pages are in use by the current instance.
> > > +See for more information.
> > >
> > > I still think we should say "server" in place of "current inst
On 3/9/23 17:15, Justin Pryzby wrote:
> On Wed, Mar 01, 2023 at 05:39:54PM +0100, Tomas Vondra wrote:
>> On 2/27/23 05:49, Justin Pryzby wrote:
>>> On Sat, Feb 25, 2023 at 08:05:53AM -0600, Justin Pryzby wrote:
On Fri, Feb 24, 2023 at 11:02:14PM -0600, Justin Pryzby wrote:
> I have some
On Thu, Mar 09, 2023 at 10:55:54AM +0100, Peter Eisentraut wrote:
> On 20.02.23 23:58, Nathan Bossart wrote:
>> For now, I've reworded these as "must inherit privileges of".
>
> I don't have a good mental model of all this role inheritance, personally,
> but I fear that this change makes the messa
On 3/9/23 01:30, Michael Paquier wrote:
> On Thu, Mar 09, 2023 at 12:39:08AM +0100, Tomas Vondra wrote:
>> IMO we should fix that. We have a bunch of buildfarm members running on
>> Ubuntu 18.04 (or older) - it's true none of them seems to be running TAP
>> tests. But considering how trivial the
On 09.03.23 18:38, Tom Lane wrote:
While reviewing this patch, I started to wonder why we don't eliminate
the maintenance hassle of xml_1.out by putting in a short-circuit
at the top of the test, similar to those in some other scripts:
/* skip test if XML support not compiled in */
SELECT 'one':
In [1] I wrote:
> PG Bug reporting form writes:
>> The following script:
>> [ leaks a file descriptor per error ]
>
> Yeah, at least on platforms where WaitEventSets own kernel file
> descriptors. I don't think it's postgres_fdw's fault though,
> but that of ExecAppendAsyncEventWait, which is i
On Thu, 2023-03-09 at 10:36 +0100, Peter Eisentraut wrote:
> 0002 seems fine to me.
Committed 0002 with some test improvements.
>
> Let's come back to that after dealing with the other two.
Leaving 0001 open for now.
0003 committed after addressing your comments.
--
Jeff Davis
PostgreSQL Co
On Thu, 2023-03-09 at 11:21 +0100, Peter Eisentraut wrote:
> How about this patch version?
Looks good to me.
Regards,
Jeff Davis
+ pg_log_error("Watch period must be non-negative
number, but argument is '%s'", opt);
After looking around at the other error messages in this file, I think we
should make this more concise. Maybe something like
pg_log_error("\\watch: invalid delay interva
Hi,
On 2023-03-09 06:51:31 -0600, Justin Pryzby wrote:
> On Tue, Mar 07, 2023 at 10:18:44AM -0800, Andres Freund wrote:
> > Hi,
> >
> > On 2023-03-06 15:21:14 -0500, Melanie Plageman wrote:
> > > Good point. Attached is what you suggested. I committed the transaction
> > > before the drop table s
On Thu, Mar 09, 2023 at 10:38:56AM -0600, Justin Pryzby wrote:
> On Thu, Mar 09, 2023 at 09:34:10AM -0500, Stephen Frost wrote:
>> To that end- perhaps this isn't appropriate as a GUC at all? Why not
>> have this just be a system information function? Functionally it really
>> provides the same i
On 2023-03-09 Th 08:28, Andrew Dunstan wrote:
At this stage I think I'm prepared to turn this loose on a couple of
my buildfarm animals, and if nothing goes awry for the remainder of
the month merge the dev/meson branch and push a new release.
There is still probably a little polishing to
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Push, thanks again!
>
> Why'd you only change HEAD? Isn't the test equally fragile in the
> back branches?
We hadn't had any complaints about it and so I wasn't sure if it was
useful to back-patch it. I'm happy to d
On Thu, Mar 09, 2023 at 06:51:21PM +0100, Alvaro Herrera wrote:
> I'd rather make all these other places use "instance" instead. We used
> to consider these terms interchangeable, but since we introduced the
> glossary to unify the terminology, they are no longer supposed to be.
> A server (== a m
Hi,
On 2023-03-09 14:47:36 -0500, Andrew Dunstan wrote:
> On 2023-03-09 Th 08:28, Andrew Dunstan wrote:
> > At this stage I think I'm prepared to turn this loose on a couple of my
> > buildfarm animals, and if nothing goes awry for the remainder of the
> > month merge the dev/meson branch and push
Greetings,
* Justin Pryzby (pry...@telsasoft.com) wrote:
> On Thu, Mar 09, 2023 at 09:34:10AM -0500, Stephen Frost wrote:
> > * Nathan Bossart (nathandboss...@gmail.com) wrote:
> > > On Wed, Feb 15, 2023 at 10:13:17AM -0800, Nathan Bossart wrote:
> > > > On Tue, Feb 14, 2023 at 07:32:56PM -0600, J
> On Mar 8, 2023, at 4:15 PM, Andres Freund wrote:
>
> I worked some more on the fixes for amcheck, and fixes for amcheck.
>
> The second amcheck fix ends up correcting some inaccurate output in the tests
> - previously xids from before xid 0 were reported to be in the future.
>
> Previously
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> On 2023-Mar-09, Justin Pryzby wrote:
> > On Thu, Mar 09, 2023 at 09:34:10AM -0500, Stephen Frost wrote:
> > > > +Reports whether huge pages are in use by the current instance.
> > > > +See for more information.
> > > >
On Thu, 2023-03-09 at 09:46 +0100, Peter Eisentraut wrote:
> This patch appears to do about three things at once, and it's not
> clear
> exactly where the boundaries are between them and which ones we might
> actually want. And I think the terminology also gets mixed up a bit,
> which makes follo
Peter Smith writes:
> The patch v19 LGTM.
I've looked through this now, and have some minor complaints and a major
one. The major one is that it doesn't work for XML that doesn't satisfy
IS DOCUMENT. For example,
regression=# select '42'::xml is
document;
?column?
--
f
(1 row)
reg
Andres Freund writes:
> On 2023-03-09 14:47:36 -0500, Andrew Dunstan wrote:
>> . There appears to be some mismatch in database names (e.g.
>> regression_dblink vs contrib_regression_dblink). That's going to cause some
>> issues with the module that adjusts things for cross version upgrade.
> I gu
On Wed, Mar 8, 2023 at 9:52 PM Thomas Munro wrote:
> Yeah. We knew that this didn't work (was discussed in a couple of
> other threads), but you might be right that an error would be better
> for now. It's absolutely not a user facing mode of operation, it was
> intended just for the replication
Hi,
I think that 4753ef37e0ed undid the work caf626b2c did to support
sub-millisecond delays for vacuum and autovacuum.
After 4753ef37e0ed, vacuum_delay_point()'s local variable msec is a
double which, after being passed to WaitLatch() as timeout, which is a
long, ends up being 0, so we don't end
On Fri, Mar 10, 2023 at 10:26 AM Melanie Plageman
wrote:
> I think that 4753ef37e0ed undid the work caf626b2c did to support
> sub-millisecond delays for vacuum and autovacuum.
>
> After 4753ef37e0ed, vacuum_delay_point()'s local variable msec is a
> double which, after being passed to WaitLatch()
Joseph Koshakow writes:
> Please see the attached patch with these changes.
Pushed with a couple of cosmetic adjustments.
regards, tom lane
Thomas Munro writes:
> On Fri, Mar 10, 2023 at 10:26 AM Melanie Plageman
> wrote:
>> I think that 4753ef37e0ed undid the work caf626b2c did to support
>> sub-millisecond delays for vacuum and autovacuum.
> Given that some of the clunkier underlying kernel primitives have
> milliseconds in their
Greetings,
* Thomas Munro (thomas.mu...@gmail.com) wrote:
> On Fri, Mar 10, 2023 at 10:26 AM Melanie Plageman
> wrote:
> > I think that 4753ef37e0ed undid the work caf626b2c did to support
> > sub-millisecond delays for vacuum and autovacuum.
> >
> > After 4753ef37e0ed, vacuum_delay_point()'s loc
On Fri, Mar 10, 2023 at 11:02 AM Tom Lane wrote:
> Thomas Munro writes:
> > On Fri, Mar 10, 2023 at 10:26 AM Melanie Plageman
> > wrote:
> >> I think that 4753ef37e0ed undid the work caf626b2c did to support
> >> sub-millisecond delays for vacuum and autovacuum.
>
> > Given that some of the clun
On Thu, Mar 9, 2023 at 5:10 PM Thomas Munro wrote:
>
> On Fri, Mar 10, 2023 at 11:02 AM Tom Lane wrote:
> > Thomas Munro writes:
> > > On Fri, Mar 10, 2023 at 10:26 AM Melanie Plageman
> > > wrote:
> > >> I think that 4753ef37e0ed undid the work caf626b2c did to support
> > >> sub-millisecond d
Thomas Munro writes:
> On Fri, Mar 10, 2023 at 11:02 AM Tom Lane wrote:
>> The caf626b2c code would only work well on platforms that have
>> microsecond-based sleep primitives, so it was already not too portable.
> Also, the previous coding was already b0rked, because pg_usleep()
> rounds up to
On Thu, Mar 09, 2023 at 05:27:08PM -0500, Tom Lane wrote:
> Is it reasonable to assume that all modern platforms can time
> millisecond delays accurately? Ten years ago I'd have suggested
> truncating the delay to a multiple of 10msec and using this logic
> to track the remainder, but maybe now th
On 2023-03-09 Th 15:25, Tom Lane wrote:
Andres Freund writes:
On 2023-03-09 14:47:36 -0500, Andrew Dunstan wrote:
. There appears to be some mismatch in database names (e.g.
regression_dblink vs contrib_regression_dblink). That's going to cause some
issues with the module that adjusts things
On Thu, Mar 9, 2023 at 5:27 PM Tom Lane wrote:
>
> Thomas Munro writes:
> > On Fri, Mar 10, 2023 at 11:02 AM Tom Lane wrote:
> >> The caf626b2c code would only work well on platforms that have
> >> microsecond-based sleep primitives, so it was already not too portable.
>
> > Also, the previous c
On Thu, Mar 9, 2023 at 5:27 PM Tom Lane wrote:
>
> Thomas Munro writes:
> > On Fri, Mar 10, 2023 at 11:02 AM Tom Lane wrote:
> >> The caf626b2c code would only work well on platforms that have
> >> microsecond-based sleep primitives, so it was already not too portable.
>
> > Also, the previous c
Hi,
During a recent code review, I was confused multiple times by the
toptxn member of ReorderBufferTXN, which is defined only for
sub-transactions.
e.g. txn->toptxn member == NULL means the txn is a top level txn.
e.g. txn->toptxn member != NULL means the txn is not a top level txn
It makes sen
On Tue, Mar 7, 2023 at 1:36 PM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:
>
> On Thu, Mar 2, 2023 at 8:01 AM Michael Paquier
> wrote:
>
>>
>> The internal implementation of _pgstat64() is used in quite a few
>>
> places, so we'd better update this part first, IMO, and then
Melanie Plageman writes:
> On Thu, Mar 9, 2023 at 5:27 PM Tom Lane wrote:
>> A minimalistic fix could be as attached. I'm not sure if it's worth
>> making the state variable global so that it can be reset to zero in
>> the places where we zero out VacuumCostBalance etc. Also note that
>> this i
On 2023-03-09 Th 14:47, Andrew Dunstan wrote:
On 2023-03-09 Th 08:28, Andrew Dunstan wrote:
At this stage I think I'm prepared to turn this loose on a couple of
my buildfarm animals, and if nothing goes awry for the remainder of
the month merge the dev/meson branch and push a new release
On Thu, Mar 09, 2023 at 09:58:46AM -0800, Nathan Bossart wrote:
> On Thu, Mar 09, 2023 at 10:55:54AM +0100, Peter Eisentraut wrote:
>> On 20.02.23 23:58, Nathan Bossart wrote:
>>> For now, I've reworded these as "must inherit privileges of".
>>
>> I don't have a good mental model of all this role
On Fri, Mar 10, 2023 at 11:37 AM Nathan Bossart
wrote:
>
> On Thu, Mar 09, 2023 at 05:27:08PM -0500, Tom Lane wrote:
> > Is it reasonable to assume that all modern platforms can time
> > millisecond delays accurately? Ten years ago I'd have suggested
> > truncating the delay to a multiple of 10ms
Erm, but maybe I'm just looking at this too myopically. Is there
really any point in letting people set it to 0.5, if it behaves as if
you'd set it to 1 and doubled the cost limit? Isn't it just more
confusing? I haven't read the discussion from when fractional delays
came in, where I imagine th
Joseph Koshakow writes:
> Also I removed some dead code from the previous patch.
This needs a rebase over bcc704b52, so I did that and made a
couple of other adjustments.
I'm inclined to think that you removed too much from DecodeTimeOnly.
That does accept date specs (at least for timetz), and I
Thomas Munro writes:
> Erm, but maybe I'm just looking at this too myopically. Is there
> really any point in letting people set it to 0.5, if it behaves as if
> you'd set it to 1 and doubled the cost limit? Isn't it just more
> confusing? I haven't read the discussion from when fractional dela
On Thu, Mar 09, 2023 at 03:37:21PM +0900, Michael Paquier wrote:
> Okay, thanks. Let's use that, then.
I have done one pass over that today, and applied it. Thanks!
I'd really like to do something about the errors we raise in the
module when specifying LSNs in the future for this release, now.
On Fri, Mar 10, 2023 at 1:46 PM Tom Lane wrote:
> >> I propose therefore that instead of increasing vacuum_cost_limit,
> >> what we ought to be doing is reducing vacuum_cost_delay by a similar
> >> factor. And, to provide some daylight for people to reduce it even
> >> more, we ought to arrange f
On Fri, Mar 10, 2023 at 6:43 AM Michael Paquier wrote:
>
> I'd really like to do something about the errors we raise in the
> module when specifying LSNs in the future for this release, now. I
> got annoyed by it again this morning while doing \watch queries that
> kept failing randomly while str
Thomas Munro writes:
> OK. One idea is to provide a WaitLatchUsec(), which is just some
> cross platform donkeywork that I think I know how to type in, and it
> would have to round up on poll() and Windows builds. Then we could
> either also provide WaitEventSetResolution() that returns 1000 or
On Fri, Mar 10, 2023 at 06:50:05AM +0530, Bharath Rupireddy wrote:
> Perhaps what is proposed here
> https://www.postgresql.org/message-id/calj2acwqj+m0hoqj9qkav2uqfq97yk5jn2modfkcxusxsyp...@mail.gmail.com
> might help and avoid many errors around input LSN validations. Let's
> discuss that in that
On Fri, Mar 10, 2023 at 12:12:37AM +0100, Juan José Santamaría Flecha wrote:
> I've broken the patch in two:
> 1. fixes the detection of unseekable files in checkSeek(), using logic that
> hopefully is backpatchable,
> 2. the improvements on file type detection for stat() proposed by the OP.
I am
1 - 100 of 118 matches
Mail list logo
