At Tue, 22 Mar 2022 20:42:37 +, Jacob Champion wrote
in
> Thanks, looks like I had some old header dependencies left over from
> several versions ago. Fixed in v9.
Thanks! Looks perfect.
> v9 contains the bare minimum but I don't think it's quite enough. How
> much of the behavior (and
On Tue, Mar 22, 2022 at 3:39 PM David Rowley wrote:
> On Thu, 17 Mar 2022 at 17:04, Corey Huinker
> wrote:
> > It seems like this effort would aid in implementing what some other
> databases implement via the QUALIFY clause, which is to window functions
> what HAVING is to aggregate functions.
Hi,
Sorry for showing up this late, but I'm a bit confused with the new situation.
Unless I'm missing something, the new situation is that the system is supposed
to prevent access to MaxBackends during s_p_l_pg_init, for reasons I totally
agree with, but without doing anything for extensions
On Tue, Mar 22, 2022 at 8:12 PM Andres Freund wrote:
> > Do you mean like this?
> > ereport(LOG,
> > /* translator: the placeholders show checkpoint options */
> > (errmsg("%s starting:%s%s%s%s%s%s%s%s",
> > restartpoint ? _("restartpoint") :
On Tue, Mar 22, 2022 at 02:42:53PM -0700, Nathan Bossart wrote:
> On Tue, Mar 22, 2022 at 04:34:05PM -0400, Robert Haas wrote:
>> Then, too, I'm not very confident about the usefulness of EXTENDED,
>> EXTERNAL, and MAIN. I think it's useful to be able to categorically
>> disable compression (as
On Fri, Mar 18, 2022 at 03:45:03PM -0700, Andres Freund wrote:
> Pushed 0001, 0002. Only change I made was to add
Thanks - is there any reason not to do the MSVC compiler warnings one, too ?
I see that it'll warn about issues with at least 3 patches (including one of
yours).
--
Justin
On Wed, Mar 23, 2022 at 10:16:34AM +0800, Julien Rouhaud wrote:
> Yeah, I thought about it but didn't rename it given your concerns about git
> history. I'm fine either way.
Oh, OK. The amount of diffs created by 0001 is still fine to grab
even with the struct rename, so let's stick with it.
--
On Tue, Mar 22, 2022 at 8:45 PM Amit Kapila wrote:
> On Tue, Mar 22, 2022 at 3:39 AM Zhihong Yu wrote:
> >
> > On Mon, Mar 21, 2022 at 3:05 PM Tom Lane wrote:
> >>
> >> Zhihong Yu writes:
> >> >> I was looking at calls to bms_free() in PG code.
> >> >> e.g.
Here's a rebased patch. I split the test into a separate patch that I
would lean to dropping. But at least it applies now.
I did look into pg_stat_get_backend_pid() and I guess it would work
but going through the stats mechanism does seem like going the long
way around since we're already looking
On Tue, Mar 22, 2022 at 3:39 AM Zhihong Yu wrote:
>
> On Mon, Mar 21, 2022 at 3:05 PM Tom Lane wrote:
>>
>> Zhihong Yu writes:
>> >> I was looking at calls to bms_free() in PG code.
>> >> e.g. src/backend/commands/publicationcmds.c line 362
>> >> bms_free(bms);
>> >> The above is just an
On Tue, Mar 22, 2022 at 11:30 PM Julien Rouhaud wrote:
> On Tue, Mar 22, 2022 at 09:37:46AM +, Niyas Sait wrote:
> > Yes, we could look into providing a build machine. Do you have any
> > reference to what the CI system looks like now for PostgresSQL and how to
> > add new workers etc.?
>
>
On Wed, 23 Mar 2022 at 11:24, David Rowley wrote:
> I think it's safer to just disable the optimisation when there are
> multiple window clauses. Multiple matching clauses are merged
> already, so it's perfectly valid to have multiple window functions,
> it's just they must share the same window
On Wed, 23 Mar 2022 at 12:50, Zhihong Yu wrote:
> The following code seems to be common between if / else blocks (w.r.t.
> wfunc_left) of find_window_run_conditions().
> It would be nice if this code can be shared.
I remember thinking about that and thinking that I didn't want to
At Wed, 23 Mar 2022 11:51:25 +0900 (JST), Kyotaro Horiguchi
wrote in
> The two places emit different outputs but the only difference is the
> delimiter between two blockrefs. (By the way, the current code forgets
> to insert a delimiter there). So even if the function took "bool
> is_waldump",
On Wed, Mar 23, 2022 at 3:23 PM Andres Freund wrote:
> On 2022-03-22 17:20:24 -0700, Andres Freund wrote:
> > I was about to propose adding headerscheck / cpluspluscheck to the CI file
> > so
> > that cfbot can catch future issues.
>
> The attached patch does so, with ICU disabled to avoid the
At Tue, 22 Mar 2022 11:00:06 -0700, Andres Freund wrote in
> Hi,
>
> On 2022-03-22 21:57:51 +0530, Bharath Rupireddy wrote:
> > > This is probably close to an order of magnitude slower than pg_waldump
> > > --stats. Which imo renders this largely useless.
> >
> > Yeah that's true. Do you
Hi,
On 2022-03-22 17:20:24 -0700, Andres Freund wrote:
> I was about to propose adding headerscheck / cpluspluscheck to the CI file so
> that cfbot can catch future issues.
The attached patch does so, with ICU disabled to avoid the problems discussed
in the thread. Example run:
On Wed, Mar 23, 2022 at 12:54 AM Alvaro Herrera wrote:
>
> On 2022-Mar-19, Tomas Vondra wrote:
>
> > @@ -174,7 +182,13 @@ ALTER PUBLICATION noinsert SET (publish = 'update,
> > delete');
> >
> > Add some tables to the publication:
> >
> > -ALTER PUBLICATION mypublication ADD TABLE
Hi,
On Wed, Mar 23, 2022 at 11:03:46AM +0900, Michael Paquier wrote:
>
> Pushing forward with 0001 by the end of the CF is the part that has no
> controversy IMO, and I have no objections to it. Now, after looking
> at this part, I found a few things, as of:
> - HbaToken, the set of elements in
On Tue, Mar 22, 2022 at 09:38:00PM +0800, Julien Rouhaud wrote:
> On Tue, Mar 22, 2022 at 03:21:20PM +0300, Aleksander Alekseev wrote:
>> Since v3-0002 adds a new view and alters pg_proc.dat shouldn't it also
>> increase CATALOG_VERSION_NO? Not sure if we generally do this in the
>> patches or
I wrote:
> Andres Freund writes:
>> There's also
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jabiru=2022-03-22%2022%3A25%3A26
>> that started failing with
>> ../../preproc/ecpg --regression -I./../../include -I. -o test1.c test1.pgc
>> test1.pgc:12: ERROR: syntax error at or near
On Wed, Mar 23, 2022 at 12:44:09PM +1300, Thomas Munro wrote:
> On Mon, Mar 21, 2022 at 12:46 PM Thomas Munro wrote:
> > On Mon, Mar 21, 2022 at 12:23 PM Thomas Munro
> > wrote:
> > > On Mon, Mar 21, 2022 at 1:58 AM Matthias van de Meent
> > > wrote:
> > > > Additionally, are there plans to
On Thu, Mar 17, 2022 at 3:36 AM Andres Freund wrote:
> I've attached a substantially improved version of the shared memory stats
> patch.
...
> - lot of the pg_stat_ views like bgwriter, pg_stat_database have zero
> coverage today
Attached are some tests including tests that reset of stats
On Tue, Mar 22, 2022 at 04:13:47PM -0700, Andres Freund wrote:
> Just skimming this thread quickly, I really have no idea what this is trying
> to achieve and the commit message doesn't help either... I didn't read the
> referenced thread, but I shouldn't have to, to get a basic idea.
Ah, my
On Wed, 23 Mar 2022 at 01:22, Maxim Orlov wrote:
> Hi!
>
> Here is v24. Changes are:
> - correct commit messages for 0001 and 0002
> - use uint64 for SLRU page numbering instead of int64 in v23
> - fix code formatting and indent
> - and minor fixes in slru.c
>
> Reviews are very welcome!
>
Hi,
I was about to propose adding headerscheck / cpluspluscheck to the CI file so
that cfbot can catch future issues. Unfortunately running cpluspluscheck with
ICU enabled is, um, not fun: There's 30k lines of error output.
/home/andres/src/postgresql/src/tools/pginclude/cpluspluscheck
On 3/22/22 20:07, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/22/22 18:18, Tom Lane wrote:
>>> Now, if our attitude to the OAT hooks is that we are going to
>>> sprinkle some at random and whether they are useful is someone
>>> else's problem, then maybe these are not interesting concerns.
Andrew Dunstan writes:
> On 3/22/22 18:18, Tom Lane wrote:
>> Now, if our attitude to the OAT hooks is that we are going to
>> sprinkle some at random and whether they are useful is someone
>> else's problem, then maybe these are not interesting concerns.
> So this was a pre-existing problem
On 3/22/22 18:31, Tom Lane wrote:
> I wrote:
>> That patch is 0-for-three on my buildfarm animals.
> ... the reason being that they use -Werror, and this patch spews
> a bunch of warnings. This is not acceptable, especially not in
> the middle of a CF when other people are trying to get work
On 3/22/22 18:18, Tom Lane wrote:
> Andrew Dunstan writes:
>> Fixed
> Now that we got past the hard failures, we can see that the test
> falls over with (some?) non-default encodings, as for instance
> here:
>
>
On Tue, Mar 22, 2022 at 3:24 PM David Rowley wrote:
> On Thu, 26 Aug 2021 at 14:54, Andy Fan wrote:
> >
> > On Thu, Aug 19, 2021 at 2:35 PM David Rowley
> wrote:
> > >
> > > On Thu, 19 Aug 2021 at 00:20, Andy Fan
> wrote:
> > > > In the current master, the result is:
> > > >
> > > > empno |
Andres Freund writes:
> There's also
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jabiru=2022-03-22%2022%3A25%3A26
> that started failing with
> ../../preproc/ecpg --regression -I./../../include -I. -o test1.c test1.pgc
> test1.pgc:12: ERROR: syntax error at or near "int"
> with this
On Mon, Mar 21, 2022 at 12:46 PM Thomas Munro wrote:
> On Mon, Mar 21, 2022 at 12:23 PM Thomas Munro wrote:
> > On Mon, Mar 21, 2022 at 1:58 AM Matthias van de Meent
> > wrote:
> > > Additionally, are there plans to validate commits of the main branch
> > > before using them as a base for CF
Justin Pryzby writes:
> If I'm not wrong, this is still causing issues at least on cfbot/windows, even
> since f0206d99.
That's probably a variant of the encoding dependency I described
upthread.
regards, tom lane
Andres Freund writes:
> On 2022-03-22 16:55:49 -0400, Tom Lane wrote:
>> BTW, I've had a bee in my bonnet for a long time about whether some of
>> nbtree's scan setup work could be done once during planning, rather than
>> over again during each indexscan start.
> It does show up in
Hi,
On 2022-03-22 18:31:39 -0400, Tom Lane wrote:
> I wrote:
> > That patch is 0-for-three on my buildfarm animals.
>
> ... the reason being that they use -Werror, and this patch spews
> a bunch of warnings. This is not acceptable, especially not in
> the middle of a CF when other people are
Hi,
On 2022-03-22 16:06:40 -0700, Nathan Bossart wrote:
> On Thu, Mar 17, 2022 at 04:45:28PM -0700, Nathan Bossart wrote:
> > I think this one requires some more work, and it needn't be a priority for
> > v15, so I've adjusted the commitfest entry to v16 and moved it to the next
> > commitfest.
>
If I'm not wrong, this is still causing issues at least on cfbot/windows, even
since f0206d99.
https://cirrus-ci.com/task/5266352712712192
https://cirrus-ci.com/task/5061218867085312
https://cirrus-ci.com/task/5663822005403648
https://cirrus-ci.com/task/5744257246953472
Hi,
On 2022-03-22 18:41:45 -0400, Tom Lane wrote:
> Mark Dilger writes:
> >> On Mar 22, 2022, at 3:20 PM, Andres Freund wrote:
> >> Seems like it might actually be good to test that object access hooks work
> >> well in a parallel worker. How about going the other way and explicitly
> >>
On Thu, Mar 17, 2022 at 04:45:28PM -0700, Nathan Bossart wrote:
> I think this one requires some more work, and it needn't be a priority for
> v15, so I've adjusted the commitfest entry to v16 and moved it to the next
> commitfest.
Here is a new patch. The main differences from v3 are in
Hi,
On 2022-03-22 16:55:49 -0400, Tom Lane wrote:
> 4. I find each of the above ideas to be far more attractive than
> optimizing SELECT-DISTINCT-that-matches-an-index, so I don't really
> understand why the current patchsets seem to be driven largely
> by that single use-case.
It's something
On Tue, 2022-03-22 at 14:48 -0700, samay sharma wrote:
> Thank you for porting this on top of the pluggable auth methods API.
> I've addressed the feedback around other backend changes in my latest
> patch, but the client side changes still remain. I had a few
> questions to understand them
Mark Dilger writes:
>> On Mar 22, 2022, at 3:20 PM, Andres Freund wrote:
>> Seems like it might actually be good to test that object access hooks work
>> well in a parallel worker. How about going the other way and explicitly
>> setting
>> force_parallel_mode = disabled for parts of the test
On Thu, 17 Mar 2022 at 17:04, Corey Huinker wrote:
> It seems like this effort would aid in implementing what some other databases
> implement via the QUALIFY clause, which is to window functions what HAVING is
> to aggregate functions.
> example:
>
> On Mar 22, 2022, at 3:20 PM, Andres Freund wrote:
>
> Seems like it might actually be good to test that object access hooks work
> well in a parallel worker. How about going the other way and explicitly
> setting
> force_parallel_mode = disabled for parts of the test and to enabled for
>
On Wed, 16 Mar 2022 at 10:24, Greg Stark wrote:
>
> This looks like an awesome addition.
Thanks
> I have one technical questions...
>
> Is it possible to actually transform the row_number case into a LIMIT
> clause or make the planner support for this case equivalent to it (in
> which case we
I wrote:
> That patch is 0-for-three on my buildfarm animals.
... the reason being that they use -Werror, and this patch spews
a bunch of warnings. This is not acceptable, especially not in
the middle of a CF when other people are trying to get work done.
Please revert.
On Thu, 26 Aug 2021 at 14:54, Andy Fan wrote:
>
> On Thu, Aug 19, 2021 at 2:35 PM David Rowley wrote:
> >
> > On Thu, 19 Aug 2021 at 00:20, Andy Fan wrote:
> > > In the current master, the result is:
> > >
> > > empno | salary | c | dr
> > > ---++---+
> > > 8 | 6000 | 4
Andrew Dunstan writes:
> I have committed the first of these. That will break the cfbot for this
> and the json_table patches. The remainder should be committed in the
> following days.
That patch is 0-for-three on my buildfarm animals.
regards, tom lane
Hi,
On 2022-03-22 13:47:27 -0400, Andrew Dunstan wrote:
> OK, I have pushed that.
Seems like it might actually be good to test that object access hooks work
well in a parallel worker. How about going the other way and explicitly setting
force_parallel_mode = disabled for parts of the test and to
Andrew Dunstan writes:
> Fixed
Now that we got past the hard failures, we can see that the test
falls over with (some?) non-default encodings, as for instance
here:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion=2022-03-22%2020%3A23%3A13
I can replicate that by running the test
On 3/5/22 09:39, Andrew Dunstan wrote:
>
> here's a new set of patches, omitting the GUC patch and with the
> beginnings of some message cleanup - there's more work to do there.
>
>
>
> This patchset restores the RETURNING clause for JSON() and JSON_SCALAR()
> but without the GUC
>
>
I have
>Can the leader pass a callback that checks PVIndStats to ambulkdelete
>an amvacuumcleanup callbacks? I think that in the passed callback, the
>leader checks if the number of processed indexes and updates its
>progress information if the current progress needs to be updated.
Hi Jacob,
Thank you for porting this on top of the pluggable auth methods API. I've
addressed the feedback around other backend changes in my latest patch, but
the client side changes still remain. I had a few questions to understand
them better.
(a) What specifically do the client side changes
On Tue, Mar 22, 2022 at 04:34:05PM -0400, Robert Haas wrote:
> We seem to have a shortage of "others" showing up with opinions on
> this topic, but I guess I'm not very confident about the general
> utility of such a setting. Just to be clear, I'm also not very
> confident about the usefulness of
On 3/22/22 11:27, Andrew Dunstan wrote:
> On 3/22/22 10:53, Alvaro Herrera wrote:
>> On 2022-Mar-22, Andrew Dunstan wrote:
>>
>>> I'm planning on pushing the functions patch set this week and json-table
>>> next week.
>> I think it'd be a good idea to push the patches one by one and let a day
>>
Peter Geoghegan writes:
> Like many difficult patches, the skip scan patch is not so much
> troubled by problems with the implementation as it is troubled by
> *ambiguity* about the design. Particularly concerning how skip scan
> meshes with existing designs, as well as future designs --
>
On Mon, Mar 21, 2022 at 2:23 PM Robert Haas wrote:
> On Mon, Mar 21, 2022 at 11:21 AM Dilip Kumar wrote:
> > I tried to debug the case but I realized that somehow
> > CHECK_FOR_INTERRUPTS() is not calling the
> > AcceptInvalidationMessages() and I could not find the same while
> > looking into
On Tue, 2022-03-22 at 13:32 +0900, Kyotaro Horiguchi wrote:
> At Fri, 18 Mar 2022 16:38:57 +0900 (JST), Kyotaro Horiguchi
> wrote in
> >
> > fe-secure-common.c doesn't need netinet/in.h.
> >
> >
> > +++ b/src/include/utils/inet.h
> > ..
> > +#include "common/inet-common.h"
> >
> > I'm not
On 3/22/22 14:01, Tom Lane wrote:
> Andrew Dunstan writes:
>> OK, I have pushed that.
> It seems like you could remove the NO_INSTALLCHECK restriction
> too. You already removed the comment defending it, and it
> seems to work fine as an installcheck now if I remove that
> locally.
>
> Other
On Tue, Mar 22, 2022 at 2:34 PM Andres Freund wrote:
> IMO it's pretty clear that having "duelling" patches below one CF entry is a
> bad idea. I think they should be split, with inactive approaches marked as
> returned with feeback or whatnot.
I have the impression that this thread is getting
On Thu, Mar 17, 2022 at 4:05 PM Nathan Bossart wrote:
> On Thu, Mar 17, 2022 at 01:04:17PM -0400, Robert Haas wrote:
> > Right, so perhaps the ultimate thing here would be a more fine-grained
> > knob than SET STORAGE EXTERNAL -- something that allows you to specify
> > that you want to compress
> On Mon, Mar 21, 2022 at 06:34:09PM -0700, Andres Freund wrote:
>
> > I don't mind having all of the alternatives under the same CF item, only
> > one being tested seems to be only a small limitation of cfbot.
>
> IMO it's pretty clear that having "duelling" patches below one CF entry is a
> bad
On 2022-Mar-19, Tomas Vondra wrote:
> @@ -174,7 +182,13 @@ ALTER PUBLICATION noinsert SET (publish = 'update,
> delete');
>
> Add some tables to the publication:
>
> -ALTER PUBLICATION mypublication ADD TABLE users, departments;
> +ALTER PUBLICATION mypublication ADD TABLE users
On Tue, Mar 22, 2022 at 3:01 PM Andres Freund wrote:
> We clearly already know how to compute whether a lock is "included" in
> something we already hold - after all ProcSleep() successfully does so.
>
> Isn't it a pretty trivial test? Seems like it'd boil down to something like
I don't mind you
On 2022-03-22 13:15:34 -0500, David Christensen wrote:
> > On Mar 21, 2022, at 7:53 PM, Tom Lane wrote:
> > If we'd done it like this from the beginning, it'd have been
> > great, but retrofitting it now is a lot less appealing.
>
> Yeah, agreed on this. As far as I’m concerned we can reject.
Hi,
On 2022-03-22 14:20:55 -0400, Robert Haas wrote:
> On Tue, Mar 22, 2022 at 1:43 PM Andres Freund wrote:
> > When LockAcquireExtended(dontWait=false) acquires a lock where we already
> > hold
> > stronger lock and somebody else is also waiting for that lock, it goes
> > through
> > a fairly
So I've been wondering about this block at the bottom of XLogWrite:
/*
* Make sure that the shared 'request' values do not fall behind the
* 'result' values. This is not absolutely essential, but it saves some
* code in a couple of places.
*/
{
On Tue, Mar 22, 2022 at 1:43 PM Andres Freund wrote:
> When LockAcquireExtended(dontWait=false) acquires a lock where we already hold
> stronger lock and somebody else is also waiting for that lock, it goes through
> a fairly circuitous path to acquire the lock:
>
> A conflicting lock is
> On Mar 21, 2022, at 7:53 PM, Tom Lane wrote:
>
> Andres Freund writes:
>> My impression is that there's not a lot of enthusiasm for the concept? If
>> that's true we maybe ought to mark the CF entry as rejected?
>
> Yeah, I'm kind of leaning that way too. I don't see how we can
>
On Mon, Mar 21, 2022 at 9:32 PM Mark Dilger
wrote:
> [ new patch version ]
This patch adds three new arguments to processSQLNamePattern() and
documents one of them. It adds three new parameters to
patternToSQLRegex() as well, and documents none of them. I think that
the text of the comment might
Andrew Dunstan writes:
> OK, I have pushed that.
It seems like you could remove the NO_INSTALLCHECK restriction
too. You already removed the comment defending it, and it
seems to work fine as an installcheck now if I remove that
locally.
Other nitpicks:
* the IsParallelWorker test could use a
Hi,
On 2022-03-22 21:57:51 +0530, Bharath Rupireddy wrote:
> On Sat, Mar 19, 2022 at 5:18 AM Andres Freund wrote:
> > On 2022-03-17 13:25:35 +0530, Bharath Rupireddy wrote:
> > > +--
> > > +-- pg_get_raw_wal_record()
> >
> > What is raw about the function?
>
> It right now gives data starting
On 3/22/22 13:08, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/22/22 12:58, Tom Lane wrote:
>>> I only suggested removing the error check in _PG_init, not
>>> changing the way the test works.
>> Mark and I discussed this offline, and decided there was no requirement
>> for the module to be
Hi,
When LockAcquireExtended(dontWait=false) acquires a lock where we already hold
stronger lock and somebody else is also waiting for that lock, it goes through
a fairly circuitous path to acquire the lock:
A conflicting lock is detected: if (lockMethodTable->conflictTab[lockmode] &
Andrew Dunstan writes:
> On 3/22/22 12:58, Tom Lane wrote:
>> I only suggested removing the error check in _PG_init, not
>> changing the way the test works.
> Mark and I discussed this offline, and decided there was no requirement
> for the module to be preloaded. Do you have a different
> On Mar 22, 2022, at 9:58 AM, Tom Lane wrote:
>
>> Ok, done as you suggest:
>
> I only suggested removing the error check in _PG_init, not
> changing the way the test works.
I should have been more explicit and said, "done as y'all suggest". The "To"
line of that email was to you and
On 3/22/22 12:58, Tom Lane wrote:
> Mark Dilger writes:
>> On Mar 22, 2022, at 9:33 AM, Tom Lane wrote:
>>> As a quick-n-dirty fix to avoid reverting the entire test module,
>>> perhaps just delete this error check for now.
>> Ok, done as you suggest:
> I only suggested removing the error
Mark Dilger writes:
> On Mar 22, 2022, at 9:33 AM, Tom Lane wrote:
>> As a quick-n-dirty fix to avoid reverting the entire test module,
>> perhaps just delete this error check for now.
> Ok, done as you suggest:
I only suggested removing the error check in _PG_init, not
changing the way the
> On Mar 22, 2022, at 9:33 AM, Tom Lane wrote:
>
> Andrew Dunstan writes:
>> On 3/22/22 11:26, Mark Dilger wrote:
>>> culicidae is complaining:
>>> 2022-03-22 14:53:27.198 UTC [2167008][not initialized][:0] FATAL:
>>> test_oat_hooks must be loaded via shared_preload_libraries
>
>> That
Andrew Dunstan writes:
> On 3/22/22 11:26, Mark Dilger wrote:
>> culicidae is complaining:
>> 2022-03-22 14:53:27.198 UTC [2167008][not initialized][:0] FATAL:
>> test_oat_hooks must be loaded via shared_preload_libraries
> That seems quite weird. I'm not sure how it's getting loaded at all if
On Sat, Mar 19, 2022 at 5:18 AM Andres Freund wrote:
>
> Hi,
>
> First look at this patch, so I might be repeating stuff already commented on /
> discussed.
Thanks for taking a look at the patch.
> On 2022-03-17 13:25:35 +0530, Bharath Rupireddy wrote:
> > +--
> > +-- pg_get_raw_wal_record()
>
Mark Dilger writes:
> The problem is coming from the REGRESS_exec_check_perms, which was included
> in the patch to demonstrate when the other hooks fired relative to the
> ExecutorCheckPerms_hook, but since it is causing problems, I can submit a
> patch with that removed. Give me a couple
> On Mar 22, 2022, at 9:11 AM, Mark Dilger wrote:
>
> Give me a couple minutes
v1-0001-Fix-build-farm-failures-in-test_oat_hooks.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Tomas Vondra писал 2022-03-22 15:28:
On 3/22/22 01:49, Andres Freund wrote:
On 2022-01-17 15:27:53 +0300, Alexander Pyhalov wrote:
Alexander Pyhalov писал 2022-01-17 15:26:
Updated patch.
Sorry, missed attachment.
Needs another update: http://cfbot.cputube.org/patch_37_3369.log
Marked as
On 2022-Mar-22, Tom Lane wrote:
> I looked briefly at 0001, and I've got to say that I disagree with
> your decision to rearrange the representation of the local LogwrtResult
> copy. It clutters the patch tremendously and makes it hard to
> understand what the actual functional change is.
> On Mar 22, 2022, at 9:09 AM, Andrew Dunstan wrote:
>
> If I can't com up with a very quick fix I'll revert it.
The problem is coming from the REGRESS_exec_check_perms, which was included in
the patch to demonstrate when the other hooks fired relative to the
ExecutorCheckPerms_hook, but
On 3/22/22 12:02, Tom Lane wrote:
> Andrew Dunstan writes:
>> That seems quite weird. I'm not sure how it's getting loaded at all if
>> not via shared_preload_libraries
> Some other animals are showing this:
>
> diff -U3
>
Andrew Dunstan writes:
> That seems quite weird. I'm not sure how it's getting loaded at all if
> not via shared_preload_libraries
Some other animals are showing this:
diff -U3
/home/postgres/pgsql/src/test/modules/test_oat_hooks/expected/test_oat_hooks.out
Hi Andres,
Rebased it.
I also removed the temp installation task and
used NoDefaultCurrentDirectoryInExePath env variable instead.
Best,
Melih
From e8a1dae0ec10efd8a967070e0d412d2bf875fa93 Mon Sep 17 00:00:00 2001
From: Melih Mutlu
Date: Mon, 21 Feb 2022 14:46:05 +0300
Subject: [PATCH] Added
On Tue, Mar 22, 2022 at 11:42 AM Andres Freund wrote:
> I might have missed it because I just skimmed the patch. But I still think it
> should contain a comment detailing why accessing catalogs from another
> database is safe in this instance, and perhaps a comment or three in places
> that could
On Mon, Mar 21, 2022 at 8:52 PM Andres Freund wrote:
> I noticed this still has an open CF entry:
> https://commitfest.postgresql.org/37/3296/
> I assume it can be marked as committed?
Yeah, done now. But don't forget that we still need to do something on
the "wrong fds used for refilenodes
On 3/22/22 11:26, Mark Dilger wrote:
>
>> On Mar 22, 2022, at 8:14 AM, Julien Rouhaud wrote:
>>
>> Hi,
>>
>> On Tue, Mar 22, 2022 at 10:41:05AM -0400, Andrew Dunstan wrote:
>>> Pushed with slight adjustments - the LOAD was unnecessary as was the
>>> setting of client_min_messages - the latter
Hi,
On 2022-03-22 11:23:16 -0400, Robert Haas wrote:
> From 116bcdb6174a750b7ef7ae05ef6f39cebaf9bcf5 Mon Sep 17 00:00:00 2001
> From: Robert Haas
> Date: Tue, 22 Mar 2022 11:22:26 -0400
> Subject: [PATCH v1] Add new block-by-block strategy for CREATE DATABASE.
I might have missed it because I
On Sat, Mar 19, 2022 at 11:43 AM Fabien COELHO wrote:
>
> Hi Sami,
>
> > Pgbench is a simple benchmark tool by design, and I wonder if adding
> > a multiconnect feature will cause pgbench to be used incorrectly.
>
> Maybe, but I do not see how it would be worse that what pgbench already
>
On Mon, Mar 21, 2022 at 2:41 PM Dagfinn Ilmari Mannsåker
wrote:
> This is no longer the accurate. How about something like like "Specifies
> details of the chosen compression method"?
Good catch. v5 attached.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi,
On 2022-03-22 18:09:08 +1300, Thomas Munro wrote:
> On Tue, Mar 22, 2022 at 4:14 PM Andres Freund wrote:
> > The problem looks to be that pg_dumpall doesn't have a dependency on OBJs,
> > which in turn is what contains the dependency on WIN32RES, which in turn
> > contains win32ver.o. So the
On 3/22/22 10:55, Daniel Gustafsson wrote:
>> On 22 Mar 2022, at 16:31, Andrew Dunstan wrote:
>> I'm planning on pushing the functions patch set this week and json-table
>> next week.
> My comments from 30827b3c-edf6-4d41-bbf1-298181874...@yesql.se are yet to be
> addressed (or at all responded
On 3/22/22 10:53, Alvaro Herrera wrote:
> On 2022-Mar-22, Andrew Dunstan wrote:
>
>> I'm planning on pushing the functions patch set this week and json-table
>> next week.
> I think it'd be a good idea to push the patches one by one and let a day
> between each. That would make it easier to
> On Mar 22, 2022, at 8:14 AM, Julien Rouhaud wrote:
>
> Hi,
>
> On Tue, Mar 22, 2022 at 10:41:05AM -0400, Andrew Dunstan wrote:
>>
>> Pushed with slight adjustments - the LOAD was unnecessary as was the
>> setting of client_min_messages - the latter would have made buildfarm
>> animals
1 - 100 of 150 matches
Mail list logo
