On Sun, Jan 16, 2022 at 6:03 PM DEVOPS_WwIT wrote:
> Solaris and FreeBSD supports large/super pages, and can be used
> automatically by applications.
>
> Seems Postgres can't use the large/super pages on Solaris and FreeBSD
> os(I think can't use the large/super page HPUX and AIX), is there
On Fri, Nov 19, 2021 at 09:18:23PM -0800, Noah Misch wrote:
> On Wed, Nov 17, 2021 at 11:05:06PM -0800, Noah Misch wrote:
> > On Wed, Nov 17, 2021 at 05:47:10PM -0500, Tom Lane wrote:
> > > Noah Misch writes:
> > > > Each of the three failures happened on a sparc64 Debian+gcc machine. I
> > > >
> 15 янв. 2022 г., в 20:46, Justin Pryzby написал(а):
>>>
>>> I was planning on running a set of stress tests on these patches. Could
>>> we confirm which ones we plan to include in the commitfest?
>>
>> Many thanks for your interest. Here's the latest version.
>
> This is failing to
Hi Hacker
Solaris and FreeBSD supports large/super pages, and can be used
automatically by applications.
Seems Postgres can't use the large/super pages on Solaris and FreeBSD
os(I think can't use the large/super page HPUX and AIX), is there anyone
could take a look?
following is my
Hi,
On Mon, Oct 18, 2021 at 10:56:53AM +0530, Amul Sul wrote:
>
> Attached is the rebased and updated version. The patch removes the
> newly introduced PerformRecoveryXLogAction() function. In addition to
> that, removed the CHECKPOINT_END_OF_RECOVERY flag and its related
> code. Also, dropped
Hi,
On Fri, Dec 24, 2021 at 07:21:59PM +0900, Kyotaro Horiguchi wrote:
> Just a complaint..
>
> At Fri, 12 Nov 2021 16:43:27 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > "" on Japanese (CP-932) environment. I didn't actually
> > tested it on Windows and msys environment ...yet.
>
> Active
Hi,
On Thu, Jan 06, 2022 at 05:29:23PM +0900, Etsuro Fujita wrote:
>
> Done. Attached is a new version.
The patchset doesn't apply anymore:
http://cfbot.cputube.org/patch_36_3392.log
=== Applying patches on top of PostgreSQL commit ID
43c2175121c829c8591fc5117b725f1f22bfb670 ===
=== applying
I wrote:
> Another thing that is bothering me a bit is that a number of the
> callers use $node->lsn('insert') as the target. This also seems
> rather dubious, because that could be ahead of what's been written
> out. These callers are just taking it on faith that something will
> eventually
On 1/15/22 06:12, Fujii Masao wrote:
On 2022/01/12 1:07, Tomas Vondra wrote:
I explored the idea of using page LSN a bit
Many thanks!
The patch from 22/12 simply checks if the change should/would wait for
sync replica, and if yes it WAL-logs the sequence increment. There's a
couple
On 1/15/22 19:35, Tomas Vondra wrote:
On 1/15/22 06:11, Justin Pryzby wrote:
On Mon, Dec 13, 2021 at 09:40:09PM +0100, Tomas Vondra wrote:
1) If the table is a separate relation (not part of an inheritance
tree), this should make no difference. -> OK
2) If the table is using "old"
Sergey Shinderuk writes:
> On 14.01.2022 13:01, Sergey Shinderuk wrote:
>> Unexpectedly, this changes the error message:
> ...
> For the record, after more poking I realized that it depends on timing.
> By injecting delays I can get any of the following from libpq:
> * could not receive data
Peter Eisentraut writes:
> The rest of the patch seems ok in principle, since AFAICT enums are the
> only query result in tab-complete.c that are not identifiers and thus
> subject to case issues.
I spent some time looking at this patch. I'm not very happy with it,
for two reasons:
1. The
On Sat, Jan 15, 2022 at 08:39:14PM +0300, Michail Nikolaev wrote:
> Hello, Junien.
>
> Thanks for your attention.
>
> > The cfbot reports that this patch is currently failing at least on
> > Linux and Windows, e.g. https://cirrus-ci.com/task/6532060239101952.
>
> Fixed. It was the issue with
On 1/15/22 06:11, Justin Pryzby wrote:
On Mon, Dec 13, 2021 at 09:40:09PM +0100, Tomas Vondra wrote:
1) If the table is a separate relation (not part of an inheritance
tree), this should make no difference. -> OK
2) If the table is using "old" inheritance, this reverts back to
pre-regression
Hello, Junien.
Thanks for your attention.
> The cfbot reports that this patch is currently failing at least on
> Linux and Windows, e.g. https://cirrus-ci.com/task/6532060239101952.
Fixed. It was the issue with the test - hangs on Windows because of
psql + spurious vacuum sometimes.
> I'm
On Sat, Jan 15, 2022 at 12:16:59PM +0500, Andrey Borodin wrote:
> > 15 янв. 2022 г., в 03:20, Shawn Debnath написал(а):
> > On Fri, Jan 14, 2022 at 05:28:38PM +0800, Julien Rouhaud wrote:
> >>> PFA rebase of the patchset. Also I've added a patch to combine
> >>> page_number, page_status, and
On Fri, Jan 14, 2022 at 10:53 PM Robert Haas wrote:
>
> On Thu, Jan 13, 2022 at 10:23 PM Michael Paquier wrote:
> > Using --compression-level=NUMBER and --server-compress=METHOD to
> > specify a server-side compression method with a level is fine by me,
> > but I find the reuse of --compress to
On Sat, Jan 15, 2022 at 2:59 PM Julien Rouhaud wrote:
>
> Hi,
>
> On Sat, Jan 15, 2022 at 02:04:12PM +0530, Bharath Rupireddy wrote:
> >
> > We had an issue where there were many mapping files generated during
> > the crash recovery and end-of-recovery checkpoint was taking a lot of
> > time. We
On Fri, Jan 14, 2022 at 5:35 PM vignesh C wrote:
>
> Thanks for the updated patch, few minor comments:
> 1) Should "SKIP" be "SKIP (" here:
> @@ -1675,7 +1675,7 @@ psql_completion(const char *text, int start, int end)
> /* ALTER SUBSCRIPTION */
> else if (Matches("ALTER",
On Fri, Jan 14, 2022 at 7:49 AM Masahiko Sawada wrote:
>
> I agree with all the comments above. I've attached an updated patch.
>
Review comments
1.
+
+
+ In this case, you need to consider changing the data on the
subscriber so that it
The starting of this sentence doesn't
> On 14. Jan 2022, at 13:21, Peter Eisentraut
wrote:
>
> There is nothing in there that says that certain branches of the
UNION in a recursive query mean certain things. In fact, it doesn't even
require the query to contain a UNION at all. It just says to iterate on
evaluating the query
Hi,
On Sat, Jan 15, 2022 at 02:04:12PM +0530, Bharath Rupireddy wrote:
>
> We had an issue where there were many mapping files generated during
> the crash recovery and end-of-recovery checkpoint was taking a lot of
> time. We had to manually intervene and delete some of the mapping
> files
Hello Andres,
The reason this test constantly fails on cfbot windows is a use-after-free
bug.
Indeed! Thanks a lot for the catch and the debug!
The ClearOrSaveResult function is quite annoying because it may or may not
clear the result as a side effect.
Attached v14 moves the status
Hi,
On Mon, Dec 06, 2021 at 07:16:12PM +, Bossart, Nathan wrote:
> On 12/5/21, 11:10 PM, "Michael Paquier" wrote:
> > On Thu, Dec 02, 2021 at 08:32:08AM +0530, Bharath Rupireddy wrote:
> >> On Thu, Dec 2, 2021 at 4:22 AM Andres Freund wrote:
> I don't have any other compelling use-
On Fri, Jan 14, 2022 at 1:08 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-12-31 18:12:37 +0530, Bharath Rupireddy wrote:
> > Currently the server is erroring out when unable to remove/parse a
> > logical rewrite file in CheckPointLogicalRewriteHeap wasting the
> > amount of work the checkpoint has
Hi,
On Thu, Oct 28, 2021 at 01:44:31PM +, Arne Roland wrote:
>
> The attached patch takes that route. I'd appreciate feedback!
The cfbot reports that the patch doesn't apply anymore:
http://cfbot.cputube.org/patch_36_3452.log
=== Applying patches on top of PostgreSQL commit ID
Hi,
On Tue, Dec 21, 2021 at 10:58:39AM -0800, Mark Dilger wrote:
>
> Rebased patch attached:
This version doesn't apply anymore:
http://cfbot.cputube.org/patch_36_3367.log
=== Applying patches on top of PostgreSQL commit ID
5513dc6a304d8bda114004a3b906cc6fde5d6274 ===
=== applying patch
On Sat, Jan 15, 2022 at 1:36 PM Bharath Rupireddy
wrote:
>
> On Thu, Jan 6, 2022 at 3:39 AM Bossart, Nathan wrote:
> >
> > On 12/30/21, 3:52 AM, "Maxim Orlov" wrote:
> > > I did check the patch too and found it to be ok. Check and check-world
> > > are passed.
> > > Overall idea seems to be
On Thu, Jan 6, 2022 at 3:39 AM Bossart, Nathan wrote:
>
> On 12/30/21, 3:52 AM, "Maxim Orlov" wrote:
> > I did check the patch too and found it to be ok. Check and check-world are
> > passed.
> > Overall idea seems to be good in my opinion, but I'm not sure where is the
> > optimal place to
29 matches
Mail list logo
