On Sat, Mar 26, 2022 at 7:53 PM vignesh C wrote:
>
> The patch was not applying on HEAD, attached patch which is rebased on
> top of HEAD.
>
IIUC, this patch provides an option that allows us to give an error if
while creating/altering subcsiction, user gives non-existant
publications. I am not
Hi Dag,
The patch adds the command "\dco" to list constraints in psql. This
seems useful to me.
Thank you!
The patch applies cleanly to HEAD, although some hunks have rather large
offsets.
As far as I can tell, the "\dco" command works as documented.
I have however found the following
On Mon, Mar 21, 2022 at 5:51 PM Euler Taveira wrote:
>
> On Mon, Mar 21, 2022, at 12:25 AM, Amit Kapila wrote:
>
> I have fixed all the above comments as per your suggestion in the
> attached. Do let me know if something is missed?
>
> Looks good to me.
>
This patch is committed
On Fri, Mar 25, 2022 at 5:33 PM Amit Kapila wrote:
>
> On Fri, Mar 25, 2022 at 11:49 AM Masahiko Sawada
> wrote:
> >
> > On Fri, Mar 25, 2022 at 2:23 PM wangw.f...@fujitsu.com
> > wrote:
> >
> > Since commit 75b1521 added decoding of sequence to logical
> > replication, the patch needs to have
On Mon, Mar 28, 2022 at 12:12:48PM +0900, Michael Paquier wrote:
> It seems to me here that the snapshot hold by autovacuum during the
> scan of pg_database to find the relations to process is enough to
> prevent the FSM truncation, as the tuples cleaned up by the DELETE
> query still need to be
On Mon, Mar 28, 2022 at 08:36:15AM -0400, Robert Haas wrote:
> Well, I think the first thing we should do is get rid of enum
> WalCompressionMethod and use enum WalCompression instead. They've got
> the same elements and very similar names, but the WalCompressionMethod
> ones just have names like
At Mon, 28 Mar 2022 12:17:50 -0400, Robert Haas wrote
in
> 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
On Thu, Mar 24, 2022 at 11:24 PM Zheng Li wrote:
>
> Hi Dilip,
>
> Thanks for the feedback.
>
> > > > > The table creation WAL and table insert WAL are available. The tricky
> > > > > part is how do we break down this command into two parts (a normal
> > > > > CREATE TABLE followed by insertions)
On Tue, Mar 29, 2022 at 12:38 AM Robert Haas wrote:
>
> 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
On 2022-03-28 19:25:51 -0400, Tom Lane wrote:
> ... even more baffling: jabiru went green after the IS JSON patch.
Broken ccache contents somehow?
On Mon, Mar 28, 2022 at 7:07 PM Tom Lane wrote:
> Right, that's the case I had in mind --- apologies if my terminology
> was faulty. btree can actually handle such a case now, but what it
> fails to do is re-descend from the tree root instead of plowing
> forward in the index to find the next
Hi All,
In the interests of trying to clean up the CF and keep things moving
I'll mark the patch rejected.
Thank you for managing the commitfest and the comments from many of
hackers. I apologize for not being able to email you more often due to
my busy day job.
First of all, I understand to
Hi,
On Mon, Mar 28, 2022 at 03:09:12PM -0400, Greg Stark wrote:
> 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
On Sat, Mar 26, 2022 at 08:23:54PM +0900, Michael Paquier wrote:
> On Wed, Mar 23, 2022 at 03:17:35PM +0900, Michael Paquier wrote:
> > FWIW, per my review the bit of the patch set that I found the most
> > relevant is the addition of a note in the docs of pg_stat_file() about
> > the case where
On Wed, 23 Mar 2022 at 16:30, David Rowley wrote:
>
> 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
On Mon, Mar 28, 2022 at 04:30:27PM -0400, Stephen Frost wrote:
>> - By default, pg_start_backup can take a long time
>> to finish.
>> + By default, pg_backup_start can take a long time
>> to finish.
>> This is because it performs a checkpoint, and the I/O
>> required for the
Peter Geoghegan writes:
> The terminology in this area is a mess. MySQL calls
> SELECT-DISTINCT-that-matches-an-index "loose index scans". I think
> that you're talking about skip scan when you say "loose index scan".
> Skip scan is where there is an omitted prefix of columns in the SQL
> query
On Mon, Mar 28, 2022 at 5:21 PM Tom Lane wrote:
> In any case, what I was on about is _bt_preprocess_keys() and
> adjacent code. I'm surprised that those aren't more expensive
> than one palloc in _bt_first. Maybe that logic falls through very
> quickly in simple cases, though.
I assume that
On Tue, Mar 22, 2022 at 1:55 PM Tom Lane wrote:
> Peter asked me off-list to spend some time thinking about the overall
> direction we ought to be pursuing here.
Thanks for taking a look!
"5.5 Exploiting Key Prefixes" and "5.6 Ordered Retrieval" from "Modern
B-Tree Techniques" are also good,
_reordering? Opinions?
>
>
> regards
>
> --
> Tomas Vondra
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
Hi,
For 0001-Optimize-order-of-GROUP-BY-keys-20220328.patch:
multiple parametes need to be
parametes -> parameters
leave
On Mon, Mar 28, 2022 at 02:34:44PM +1300, Thomas Munro wrote:
> Just a thought: we could consider back-patching
> allow_in_place_tablespaces, after a little while, if we're happy with
> how that is working out, if it'd be useful for verifying bug fixes in
> back branches. It's
On Mon, Mar 28, 2022 at 2:11 AM I wrote:
> Rebase the patch.
After reviewing anohter patch[1], I think this patch should also add a loop in
function WalSndUpdateProgress like what did in function WalSndWriteData.
So update the patch to be consistent with the existing code and the patch
mentioned
At Mon, 28 Mar 2022 10:37:04 -0400, Robert Haas wrote
in
> 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
Dear Amit, Wang,
> > I think maybe we do not need to deal with this use case.
> > The maximum number of table columns allowed by PG is 1600
> > (macro MaxHeapAttributeNumber), and after loop through all columns in the
> > function logicalrep_write_tuple, the function OutputPluginWrite will be
>
On Mon, Mar 28, 2022 at 04:33:30PM +0800, Julien Rouhaud wrote:
> Ok, v5 attached without the TAP tests and updated sysviews tests.
The update of the query related to pg_hba_file_rules in the regression
tests was independant, so I have split and applied that first, as of
091a971.
Now, for the
> On Mar 28, 2022, at 7:25 PM, Tom Lane wrote:
>
> ... even more baffling: jabiru went green after the IS JSON patch.
>
>
Yeah, bizarre. Let’s see if I can upset that tomorrow with the next patch :-)
cheers
andrew
Peter Geoghegan writes:
> We could get rid of dynamic allocations for BTStackData in
> _bt_first(), perhaps. The problem is that there is no simple,
> reasonable proof of the maximum height on a B-tree, even though a
> B-Tree with more than 7 or 8 levels seems extraordinarily unlikely.
Start
> 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
On Tue, Mar 22, 2022 at 4:06 PM Andres Freund wrote:
> Are you thinking of just moving the setup stuff in nbtree (presumably parts of
> _bt_first() / _bt_preprocess_keys()) or also stuff in
> ExecIndexBuildScanKeys()?
>
> The latter does show up a bit more heavily in profiles than nbtree specific
Justin Pryzby writes:
> Also, why wouldn't *kwend be checked in any case ?
I suspect Robert wrote it that way intentionally --- but if so,
I agree it could do with more than zero commentary.
regards, tom lane
On Mon, Mar 28, 2022 at 05:39:31PM -0400, Robert Haas wrote:
> 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?
I find this much easier to understand:
/* If we
> > +static void show_loop_info(Instrumentation *instrument, bool isworker,
> > + ExplainState *es);
> >
> > I think this should be done as a separate refactoring commit.
Right - the 0001 patch I sent seems independently beneficial, and makes the
changes in 0002 more
... even more baffling: jabiru went green after the IS JSON patch.
regards, tom lane
Hi,
On 2022-03-28 18:58:19 -0400, Tom Lane wrote:
> If we can commit meson build infrastructure without removing the
> existing infrastructure, then the buildfarm can continue to work,
> and we can roll out support for the new way slowly.
I think it's not a huge issue to have both for a while.
Andrew Dunstan writes:
> On 3/28/22 15:59, Andres Freund wrote:
>> In our context it could make sense to merge meson, after a few months of
>> shakeup remove the current windows buildsystems, and then in release + 1
>> remove the make based stuff.
That sounds like a decent plan.
> I'd like to
On 3/28/22 15:59, Andres Freund wrote:
>
> One thing I'd like to discuss fairly soon is what kind of approach to take for
> integrating meson support. Most other projects I looked kept parallel
> buildsystems for at least a release, so that there's one round of "broad" user
> feedback.
We did
Andres Freund writes:
> On 2022-03-28 23:27:56 +0200, Daniel Gustafsson wrote:
>> Do you think this potential foot-gun is scary enough to reject this patch?
>> There are lots of creative ways to cause Nagios alerts from ones database,
>> but
>> this has the potential to do so with a small bug in
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.
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
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:
> 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
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
> 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
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
> 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
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 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
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
> 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
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
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 /*
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
> 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
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
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=#
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
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
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
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
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
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:
>
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
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
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
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
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
FYI I think the patch failure in the cfbot is spurious because the
cfbot got confused by Erik's patch.
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.
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
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.
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
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
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?
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
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
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
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
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
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
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
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
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
> 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
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
> >
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
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,
>
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 },
> +
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
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
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
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
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
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
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.
>
>
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
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 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
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
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
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
1 - 100 of 145 matches
Mail list logo
