On Thu, Feb 02, 2023 at 03:23:51PM -0500, Robert Haas wrote:
> 0001 fixes what I believe to be a slight logical error in sendFile(),
> introduced by me during the v15 development cycle when I introduced
> the bbsink abstraction. I believe that it is theoretically possible
> for this to cause an
Hi,
On 3/1/23 8:54 PM, Gregory Stark (as CFM) wrote:
Looks like you have a path forward on this and it's not ready to
commit yet? In which case I'll mark it Waiting on Author?
Yeah, there is some dependencies around this one.
[1]: depends on it
Current one depends of [2], [3] and [4]
On Thu, Mar 2, 2023 at 10:41 AM Melanie Plageman
wrote:
>
> On Mon, Feb 27, 2023 at 9:12 AM Masahiko Sawada wrote:
> > On Fri, Feb 24, 2023 at 7:08 AM Melanie Plageman
> > wrote:
> > > Users may wish to speed up long-running vacuum of a large table by
> > > decreasing
On Wed, Jan 25, 2023 at 11:22:04PM +, Imseih (AWS), Sami wrote:
> Doing some work with extended query protocol, I encountered the same
> issue that was discussed in [1]. It appears when a client is using
> extended query protocol and sends an Execute message to a portal with
> max_rows, and a
Hi,
On 3/1/23 5:47 AM, Michael Paquier wrote:
On Mon, Feb 20, 2023 at 11:34:59AM +0900, Michael Paquier wrote:
With the patches..
Attached is an updated patch set, where I have done more refactoring
work for the regression tests of pg_stat_statements, splitting
pg_stat_statments.sql into the
Hi,
On Wed, 1 Mar 2023 at 22:21, Peter Eisentraut
wrote:
>
> Looks good to me. I did a small pass over it to adjust some namings.
> For example, I renamed test_install_files to test_install_data, so it's
> consistent with the overall meson naming:
>
> -install_data(
> +test_install_data +=
On Sat, Dec 17, 2022 at 12:55:24AM +0100, Daniel Watzinger wrote:
> Well, this is embarassing. Sorry for the inconvenience. Some part
> of my company's network infrastruture must have mangled the attachment.
> Both mails were sent using a combination of git format-patch
> and git send-email.
On Thu, Mar 02, 2023 at 02:53:02PM +0900, Michael Paquier wrote:
> - if (params->options & VACOPT_FULL)
> + if (params->options & VACOPT_FULL &&
> + params->options & VACOPT_PROCESS_MAIN)
> Perhaps this is a bit under-parenthesized, while reading through it
> once again..
fixed
>
> +
On Thu, Mar 2, 2023 at 5:45 AM Andres Freund wrote:
>
> On 2023-02-28 11:16:45 +0900, Masahiko Sawada wrote:
> > On Tue, Feb 28, 2023 at 10:21 AM Andres Freund wrote:
> > > On 2023-02-27 23:11:53 +0900, Masahiko Sawada wrote:
> > > > As far as I know there are not such GUC parameters in the core
On Wed, Mar 01, 2023 at 09:26:37AM -0800, Nathan Bossart wrote:
> Thanks for taking a look.
>
> On Wed, Mar 01, 2023 at 03:31:48PM +0900, Michael Paquier wrote:
> > PROCESS_TOAST has that:
> > /* sanity check for PROCESS_TOAST */
> > if ((params->options & VACOPT_FULL) != 0 &&
> >
On Thu, Mar 2, 2023 at 2:26 PM Nathan Bossart wrote:
>
> On Thu, Mar 02, 2023 at 02:21:08PM +0900, Michael Paquier wrote:
> > On Thu, Mar 02, 2023 at 12:58:32PM +0900, Masahiko Sawada wrote:
> >> Cutting the toast relation name to 'pg_toast' is a bit confusing to me
> >> as we have the pg_toast
On Thu, Mar 02, 2023 at 02:21:08PM +0900, Michael Paquier wrote:
> On Thu, Mar 02, 2023 at 12:58:32PM +0900, Masahiko Sawada wrote:
>> Cutting the toast relation name to 'pg_toast' is a bit confusing to me
>> as we have the pg_toast schema. How about using the following query
>> instead to improve
On Thu, Mar 02, 2023 at 12:58:32PM +0900, Masahiko Sawada wrote:
> Cutting the toast relation name to 'pg_toast' is a bit confusing to me
> as we have the pg_toast schema. How about using the following query
> instead to improve the readability?
>
>SELECT
>CASE WHEN c.relname IS
On Thu, Mar 2, 2023 at 7:27 AM Peter Smith wrote:
>
> On Thu, Mar 2, 2023 at 5:10 AM Melih Mutlu wrote:
> >
> > Hi,
> >
> > Hayato Kuroda (Fujitsu) , 1 Mar 2023 Çar, 18:40
> > tarihinde şunu yazdı:
> >>
> >> Dear Melih,
> >>
> >> If we do not have to treat the case Shi pointed out[1] as
Dear Amit, Sawada-san,
> I think Kuroda-San wants to emit a WARNING at the time of CREATE
> SUBSCRIPTION. But it won't be possible to emit a WARNING at the time
> of ALTER SUBSCRIPTION. Also, as you say if the user later changes the
> value of max_slot_wal_keep_size, then even if we issue
On Thu, Mar 2, 2023 at 7:38 AM Masahiko Sawada wrote:
>
> On Wed, Mar 1, 2023 at 6:21 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > >
> > > Apart from a bad-use case example I mentioned, in general, piling up
> > > WAL files due to the replication slot has many bad effects on the
> > > system. I'm
On Thu, Mar 2, 2023 at 4:13 AM Nathan Bossart wrote:
>
> On Wed, Mar 01, 2023 at 07:09:53PM +0100, Alvaro Herrera wrote:
> > On 2023-Mar-01, Michael Paquier wrote:
> >
> >> +-- PROCESS_MAIN option
> >> +VACUUM (PROCESS_MAIN FALSE) vactst;
> >> +VACUUM (PROCESS_MAIN FALSE, PROCESS_TOAST FALSE)
On Thu, Mar 2, 2023 at 6:59 AM Tom Lane wrote:
> Yeah. I split out those executor fixes as 0002; 0003 is the changes
> to bitmapsets proper, and then 0004 removes now-dead code.
+1 to all these patches. Some minor comments from me.
*0003
It seems that the Bitmapset checked by
I wrote:
> I'm a little inclined to see if I can turn on -std=gnu99 on my
> clang-based buildfarm animals. I use that with gcc for my
> normal development activities, but now that I see that clang
> catches some things gcc doesn't ...
FTR: done on sifaka and longfin.
Peter Smith writes:
> Apparently, not all C99 compilers can be assumed to work using the
> strict C99 rules.
While googling this issue I came across a statement that clang currently
defaults to C17 rules. Even relatively old compilers might default to
C11. But considering how long we held on
On Thu, Mar 2, 2023 at 4:19 AM Gregory Stark (as CFM)
wrote:
> On Wed, 8 Feb 2023 at 15:04, Andres Freund wrote:
> >
> > Attached is a current, quite rough, prototype. It addresses some of the
> > points
> > raised, but far from all. There's also several XXXs/FIXMEs in it. I changed
> >
On Thu, Mar 2, 2023 at 12:40 PM Tom Lane wrote:
>
> I wrote:
> > Peter Smith writes:
> >> On Thu, Mar 2, 2023 at 10:04 AM Tom Lane wrote:
> >>> Sadly, this is almost certainly going to cause bitching on the part of
> >>> some compilers, because depending on the order of header inclusions
> >>>
I wrote:
> Maybe later versions of the C
> spec clarify this, but I think duplicate typedefs are pretty
> clearly not OK per C99.
Further research shows that C11 allows this, but it's definitely
not okay in C99, which is still our reference standard.
> Perhaps with sufficiently tight warning
>
On Wed, Mar 1, 2023 at 6:21 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Sawada-san,
>
> Thank you for giving your consideration!
>
> > > We have documented at least one such case
> > > already where during Drop Subscription, if the network is not
> > > reachable then also, a similar problem can
On Thu, Mar 2, 2023 at 5:10 AM Melih Mutlu wrote:
>
> Hi,
>
> Hayato Kuroda (Fujitsu) , 1 Mar 2023 Çar, 18:40
> tarihinde şunu yazdı:
>>
>> Dear Melih,
>>
>> If we do not have to treat the case Shi pointed out[1] as code-level, I
>> agreed to
>> same option binary because it is simpler.
>
>
>
On Mon, Feb 27, 2023 at 9:12 AM Masahiko Sawada wrote:
> On Fri, Feb 24, 2023 at 7:08 AM Melanie Plageman
> wrote:
> > Users may wish to speed up long-running vacuum of a large table by
> > decreasing autovacuum_vacuum_cost_delay/vacuum_cost_delay, however the
> > config file is only reloaded
I wrote:
> Peter Smith writes:
>> On Thu, Mar 2, 2023 at 10:04 AM Tom Lane wrote:
>>> Sadly, this is almost certainly going to cause bitching on the part of
>>> some compilers, because depending on the order of header inclusions
>>> they are going to see multiple typedefs for the same name.
>>
On Wed, Mar 01, 2023 at 03:47:17PM +0900, Michael Paquier wrote:
> The CF would begin in more or less 5 hours as of the moment of this
> message:
> https://www.timeanddate.com/time/zones/aoe
Note: I have switched this CF as "In Process" a few hours ago.
--
Michael
signature.asc
Description: PGP
On Wed, Mar 01, 2023 at 07:56:47AM -0800, Nikolay Samokhvalov wrote:
> On Tue, Feb 28, 2023 at 4:43 PM Julien Rouhaud wrote:
> >
> > On Tue, Feb 28, 2023 at 08:02:13AM -0800, Nikolay Samokhvalov wrote:
> > > 0. Temporarily, forbid running any DDL on the source cluster.
> >
> > This is (at least
On Wed, Mar 01, 2023 at 03:31:06PM -0500, Greg Stark wrote:
> Fwiw I prefer the functions approach. I do like me some nice syntax
> but I don't see any particular advantage of the special syntax in this
> case. They don't seem to provide any additional expressiveness.
So do I, eventhough I saw a
On Thu, Mar 2, 2023 at 1:09 PM Andres Freund wrote:
> On 2023-03-02 12:29:28 +1300, Thomas Munro wrote:
> > ... Huh... what am I missing? I
> > thought the only risk was handlers running in the opposite of send
> > order because they 'overlapped', not non-handler code being allowed to
> > run in
Peter Smith writes:
> On Thu, Mar 2, 2023 at 10:04 AM Tom Lane wrote:
>> Sadly, this is almost certainly going to cause bitching on the part of
>> some compilers, because depending on the order of header inclusions
>> they are going to see multiple typedefs for the same name. Redundant
>>
On Wed, Mar 01, 2023 at 07:09:53PM +0100, Alvaro Herrera wrote:
> Maybe instead of reading the log, read values from pg_stat_all_tables.
Ah, right. I was looking at pg_stat_user_tables yesterday, and forgot
that pg_stat_all_tables tracks toast tables, so it should be fine to
do some validation
On Wed, Mar 01, 2023 at 03:34:30PM -0800, Andres Freund wrote:
> On 2023-02-28 13:45:41 +0900, Michael Paquier wrote:
>> From what I can see, SIGTERM is actually received by the backends
>> before SIGQUIT, and I can also see that the backends have enough room
>> to process CFIs in some cases,
On Wed, Mar 01, 2023 at 02:26:21PM -0500, Gregory Stark (as CFM) wrote:
> So I'll set it to "Waiting on Author" pending that new patchset...
There is still an entry as of https://commitfest.postgresql.org/42/4112/.
Support for group detection in pg_ident.conf has been added in efb6f4a
already, so
On Thu, Mar 2, 2023 at 10:04 AM Tom Lane wrote:
>
> Peter Smith writes:
> > AFAICT just by pre-declaring the typedef struct
> > LogicalDecodingContext, all of those 'struct LogicalDecodingContext'
> > can be culled, resulting in cleaner and more consistent function
> > signatures.
>
> Sadly,
On Wed, 2023-03-01 at 11:51 +0100, Drouvot, Bertrand wrote:
>
> Why not "simply" call ConditionVariablePrepareToSleep() without any
> call to ConditionVariableTimedSleep() later?
ConditionVariableSleep() re-inserts itself into the queue if it was
previously removed. Without that, a single
Hi,
On 2023-02-28 08:37:02 -0500, Robert Haas wrote:
> On Mon, Feb 27, 2023 at 7:37 PM Jeff Davis wrote:
> > > Yeah. That's the idea I was floating, at least.
> >
> > Isn't that a hard problem; maybe impossible?
>
> It doesn't seem that hard to me; maybe I'm missing something.
>
> The existing
On 3/2/23 00:18, Jehan-Guillaume de Rorthais wrote:
> Hi,
>
> On Wed, 1 Mar 2023 20:29:11 +0100
> Tomas Vondra wrote:
>> On 3/1/23 18:48, Jehan-Guillaume de Rorthais wrote:
>>> On Tue, 28 Feb 2023 20:51:02 +0100
>>> Tomas Vondra wrote:
On 2/28/23 19:06, Jehan-Guillaume de Rorthais wrote:
Nathan Bossart writes:
> On Wed, Mar 01, 2023 at 05:59:45PM -0500, Tom Lane wrote:
>> + /* attidx is zero-based, attrnum is the normal attribute number */
>> + int attrnum = attidx + FirstLowInvalidHeapAttributeNumber;
> nitpick: Shouldn't this be an AttrNumber?
I stuck with the
On Wed, Mar 01, 2023 at 05:59:45PM -0500, Tom Lane wrote:
> bms_first_member is definitely legacy code, so let's just get
> rid of it. Done like that in 0001 below. (This was slightly more
> complex than I foresaw, because some of the callers were modifying
> the result variables. But they're
Hi,
On 2023-02-28 11:16:45 +0900, Masahiko Sawada wrote:
> On Tue, Feb 28, 2023 at 10:21 AM Andres Freund wrote:
> > On 2023-02-27 23:11:53 +0900, Masahiko Sawada wrote:
> > > As far as I know there are not such GUC parameters in the core but
> > > there might be in third-party table AM and
Hi,
On 2023-02-28 12:36:38 -0800, Jeff Davis wrote:
> On Tue, 2023-02-28 at 11:28 -0800, Andres Freund wrote:
> > I can only repeat myself in stating that SECURITY DEFINER solves none
> > of the
> > relevant issues. I included several examples of why it doesn't in the
> > recent
> > thread about
Hi,
On 2023-03-02 12:29:28 +1300, Thomas Munro wrote:
> In theory you could straighten this out by asking what else is pending
> so that we imposed our own priority, if that were a problem, but there
> is something I don't understand: you said we could handle SIGTERM and
> then make it all the
On 3/1/23 11:09, Peter Eisentraut wrote:
The SQL standard defines several standard collations. Most of them are
only of legacy interest (IMO), but two are currently relevant: UNICODE
and UCS_BASIC. UNICODE sorts by the default Unicode collation algorithm
specifications and UCS_BASIC sorts by
Hi,
On 2023-02-28 13:45:41 +0900, Michael Paquier wrote:
> On Tue, Feb 14, 2023 at 12:47:12PM -0800, Andres Freund wrote:
> > Just naively hacking this behaviour change into the current code, would
> > yield
> > sending SIGQUIT to postgres, and then SIGTERM to the whole process
> > group. Which
On Tue, Feb 28, 2023 at 5:45 PM Michael Paquier wrote:
> On Tue, Feb 14, 2023 at 12:47:12PM -0800, Andres Freund wrote:
> > Just naively hacking this behaviour change into the current code, would
> > yield
> > sending SIGQUIT to postgres, and then SIGTERM to the whole process
> > group. Which
On Wed, Mar 01, 2023 at 03:13:04PM -0800, Andres Freund wrote:
> FWIW, I think we could rely on va_start() et al to be signal safe. The
> standardese isn't super clear about this, because they aren't functions, and
> posix only talks about functions being async signal safe...
Good to know. I
Hi,
On Wed, 1 Mar 2023 20:29:11 +0100
Tomas Vondra wrote:
> On 3/1/23 18:48, Jehan-Guillaume de Rorthais wrote:
> > On Tue, 28 Feb 2023 20:51:02 +0100
> > Tomas Vondra wrote:
> >> On 2/28/23 19:06, Jehan-Guillaume de Rorthais wrote:
> >>> * HashBatchContext goes up to 1441MB after 240s then
Hi,
On 2023-03-01 14:47:51 -0800, Nathan Bossart wrote:
> On Tue, Feb 28, 2023 at 08:36:03PM -0800, Nathan Bossart wrote:
> > On Sun, Feb 26, 2023 at 12:12:27PM -0800, Andres Freund wrote:
> >> Partially I just want something that can easily be searched for, that can
> >> have
> >> comments
Peter Smith writes:
> AFAICT just by pre-declaring the typedef struct
> LogicalDecodingContext, all of those 'struct LogicalDecodingContext'
> can be culled, resulting in cleaner and more consistent function
> signatures.
Sadly, this is almost certainly going to cause bitching on the part of
Nathan Bossart writes:
> On Tue, Feb 28, 2023 at 04:59:48PM -0500, Tom Lane wrote:
>> When I designed the Bitmapset module, I set things up so that an empty
>> Bitmapset could be represented either by a NULL pointer, or by an
>> allocated object all of whose bits are zero. I've recently come to
On Tue, Feb 28, 2023 at 08:36:03PM -0800, Nathan Bossart wrote:
> On Sun, Feb 26, 2023 at 12:12:27PM -0800, Andres Freund wrote:
>> Partially I just want something that can easily be searched for, that can
>> have
>> comments attached to it documenting why what it is doing is safe.
>>
>> It'd
On Tue, Feb 28, 2023 at 08:15:37PM +0100, Alvaro Herrera wrote:
> Since nobody liked the idea of listing the constraints in psql \d's
> footer, I changed \d+ so that the "not null" column shows the name of
> the constraint if there is one, or the string "(primary key)" if the
> attnotnull marking
On Wed, 2023-03-01 at 16:06 -0500, Robert Haas wrote:
> To be fair, it's possible that there's no solution to this class of
> problems that *doesn't* suck, but I think we should look a lot harder
> before coming to that conclusion.
Fair enough. The situation is bad enough that I'm willing to
On Wed, Mar 1, 2023 at 3:03 PM Gregory Stark (as CFM)
wrote:
>
>It looks like this patch needs a (perhaps trivial) rebase.
Attached is a rebased patch.
>It sounds like all the design questions are resolved so perhaps this
>can be set to Ready for Committer once it's rebased?
There
Hi,
During a recent code review, I noticed a lot of 'struct
LogicalDecodingContext' usage.
There are many function prototypes where the params are (for no
apparent reason to me) a mixture of structs and typedef structs.
AFAICT just by pre-declaring the typedef struct
LogicalDecodingContext, all
On 01/03/2023 09:33, Andres Freund wrote:
On 2023-02-21 17:33:31 +0100, Alvaro Herrera wrote:
On 2023-Feb-21, Heikki Linnakangas wrote:
+static BlockNumber
+BulkExtendSharedRelationBuffered(Relation rel,
+SMgrRelation
smgr,
+
On Wed, 1 Mar 2023 20:34:08 +0100
Tomas Vondra wrote:
> On 3/1/23 19:09, Jehan-Guillaume de Rorthais wrote:
> > On Wed, 1 Mar 2023 18:48:40 +0100
> > Jehan-Guillaume de Rorthais wrote:
> > ...
> >> You'll find some intermediate stats I already collected in attachment:
> >>
> >> * break 1, 2
On Tue, Feb 28, 2023 at 1:59 PM Tom Lane wrote:
> I also discovered that nodeAppend.c is relying on bms_del_members
> not reducing a non-empty set to NULL, because it uses the nullness
> of appendstate->as_valid_subplans as a state boolean.
I seem to recall that Deep and I tripped into this
Hi,
On 2023-03-01 16:21:32 -0500, Andrew Dunstan wrote:
> Perhaps the latest version will be more to your taste.
I'll check it out.
> This is now working
> on my MSVC test rig (WS2019, VS2019, Strawberry Perl), including TAP tests.
> I do get a whole lot of annoying messages like this:
>
>
On Wed, Mar 1, 2023 at 11:55 AM Jim Jones wrote:
> On 01.03.23 17:13, Kirk Wolak wrote:
>
> Thanks, corrected, and confirmed Unix line endings.
> FWIW, the simplest way to test it is with this command (I usually get it
> wrong on the first guess)
>
> \set PROMPT1 %T ' ' :PROMPT1
>
> Kirk
>
>
On 2023-02-23 Th 10:58, Andres Freund wrote:
On 2023-02-23 06:27:23 -0500, Andrew Dunstan wrote:
On 2023-02-22 We 20:20, Andres Freund wrote:
There is work to do to make sure we pick up the right log files, and maybe
adjust a module or two. I have adopted a design where instead of trying to
On Thu, 5 Jan 2023 at 02:59, Antonin Houska wrote:
>
> vignesh C wrote:
>
> > The patch does not apply on top of HEAD as in [1], please post a rebased
> > patch:
And again...
Setting this to Waiting on Author for the moment.
Do you think this patch is likely to be ready for this release or
On Wed, Mar 1, 2023 at 1:13 PM Jeff Davis wrote:
> I don't think it's magic, as I said above. But I assume that your more
> general point is that if we take some responsibility away from the
> invoker and place it on the definer, then it creates room for new kinds
> of problems. And I agree.
>
>
On Thu, 19 Jan 2023 at 16:12, Dmitry Koval wrote:
>
> >The patch does not apply on top of HEAD ...
>
> Thanks!
> Here is a fixed version.
Sorry to say, but this needs a rebase again... Setting to Waiting on Author...
Are there specific feedback needed to make progress? Once it's rebased
if you
On Thu, Mar 2, 2023 at 9:49 AM Gregory Stark (as CFM)
wrote:
> On Mon, 20 Feb 2023 at 23:04, Thomas Munro wrote:
> >
> > Done like that in this version. This is the version I'm thinking of
> > committing, unless someone wants to argue for another level.
>
> FWIW the cfbot doesn't understand
On Mon, 20 Feb 2023 at 23:04, Thomas Munro wrote:
>
> Done like that in this version. This is the version I'm thinking of
> committing, unless someone wants to argue for another level.
FWIW the cfbot doesn't understand this patch series. I'm not sure why
but it's only trying to apply the first
> On 1 Mar 2023, at 21:04, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> Yes please!
>
>> I have occasionally wondered whether just passing the isnull argument as
>> NULL would be sufficient, so we don't need a new function.
>
> I thought about that too. I think I prefer Daniel's
On Tue, 28 Feb 2023 at 05:13, Kartyshov Ivan wrote:
>
> Below I provide the implementation of patches for the first three types.
> I propose to discuss this feature again/
Oof, that doesn't really work with the cfbot. It tries to apply all
three patches and of course the second and third fail to
On Wed, 2023-03-01 at 11:43 -0800, Jacob Champion wrote:
> I work around it by manually setting -Dextra_lib_dirs. I just tried
> doing that with ICU 72, and it worked without a patch. Hopefully that
> helps some?
Yes, works, thank you.
Obviously we'd like a little better solution so that others
On Tue, Feb 28, 2023 at 04:59:48PM -0500, Tom Lane wrote:
> When I designed the Bitmapset module, I set things up so that an empty
> Bitmapset could be represented either by a NULL pointer, or by an
> allocated object all of whose bits are zero. I've recently come to
> the conclusion that that
On Wed, 8 Feb 2023 at 15:04, Andres Freund wrote:
>
> Attached is a current, quite rough, prototype. It addresses some of the points
> raised, but far from all. There's also several XXXs/FIXMEs in it. I changed
> the file-ending to .txt to avoid hijacking the CF entry.
It looks like this patch
Hi Gregory,
On Wed, 2023-03-01 at 14:24 -0500, Gregory Stark (as CFM) wrote:
> The CFBot (http://cfbot.cputube.org/) doesn't seem to like this. It
> looks like all the Meson builds are failing, perhaps there's
> something
> particular about the test environment that is either not set up right
>
Peter Eisentraut writes:
> Yes please!
> I have occasionally wondered whether just passing the isnull argument as
> NULL would be sufficient, so we don't need a new function.
I thought about that too. I think I prefer Daniel's formulation
with the new function, but I'm not especially set on
done and updated cf entry
On Wed, 1 Mar 2023 at 20:13, Greg S wrote:
>
> This patch seems to need a rebase.
>
> I'll update the status to Waiting on Author for now. After rebasing
> please update it to either Needs Review or Ready for Committer
> depending on how simple the rebase was and
On Sun, 15 Jan 2023 at 11:44, Joseph Koshakow wrote:
>
> On Sat, Jan 14, 2023 at 4:22 PM Joseph Koshakow wrote:
> I've gone ahead and updated the patch to only look at the months field.
> I'll submit this email and patch to the Feb commitfest.
It looks like this patch needs a (perhaps
On Mon, 6 Feb 2023 at 23:48, Kyotaro Horiguchi wrote:
>
> Thank you for the comment!
>
> At Fri, 3 Feb 2023 08:42:52 +0100, Heikki Linnakangas wrote
> in
> > I want to call out this part of this patch:
Looks like this patch has received some solid feedback from Heikki and
you have a path
Looks like you have a path forward on this and it's not ready to
commit yet? In which case I'll mark it Waiting on Author?
On Fri, 13 Jan 2023 at 13:38, Andres Freund wrote:
>
> On 2023-01-13 10:36:49 +0100, Drouvot, Bertrand wrote:
>
> > I'll first look at 1).
>
> Makes sense.
>
> > And it
Thanks for the feedback and questions, Pavel!
On Fri, Feb 24, 2023 at 3:43 AM Pavel Borisov wrote:
> I have a couple of small questions:
> Can this patch also read the current GUC value if it's modified by the
> SET command, without editing config file?
If a user sets a guc like
On Wed, 1 Mar 2023 at 14:48, Jelte Fennema wrote:
> > > This looks like it needs a rebase.
>
> done
Great. Please update the CF entry to Needs Review or Ready for
Committer as appropriate :)
--
Gregory Stark
As Commitfest Manager
On 28.02.23 21:14, Daniel Gustafsson wrote:
Today we have two fairly common patterns around extracting an attr from a
cached tuple:
a = SysCacheGetAttr(OID, tuple, Anum_pg_foo_bar, );
Assert(!isnull);
a = SysCacheGetAttr(OID, tuple, Anum_pg_foo_bar, );
if (isnull)
elog(ERROR,
On Thu, 12 Jan 2023 at 03:46, Anthonin Bonnefoy
wrote:
>
>
> That would make sense. I've created a new patch with everything moved in
> pgstat_report_checkpointer().
> I did split the checkpointer flush in a pgstat_flush_checkpointer() function
> as it seemed more readable. Thought?
This patch
On Sun, Feb 26, 2023 at 7:36 PM Jeff Davis wrote:
>
> On Sun, 2023-02-26 at 09:57 -0800, Andres Freund wrote:
> > If you tell meson where to find the pkg-config file in those
> > directories it'd
> > also work. -Dpkg_config_path=...
>
> Setup is able to find it, which is good, but it seems like
On Thu, 9 Feb 2023 at 05:43, Aleksander Alekseev
wrote:
>
> >> I don't buy your argument about DO UPDATE needing to be brought into
> >> line with DO NOTHING. In any case I'm pretty sure that Tom's remarks
> >> in 2016 about a behavioral inconsistencies (which you cited) actually
> >> called for
On 3/1/23 19:09, Jehan-Guillaume de Rorthais wrote:
> On Wed, 1 Mar 2023 18:48:40 +0100
> Jehan-Guillaume de Rorthais wrote:
> ...
>> You'll find some intermediate stats I already collected in attachment:
>>
>> * break 1, 2 and 3 are from AllocSetAlloc, break 4 is from AllocSetFree.
>> * most
On 3/1/23 18:48, Jehan-Guillaume de Rorthais wrote:
> Hi Tomas,
>
> On Tue, 28 Feb 2023 20:51:02 +0100
> Tomas Vondra wrote:
>> On 2/28/23 19:06, Jehan-Guillaume de Rorthais wrote:
>>> * HashBatchContext goes up to 1441MB after 240s then stay flat until the end
>>> (400s as the last record)
On Wed, 11 Jan 2023 at 04:00, Jelte Fennema wrote:
>
> I'm working on a new patchset for my commitfest entry.
So I'll set it to "Waiting on Author" pending that new patchset...
--
Gregory Stark
As Commitfest Manager
On Wed, 1 Mar 2023 at 04:04, Andrei Zubkov wrote:
>
> Hi!
>
> I've attached a new version of a patch - rebase to the current master.
The CFBot (http://cfbot.cputube.org/) doesn't seem to like this. It
looks like all the Meson builds are failing, perhaps there's something
particular about the
On 23.02.23 19:06, Nazir Bilal Yavuz wrote:
Hi,
Thanks for the review.
On Mon, 20 Feb 2023 at 21:44, Peter Eisentraut
wrote:
I tested this a bit. It works fine. The approach makes sense to me.
The install_additional_files script could be simplified a bit. You
could use os.makedirs(dest,
On Wed, Mar 01, 2023 at 07:09:53PM +0100, Alvaro Herrera wrote:
> On 2023-Mar-01, Michael Paquier wrote:
>
>> +-- PROCESS_MAIN option
>> +VACUUM (PROCESS_MAIN FALSE) vactst;
>> +VACUUM (PROCESS_MAIN FALSE, PROCESS_TOAST FALSE) vactst;
>> +VACUUM (PROCESS_MAIN FALSE, FULL) vactst;
>>
>> Thinking
This patch seems to need a rebase.
I'll update the status to Waiting on Author for now. After rebasing
please update it to either Needs Review or Ready for Committer
depending on how simple the rebase was and whether there are open
questions to finish it.
On Tue, 28 Feb 2023 at 15:59, Gregory Stark wrote:
>
> This looks like it needs a rebase.
So I'm updating the patch to Waiting on Author
On 2023-Feb-24, Tomas Vondra wrote:
> On 2/24/23 16:14, Alvaro Herrera wrote:
> > I think a formulation of this kind has the benefit that it works after
> > BlockNumber is enlarged to 64 bits, and doesn't have to be changed ever
> > again (assuming it is correct).
>
> Did anyone even propose
On Wed, 2023-03-01 at 10:05 -0500, Robert Haas wrote:
> For this reason, these expressions are, by
> default, restricted from doing .
The hard part is defining without resorting to a bunch of
special cases, and also in a way that doesn't break a bunch of stuff.
> You earlier
> mentioned that
On 2023-Mar-01, Michael Paquier wrote:
> +-- PROCESS_MAIN option
> +VACUUM (PROCESS_MAIN FALSE) vactst;
> +VACUUM (PROCESS_MAIN FALSE, PROCESS_TOAST FALSE) vactst;
> +VACUUM (PROCESS_MAIN FALSE, FULL) vactst;
>
> Thinking a bit here. This set of tests does not make sure that the
> main relation
Hi,
Hayato Kuroda (Fujitsu) , 1 Mar 2023 Çar, 18:40
tarihinde şunu yazdı:
> Dear Melih,
>
> If we do not have to treat the case Shi pointed out[1] as code-level, I
> agreed to
> same option binary because it is simpler.
How is this an issue if we let the binary option do binary copy and not an
On Wed, 1 Mar 2023 18:48:40 +0100
Jehan-Guillaume de Rorthais wrote:
...
> You'll find some intermediate stats I already collected in attachment:
>
> * break 1, 2 and 3 are from AllocSetAlloc, break 4 is from AllocSetFree.
> * most of the non-free'd chunk are allocated since the very beginning,
Hi,
When using pg_walinspect, and calling functions like
pg_get_wal_records_info(), I often wish that the various information in
the block_ref column was separated out into columns so that I could
easily access them and pass them to various other functions to add
information -- like getting the
Hi Tomas,
On Tue, 28 Feb 2023 20:51:02 +0100
Tomas Vondra wrote:
> On 2/28/23 19:06, Jehan-Guillaume de Rorthais wrote:
> > * HashBatchContext goes up to 1441MB after 240s then stay flat until the end
> > (400s as the last record)
>
> That's interesting. We're using HashBatchContext for
1 - 100 of 156 matches
Mail list logo
