On 3/16/22 13:33, Thomas Munro wrote:
It seems that the warning at line 8313 is essentially dead code now. I
don't expect test code to have an impact on production systems, even if
the effect is minor.
It's not dead, it's how we'd report something like EACCES or EIO. Why
we only warn and pre
On 3/15/22 23:42, Kyotaro Horiguchi wrote:
At Wed, 16 Mar 2022 11:13:53 +1300, Thomas Munro wrote
in
On Wed, Mar 16, 2022 at 10:28 AM Tom Lane wrote:
David Steele writes:
On 3/14/22 19:31, Thomas Munro wrote:
Fix pg_basebackup with in-place tablespaces.
Perhaps I'm being picky
On 3/14/22 19:31, Thomas Munro wrote:
Fix pg_basebackup with in-place tablespaces.
Previously, pg_basebackup from a cluster that contained an 'in-place'
tablespace, as introduced by commit 7170f215, would produce a harmless
warning on Unix and fail completely on Windows.
Perhaps I'm being pick
On 6/25/20 11:02 AM, Magnus Hagander wrote:
On Thu, Jun 25, 2020 at 4:56 PM David Steele <mailto:da...@pgmasters.net>> wrote:
So we added that to session initialization in pgBackRest:
https://github.com/pgbackrest/pgbackrest/commit/ea04ec7b3f4c6cf25c1b827c25c6a3c5896159a8
P
On 6/25/20 8:43 AM, Magnus Hagander wrote:
On Thu, Jun 25, 2020 at 2:11 PM David Steele <mailto:da...@pgmasters.net>> wrote:
On 6/24/20 6:27 PM, Tom Lane wrote:
>
> I was able to force it like this:
>
> regression=# set force_parallel_mode TO 'on
On 6/24/20 6:27 PM, Tom Lane wrote:
David Steele writes:
... So apparently it is possible. To get them working as soon as possible I
recommended that they run:
alter role postgres set max_parallel_workers_per_gather = 0;
And that solved their problem. 9.6 is getting on in years so I'm not
On 3/6/17 3:28 PM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
David Steele writes:
On 3/6/17 12:48 PM, Robert Haas wrote:
This issue also exists in 9.6, but we obviously can't do anything
about 9.6 clusters that already exist. Possibly this could be
back-patched so
On 4/7/20 7:32 PM, Alexander Korotkov wrote:
On Wed, Apr 8, 2020 at 1:34 AM Anna Akenteva wrote:
On 2020-04-08 00:45, David G. Johnston wrote:
While there is lots of discussion it ended up with the thread at
"returned with feedback" (a month ago) and now we have a commit.
There seems to be
On 3/5/20 8:10 PM, Michael Paquier wrote:
On Thu, Mar 05, 2020 at 07:58:50PM -0500, David Steele wrote:
Yeah, keeping BLKSZ a constant is pretty important for performance. That's
one of the main reasons that we only support the default.
Doing something is not complicated, now how would p
On 3/5/20 7:48 PM, Michael Paquier wrote:
On Thu, Mar 05, 2020 at 04:14:20PM -0800, Magnus Hagander wrote:
That's a pretty dangerous mistake, and moreso because we don't have a
test around it. We should really find a way to add such a test -- just
a hardcoded page calculation that should always
On 3/5/20 6:30 PM, Michael Paquier wrote:
On Thu, Mar 05, 2020 at 12:51:50PM -0500, David Steele wrote:
Bit of a bummer that this passed make check-world, but the pgBackRest tests
definitely did not like it.
Is that because you have a copy of this routine in your code?
Yes, we pull this
On 3/5/20 7:14 PM, Magnus Hagander wrote:
On Thu, Mar 5, 2020 at 3:30 PM Michael Paquier wrote:
On Thu, Mar 05, 2020 at 12:51:50PM -0500, David Steele wrote:
Looks like you changed 65535 -> 65536 before commit. I checked the original
patch and it has 65535.
That's my fault, th
Hi Michael,
On 3/5/20 12:13 AM, Michael Paquier wrote:
Avoid -Wconversion warnings when using checksum_impl.h
This does not matter much when compiling Postgres proper as many
warnings exist when enabling this compilation flag, but it can be
annoying for external modules willing to use both.
L
On 11/6/19 4:49 AM, Fujii Masao wrote:
On Wed, Nov 6, 2019 at 4:29 PM Peter Eisentraut
wrote:
On 2019-11-06 05:48, Fujii Masao wrote:
Patch attached. As I argued upthread, IMO it's better to remove
the latter description from the doc and the patch does that.
Also the patch adds "mainly" into
On 9/29/19 11:02 PM, Fujii Masao wrote:
> On Mon, Sep 30, 2019 at 11:45 AM Michael Paquier wrote:
>>
>> Hi Fujii-san,
>>
>> On Mon, Sep 30, 2019 at 01:21:00AM +, Fujii Masao wrote:
>>> Make crash recovery ignore recovery target settings.
>>>
>>> In v11 or before, recovery target settings could
On 11/9/18 10:30 PM, Andres Freund wrote:
> On 2018-11-09 21:45:18 -0500, David Steele wrote:
>> On 10/5/18 1:03 PM, David Steele wrote:
>>>
>>> So, while the WAL segment size used to be expressed in terms of 8K pages
>>> it is now expressed in terms of abso
On 10/5/18 1:03 PM, David Steele wrote:
> Hi Andres,
>
> On 10/5/18 5:54 PM, Andres Freund wrote:
>> On 2018-09-20 11:48:08 -0400, David Steele wrote:
>>
>>> diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
>>> index e1073ac6d3..3bfd172441 10
Hi Andres,
On 10/5/18 5:54 PM, Andres Freund wrote:
On 2018-09-20 11:48:08 -0400, David Steele wrote:
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index e1073ac6d3..3bfd172441 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -8440,10 +8440,8
On 9/21/18 12:44 PM, David Steele wrote:
On 9/21/18 12:53 AM, Michael Paquier wrote:
On Thu, Sep 20, 2018 at 06:23:54PM -0700, Andres Freund wrote:
16*M*B, right? If so, that's normal - pg_settings just reports the
values in the underlying unit - which is XLOG_BLCKSZ, compile-time
defau
On 9/21/18 12:53 AM, Michael Paquier wrote:
> On Thu, Sep 20, 2018 at 06:23:54PM -0700, Andres Freund wrote:
>> 16*M*B, right? If so, that's normal - pg_settings just reports the
>> values in the underlying unit - which is XLOG_BLCKSZ, compile-time
>> defaulting to 8KB. 8192 * 2048 = 16MB. That's
On 9/20/18 7:59 PM, Michael Paquier wrote:
> On Thu, Sep 20, 2018 at 11:48:08AM -0400, David Steele wrote:
>>
>>
>>
>> -Reports the number of blocks (pages) in a WAL segment file.
>> -The total size of a WAL
Hi Andres,
On 9/20/17 1:04 AM, Andres Freund wrote:
>
> Make WAL segment size configurable at initdb time.
<...>
> https://git.postgresql.org/pg/commitdiff/fc49e24fa69a15efacd5b8958115ed9c43c48f9a
It appears that fc49e24f missed updating the runtime config presets
documentation.
Patch attached.
On 4/3/18 4:48 PM, Michael Banck wrote:
Attached is a patch which does that hopefully:
1. creates two user tables, one large enough for at least 6 blocks
(around 360kb), the other just one block.
2. stops the cluster before scribbling over its data and starts it
afterwards.
3. uses the blocks
On 3/27/18 10:24 AM, Teodor Sigaev wrote:
>> Hm, seems, Windows doesn't like this patch
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2018-03-27
>>
>
> sorry for wrong URL
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2018-03-27%2013%3A30%3A24
Lo
On 3/27/18 10:17 AM, Teodor Sigaev wrote:
> Hm, seems, Windows doesn't like this patch
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2018-03-27
Will do. Probably a path problem, which hopefully I can fix with the new
function Andrew wrote.
--
-David
da...@pgmasters.net
On 3/25/18 3:54 PM, Tom Lane wrote:
> David Steele writes:
>> On 3/25/18 3:22 PM, Tom Lane wrote:
>>> Actually, that code didn't guarantee zero termination under *any*
>>> circumstances; it only happened to work if the stack contained
>>> zeroes to start
On 3/25/18 3:22 PM, Tom Lane wrote:
> David Steele writes:
>> On 3/25/18 2:16 PM, Tom Lane wrote:
>>> Buildfarm member skink (valgrind) has reported this during its last couple
>>> of runs:
>
>> I think skink is using large values for rel oids and that has ex
On 3/25/18 2:16 PM, Tom Lane wrote:
> Teodor Sigaev writes:
>> Exclude unlogged tables from base backups
>
> Buildfarm member skink (valgrind) has reported this during its last couple
> of runs:
>
> 2018-03-24 03:18:23.409 UTC [17302] 010_pg_basebackup.pl LOG: received
> replication command: B
On 3/23/18 11:49 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> Fix interaction of Perl and stdbool.h
>
> Not sure if this broke it or it was already broken, but my compiler
> is now very unhappy.
>
> In file included from /usr/lib64/perl5/CORE/perl.h:2424,
> from plperl.h:60
On 3/19/18 5:58 PM, Andrew Dunstan wrote:
> On Mon, Mar 19, 2018 at 11:33 PM, David Steele wrote:
>> On 3/19/18 4:15 AM, Andrew Dunstan wrote:
>>>
>>> The attached fixes it. We should probably put the function or something
>>> like it in TestLib.pm, though.
On 3/19/18 4:15 AM, Andrew Dunstan wrote:
>
> The attached fixes it. We should probably put the function or something
> like it in TestLib.pm, though. The call to pwd is quite tricky - it
> needs to be done pretty much exactly like this, not quite sure why, but
> direct calls to "pwd -W" via syste
On 3/15/18 11:51 PM, Tom Lane wrote:
> I wrote:
>> Peter Eisentraut writes:
>>> Add tests for reinit.c
>
>> BTW, buildfarm member jacana hasn't succeeded at this test once.
>> The failures look like
>
>> ok 1 - init fork in base exists
>> ok 2 - main fork in base exists
>> error running SQL: 'ps
32 matches
Mail list logo
