Hi,
On Mon, Apr 11, 2022 at 02:14:35PM -0700, Nathan Bossart wrote:
> On Mon, Apr 11, 2022 at 01:44:42PM -0700, Nathan Bossart wrote:
> > On Mon, Apr 11, 2022 at 04:36:36PM -0400, Robert Haas wrote:
> >> If we throw an error while defining_custom_guc is true, how will it
> >> ever again become
On Thu, Apr 7, 2022 at 2:09 PM Peter Smith wrote:
>
> FYI, here is a test script that is using the current patch (v6) to
> demonstrate a way to share table data between different numbers of
> nodes (up to 5 of them here).
>
> The script starts off with just 2-way sharing (nodes N1, N2),
> then
Hi,
I was going through pg_stat_recovery_prefetch documentation and saw an
issue with formatting. Attached a small patch to fix the issue. This is the
first time I am sending an email to hackers. Please educate me if I
miss something.
On Mon, Apr 11, 2022 at 6:33 PM Bharath Rupireddy
wrote:
>
> On Mon, Apr 11, 2022 at 4:21 PM Amit Kapila wrote:
> >
> > On Thu, Apr 7, 2022 at 3:35 PM Bharath Rupireddy
> > wrote:
> > >
> >
> > I am facing the below doc build failure on my machine due to this work:
> >
> > ./filelist.sgml:
> >
On Mon, Apr 11, 2022 at 11:03 PM Euler Taveira wrote:
>
> On Mon, Apr 11, 2022, at 7:40 AM, Amit Kapila wrote:
>
> Regarding the new examples (for partitioned tables), shouldn't we move the
> parent / child definitions to the beginning of the Examples section?
>
I think that will make examples
On Mon, Apr 11, 2022 at 06:48:58PM +1200, Thomas Munro wrote:
> 1. This test had some pre-existing bugs/races, which hadn't failed
> before due to scheduling, even under Valgrind. The above changes
> appear to fix those problems. To Michael for comment.
Yeah, there are two problems here. From
At Mon, 11 Apr 2022 12:48:25 +0200, Matthias van de Meent
wrote in
> On Mon, 11 Apr 2022 at 06:30, Kyotaro Horiguchi
> wrote:
> I won't speak for Robert H., but this might be because of gmail not
> putting this mail in the right thread: Your mail client dropped the
> "[was: pgsql: ...]" tag,
On Tue, Apr 12, 2022 at 11:31 AM houzj.f...@fujitsu.com
wrote:
>
> On Tuesday, April 12, 2022 8:40 AM Peter Smith wrote:
> >
> > FYI, I was playing with row filters and partitions recently, and while doing
> > something a bit unusual I received a cache leak warning.
> >
> > Below are the steps
On Tuesday, April 12, 2022 8:40 AM Peter Smith wrote:
>
> FYI, I was playing with row filters and partitions recently, and while doing
> something a bit unusual I received a cache leak warning.
>
> Below are the steps to reproduce it:
>
>
> test_pub=# CREATE TABLE parent(a int primary key)
Hi,
On Thu, Apr 7, 2022 at 4:37 PM Andres Freund wrote:
>
> Hi,
>
> On 2022-04-06 00:07:07 -0400, Tom Lane wrote:
> > Amit Langote writes:
> > > On Sun, Apr 3, 2022 at 10:31 PM Greg Stark wrote:
> > >> Is this a problem with the patch or its tests?
> > >> [18:14:20.798] Test Summary Report
> >
On Mon, 11 Apr 2022 at 22:11, John Naylor wrote:
>
> On Mon, Apr 11, 2022 at 5:34 AM David Rowley wrote:
>
> > With this particular test, v15 is about 15% *slower* than v14. I
> > didn't know what to blame at first, so I tried commenting out the sort
> > specialisations and got the results in
FYI, I was playing with row filters and partitions recently, and while
doing something a bit unusual I received a cache leak warning.
Below are the steps to reproduce it:
test_pub=# CREATE TABLE parent(a int primary key) PARTITION BY RANGE(a);
CREATE TABLE
test_pub=# CREATE TABLE child
On 4/11/22 4:11 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
My question is if we're only going to list out the settings that are
customized, are we going to:
1. Hide a setting if it matches a default value, even if a user set it
to be the default value? OR
2. Comment out all of the
On Mon, 11 Apr 2022 at 20:20, Tom Lane wrote:
>
> >> How about we just say "uses a linear-feedback shift register algorithm"?
I think it'd be sufficient to just say that it's a deterministic
pseudorandom number generator. I don't see much value in documenting
the internal algorithm used.
> >
On Mon, Apr 11, 2022 at 01:21:23PM -0700, SATYANARAYANA NARLAPURAM wrote:
> Correct. The idea is to make sure the file is fully allocated before
> treating it as a current file.
Another problem comes to compression, as the pre-padding cannot be
applied in this case because zlib and lz4 don't know
Hi,
On 2022-04-12 10:33:28 +1200, Thomas Munro wrote:
> Huh. I wouldn't have started a separate thread for this if I'd
> realised I was getting close to the cause of the CI failure...
:)
> Instead of bothering to create N different XXXPending variables for
> the different conflict "reasons",
On Mon, Apr 11, 2022 at 11:15:46AM -0400, Robert Haas wrote:
> +1 for this in general, but I think that naming like
> "compression_algo" stinks. If you think "compression_algorithm" is too
> long, I think you should use "algorithm" or "compression" or
> "compression_method" or something.
Yes, I
On Sun, Apr 10, 2022 at 11:00 AM Andres Freund wrote:
> On 2022-04-09 14:39:16 -0700, Andres Freund wrote:
> > On 2022-04-09 17:00:41 -0400, Tom Lane wrote:
> > > Thomas Munro writes:
> > > > Unlike most "procsignal" handler routines, RecoveryConflictInterrupt()
> > > > doesn't just set a
Thomas Munro writes:
> On Tue, Apr 12, 2022 at 8:58 AM Robert Haas wrote:
>> On Mon, Apr 11, 2022 at 2:20 PM Tom Lane wrote:
>>> I think we should make this a little less fragile. Since we
>>> already have XLogRecGetBlockTagExtended, I propose that callers
>>> that need to handle the case of
On Tue, Apr 12, 2022 at 8:58 AM Robert Haas wrote:
> On Mon, Apr 11, 2022 at 2:20 PM Tom Lane wrote:
> > Currently, XLogRecGetBlockTag has 41 callers, of which only four
> > bother to check the function's result. The remainder take it on
> > faith that they got valid data back, and many of them
On Mon, Apr 11, 2022 at 01:44:42PM -0700, Nathan Bossart wrote:
> On Mon, Apr 11, 2022 at 04:36:36PM -0400, Robert Haas wrote:
>> If we throw an error while defining_custom_guc is true, how will it
>> ever again become false?
>
> Ah, I knew I was forgetting something this morning.
>
> It won't,
On Mon, Apr 11, 2022 at 2:20 PM Tom Lane wrote:
> Currently, XLogRecGetBlockTag has 41 callers, of which only four
> bother to check the function's result. The remainder take it on
> faith that they got valid data back, and many of them will
> misbehave in seriously nasty ways if they didn't.
On Mon, Apr 11, 2022 at 04:36:36PM -0400, Robert Haas wrote:
> On Mon, Apr 11, 2022 at 12:44 PM Nathan Bossart
> wrote:
>> Here are some patches. 0001 reverts all the recent commits in this area,
>> 0002 is the patch I posted in August, and 0003 is an attempt at blocking
>> GUC changes in
On Mon, Apr 11, 2022 at 12:44 PM Nathan Bossart
wrote:
> Here are some patches. 0001 reverts all the recent commits in this area,
> 0002 is the patch I posted in August, and 0003 is an attempt at blocking
> GUC changes in preloaded libraries' _PG_init() functions.
If we throw an error while
On Mon, Apr 11, 2022 at 4:05 AM Antonin Houska wrote:
> There are't really that many kinds of files to encrypt:
>
> https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#List_of_the_files_that_contain_user_data
>
> (And pg_stat/* files should be removed from the list.)
This kind of gets
Christoph Berg writes:
> Plus maybe making initdb not set values to their default if the auto probing
> ends up at that values.
Seems a bit fragile: we'd have to make sure that initdb knew what the
boot_val is. IIRC, some of those are not necessarily immutable constants,
so there'd be room for
On Sun, Apr 10, 2022 at 11:16 PM Kyotaro Horiguchi
wrote:
> Sorry for the terrible typos..
>
> At Sat, 9 Apr 2022 18:03:01 +0530, Bharath Rupireddy <
> bharath.rupireddyforpostg...@gmail.com> wrote in
> > On Tue, Jan 4, 2022 at 1:40 AM SATYANARAYANA NARLAPURAM
> > wrote:
> > >
> > > On Sun, Jan
Plus maybe making initdb not set values to their default if the auto probing
ends up at that values.
Christoph
"Jonathan S. Katz" writes:
> My question is if we're only going to list out the settings that are
> customized, are we going to:
> 1. Hide a setting if it matches a default value, even if a user set it
> to be the default value? OR
> 2. Comment out all of the settings in a generated
On Mon, 2022-04-11 at 15:21 -0400, Robert Haas wrote:
> ... before v13, the commit in question actually
> changed the size of PGXACT, which is really quite bad -- it needs to
> be 12 bytes for performance reasons. And there's no spare bytes
> available, so I think we should follow one of the
On 4/11/22 3:12 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
On 4/9/22 12:27 PM, Tom Lane wrote:
Sure, but then you do "\dconfig *". With there being several hundred
GUCs (and no doubt more coming), I'm not sure that "show me every GUC"
is a common use-case at all, let alone so common as
On Fri, Apr 8, 2022 at 11:50 AM Robert Haas wrote:
> On Fri, Apr 8, 2022 at 4:47 AM Markus Wanner
> wrote:
> > I agree with Michael, it would be nice to not duplicate the code, but
> > use a common underlying method. A modified patch is attached.
>
> I don't think this is better, but I don't
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>> How about we just say "uses a linear-feedback shift register algorithm"?
> That works for me. Nice and simple, and not overly specific. Should we
> perhaps also add a warning that the same seed is not guaranteed to
>
"Jonathan S. Katz" writes:
> On 4/9/22 12:27 PM, Tom Lane wrote:
>> Sure, but then you do "\dconfig *". With there being several hundred
>> GUCs (and no doubt more coming), I'm not sure that "show me every GUC"
>> is a common use-case at all, let alone so common as to deserve being
>> the
Tom Lane writes:
> =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
>> I just noticed that the since the random() rewrite¹, the documentation's
>> claim² that it "uses a simple linear congruential algorithm" is no
>> longer accurate (xoroshiro128** is an xorshift variant, which is a
>>
On Mon, 11 Apr 2022, 15:55 Robert Haas, wrote:
> On Fri, Apr 8, 2022 at 11:10 AM Robert Haas wrote:
> > On Fri, Apr 8, 2022 at 10:45 AM Thom Brown wrote:
> > > Thanks. This doesn't include my self-correction:
> > >
> > > s/kept on standby/kept on the standby/
> >
> > Here is v2, endeavoring to
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> I just noticed that the since the random() rewrite¹, the documentation's
> claim² that it "uses a simple linear congruential algorithm" is no
> longer accurate (xoroshiro128** is an xorshift variant, which is a
> linear-feedback shift register
Greetings,
* Qiongwen Liu (qiongwen7...@berkeley.edu) wrote:
> Hi, I am Qiongwen Liu, and I am studying at the University of California,
> Berkeley as an economics and computer science major. I am interested in the
> Develop Performance Farm Benchmarks and Website of PostgreSQL in
> this program,
Greetings,
* Samuel Bassaly (shksh...@gmail.com) wrote:
> My name is Samuel Bassaly, and I would like to submit my proposal for this
> year's GSoC.
> Your feedback is highly appreciated.
Great, thanks! Will respond off-list.
Stephen
signature.asc
Description: PGP signature
Hi Hackers,
I just noticed that the since the random() rewrite¹, the documentation's
claim² that it "uses a simple linear congruential algorithm" is no
longer accurate (xoroshiro128** is an xorshift variant, which is a
linear-feedback shift register algorithm).
I don't have a suggestion for the
On Fri, Apr 08, 2022 at 05:16:06PM +0200, Gilles Darold wrote:
> Attached v7 of the patch that should pass cfbot.
Thanks for the new patch! Unfortunately, it looks like some recent changes
have broken it again.
> +enum trivalue schema_is_exclude = TRI_DEFAULT;
> +
> +/*
> + * The kind of object
Currently, XLogRecGetBlockTag has 41 callers, of which only four
bother to check the function's result. The remainder take it on
faith that they got valid data back, and many of them will
misbehave in seriously nasty ways if they didn't. (This point
was drawn to my attention by a Coverity
On Mon, Apr 11, 2022 at 6:48 AM Matthias van de Meent
wrote:
> So, this might be the reason Robert overlooked your declaration to
> volunteer: he was looking for volunteers in the thread "Re: API
> Stability [was: pgsql: ...]" in the Gmail UI, which didn't show your
> messages there because of
On Mon, Apr 11, 2022 at 4:56 AM David Rowley wrote:
> 0011 (Could do with input from Robert and Joe)
Seems like a reasonable change to me.
--
Robert Haas
EDB: http://www.enterprisedb.com
> I'm planning to work on the initial DDL replication. I'll open a new thread as
> soon as I write a design for it. Just as an example, the pglogical approach is
> to use pg_dump behind the scenes to provide the schema [1]. It is a reasonable
> approach but an optimal solution should be an API to
On Mon, Apr 11, 2022, at 7:40 AM, Amit Kapila wrote:
> On Mon, Apr 11, 2022 at 12:39 PM Peter Smith wrote:
> >
> > On Fri, Apr 8, 2022 at 4:12 PM Peter Smith wrote:
> >
> > OK. Added in v7 [1]
> >
>
> Thanks, this looks mostly good to me. I didn't like the new section
> added for partitioned
Hi Amit,
> Some initial comments:
> ===
> 1.
> +/*
> + * Write logical decoding DDL message into XLog.
> + */
> +XLogRecPtr
> +LogLogicalDDLMessage(const char *prefix, Oid roleoid, const char *message,
> + size_t size, bool transactional)
>
> I don't see anywhere the patch using a
On Mon, Apr 11, 2022 at 12:28:47PM -0400, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 11, 2022 at 5:12 AM Kyotaro Horiguchi
>> wrote:
>>> If this diagnosis is correct, the comment is proved to be paranoid.
>
>> It's sometimes difficult to understand what problems really old code
>>
On Mon, Apr 11, 2022 at 10:47:17AM -0400, Robert Haas wrote:
> On Sat, Apr 9, 2022 at 9:24 AM Julien Rouhaud wrote:
>> > FWIW I would be on board with reverting all the GetMaxBackends() stuff if
>> > we made the value available in _PG_init() and stopped supporting GUC
>> > overrides by extensions
Hi,
> > Good catch. The reason for having isTopLevel in the condition is
> > because I haven't decided if a DDL statement inside a PL should
> > be replicated from the user point of view. For example, if I execute a
> > plpgsql function or a stored procedure which creates a table under the hood,
Robert Haas writes:
> On Mon, Apr 11, 2022 at 5:12 AM Kyotaro Horiguchi
> wrote:
>> If this diagnosis is correct, the comment is proved to be paranoid.
> It's sometimes difficult to understand what problems really old code
> comments are worrying about. For example, could they have been
>
Justin Pryzby writes:
> On Mon, Apr 11, 2022 at 11:54:11AM -0400, Andrew Dunstan wrote:
>> I will deal with the structural issues soon.
> I didn't actually intend this as a complaint. The ability for a reference to
> be specific and granular is good. So there may be reasons to change the
>
On Mon, Apr 11, 2022 at 5:12 AM Kyotaro Horiguchi
wrote:
> So, the only thing we need to care is segment switch. Without it, the
> segment that InstallXLogFileSegment found by the stat loop is known to
> be safe to overwrite even if exists.
>
> When segment switch finds an existing file, it's no
On Mon, Apr 11, 2022 at 11:54:11AM -0400, Andrew Dunstan wrote:
> >> BTW, the documentation references look a little like OIDs...
> >> Does someone already have an SNMP-based doc browser ?
> >> | For details, see Section 9.16.3.4.2.
> >
> > I already had a couple of these items on my list but I
On 2022-04-08 Fr 08:15, Andrew Dunstan wrote:
> On 4/8/22 08:02, Justin Pryzby wrote:
>> On Thu, Mar 31, 2022 at 04:25:58PM -0400, Andrew Dunstan wrote:
>>> No code chunks left, only a documentation patch which should land
>> Documentation review for a6baa4bad.
>>
>>> Construct a JSON the
Hi,
On Mon, Apr 11, 2022 at 10:47:17AM -0400, Robert Haas wrote:
> On Sat, Apr 9, 2022 at 9:24 AM Julien Rouhaud wrote:
>
> > On the bright side, I see that citus is using SetConfigOption() to increase
> > max_prepared_transactions [1]. That's the only extension mentioned in that
> > thread
Hi,
On Sun, Apr 10, 2022 at 03:43:33PM -0500, Justin Pryzby wrote:
> On Sun, Apr 10, 2022 at 08:30:39PM +0200, Pavel Stehule wrote:
> > I am sending fresh rebased patch + separation to more patches. This split
> > is initial, and can be changed later
>
> The 0001 patch requires this, but it's
Peter Eisentraut writes:
> On 08.04.22 22:26, Tom Lane wrote:
>>> I think we should put a centralized level check
>>> into logging.c, and get rid of at least the "if (likely())"
>>> checks, because those are going to succeed approximately 100.0%
>>> of the time. Maybe there's an argument for
On Mon, Apr 11, 2022 at 2:52 AM Michael Paquier wrote:
> Since ba5 and the introduction of LZ4, I have reworked the way
> compression is controlled for pg_receivewal, with two options:
> - --compress-method, settable to "gzip", "none" or "lz4".
> - --compress, to pass down a compression
On Mon, Apr 11, 2022 at 7:06 AM Justin Pryzby wrote:
> On Sat, Apr 02, 2022 at 07:21:11PM +0200, Alvaro Herrera wrote:
> > Small things here.
>
> > 1. in VACUUM FULL we only process partitions that are owned by the
> > invoking user. We don't have this test in the new code. I'm not sure
> >
On 08.04.22 22:26, Tom Lane wrote:
I wrote:
One other loose end is bothering me: I stuck with logging.h's
original choice to put "if (likely())" or "if (unlikely())"
conditionals into the macros, but I rather suspect that that's
just a waste. I think we should put a centralized level check
On Fri, Apr 8, 2022 at 11:10 AM Robert Haas wrote:
> On Fri, Apr 8, 2022 at 10:45 AM Thom Brown wrote:
> > Thanks. This doesn't include my self-correction:
> >
> > s/kept on standby/kept on the standby/
>
> Here is v2, endeavoring to rectify that oversight.
Committed.
--
Robert Haas
EDB:
On Sat, Apr 9, 2022 at 9:24 AM Julien Rouhaud wrote:
> > FWIW I would be on board with reverting all the GetMaxBackends() stuff if
> > we made the value available in _PG_init() and stopped supporting GUC
> > overrides by extensions (e.g., ERROR-ing in SetConfigOption() when
> >
On Sat, Apr 02, 2022 at 07:21:11PM +0200, Alvaro Herrera wrote:
> Small things here.
> 1. in VACUUM FULL we only process partitions that are owned by the
> invoking user. We don't have this test in the new code. I'm not sure
> why do we do that there; is it worth doing the same here?
That
Julien Rouhaud writes:
> On Mon, Apr 11, 2022 at 03:58:01PM +0900, Michael Paquier wrote:
>> On Mon, Apr 11, 2022 at 02:08:38PM +0800, Julien Rouhaud wrote:
>>> I just noticed that parse_jsontable.c was added with a wrong copyright year,
>>> trivial patch attached.
>> Thanks, I'll go fix that in
On Mon, Apr 11, 2022 at 4:21 PM Amit Kapila wrote:
>
> On Thu, Apr 7, 2022 at 3:35 PM Bharath Rupireddy
> wrote:
> >
>
> I am facing the below doc build failure on my machine due to this work:
>
> ./filelist.sgml:
> Tabs appear in SGML/XML files
> make: *** [check-tabs] Error 1
>
> The attached
On Mon, Apr 11, 2022, at 2:00 AM, Amit Kapila wrote:
> On Thu, Apr 7, 2022 at 3:46 PM Amit Kapila wrote:
> >
> > On Wed, Mar 23, 2022 at 10:39 AM Japin Li wrote:
> >
> > 2. For DDL replication, do we need to wait for a consistent point of
> > snapshot? For DMLs, that point is a convenient point
On Monday, April 11th, 2022 at 8:52 AM, Michael Paquier
wrote:
> This is something I think we had better fix before beta1, because now
> we have binaries that use an inconsistent set of options. So,
> attached is a patch set aimed at rework this option set from the
> ground, taking advantage
On Tue, Apr 05, 2022 at 05:14:09PM -0400, Greg Stark wrote:
> This is not passing regression tests due to some details of the plan
> output - marking Waiting on Author:
It's unstable due to parallel workers.
I'm not sure what the usual workarounds here.
Maybe set parallel_leader_participation=no
On Tue, Mar 22, 2022 at 2:00 AM Andres Freund wrote:
>
> Currently fails to apply, please rebase:
> http://cfbot.cputube.org/patch_37_3450.log
>
> Marked as waiting-on-author.
>
> Please, find attached a rebased version, no other significant change.
Regards,
Juan José Santamaría Flecha
On Thu, Apr 7, 2022 at 3:35 PM Bharath Rupireddy
wrote:
>
I am facing the below doc build failure on my machine due to this work:
./filelist.sgml:
Tabs appear in SGML/XML files
make: *** [check-tabs] Error 1
The attached patch fixes this for me.
--
With Regards,
Amit Kapila.
On Mon, 11 Apr 2022 at 06:30, Kyotaro Horiguchi wrote:
>
> (a bit off-topic)
>
> I'm not sure where I am..
>
> At Wed, 06 Apr 2022 10:36:30 +0900 (JST), Kyotaro Horiguchi
> wrote in
> me> > this if nobody else would like to do it, but let me ask whether
> me> > Kyotaro Horiguchi would like to
On Mon, Apr 11, 2022 at 3:55 PM Masahiko Sawada wrote:
>
> On Mon, Apr 11, 2022 at 7:10 PM Justin Pryzby wrote:
> >
> > Amit or Masahiko may want to comment on 0012 (doc review: Add ALTER
> > SUBSCRIPTION ... SKIP).
>
> Thank you for the patch! I've looked at 0012 patch. Regarding the
>
On Mon, Apr 11, 2022 at 12:39 PM Peter Smith wrote:
>
> On Fri, Apr 8, 2022 at 4:12 PM Peter Smith wrote:
>
> OK. Added in v7 [1]
>
Thanks, this looks mostly good to me. I didn't like the new section
added for partitioned tables examples, so I removed it and added some
explanation of the tests.
On Mon, Apr 11, 2022 at 7:10 PM Justin Pryzby wrote:
>
> On Mon, Apr 11, 2022 at 04:39:30PM +1200, David Rowley wrote:
> > I'm not entirely certain this is an improvement. Your commit message
> > I'd say is not true going by git grep "compression algorithm". There
> > are 3 matches in the docs
On Mon, Apr 11, 2022 at 04:39:30PM +1200, David Rowley wrote:
> I'm not entirely certain this is an improvement. Your commit message
> I'd say is not true going by git grep "compression algorithm". There
> are 3 matches in the docs and take [1], for example. I'd say in that
> one it's better to
On Mon, Apr 11, 2022 at 5:34 AM David Rowley wrote:
> With this particular test, v15 is about 15% *slower* than v14. I
> didn't know what to blame at first, so I tried commenting out the sort
> specialisations and got the results in the red bars in the graph. This
> made it about 7.5% *faster*
On Mon, Apr 11, 2022 at 03:58:01PM +0900, Michael Paquier wrote:
> On Mon, Apr 11, 2022 at 02:08:38PM +0800, Julien Rouhaud wrote:
> > I just noticed that parse_jsontable.c was added with a wrong copyright year,
> > trivial patch attached.
>
> Thanks, I'll go fix that in a bit. I am spotting
At Thu, 7 Apr 2022 11:29:54 -0700, Nathan Bossart
wrote in
> The attached patch prevents this problem by using durable_rename() instead
> of durable_rename_excl() for WAL recycling. This removes the protection
> against accidentally overwriting an existing WAL file, but there shouldn't
> be
On Tuesday, December 14, 2021 3:42 PM houzj.f...@fujitsu.com
wrote:
>
> On Sat, Nov 20, 2021 7:31 PM Amit Kapila wrote:
> > On Fri, Nov 19, 2021 at 10:58 AM Amit Kapila
> > wrote:
> > >
> > > On Fri, Nov 19, 2021 at 7:19 AM Amit Langote
> > >
> > wrote:
> > > >
> > > > The problematic case
On Mon, 11 Apr 2022 at 16:39, David Rowley wrote:
> I will start pushing the less controversial of these, after a bit of
> squashing.
I just committed 3 separate commits for the following:
Committed: 0001 + 0003 + 0004 + 0006 + 0007 (modified) + 0008 + 0009 +
0012 (doc parts)
Committed: 0012
孔凡深(云梳) wrote:
> Hi, Antonin. I am more interested in zheap. Recently reviewing the patch you
> submitted.
> When I use pg_undodump-tool to dump the undo page chunk, I found that some
> chunk header is abnormal.
> After reading the relevant codes in
>
To Whom It May Concern,
Hi, I am Qiongwen Liu, and I am studying at the University of California,
Berkeley as an economics and computer science major. I am interested in the
Develop Performance Farm Benchmarks and Website of PostgreSQL in
this program, attached below is my application. Please
Robert Haas wrote:
> On Fri, Apr 8, 2022 at 4:54 AM Antonin Houska wrote:
> > Do you think that the use of a system call is a problem itself (e.g. because
> > the code looks less simple if read/write is used somewhere and fread/fwrite
> > elsewhere; of course of read/write is mandatory in
On Thu, Apr 7, 2022 at 10:05 AM Amit Langote wrote:
> There were rebase conflicts with the recently committed
> execPartition.c/h changes. While fixing them, I thought maybe
> find_leaf_part_for_key() doesn't quite match in style with its
> neighbors in execPartition.h, so changed it to
>
On Mon, Apr 11, 2022 at 06:48:58PM +1200, Thomas Munro wrote:
> Sorry for the delay... I got a bit confused about the different things
> going on in this thread but I hope I've got it now:
>
> 1. This test had some pre-existing bugs/races, which hadn't failed
> before due to scheduling, even
On Mon, Apr 11, 2022 at 2:39 PM I wrote:
> Attach the new patch.
Also, share test results and details.
To check that the lsn information used for the calculation is what we expected,
I get some information by adding logs in the function LagTrackerRead.
Summary of test results:
- In current HEAD
On Mon, Apr 11, 2022 at 1:27 PM Amit Kapila wrote:
>
> On Fri, Apr 8, 2022 at 11:42 AM Peter Smith wrote:
> >
> > On Wed, Apr 6, 2022 at 8:58 PM Amit Kapila wrote:
> > >
> >
> > > 3.
> > > +
> > > +Whenever an UPDATE is processed, the row filter
> > > +expression is evaluated for
On Fri, Apr 8, 2022 at 4:12 PM Peter Smith wrote:
>
> On Wed, Apr 6, 2022 at 8:58 PM Amit Kapila wrote:
> >
> > On Thu, Mar 24, 2022 at 11:48 AM Peter Smith wrote:
> > >
> >
> > Review comments:
> > ===
[snip]
>
> > 9. I suggest adding an example for partition tables showing how the
On 4/11/22 02:57, Michael Paquier wrote:
On Fri, Apr 08, 2022 at 04:23:48PM +0200, Frédéric Yhuel wrote:
Thank you Michael.
And done as of 8ac700a.
--
Thank you Micheal!
For reference purposes, we can see in the code of get_relation_info(),
in plancat.c, that indeed every index of the
PSA patch v7 which addresses all the remaining review comments (from
Amit [1a][1b], and from Alvaro [2]).
--
[1a]
https://www.postgresql.org/message-id/CAHut%2BPvDFWGUOBugYMtcXhAiViZu%2BQ6P-kxw2%2BU83VOGx0Osdg%40mail.gmail.com
[1b]
On Mon, Apr 11, 2022 at 02:08:38PM +0800, Julien Rouhaud wrote:
> I just noticed that parse_jsontable.c was added with a wrong copyright year,
> trivial patch attached.
Thanks, I'll go fix that in a bit. I am spotting four more, as of
src/backend/replication/basebackup_*.c that point to 2020.
--
Hi all,
(Added Robert and Georgios in CC:)
Since ba5 and the introduction of LZ4, I have reworked the way
compression is controlled for pg_receivewal, with two options:
- --compress-method, settable to "gzip", "none" or "lz4".
- --compress, to pass down a compression level, where the allowed
On Sat, Apr 9, 2022 at 12:59 PM Andres Freund wrote:
> On 2022-04-08 17:55:51 -0400, Tom Lane wrote:
> > I tried adjusting the patch so it does guarantee that (as attached),
> > and in two out of two tries it got past the archive_cleanup_command
> > failure but then hung up waiting for standby2
On Wed, Apr 7, 2022 at 1:34 PM Amit Kapila wrote:
> On Wed, Apr 6, 2022 at 6:30 PM wangw.f...@fujitsu.com
> wrote:
> >
> > On Wed, Apr 6, 2022 at 1:58 AM Amit Kapila wrote:
> > On Wed, Apr 6, 2022 at 4:32 AM Amit Kapila wrote:
> > > Also, let's try to evaluate how it impacts lag functionality
Thanks for all of your opinions. I have almost the same feeling.
The best layer for mitigation should be probably a user application.
There can be arranged the correct data layout in the database, set up
access limit for the app, and many other mitigation mechanisms.
-Filip-
st 6. 4. 2022
Sorry for the terrible typos..
At Sat, 9 Apr 2022 18:03:01 +0530, Bharath Rupireddy
wrote in
> On Tue, Jan 4, 2022 at 1:40 AM SATYANARAYANA NARLAPURAM
> wrote:
> >
> > On Sun, Jan 2, 2022 at 11:56 PM Michael Paquier wrote:
> >> Are you referring to the pre-padding when creating a new partial
At Sat, 9 Apr 2022 18:03:01 +0530, Bharath Rupireddy
wrote in
> On Tue, Jan 4, 2022 at 1:40 AM SATYANARAYANA NARLAPURAM
> wrote:
> >
> > On Sun, Jan 2, 2022 at 11:56 PM Michael Paquier wrote:
> >> Are you referring to the pre-padding when creating a new partial
> >> segment, aka when we write
Hi,
I just noticed that parse_jsontable.c was added with a wrong copyright year,
trivial patch attached.
While at it I also see that a lot of Spanish translation files seems to be
stuck in 2019, but those were fixed in the pgtranslation repo last June so they
will get synced eventually.
>From
99 matches
Mail list logo
