At Tue, 9 Nov 2021 10:47:11 +0900, Michael Paquier wrote
in
> Hi all,
>
> I have noticed $subject while looking at a patch in this area:
> https://www.postgresql.org/message-id/yyiqxteqhgb5g...@paquier.xyz
>
> While we don't expect the four callers of XLogReadRecord() related to
> logical deco
On Tue, Nov 9, 2021 at 11:57 AM Amit Kapila wrote:
>
> On Tue, Nov 9, 2021 at 11:37 AM Dilip Kumar wrote:
> > 1.
> > I don't like the fact that this view is very specific for showing the
> > errors but the name of the view is very generic. So are we keeping
> > this name to expand the scope of t
Thank you for the comments!
At Tue, 9 Nov 2021 09:53:15 +0900, Michael Paquier wrote
in
> On Mon, Nov 08, 2021 at 02:59:46PM +0900, Kyotaro Horiguchi wrote:
> > While checking the behavior for the case of missing-contrecord, I
> > noticed that emode_for_corrupt_record() doesn't work as expected
On Tue, Nov 9, 2021 at 3:08 PM Amit Kapila wrote:
>
> On Sun, Nov 7, 2021 at 7:50 PM Masahiko Sawada wrote:
> >
> > On Wed, Nov 3, 2021 at 12:41 PM Amit Kapila wrote:
> > >
> > > On Tue, Nov 2, 2021 at 2:17 PM Masahiko Sawada
> > > wrote:
> > >
> > > If we follow the idea of keeping stats at d
On Tue, Nov 9, 2021 at 11:37 AM Dilip Kumar wrote:
>
> On Sun, Nov 7, 2021 at 7:50 PM Masahiko Sawada wrote:
> > I've attached an updated patch. In this version patch, subscription
> > worker statistics are collected per-database and handled in a similar
> > way to tables and functions. I think p
On Sun, Nov 7, 2021 at 7:50 PM Masahiko Sawada wrote:
>
> On Wed, Nov 3, 2021 at 12:41 PM Amit Kapila wrote:
> >
> > On Tue, Nov 2, 2021 at 2:17 PM Masahiko Sawada
> > wrote:
> >
> > If we follow the idea of keeping stats at db level (in
> > PgStat_StatDBEntry) as discussed above then I think w
On Sun, Nov 7, 2021 at 7:50 PM Masahiko Sawada wrote:
> I've attached an updated patch. In this version patch, subscription
> worker statistics are collected per-database and handled in a similar
> way to tables and functions. I think perhaps we still need to discuss
> details of how the statistic
On 2021/11/09 13:01, Michael Paquier wrote:
On Tue, Nov 09, 2021 at 12:51:39PM +0900, Fujii Masao wrote:
I'm fine with this. Barring any objection, I will commit the patch.
I have to admit that the timing is kind of odd, or strange, or both,
because I was just going through my backlog from
On Tue, Nov 09, 2021 at 12:51:39PM +0900, Fujii Masao wrote:
> I'm fine with this. Barring any objection, I will commit the patch.
I have to admit that the timing is kind of odd, or strange, or both,
because I was just going through my backlog from -hackers, and just
bumped on this thread like 15
On 2021/11/05 14:52, Bharath Rupireddy wrote:
Hi,
I see that "procsignal" and "ProcSignal" are being used in the code
comments which look inconsistent. IMO, "ProcSignal" is the right word
to use and let's be consistent across the code comments. Attaching a
tiny patch for that.
Thoughts?
I'
On Mon, Nov 08, 2021 at 05:55:16PM +0900, Kyotaro Horiguchi wrote:
I have quickly looked at the patch set.
> 0001: (I don't remember about this, though) I don't see how to make it
> work on Windows. Anyway the next step would be to write comments.
Look at Utils.pm where we have dir_symlink, the
On 2021/11/08 16:23, Julien Rouhaud wrote:
On Mon, Nov 8, 2021 at 3:19 PM Fujii Masao wrote:
On 2021/11/08 15:12, Ken Kato wrote:
Hi,
Configuration parameters for pg_stat_statements were not in the index,
so I added them just like auto_explain configuration parameters.
Thanks for the pa
On Mon, Nov 08, 2021 at 12:49:52PM -0500, Robert Haas wrote:
> Even with this patch, the name ThisTimeLineID is still used for
> multiple purposes. It remains part of the CheckPoint struct, and also
> part of the xl_end_of_recovery struct. But in both of those cases, the
> name ThisTimeLineID actua
On Fri, Nov 5, 2021 at 7:11 PM osumi.takami...@fujitsu.com
wrote:
>
I did a quick scan through the latest v8 patch and noticed the following things:
src/backend/postmaster/pgstat.c
(1) pgstat_recv_subworker_twophase_xact()
The copying from msg->m_gid to key.gid does not seem to be correct.
strl
On Friday, November 5, 2021 1:14 PM, Peter Smith wrote:
>
> PSA new set of v37* patches.
>
Thanks for your patch. I have a problem when using this patch.
The document about "create publication" in patch says:
The WHERE clause should contain only columns that are
part of the primary key
Unknown why people have so little interest in this, AFAICS, there are more great
usages of UniqueKey rather than the 'marking-distinct-as-noop'. The most
exciting usage for me is it is helpful for JoinRel's pathkey.
Take an example of this:
SELECT .. FROM t1 JOIN t2 ON t1.any_column = t2.uniqueke
On Mon, Nov 08, 2021 at 03:07:43PM +0900, Kyotaro Horiguchi wrote:
> I noticed I'm one of the author^^; I'll also look into the comments
> and try to address them.
Cool, thanks. I'll come back to this thread from this point, then.
--
Michael
signature.asc
Description: PGP signature
On Mon, Nov 08, 2021 at 01:42:46PM +0900, Michael Paquier wrote:
> Indeed. Looking closer, I think that we'd better improve
> DecodingContextFindStartpoint(),
> pg_logical_replication_slot_advance(), XLogSendLogical() as well as
> pg_logical_slot_get_changes_guts() to follow a format closer to wha
FYI - I spotted a trivial SQL mistake (?) of the schema publication patch [1].
See the file describe.c, function describeOneTableDetails.
The new SQL has a 3rd UNION that looks like:
...
"UNION\n"
"SELECT pubname\n"
"FROM pg_catalog.pg_publication p\n"
"WHERE puballtables AND pg_catalog.pg_relat
Hi all,
I have noticed $subject while looking at a patch in this area:
https://www.postgresql.org/message-id/yyiqxteqhgb5g...@paquier.xyz
While we don't expect the four callers of XLogReadRecord() related to
logical decoding to fail in the code paths changed by the patch
attached, I think that it
On Mon, Nov 08, 2021 at 02:59:46PM +0900, Kyotaro Horiguchi wrote:
> While checking the behavior for the case of missing-contrecord, I
> noticed that emode_for_corrupt_record() doesn't work as expected since
> readSource is reset to XLOG_FROM_ANY after a read failure. We could
> remember the last f
On Mon, 2021-11-08 at 12:47 -0500, Stephen Frost wrote:
>
> I don't feel as strongly as others apparently do on this point
> though,
> and I'd rather have non-superusers able to run CHECKPOINT *somehow*
> than not, so if the others feel like a predefined role is a better
> approach then I'm alrigh
On Fri, Nov 5, 2021 at 7:11 PM osumi.takami...@fujitsu.com
wrote:
>
> I'm not sure about the last part.
> > additionally increase the available subscriber memory,
> Which GUC parameter did you mean by this ?
> Could we point out and enalrge the memory size only for
> subscriber's apply processing
On Fri, 2021-11-05 at 10:00 +0530, Amit Kapila wrote:
> I am not talking about decoding plugin but rather decoding itself,
> basically, the work we do in reorderbuffer.c, decode.c, etc. The two
> things I remember were tuple format and transaction ids as mentioned
> in my previous email.
If it's
Motivation:
I'm working on a columnar compression AM[0]. Currently, it uses generic
xlog, which works for crash recovery and physical replication, but not
logical decoding/replication.
Extensible rmgr would enable the table AM to support its own
redo/decode hooks and WAL format, so that it could
On 11/8/21 2:04 PM, Stephen Frost wrote:
* David Steele (da...@pgmasters.net) wrote:
I looked at trying to make this code common between the server and client
but due to the differences in error reporting it seemed like more trouble
than it was worth.
Maybe we should at least have the comment
> On 29 Mar 2021, at 15:36, David Steele wrote:
> A rebase is also required so marked Waiting for Author.
Many months on and this patch still needs a rebase to apply, and the thread has
stalled. I'm marking this Returned with Feedback. Please feel free to open a
new entry if you return to this
On Mon, Nov 8, 2021 at 3:44 PM Stephen Frost wrote:
>
> Greetings,
>
> * Joshua Brindle (joshua.brin...@crunchydata.com) wrote:
> > On Wed, Oct 27, 2021 at 5:20 PM Joshua Brindle
> > wrote:
> > > On Wed, Oct 27, 2021 at 5:16 PM Robert Haas wrote:
> > > > On Wed, Oct 27, 2021 at 5:14 PM Joshua B
"Dian M Fay" writes:
> On Tue Nov 2, 2021 at 7:10 PM EDT, Tom Lane wrote:
>> Actually ... we could make that a lot safer by insisting that the
>> other input be a plain Var, which'd necessarily be a column of the
>> foreign table. That would still cover most cases of practical
>> interest, I think
On Mon, Nov 8, 2021 at 11:34 AM Robert Haas wrote:
> Anyway, here's my proposal for fixing the issue immediately before us.
> 0001 adds logic to pad out the unterminated tar archives, and 0002
> makes the server terminate its tar archives while preserving the logic
> added by 0001 for cases where
Greetings,
* Joshua Brindle (joshua.brin...@crunchydata.com) wrote:
> On Wed, Oct 27, 2021 at 5:20 PM Joshua Brindle
> wrote:
> > On Wed, Oct 27, 2021 at 5:16 PM Robert Haas wrote:
> > > On Wed, Oct 27, 2021 at 5:14 PM Joshua Brindle
> > > wrote:
> > > > Attached is an updated version of the p
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Wed, 2021-10-27 at 12:53 -0400, Jonathan S. Katz wrote:
> > The patch I propose just layers on top of the existing functionality --
> > you could even argue that it's "fixing a bug" that we did not add the
> > current "map" support
On Mon, Nov 08, 2021 at 02:52:28PM -0500, Melanie Plageman wrote:
> On Tue, Nov 2, 2021 at 4:23 PM Justin Pryzby wrote:
> >
> > Several places have a conditional value for the first argument
> > (randomAccess),
> > but your patch changes the behavior to a constant "true". I didn't review
> > th
On Tue, Nov 2, 2021 at 4:23 PM Justin Pryzby wrote:
>
> Several places have a conditional value for the first argument (randomAccess),
> but your patch changes the behavior to a constant "true". I didn't review the
> patch beyond that.
>
> > @@ -740,18 +724,14 @@ pg_prepared_statement(PG_FUNCTION
The attached patch contains a helper now named
MakeFuncResultTuplestore() which aims to eliminate a few lines of
redundant code that all FUNCAPI functions making tuplestores repeated.
While investigating all of these call sites and making the changes
suggested by Álvaro, I noticed that the functio
> On Nov 8, 2021, at 10:38 AM, Stephen Frost wrote:
>
> I don't quite follow this. The entire point of Alice writing a script
> that uses IF NOT EXISTS is to have that command not fail if, indeed,
> that role already exists, but for the rest of the script to be run.
> That there's some potent
Greetings,
* Isaac Morland (isaac.morl...@gmail.com) wrote:
> On Tue, 2 Nov 2021 at 19:00, Vik Fearing wrote:
> > On 11/2/21 11:14 PM, Vik Fearing wrote:
> >
> > > This would be nice, but there is nothing to hang our hat on:
> > >
> > > GRANT CHECKPOINT TO username;
> >
> > Thinking about thi
Greetings,
* David Steele (da...@pgmasters.net) wrote:
> I noticed recently that permissions checking is done differently for the
> server certificate key than the client key. Specifically, on the server the
> key can have 640 perms if it is owned by root.
Yeah, that strikes me as odd too, partic
Stephen Frost writes:
> I don't quite follow this. The entire point of Alice writing a script
> that uses IF NOT EXISTS is to have that command not fail if, indeed,
> that role already exists, but for the rest of the script to be run.
> That there's some potential attacker with CREATEROLE running
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> > On 3 Nov 2021, at 23:18, Tom Lane wrote:
> > I'm generally pretty down on IF NOT EXISTS semantics in all cases,
> > but it seems particularly dangerous for something as fundamental
> > to privilege checks as a role. It's not hard at all
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> On 2021-Nov-08, Stephen Frost wrote:
>
> > * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
>
> > > That said, if the list is short, then additional predefined roles seem
> > > preferrable to having a ton of infrastructure code that
On Mon, Nov 8, 2021 at 8:27 AM Robert Haas wrote:
> Perhaps. That's related to the point I made before, that it might be a
> good idea to be more clear about which of these functions are intended
> to be used in recovery and which ones are intended to be used in
> normal running. I don't rule out
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2021-11-08 12:23:18 -0500, Stephen Frost wrote:
> > though I continue to feel like the function based approach is better.
>
> I think it's a somewhat ugly hack.
I suppose we'll just have to disagree on that. :)
I don't feel as strongly
On 2021-Nov-08, Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> > That said, if the list is short, then additional predefined roles seem
> > preferrable to having a ton of infrastructure code that might be much
> > more clutter than what seems a short list of additional
Greetings,
* Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote:
> On 2021-Nov-04, Jeff Davis wrote:
> > But I don't see it generalizing to a lot of commands, either. I looked
> > at the list, and it's taking some creativity to think of more than a
> > couple other commands where it makes sense. Maybe
Hi,
On 2021-11-08 12:23:18 -0500, Stephen Frost wrote:
> If we're actually worried about catalog corruption (and, frankly, I've
> got some serious doubts that jumping in and running CHECKPOINT; by hand
> is a great idea if there's such active corruption)
I've been there when recovering from corru
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2021-11-05 08:54:37 -0400, Robert Haas wrote:
> > On Thu, Nov 4, 2021 at 6:46 PM Andres Freund wrote:
> > > What about extending GRANT to allow to grant rights on commands? Yes,
> > > it'd be
> > > a bit of work to make that work in the
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2021-11-05 08:42:58 -0400, Robert Haas wrote:
> > On Thu, Nov 4, 2021 at 7:38 PM Jeff Davis wrote:
> > > It seems like this specific approach has been mostly shot down already.
> > > But out of curiosity, are you intending to run CHECKP
I wrote:
> The rough idea I have is that prior to 8162464a2, we sucked in
> that #define during postgres.h and then OpenSSL's headers were
> able to undo it. After 8162464a2, we don't read
> during postgres.h, but some *other* header that be-secure-openssl.c
> is including after the OpenSSL heade
On Mon, Nov 8, 2021 at 10:59 AM Tom Lane wrote:
> Robert Haas writes:
> > It turns out that these commits are causing failures on prairiedog.
> > Per email from Tom off-list, that's apparently because prairiedog has
> > a fussy version of tar that doesn't like it when you omit the trailing
> > NU
On Mon, Nov 8, 2021 at 8:07 AM Alvaro Herrera
wrote:
> On 2021-Nov-08, Michel Pelletier wrote:
>
> > I posted this last week to psql-general, and Pavel Stehule suggested it
> > would be a good candidate for inclusion in the contrib collection and
> that
> > I write this proposal to suggest the ex
On 2021-Nov-08, Michel Pelletier wrote:
> I posted this last week to psql-general, and Pavel Stehule suggested it
> would be a good candidate for inclusion in the contrib collection and that
> I write this proposal to suggest the extension get into the next commit
> fest.
Hmm, I think src/test/mo
Hello,
Expanded data types (types that have a different in-memory working
representation than on disk) are pretty essential to a couple of projects
that I work on, and while the prose documentation is great at explaining
the rationale and technical overview, there isn't a complete,
self-contained,
Robert Haas writes:
> It turns out that these commits are causing failures on prairiedog.
> Per email from Tom off-list, that's apparently because prairiedog has
> a fussy version of tar that doesn't like it when you omit the trailing
> NUL blocks that are supposed to be part of a tar file.
FTR,
On Fri, Nov 5, 2021 at 11:50 AM Robert Haas wrote:
> I went ahead and committed 0001 and 0002, but got nervous about
> proceeding with 0003.
It turns out that these commits are causing failures on prairiedog.
Per email from Tom off-list, that's apparently because prairiedog has
a fussy version of
Dear Horiguchi-san, Fujii-san
Thank you for discussing!
> Isn't it enough to perform this assertion check only once
> at the top of parse_pgfdw_appname()?
Fixed.
> If possible, I'd like to see this change as a separate patch
> and commt it first because this is the description for
> the existin
On Sun, Nov 7, 2021 at 11:24 PM Michael Paquier wrote:
> I got to wonder whether it would be better to add in GetFlushRecPtr()
> the same assertion as GetWALInsertionTimeLine(). All the in-core
> callers of this routine already assume that, and it would be buggy if
> one passes down insertTLI to
On Tue, Nov 2, 2021 at 4:12 PM osumi.takami...@fujitsu.com
wrote:
>
> On Monday, June 28, 2021 1:47 PM Masahiko Sawada
> wrote:
> > On Mon, Jun 21, 2021 at 11:26 AM Mark Dilger
> > wrote:
> > > > On Jun 20, 2021, at 7:17 PM, Masahiko Sawada
> > wrote:
> > > >
> > > > I will submit the patch.
>
Fujii-san,
Thank you for your comment.
As advised by Justin, I modified the comment according to the style guide and
split the if statement.
As you say, the NOTICE log was deleted as it may not be needed.
Regards,
Noriyoshi Shinoda
-Original Message-
From: Fujii Masao [mailto:masao.fu..
On 2021-Nov-08, Alexander Lakhin wrote:
> Hello Alvaro,
> 14.10.2021 01:09, Alvaro Herrera wrote:
> >> Yea, let's go for your patch then. I've verified that at least locally it
> >> passes under valgrind.
> > Ah great, thanks. Pushed then.
> >
> While translating messages I've noticed that the ve
> 7 нояб. 2021 г., в 06:31, Noah Misch написал(а):
>
> As a first step, let's report the actual XLogReadRecord() error message.
> Attached. All the other sites that expect no error already do this.
BTW some time ago I've spotted a good number of related unreported errors [0].
[0]
https://
On Mon, 2021-11-08 at 10:20 +0100, Magnus Hagander wrote:
> On Mon, Nov 8, 2021 at 10:11 AM Michael J. Baars
> wrote:
> > On Mon, 2021-11-08 at 13:30 +0530, Abhijit Menon-Sen wrote:
> >
> > > At 2021-11-08 08:41:42 +0100, mjbaars1977.pgsql.hack...@gmail.com wrote:
> >
> > > > Could someone plea
On Sun, Nov 07, 2021 at 10:14:00PM +0100, Tomas Vondra wrote:
> I'd probably vote for "session variables". We can call it local/global
> session variables in the future, if we end up implementing that.
By chance, I ran into this pre-existing use of the phrase "session variable".
introduced since 8
On Tue, Aug 24, 2021 at 09:51:25PM -0700, Soumyadeep Chakraborty wrote:
> Ashwin and I recently got a chance to work on this and we addressed all
> outstanding feedback and suggestions. PFA a significantly reworked patch.
+static void
+StartWALReceiverEagerly()
+{
The patch fails to apply because
At 2021-11-08 10:10:55 +0100, mjbaars1977.pgsql.hack...@gmail.com wrote:
>
> > https://en.wikipedia.org/wiki/CRIME
>
> Well Abhijit, personally I don't see any connection between crime and
> compression.
Reading the page I linked to may help you make the connection. If not,
try any of the numerou
On Mon, Nov 8, 2021 at 10:11 AM Michael J. Baars <
mjbaars1977.pgsql.hack...@gmail.com> wrote:
> On Mon, 2021-11-08 at 13:30 +0530, Abhijit Menon-Sen wrote:
> > At 2021-11-08 08:41:42 +0100, mjbaars1977.pgsql.hack...@gmail.com wrote:
> > > Could someone please explain to me, why compression is bei
On Mon, 2021-11-08 at 13:30 +0530, Abhijit Menon-Sen wrote:
> At 2021-11-08 08:41:42 +0100, mjbaars1977.pgsql.hack...@gmail.com wrote:
> > Could someone please explain to me, why compression is being
> > considered unsafe / insecure?
>
> https://en.wikipedia.org/wiki/CRIME
>
Well Abhijit, person
Thanks Zhihong/Pavel,
On Mon, 8 Nov 2021 at 10:03, Pavel Stehule wrote:
>
>
> po 8. 11. 2021 v 5:24 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> po 8. 11. 2021 v 5:07 odesílatel Pavel Stehule
>> napsal:
>>
>>>
+set_errcurrent_query (const char *query)
You can remove the sp
At Thu, 4 Nov 2021 13:34:33 +0100, Daniel Gustafsson wrote in
> This patch again fails to apply (seemingly from the Perl namespace work on the
> testcode), and needs a few updates as per the above review.
Rebased the latest patch removing some of the chages.
0001: (I don't remember about this,
At 2021-11-08 08:41:42 +0100, mjbaars1977.pgsql.hack...@gmail.com wrote:
>
> Could someone please explain to me, why compression is being
> considered unsafe / insecure?
https://en.wikipedia.org/wiki/CRIME
> Might the underlying reason be, that certain people have shown
> interest in my libpq/PQb
70 matches
Mail list logo
