Hi all,
This is a follow-up of the point I have made a few weeks ago on this
thread of pgsql-bugs about $subject:
https://www.postgresql.org/message-id/Y/Q/17rpys7yg...@paquier.xyz
https://www.postgresql.org/message-id/Y/v0c+3W89NBT/i...@paquier.xyz
Here is a short summary of what I think is inco
On Thu, Mar 9, 2023 at 1:51 PM Masahiko Sawada
wrote:
> I've attached the new version patches. I merged improvements and fixes
> I did in the v29 patch.
I haven't yet had a chance to look at those closely, since I've had to
devote time to other commitments. I remember I wasn't particularly
impre
On Fri, Mar 10, 2023 at 11:17 AM Peter Smith wrote:
>
> On Fri, Mar 10, 2023 at 3:32 PM Amit Kapila wrote:
> >
> > On Thu, Mar 9, 2023 at 10:56 AM Peter Smith wrote:
> > >
> > > 2. rollback_prepared_cb_wrapper
> > >
> > > /*
> > > * If the plugin support two-phase commits then rollback prepa
On Fri, Mar 10, 2023 at 2:45 PM Thomas Munro wrote:
> I'll go and see about usec latch waits. More soon.
Here are some experimental patches along those lines. Seems good
locally, but I saw a random failure I don't understand on CI so
apparently I need to find a bug; at least this gives an idea
On Fri, Mar 10, 2023 at 3:32 PM Amit Kapila wrote:
>
> On Thu, Mar 9, 2023 at 10:56 AM Peter Smith wrote:
> >
> > 2. rollback_prepared_cb_wrapper
> >
> > /*
> > * If the plugin support two-phase commits then rollback prepared callback
> > * is mandatory
> > + *
> > + * FIXME: This should ha
I can use relation struct to get all attributes' typeoid, so which funcion I
can use
to get the real type.
jack...@gmail.com
On Thu, Mar 9, 2023 at 5:47 PM Önder Kalacı wrote:
>
> 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 e
On Wed, Mar 8, 2023 at 1:40 PM Bharath Rupireddy
wrote:
>
> On Tue, Mar 7, 2023 at 11:17 AM Julien Rouhaud wrote:
>
> Here I'm with the v3 patch addressing the above comments. Please
> review it further.
Needed a rebase. v4 patch is attached. I'll address the latest review
comments in a bit.
--
10.03.2023 03:26, Tom Lane wrote:
Joseph Koshakow writes:
Also I removed some dead code from the previous patch.
That's a little weird, or maybe even a lot weird, but it's not
inherently nonsensical so I'm hesitant to stop accepting it.
However, if UNITS acts that way, then why is ISOTIME diff
On Thu, Mar 9, 2023 at 10:56 AM Peter Smith wrote:
>
> 2. rollback_prepared_cb_wrapper
>
> /*
> * If the plugin support two-phase commits then rollback prepared callback
> * is mandatory
> + *
> + * FIXME: This should have been caught much earlier.
> */
> if (ctx->callbacks.rollback_prep
On Wed, Mar 08, 2023 at 01:40:46PM +0530, Bharath Rupireddy wrote:
> 1. When start_lsn is NULL or invalid ('0/0'), emit an error. There was
> a comment on the functions automatically determining start_lsn to be
> the oldest WAL LSN. I'm not implementing this change now, as it
> requires extra work
Here are some review comments for patch v39-0001 (mostly the test code).
==
src/backend/replication/logical/relation.c
1. FindUsableIndexForReplicaIdentityFull
+static Oid
+FindUsableIndexForReplicaIdentityFull(Relation localrel)
+{
+ List*indexlist = RelationGetIndexList(localrel);
+ Oi
On Tue, Mar 07, 2023 at 01:47:01PM +0800, Julien Rouhaud wrote:
> So keep this "deprecated" C function working, as it would only be a few lines
> of code?
Yes, I guess that this would be the final picture, moving forward I'd
like to think that we should just remove the SQL declaration of the
till_
On Wed, Mar 8, 2023 at 8:24 AM wangw.f...@fujitsu.com
wrote:
>
> Attach the new patch.
>
I think this combines multiple improvements in one patch. We can
consider all of them together or maybe it would be better to split
some of those. Do we think it makes sense to split some of the
improvements?
On Fri, Mar 10, 2023 at 11:23 AM Melanie Plageman
wrote:
>
> On Tue, Mar 7, 2023 at 12:10 AM Masahiko Sawada wrote:
> >
> > On Mon, Mar 6, 2023 at 5:26 AM Melanie Plageman
> > wrote:
> > >
> > > On Thu, Mar 2, 2023 at 6:37 PM Melanie Plageman
> > > In this version I've removed wi_cost_delay from
On Tue, Mar 7, 2023 at 12:10 AM Masahiko Sawada wrote:
>
> On Mon, Mar 6, 2023 at 5:26 AM Melanie Plageman
> wrote:
> >
> > On Thu, Mar 2, 2023 at 6:37 PM Melanie Plageman
> > In this version I've removed wi_cost_delay from WorkerInfoData. There is
> > no synchronization of cost_delay amongst wor
On Fri, Mar 10, 2023 at 2:21 PM Tom Lane wrote:
> 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
On Thu, Mar 09, 2023 at 09:51:09AM -0500, Stephen Frost wrote:
> I agree with matching how SSL is handled here and in a review of the
> patch proposed didn't see any issues with it. Seems like it's probably
> something that should also be back-patched and it doesn't look terribly
> risky to do so,
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
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
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 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
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 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.
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
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
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
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
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 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
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 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
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 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
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 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
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 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
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
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
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
Joseph Koshakow writes:
> Please see the attached patch with these changes.
Pushed with a couple of cosmetic adjustments.
regards, tom lane
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()
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 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
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
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
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
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 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,
* 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
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
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
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 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
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
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
+ 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
On Thu, 2023-03-09 at 11:21 +0100, Peter Eisentraut wrote:
> How about this patch version?
Looks good to me.
Regards,
Jeff Davis
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
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 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':
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 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 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 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
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);
+
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, 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
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
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
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
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
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
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
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,
* 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,
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,
* 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
> >>> 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
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
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 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:
>
> 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?
> >
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 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
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 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 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 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 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
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 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,
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
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,
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
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
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
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
1 - 100 of 118 matches
Mail list logo
