On Fri, Mar 25, 2022 at 12:50 PM houzj.f...@fujitsu.com
wrote:
>
> Attach the new version patch with this change.
>
Few comments:
=
1. I think we can move the keep_alive check after the tracklag record
check to keep it consistent with another patch [1].
2. Add the comment about th
On Fri, Mar 18, 2022 at 3:30 PM Dongming Liu wrote:
> So it's OK for a segment to be in a bin that suggests that it has more
>> consecutive free pages than it really does. But it's NOT ok for a
>> segment to be in a bin that suggests it has fewer consecutive pages
>> than it really does. If dsa_f
On Sun, Mar 27, 2022 at 05:52:22PM +0800, Julien Rouhaud wrote:
> I didn't like the various suggestions, as it would mean to scatter the tests
> all over the place. The whole point of those views is indeed to check the
> current content of a file without applying the configuration change (not on
>
On Mon, Mar 28, 2022 at 04:20:07PM +0900, Michael Paquier wrote:
> See the attached, for reference, but it would fail with EXEC_BACKEND
> on WIN32.
Ditto.
--
Michael
From 69e02734fd0199ba02cc34bc468b04584bdf0efd Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Mon, 28 Mar 2022 16:20:40 +0900
Hi,
On Mon, Mar 28, 2022 at 04:20:07PM +0900, Michael Paquier wrote:
>
> > Note that those tests fail on Windows (and I'm assuming on EXEC_BACKEND
> > builds), as they're testing invalid files which by definition prevent any
> > further connection attempt. I'm not sure what would be best to do he
On Mon, Mar 28, 2022 at 8:14 PM Dongming Liu wrote:
> On Fri, Mar 18, 2022 at 3:30 PM Dongming Liu wrote:
>> I'm trying to move segments into appropriate bins in dsa_free().
>> In 0001-Re-bin-segment-when-dsa-memory-is-freed.patch, I extract
>> the re-bin segment logic into a separate function ca
Hello,
On 2022-Mar-27, Tatsuo Ishii wrote:
> After:
> interval_start num_transactions sum_latency sum_latency_2 min_latency
> max_latency
> { failures | serialization_failures deadlock_failures } [ sum_lag sum_lag_2
> min_lag max_lag [ skipped ] ] [ retried retries ]
You're showing an indent
On Mon, Mar 28, 2022 at 03:43:41PM +0800, Julien Rouhaud wrote:
> On Mon, Mar 28, 2022 at 04:20:07PM +0900, Michael Paquier wrote:
>> We could use a failure path for each psql command rather than a SKIP
>> block, as you told me, if the psql fails and check that we get some
>> error strings related
At Mon, 28 Mar 2022 10:01:05 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 25 Mar 2022 13:26:05 +0100, Alvaro Herrera
> wrote in
> > Pushed this, backpatching to 14 and 13. It would have been good to
> > backpatch further, but there's an (textually trivial) merge conflict
> > related to
On Mon, Mar 28, 2022 at 05:02:14PM +0900, Michael Paquier wrote:
> On Mon, Mar 28, 2022 at 03:43:41PM +0800, Julien Rouhaud wrote:
> >
> > Ok. We could still keep the tests for the valid lines part though?
>
> With the SQLs modified as below, this part is less interesting.
Ok.
> > Do you mean so
> On 28 Mar 2022, at 00:44, Daniel Gustafsson wrote:
> I'll take a look at fixing up the test in this patch tomorrow.
Fixing up the switch_server_cert() calls and using default_ssl_connstr makes
the test pass for me. The required fixes are in the supplied 0004 diff, I kept
them separate to allo
Thanks for all the feedback everyone. I'll try to send a new patch
later this week that includes user facing docs and a simplified API.
For now a few responses:
> Yeah. We need to choose a name for these new function(s) that is
> sufficiently different from "PQcancel" that people won't expect the
At Sun, 27 Mar 2022 20:32:45 +0200, Erik Rijkers wrote in
> On master I got a FailedAssertion("HaveRegisteredOrActiveSnapshot()"
> on an assert-enabled instance and with (I think) data over a certain
> length.
>
> I whittled it down to the attached bash (careful - it drops stuff).
> It has 5 tsv
I have updated the patch addressing the review comments, but I didn't moved
this code block into VERBOSE mode, to keep consistency with
`show_incremental_sort_info`:
https://github.com/postgres/postgres/blob/d4ba8b51c76300f06cc23f4d8a41d9f7210c4866/src/backend/commands/explain.c#L2890
Please r
Hi hackers,
> Here is v30.
I took another look at the patchset. Personally I don't think it will get much
better than it is now. I'm inclined to change the status of the CF entry to
"Ready for Committer" unless anyone disagrees.
cfbot reports a problem with t/013_partition.pl but the test seems
On 3/27/22 19:14, Tom Lane wrote:
> I wrote:
>>> Andres Freund writes:
There's also
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jabiru&dt=2022-03-22%2022%3A25%3A26
that started failing with
../../preproc/ecpg --regression -I./../../include -I. -o test1.c test1.pgc
On Monday, March 28, 2022 3:08 PM Amit Kapila wrote:
>
> On Fri, Mar 25, 2022 at 12:50 PM houzj.f...@fujitsu.com
> wrote:
> >
> > Attach the new version patch with this change.
> >
>
> Few comments:
Thanks for the comments.
> =
> 1. I think we can move the keep_alive check aft
On Sun, Mar 27, 2022 at 12:06 PM Justin Pryzby wrote:
> Maybe it should take an argument which specifies the default algorithm to use
> for input of a numeric "level". And reject such input if not specified, since
> wal_compression has never taken a "level", so it's not useful or desirable to
> h
Daniel Gustafsson писал 2022-03-22 11:43:
On 22 Mar 2022, at 04:48, Andres Freund wrote:
docs fail to build:
https://cirrus-ci.com/task/5556234047717376?logs=docs_build#L349
Ugh, that one was on me and not the original author. Fixed.
+data initialization. It is vital that any event t
On 3/16/22 00:00, Justin Pryzby wrote:
> On Mon, Mar 14, 2022 at 05:23:54PM -0400, Robert Haas wrote:
>> On Fri, Jan 21, 2022 at 1:31 PM Tomas Vondra
>> wrote:
>>> [ new patch ]
>>
>> This patch is originally by Justin. The latest version is by Tomas. I
>> think the next step is for Justin to say
On Sun, Mar 27, 2022 at 1:00 PM James Coleman wrote:
> So "undocumented concept" is just not accurate, and so I don't see it
> as a valid reason to reject the patch.
I mean, I think it's pretty accurate. The fact that you can point to a
few uses of the terms "table rewrite" and "table scan" in th
Alvaro Herrera writes:
>> After:
>> interval_start num_transactions sum_latency sum_latency_2 min_latency
>> max_latency
>> { failures | serialization_failures deadlock_failures } [ sum_lag sum_lag_2
>> min_lag max_lag [ skipped ] ] [ retried retries ]
> I think that the explanatory paragraph i
Andrew Dunstan writes:
> On 3/27/22 19:14, Tom Lane wrote:
>> What's worse, I'm unable to replicate the failure on an OpenBSD 7.0
>> system here. So there's something odd about jabiru's build
>> environment; but what?
> It's hard to see how this could be caused by the OS environment. Maybe a
> f
On 28.03.22 12:46, Aleksander Alekseev wrote:
Personally I don't have a strong opinion here. Merging the patch sooner will
allow us to move toward 64-bit XIDs faster (e.g. to gather the feedback from
the early adopters, allow the translators to do their thing earlier, etc).
Merging it later will
On Mon, Mar 28, 2022 at 9:30 AM Robert Haas wrote:
>
> On Sun, Mar 27, 2022 at 1:00 PM James Coleman wrote:
> > So "undocumented concept" is just not accurate, and so I don't see it
> > as a valid reason to reject the patch.
>
> I mean, I think it's pretty accurate. The fact that you can point to
On Fri, Mar 25, 2022 at 7:23 PM Tom Lane wrote:
>
> Ashutosh Bapat writes:
> > All these functions are too low level to be helpful to know. Knowing
> > the caller might actually give a hint as to where the unknown node
> > originated from. We may get that from the stack trace if that's
> > availa
On 3/28/22 09:35, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/27/22 19:14, Tom Lane wrote:
>>> What's worse, I'm unable to replicate the failure on an OpenBSD 7.0
>>> system here. So there's something odd about jabiru's build
>>> environment; but what?
>> It's hard to see how this could be
On Sun, Mar 27, 2022 at 11:07:27AM -0500, Jaime Casanova wrote:
> > > It lacks documentation and I need help with WIN32 part of it, I created
> > > this new mail to put the patch on the next commitfest.
> >
> > The patch currently fails on cfbot due to warnings, likely related due to
> > the
> >
On Fri, Mar 25, 2022 at 8:26 AM Alvaro Herrera wrote:
> On 2022-Mar-21, Alvaro Herrera wrote:
> > I had a look at this latest version of the patch, and found some things
> > to tweak. Attached is v21 with three main changes from Kyotaro's v20:
>
> Pushed this, backpatching to 14 and 13. It would
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Mar 24, 2022 at 1:10 PM Tom Lane wrote:
> > > However, it might. And if it does, I think it would be best if
> > > removing that exception were the *only* change in this area made by
> > > that release.
> >
> > Good idea, especiall
On 2022-Mar-28, Alvaro Herrera wrote:
> I intend to get this pushed after lunch.
Pushed, with one more change: fetching the tuple ID junk attribute in
ExecMerge was not necessary, since we already had done that in
ExecModifyTable. We just needed to pass that down to ExecMerge, and
make sure to h
On Mon, 28 Mar 2022 at 06:33, Michael Paquier wrote:
>
> On Wed, Feb 16, 2022 at 10:24:58PM +0100, Matthias van de Meent wrote:
> > A first good reason to do this is preventing further damage when a
> > page is corrupted: if I can somehow overwrite pd_special,
> > non-assert-enabled builds would s
Julien Rouhaud writes:
> I'm attaching a v5 with hopefully a better comment for the function, and only
> the "pretty" parameter.
Pushed with some minor cosmetic adjustments.
regards, tom lane
On 3/28/22 11:05, Nikola Ivanov wrote:
> Hi Andrew,
>
> Let me know check what can I do with the access. I will get back to
> you in an hour.
Thanks for you help and prompt response.
In the first instance we'd like to know what might be different about
jabiru from the openbsd7/clang11 instance
Hi,
On 2022-03-28 18:05:19 +0300, Nikola Ivanov wrote:
> Let me know check what can I do with the access. I will get back to you in
> an hour.
Perhaps you can temporarily enable keep_error_builds, and send in
src/interfaces/ecpg/preproc/c_kwlist_d.h
src/interfaces/ecpg/preproc/pgc.c
src/interface
On Mon, Mar 28, 2022 at 9:54 AM James Coleman wrote:
> No, I've appreciated constructive feedback from both Tom and David on
> this thread. Your original email was so incredibly strongly worded
> (and contained no constructive recommendations about a better path
> forward, unlike Tom's and David's
On Mon, Mar 28, 2022 at 11:20:42AM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > I'm attaching a v5 with hopefully a better comment for the function, and
> > only
> > the "pretty" parameter.
>
> Pushed with some minor cosmetic adjustments.
Thanks a lot!
I just published an extension usin
ok, I have enabled it. Will send it after the next build.
Regards
On Mon, 28 Mar 2022 at 18:39, Andres Freund wrote:
> Hi,
>
> On 2022-03-28 18:05:19 +0300, Nikola Ivanov wrote:
> > Let me know check what can I do with the access. I will get back to you
> in
> > an hour.
>
> Perhaps you can te
Hi Andrew,
Let me know check what can I do with the access. I will get back to you in
an hour.
Regards
On Mon, Mar 28, 2022, 17:30 Andrew Dunstan wrote:
>
> On 3/28/22 09:35, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> On 3/27/22 19:14, Tom Lane wrote:
> >>> What's worse, I'm unable to re
On Mon, Mar 21, 2022 at 3:02 PM Alvaro Herrera wrote:
> > 2. Why not instead change the code so that the operation can succeed,
> > by creating the prerequisite parent directories? Do we not have enough
> > information for that? I'm not saying that we definitely should do it
> > that way rather th
On Sun, Mar 27, 2022 at 12:28 AM Tom Lane wrote:
> Thomas Munro writes:
> > On Sat, Mar 26, 2022 at 4:14 PM Justin Pryzby
> wrote:
> >> I see it here (and in cfbot), although I'm not sure how you created a
> new
> >> patch for the active CF, and not for the next CF.
>
> > Anyone who has ever be
On Fri, Mar 25, 2022 at 9:23 AM Dipesh Pandit wrote:
> The changes look good to me.
Thanks. Committed.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, Mar 24, 2022 at 9:19 AM Dagfinn Ilmari Mannsåker
wrote:
> Per the TAP protocol, every line of non-test-result output should be
> prefixed by "# ". The note() function does this for you, see
> https://metacpan.org/pod/Test::More#Diagnostics for details.
True, but that also means it shows u
Robert Haas writes:
> On Thu, Mar 24, 2022 at 9:19 AM Dagfinn Ilmari Mannsåker
> wrote:
>> Per the TAP protocol, every line of non-test-result output should be
>> prefixed by "# ". The note() function does this for you, see
>> https://metacpan.org/pod/Test::More#Diagnostics for details.
>
> True
On Mon, Mar 28, 2022 at 12:52 PM Dagfinn Ilmari Mannsåker
wrote:
> > True, but that also means it shows up in the actual failure message,
> > which seems too verbose. By just using 'print', it ends up in the log
> > file if it's needed, but not anywhere else. Maybe there's a better way
> > to do t
On Sun, Mar 27, 2022 at 4:50 PM Justin Pryzby wrote:
> Actually, I suggest to remove those comments:
> | "We check for failure here because..."
>
> That should be the rule rather than the exception, so shouldn't require
> justifying why one might checks the return value of library and system calls
Hi,
On 2022-03-28 15:57:37 +0300, a.soko...@postgrespro.ru wrote:
> +data initialization. It is vital that any event trigger using the
> +login event checks whether or not the database is in
> +recovery.
>
> Does any trigger really have to contain a pg_is_in_recovery() call?
Not *any
I've suddenly found that the test in this patch is based on a fact that
heap pages don't have PageSpecial or it is of different size with btree
pages Special area:
CREATE TABLE test1 (a int8, b int4range);
SELECT bt_page_items(get_raw_page('test1', 0));
In the current state is is so, but it is
On Mon, Mar 28, 2022 at 12:57 PM Robert Haas wrote:
> Here's an updated and rebased version of my patch.
Well, that only updated the comment on the client side. Let's try again.
--
Robert Haas
EDB: http://www.enterprisedb.com
v3-0001-Allow-parallel-zstd-compression-when-taking-a-bas.patch
Desc
On Thu, Mar 24, 2022 at 01:31:08PM -0700, Nathan Bossart wrote:
> A couple of other options to consider:
>
> 1) Always set log_min_messages to WARNING/ERROR/FATAL for 'postgres -C'.
> We might need some special logic for handling the case where the user is
> inspecting the log_min_messages paramet
Hi,
On 2022-03-23 21:43:08 -0700, Jeff Davis wrote:
> /* must be kept in sync with RmgrData definition in xlog_internal.h */
> #define PG_RMGR(symname,name,redo,desc,identify,startup,cleanup,mask,decode)
> \
> - { name, redo, desc, identify, startup, cleanup, mask, decode },
> + &(struc
On Mon, Mar 28, 2022 at 10:51 AM Stephen Frost wrote:
> > > > So I propose to commit something like what I posted here:
> > > > http://postgr.es/m/ca+tgmobgek0jraowqvpqhsxcfbdfitxsomoebhmmmhmj4gl...@mail.gmail.com
> > >
> > > +1, although the comments might need some more work. In particular,
> >
I've started reviewing this patch in earnest, and almost immediately
hit a serious problem: these regression tests aren't even a little bit
committable. For one thing, they fail if you do "make installcheck"
twice in a row. This seems to be because the first run leaves some
cruft behind in pg_par
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-03-18 15:23:21 -0400, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2022-03-18 00:45:49 -0400, Stephen Frost wrote:
> > > > > I also don’t think that I agree that it’s acceptable to only have the
> > >
> On Mar 28, 2022, at 11:31 AM, Tom Lane wrote:
>
> I think we probably have to trash the core-regression-tests part of
> the patch altogether and instead use a TAP test for whatever testing
> we want to do. It might be all right to test SET privileges without
> testing ALTER SYSTEM, but I'm
I'm going to mark this returned with feedback.
If you have a chance to update the patch moving the documentation to
xfunc.sgml the way Tom describes make sure to create a new commitfest
entry. I would suggest submitting the patch as a followup on this
thread so when it's added to the commitfest it
On 3/28/22 14:31, Nikola Ivanov wrote:
> Hi Andreas,
>
> Archive with the files is attached.
That didn't help, there are no differences that matter (just #line
directives as I did a vpath build). :-(
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
In the interests of trying to clean up the CF and keep things moving
I'll mark the patch rejected.
That doesn't mean the decision can't change or that nobody's allowed
to keep discussing it. It's just that that seems to be the decision
right now and there are too many patches queued up to keep thi
On Mon, Mar 28, 2022 at 2:18 AM Dilip Kumar wrote:
> > I have put the similar logic for relmap_update WAL replay as well,
>
> There was some mistake in the last patch, basically, for relmap update
> also I have checked the missing tablespace directory but I should have
> checked the missing databa
This patch got some very positive feedback and some significant amount
of work earlier in the release cycle. The feedback from Julien earlier
this month seemed pretty minor.
Ekaterina, is there any chance you'll be able to work on this this
week and do you think it has a chance of making this rele
Mark Dilger writes:
> Version 12 also introduces \dcp (pneumonic, "Describe Configuration
> Parameter") for listing parameters, with \dcp+ also showing the acl, like:
The fact that that code is not dry behind the ears is painfully obvious.
It's not documented in psql-ref, not tested anywhere AFA
Mark Dilger writes:
> On Mar 28, 2022, at 11:31 AM, Tom Lane wrote:
>> I think we probably have to trash the core-regression-tests part of
>> the patch altogether and instead use a TAP test for whatever testing
>> we want to do. It might be all right to test SET privileges without
>> testing ALT
On Sat, Mar 26, 2022 at 2:23 AM Bharath Rupireddy
wrote:
> Thanks. It makes sense to put the comment in SInvalShmemSize.
> Attaching v2 patch. Please review it.
How about this version, which I have edited lightly for grammar?
--
Robert Haas
EDB: http://www.enterprisedb.com
sinvalshmemsize-com
Hi,
On 2022-03-28 14:57:20 -0400, Andrew Dunstan wrote:
> That didn't help, there are no differences that matter (just #line
> directives as I did a vpath build). :-(
Yea. I didn't see any differences when comparing to a non-vpath build that
runs tests successfully. Pretty weird.
Nikola, unless
I notice a number of patches have a failure in the cfbot on the
027_stream_regress test. I think these are related to a bug in that
test being discussed in a thread somewhere though I don't have it
handy. Is that right?
I think it doesn't indicate anything wrong with the individual patches right?
On 3/21/22 16:15, Joe Conway wrote:
On 3/20/22 12:38, Stephen Frost wrote:
Greetings,
On Sun, Mar 20, 2022 at 18:31 Joshua Brindle
mailto:joshua.brin...@crunchydata.com>>
wrote:
On Sun, Mar 20, 2022 at 12:27 PM Joe Conway mailto:m...@joeconway.com>> wrote:
>
> On 3/3/22 11:26,
This patch is currently showing up with a test failure in the CFBot
however I do *not* believe this is a bug in the patch. I think it's a
bug in that test which is being discussed elsewhere.
It's also a very short and straightforward patch that a committer
could probably make a decision about whet
Andres Freund writes:
> On 2022-03-28 14:57:20 -0400, Andrew Dunstan wrote:
>> That didn't help, there are no differences that matter (just #line
>> directives as I did a vpath build). :-(
> Yea. I didn't see any differences when comparing to a non-vpath build that
> runs tests successfully. Pret
On Tue, 22 Mar 2022 at 09:52, Michail Nikolaev
wrote:
>
> Thanks for notifying me. BTW, some kind of automatic email in case of
> status change could be very helpful.
I agree but realize the cfbot is quite new and I guess the priority is
to work out any kinks before spamming people with false pos
On Mon, 28 Mar 2022 at 05:17, Daniel Gustafsson wrote:
>
> named to match the git format-patch output
> since I think the CFBot just applies the patches in alphabetical order).
The first patch doesn't seem to actually apply though so it doesn't
get to the subsequent patches.
http://cfbot.cputube
FYI I think the patch failure in the cfbot is spurious because the
cfbot got confused by Erik's patch.
Hi,
On 2022-03-28 15:28:20 -0400, Greg Stark wrote:
> I notice a number of patches have a failure in the cfbot on the
> 027_stream_regress test. I think these are related to a bug in that
> test being discussed in a thread somewhere though I don't have it
> handy. Is that right?
It looks more lik
On Sun, Mar 27, 2022 at 1:47 PM Tom Lane wrote:
> Coverity has a nitpick about this:
>
> /srv/coverity/git/pgsql-git/postgresql/src/common/backup_compression.c: 194
> in parse_bc_specification()
> 193 /* Advance to next entry and loop around. */
> >>> CID 1503251: Null po
On Mon, Mar 21, 2022 at 4:15 PM Joe Conway wrote:
> Robert -- any opinion on this? If I am not mistaken it is code that you
> are actively working on.
Woops, I only just saw this. I don't mind if you want to change the
calls to is_member_of_role() in basebackup_server.c and
basebackup_to_shell.c
Hi,
On 2022-03-25 10:01:09 +0100, Peter Eisentraut wrote:
> On 22.03.22 03:22, Andres Freund wrote:
> > Attached is v8. It's just a rebase to resolve conflicts with recent changes.
>
> I have committed the DLSUFFIX refactoring, and also a stripped-down version
> of the patch that makes update-uni
On 3/28/22 15:56, Robert Haas wrote:
On Mon, Mar 21, 2022 at 4:15 PM Joe Conway wrote:
Robert -- any opinion on this? If I am not mistaken it is code that you
are actively working on.
Woops, I only just saw this. I don't mind if you want to change the
calls to is_member_of_role() in basebacku
On Tue, Mar 22, 2022 at 12:50 AM Andres Freund wrote:
> Hi,
>
> On 2022-03-07 13:10:32 +0100, Magnus Hagander wrote:
> > Meanwhile here is an updated based on your other comments above, as
> > well as those from Julien.
>
> This fails on cfbot, due to compiler warnings:
> https://cirrus-ci.com/ta
I had to rebase this again after Tom's cleanup of heap.c removing some includes.
I had to re-add snapmgr to access RecentXmin. I occurs to me to ask
whether RecentXmin is actually guaranteed to be set. I haven't
checked. I thought it was set when the first snapshot was taken and
presumably even if
Fwiw the cfbot is failing due to a duplicate OID. Traditionally we
didn't treat duplicate OIDs as reason to reject a patch because
they're inevitable as other patches get committed and the committer
can just renumber them.
I think the cfbot kind of changes this calculus since it's a pain lose
the
On Mon, 2022-03-28 at 11:17 +0200, Daniel Gustafsson wrote:
> Fixing up the switch_server_cert() calls and using default_ssl_connstr makes
> the test pass for me. The required fixes are in the supplied 0004 diff, I
> kept
> them separate to allow the original author to incorporate them without ha
On Mon, Mar 28, 2022 at 12:40 PM Greg Stark wrote:
> I'm seeing a recovery test failure. Not sure if this represents an
> actual bug or just a test that needs to be adjusted for the new
> behaviour.
>
> https://cirrus-ci.com/task/5711008294502400
I doubt that the patch's use of pg_memory_barrier(
Hi,
On 2022-03-28 16:11:55 -0400, Greg Stark wrote:
> From 4515075b644d1e38920eb5bdaaa898e1698510a8 Mon Sep 17 00:00:00 2001
> From: Greg Stark
> Date: Tue, 22 Mar 2022 15:51:32 -0400
> Subject: [PATCH v4 1/2] Update relfrozenxmin when truncating temp tables
>
> Make ON COMMIT DELETE ROW
Greetings,
* Nathan Bossart (nathandboss...@gmail.com) wrote:
> On Thu, Mar 10, 2022 at 07:13:14PM -0500, Chapman Flack wrote:
> > Looks like this change to an example in func.sgml is not quite right:
> >
> > -postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
> > +postgres=# SELE
Hi,
On 2022-03-21 21:09, Greg Stark wrote:
This patch seems to be getting ignored. Like David I'm a bit puzzled
because it doesn't seem like an especially obscure or difficult patch
to review. Yet it's been multiple years without even a superficial
"does it meet the coding requirements" review l
> On 25 Mar 2022, at 23:45, Jacob Champion wrote:
>
> On Fri, 2022-03-25 at 18:00 -0400, Tom Lane wrote:
>> Jacob Champion writes:
>>> Do I need to merge my tiny test program into the libpq_pipeline tests?
>>
>> Doesn't seem worth the trouble to me, notably because you'd
>> then have to cope wi
Robert Haas writes:
> On Sun, Mar 27, 2022 at 1:47 PM Tom Lane wrote:
>> Not sure if you should remove this null-check or add some other ones,
>> but I think you ought to do one or the other.
> As I hope is apparent, the first hunk of this patch is not for commit,
> and the second hunk is for co
On Mon, Mar 28, 2022 at 03:50:50PM -0400, Robert Haas wrote:
> On Sun, Mar 27, 2022 at 1:47 PM Tom Lane wrote:
> > Coverity has a nitpick about this:
> >
> > /srv/coverity/git/pgsql-git/postgresql/src/common/backup_compression.c: 194
> > in parse_bc_specification()
> > 193 /*
I just came across something odd in v12 that is still there in v13:
ExecGrant_Parameter uses InvokeObjectPostAlterHook not
InvokeObjectPostAlterHookArgStr. This seems pretty inconsistent.
Is there a good argument for it?
... or, for that matter, why is there any such call at all?
No other GRANT/R
> On 28 Mar 2022, at 19:10, Andres Freund wrote:
> On 2022-03-28 15:57:37 +0300, a.soko...@postgrespro.ru wrote:
>> +data initialization. It is vital that any event trigger using the
>> +login event checks whether or not the database is in
>> +recovery.
>>
>> Does any trigger really
Hi,
On 2022-03-28 23:27:56 +0200, Daniel Gustafsson wrote:
> > On 28 Mar 2022, at 19:10, Andres Freund wrote:
> > On 2022-03-28 15:57:37 +0300, a.soko...@postgrespro.ru wrote:
>
> >> +data initialization. It is vital that any event trigger using the
> >> +login event checks whether or no
> On 28 Mar 2022, at 23:31, Andres Freund wrote:
>
> Hi,
>
> On 2022-03-28 23:27:56 +0200, Daniel Gustafsson wrote:
>>> On 28 Mar 2022, at 19:10, Andres Freund wrote:
>>> On 2022-03-28 15:57:37 +0300, a.soko...@postgrespro.ru wrote:
>>
+data initialization. It is vital that any event
On Mon, Mar 28, 2022 at 4:53 PM Justin Pryzby wrote:
> I suggest to write it differently, as in 0002.
That doesn't seem better to me. What's the argument for it?
--
Robert Haas
EDB: http://www.enterprisedb.com
> On Mar 28, 2022, at 2:16 PM, Tom Lane wrote:
>
> I just came across something odd in v12 that is still there in v13:
> ExecGrant_Parameter uses InvokeObjectPostAlterHook not
> InvokeObjectPostAlterHookArgStr. This seems pretty inconsistent.
> Is there a good argument for it?
>
For SET and
On Mon, Mar 28, 2022 at 1:23 PM Peter Geoghegan wrote:
> I doubt that the patch's use of pg_memory_barrier() in places like
> _bt_killitems() is correct.
I also doubt that posting list splits are handled correctly.
If there is an LP_DEAD bit set on a posting list on the primary, and
we need to d
> On 25 Mar 2022, at 22:01, Daniel Gustafsson wrote:
>> On 25 Mar 2022, at 20:58, Robert Haas wrote:
>> However, if we're not ready/willing to make a bigger change, then doing as
>> you
>> have proposed here seems fine to me.
>
> Thanks for review! Trying out again just now the patch still ap
Mark Dilger writes:
>> On Mar 28, 2022, at 2:16 PM, Tom Lane wrote:
>> I just came across something odd in v12 that is still there in v13:
>> ExecGrant_Parameter uses InvokeObjectPostAlterHook not
>> InvokeObjectPostAlterHookArgStr. This seems pretty inconsistent.
>> Is there a good argument for
> On Mar 28, 2022, at 2:54 PM, Tom Lane wrote:
>
> Yeah, I know it's *possible* to make this work. The question is why is
> it good to do it like this rather than to use the string API, now that
> we have the latter. AFAICS this way just guarantees that the hook must
> do a catalog lookup in
On 3/28/22 15:48, Greg Stark wrote:
> FYI I think the patch failure in the cfbot is spurious because the
> cfbot got confused by Erik's patch.
The cfbot is likely to be confused until I am finished committing the
SQL/JSON patches. Just disregard it.
cheers
andrew
--
Andrew Dunstan
EDB: h
I'm going to be mostly unavailable till Wednesday, but I'll leave
you with another thing to chew on:
regression=# create user joe;
CREATE ROLE
regression=# grant set on parameter plpgsql.extra_warnings to joe;
ERROR: unrecognized configuration parameter "plpgsql.extra_warnings"
This is problemat
Mark Dilger writes:
> I was about to write another patch using the HookStr form, but if you are
> already editing, then I'll let you make the change. I don't see a problem
> with what you are proposing.
Don't sweat about that, I can easily rebase what I've done so far
over your updates.
1 - 100 of 138 matches
Mail list logo
