On Tuesday, September 13, 2022 12:40 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 12 Sep 2022 04:26:48 +, "houzj.f...@fujitsu.com"
> wrote in
> > On Monday, September 12, 2022 1:08 AM Mark Dilger
> > wrote:
> > > > > On Sep 10, 2022, at 4:17 PM, Robert Haas
> > > > > wrote:
> > > >
> > >
On Wed, Sep 07, 2022 at 12:39:08PM -0700, Andres Freund wrote:
> Hi,
>
> On 2022-09-06 18:40:49 -0500, Jaime Casanova wrote:
> > I'm not sure what is causing this, but I have seen this twice. The
> > second time without activity after changing the set of tables in a
> > PUBLICATION.
This crash
> On 12 Sep 2022, at 23:01, Tom Lane wrote:
>
> Andrey Borodin writes:
>>> On 12 Sep 2022, at 18:18, Julien Rouhaud wrote:
>>> That being
>>> said I don't know if adding a timeout would be too expensive for the lwlock
>>> infrastructure.
>
> I want to object fiercely to loading down LWLock
On 2022-09-09 19:46, Justin Pryzby wrote:
In pg14:
|postgres=# create database a LC_COLLATE C LC_CTYPE C LOCALE C;
|ERROR: conflicting or redundant options
|DETAIL: LOCALE cannot be specified together with LC_COLLATE or
LC_CTYPE.
In pg15:
|postgres=# create database a LC_COLLATE
Hi,
On 9/13/22 6:33 AM, Julien Rouhaud wrote:
Hi,
On Tue, Sep 13, 2022 at 11:43:52AM +0900, bt22kawamotok wrote:
I found that utility statement is counted separately in upper and lower
case.
For example BEGIN and begin are counted separately.
Is it difficult to fix this problem?
This is a
On 2022-09-12 18:20, bt22kawamotok wrote:
Other than this correction, the parts that can be put together in OR
were corrected in fix_tab_completion_merge_v4.patch.
When I tried to apply this patch, I got the following warning, please
fix it.
Other than that, I think everything is fine.
$
At Mon, 12 Sep 2022 04:26:48 +, "houzj.f...@fujitsu.com"
wrote in
> On Monday, September 12, 2022 1:08 AM Mark Dilger
> wrote:
> > > > On Sep 10, 2022, at 4:17 PM, Robert Haas wrote:
> > >
> > >>> I don't understand why we
> > >>> used this ALL TABLES IN SCHEMA language.
> > >>
> > >>
Hi,
On Tue, Sep 13, 2022 at 11:43:52AM +0900, bt22kawamotok wrote:
>
> I found that utility statement is counted separately in upper and lower
> case.
> For example BEGIN and begin are counted separately.
> Is it difficult to fix this problem?
This is a known behavior, utility command aren't
On Mon, Sep 12, 2022 at 09:13:11PM -0500, Justin Pryzby wrote:
> Like this, maybe.
>
> It's similar to what I suggested to consider backpatching here:
> https://www.postgresql.org/message-id/20201214032224.GA30237%40telsasoft.com
At the same time, df9274adf has been done because the
On Mon, Sep 12, 2022 at 08:22:56PM -0700, Noah Misch wrote:
> I plan to use that message's patch, because it guarantees WALRCV_STOPPED at
> the code location being changed. Today, in the unlikely event of
> !WalRcvStreaming() due to WALRCV_WAITING or WALRCV_STOPPING, that code
> proceeds without
Hi,
Param isSlice was once used to identity targetTypeId for
transformAssignmentIndirection.
In commit c7aba7c14e, the evaluation was pushed down to
transformContainerSubscripts.
No need to keep isSlice around transformAssignmentSubscripts.
Attach a patch to remove it.
Regards,
Zhang
On Mon, Sep 12, 2022 at 05:58:08PM +0530, Bharath Rupireddy wrote:
> On Mon, Sep 12, 2022 at 12:30 PM Michael Paquier wrote:
> > On Sat, Sep 10, 2022 at 07:52:01AM +0530, Bharath Rupireddy wrote:
> > > Just for the records - there's another report of the assertion failure
> > > at [1], many
Hi Alvaro,
On Sat, Sep 10, 2022 at 2:58 AM Alvaro Herrera wrote:
> There were a lot more problems in that submission than I at first
> realized, and I had to rewrite a lot of code in order to fix them. I
> have fixed all the user-visible problems I found in this version, and
> reviewed the
Attached v5 to normalize 2PC commands too, so that we get things like:
create table test_tx (a int);
begin;
prepare transaction 'tx1';
insert into test_tx values (1);
commit prepared 'tx1';
begin;
prepare transaction 'tx2';
insert into test_tx values (2);
commit prepared 'tx2';
begin;
prepare
On Sun, Sep 11, 2022 at 07:54:43PM -0500, Justin Pryzby wrote:
> On Tue, Aug 03, 2021 at 02:19:22PM +1200, Thomas Munro wrote:
> > On Tue, Aug 3, 2021 at 9:52 AM Thomas Munro wrote:
> > > On Tue, Aug 3, 2021 at 1:17 AM Robert Haas wrote:
> > > > That's great. I just realized that this leaves us
On Mon, Sep 12, 2022 at 05:06:16PM +0530, Bharath Rupireddy wrote:
> Hi, it looks like the commit [1] renamed pg_stop_backup() to
> pg_backup_stop() but forgot to rename the associated
> PG_STOP_BACKUP_V2_COLS macro. While this is harmless, here's a patch
> to rename the macro to be in sync with
On Mon, Sep 12, 2022 at 04:29:22PM -0500, Justin Pryzby wrote:
> After another round of restore-from-backup, and sqlsmith-with-kill-9, it
> looks to be okay. The issue was evidently another possible symptom of
> the recovery prefetch bug, which is already fixed in REL_15_STABLE (but
> not in
On Mon, Sep 12, 2022 at 09:51:32AM +0200, Daniel Gustafsson wrote:
> Sure, go for it.
Thanks. Done, then, after an extra look.
--
Michael
signature.asc
Description: PGP signature
On Tue, Sep 13, 2022 at 3:22 AM Andres Freund wrote:
>
> It's not obvious to me that it's the right design (or even correct) to ask
> reorderbuffer about an xid being a subxid. Maybe I'm missing something, but
> why would reorderbuffer even be guaranteed to know about all these subxids?
Yeah,
Hi,
On 2022-09-07 07:00:17 +0200, Peter Eisentraut wrote:
> On 31.08.22 20:11, Andres Freund wrote:
> > > src/port/win32ver.rc.in: This is redundant with src/port/win32ver.rc.
> > > (Note that the latter is also used as an input file for text
> > > substitution. So having another file named *.in
Hi,
Checking if you're planning to work on this patch still ?
On Thu, Jul 28, 2022 at 05:27:34PM -0500, Justin Pryzby wrote:
> Note that this can currently exposes internal elog() errors to users:
>
> postgres=# select pg_normalize_config_value('log_min_messages','abc');
> WARNING: invalid
Em seg., 12 de set. de 2022 às 20:06, David Rowley
escreveu:
> On Tue, 6 Sept 2022 at 13:29, David Rowley wrote:
> > I'll hold off a few days before pushing the other patch. Tom stamped
> > beta4 earlier, so I'll hold off until after the tag.
>
> I've now pushed this.
>
Thank you David.
But
Hi,
While looking at Robert's work to improve our handling of roles I found it
helpful to be able to see not only the directly recorded membership
information, which now includes grantor, but also to see what was reachable
via SET ROLE. The attached patch puts that information at our users'
Andrew Dunstan writes:
> I think the discussion here is a bit tangential to the original topic.
Indeed, because I just wanted to reimplement *how* we resolve the
executable path to absolute, not question whether we should do it at all.
> The point you make is reasonable, but it seems a bit more
On Tue, 6 Sept 2022 at 13:29, David Rowley wrote:
> I'll hold off a few days before pushing the other patch. Tom stamped
> beta4 earlier, so I'll hold off until after the tag.
I've now pushed this.
David
On 2022-09-12 Mo 16:07, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 12.09.22 17:33, Tom Lane wrote:
>>> Are you proposing we give up the support for relocatable installations?
>>> I'm not here to defend that feature, but I bet somebody will. (And
>>> doesn't "make check" depend on it?)
>>
Hi,
On 2022-09-09 13:19:14 -0400, Robert Haas wrote:
> I mentioned this patch to Andres in conversation, and he expressed a
> concern that there might be no guarantee that we retain enough CLOG to
> look up XIDs.
I was concerned we wouldn't keep enough subtrans, rather than clog. But I
think
Hi,
Thanks for working on this!
I think this should include a test that fails without this change and succeeds
with it...
On 2022-07-19 11:55:06 +0900, Kyotaro Horiguchi wrote:
> From abcf0a0e0b3e2de9927d8943a3e3c145ab189508 Mon Sep 17 00:00:00 2001
> From: Kyotaro Horiguchi
> Date: Tue, 19
On Sun, Sep 4, 2022 at 7:54 PM Alvaro Herrera wrote:
> On 2022-Apr-07, Thomas Munro wrote:
> I propose a small wording change in guc.c,
>
> diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
> index 9fbbfb1be5..9803741708 100644
> --- a/src/backend/utils/misc/guc.c
> +++
On Wed, Aug 24, 2022 at 2:59 AM Nikita Malakhov wrote:
> I've rebased actual branch onto the latest master and re-created patches.
> Checked with git am,
> all applied correctly. Please check the attached patches.
> Rebased branch resides here:
>
On 9/4/22 2:42 PM, Nathan Bossart wrote:
I noticed that the v15 release notes still refer to pg_checkpointer, which
was renamed to pg_checkpoint in b9eb0ff.
diff --git a/doc/src/sgml/release-15.sgml b/doc/src/sgml/release-15.sgml
index d432c2db44..362728753a 100644
---
On Mon, Sep 12, 2022 at 11:53:14AM +0900, Michael Paquier wrote:
> On Mon, Sep 12, 2022 at 02:34:48PM +1200, Thomas Munro wrote:
> > On Mon, Sep 12, 2022 at 2:27 PM Justin Pryzby wrote:
> >> Yeah ... I just realized that I've already forgotten the relevant
> >> chronology.
> >>
> >> The
On Tue, Sep 13, 2022 at 08:17:27AM +1200, David Rowley wrote:
> > certain operating systems, PostgreSQL 15 supports the ability to
> > [prefetch WAL file
> > contents](https://www.postgresql.org/docs/15/runtime-config-wal.html#GUC-RECOVERY-PREFETCH)
>
> I think "ability to prefetch WAL file
On Tue, 13 Sept 2022 at 08:56, Jonathan S. Katz wrote:
> What do you think of this (copied from the attached file)
>
> On certain operating systems, PostgreSQL 15 adds support to [prefetch
> pages referenced in
>
My ongoing project to make VACUUM more predictable over time by
proactive freezing [1] will increase the overall number of tuples
frozen by VACUUM significantly (at least in larger tables). It's
important that we avoid any new user-visible impact from extra
freezing, though. I recently spent a lot
On 9/12/22 4:17 PM, David Rowley wrote:
On Tue, 13 Sept 2022 at 04:53, Jonathan S. Katz wrote:
Here is a (penultimate?) draft that includes URLs. Please provide any
additional feedback no later than 2022-09-14 0:00 AoE. After that, we
will begin the translation process.
Thanks for drafting
Hi,
On 2022-09-12 21:12:03 +0100, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane writes:
>
> >> I think this is localized enough that asking people to manually resolve a
> >> conflict around adding a GUC entry wouldn't be asking for that much. And I
> >> think plenty changes might be automatically
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Git can detect more complicated code movement (see the `--color-moved`
> option to `git diff`), but I'm not sure it's clever enough to realise
> that a change modifying a block of code that was moved in the meanwhile
> should be applied at the
On Tue, 13 Sept 2022 at 04:53, Jonathan S. Katz wrote:
> Here is a (penultimate?) draft that includes URLs. Please provide any
> additional feedback no later than 2022-09-14 0:00 AoE. After that, we
> will begin the translation process.
Thanks for drafting these up.
I noticed a couple of
Tom Lane writes:
>> I think this is localized enough that asking people to manually resolve a
>> conflict around adding a GUC entry wouldn't be asking for that much. And I
>> think plenty changes might be automatically resolvable, despite the rename.
>
> I wonder whether git will be able to
Peter Eisentraut writes:
> On 12.09.22 17:33, Tom Lane wrote:
>> Are you proposing we give up the support for relocatable installations?
>> I'm not here to defend that feature, but I bet somebody will. (And
>> doesn't "make check" depend on it?)
> I'm complaining specifically about the
On 12/09/2022 18:49, Peter Eisentraut wrote:
On 09.09.22 21:23, Heikki Linnakangas wrote:
So I fear we're optimizing for a case that stopped being mainstream
a decade or more back. I could get behind switching the code back
to using $(INSTALL) for this, and then offering some way to inject
On 9/12/22 3:34 PM, Justin Pryzby wrote:
On Mon, Sep 12, 2022 at 12:52:49PM -0400, Jonathan S. Katz wrote:
sorted. Using `row_number()`, `rank()`, and `count()` as
[window functions](https://www.postgresql.org/docs/15/functions-window.html)
also have performance benefits in PostgreSQL 15, and
On 12.09.22 17:33, Tom Lane wrote:
Peter Eisentraut writes:
On 02.09.22 01:39, Tom Lane wrote:
find_my_exec() wants to obtain an absolute, symlink-free path
to the program's own executable, for what seem to me good
reasons.
I still think they are bad reasons, and we should kill all that
Andres Freund writes:
> - a bit worried that in_hot_standby will be confusing due vs InHotStandby. I
> wonder if we could perhaps get rid of an underlying variable in cases where
> we really just need the GUC entry to trigger the show hook?
Yeah, that worried me too. We do need the variable
Hi,
On 2022-09-11 18:31:41 -0400, Tom Lane wrote:
> Here's a v3 that gets rid of guc_hooks.c in favor of moving the
> hook functions to related modules (though some did end up in
> variables.c for lack of a better idea).
- a bit worried that in_hot_standby will be confusing due vs InHotStandby.
On Mon, Sep 12, 2022 at 12:52:49PM -0400, Jonathan S. Katz wrote:
> sorted. Using `row_number()`, `rank()`, and `count()` as
> [window functions](https://www.postgresql.org/docs/15/functions-window.html)
> also have performance benefits in PostgreSQL 15, and queries using
Remove "using" ?
>
On 9/12/22 2:01 PM, Peter Eisentraut wrote:
On 12.09.22 18:52, Jonathan S. Katz wrote:
On 9/1/22 9:10 PM, Jonathan S. Katz wrote:
New version attached.
Here is a (penultimate?) draft that includes URLs. Please provide any
additional feedback no later than 2022-09-14 0:00 AoE. After that,
I wrote:
> 3. I think it's highly likely that the new test case is not portable.
> In particular a machine with MAXALIGN 4 would be likely to put a
> different number of tuples per page, or do the page split differently
> so that the page with fewer index tuples isn't page 3. Unfortunately
> I
> On 12 Sep 2022, at 18:13, James Coleman wrote:
> See attached simple patch to fix $SUBJECT; the old link generates a Not Found.
According to archive.org the freebsd.org site changed sometime in early 2021
with a 301 redirect to docproj/docproj which then ends up with a 404. I'll
apply this
On Mon, Sep 12, 2022 at 02:01:23PM -0400, Tom Lane wrote:
> Andrey Borodin writes:
> >> On 12 Sep 2022, at 18:18, Julien Rouhaud wrote:
> >> That being
> >> said I don't know if adding a timeout would be too expensive for the lwlock
> >> infrastructure.
>
> I want to object fiercely to loading
On 12.09.22 18:52, Jonathan S. Katz wrote:
On 9/1/22 9:10 PM, Jonathan S. Katz wrote:
New version attached.
Here is a (penultimate?) draft that includes URLs. Please provide any
additional feedback no later than 2022-09-14 0:00 AoE. After that, we
will begin the translation process.
Is
Andrey Borodin writes:
>> On 12 Sep 2022, at 18:18, Julien Rouhaud wrote:
>> That being
>> said I don't know if adding a timeout would be too expensive for the lwlock
>> infrastructure.
I want to object fiercely to loading down LWLock with anything like
timeouts. It's supposed to be
On 12.09.22 19:03, Julien Rouhaud wrote:
On Mon, Sep 12, 2022 at 05:59:09PM +0200, Peter Eisentraut wrote:
committed, thanks
FTR lapwing is complaining about this commit:
https://brekka.postgresql.org/cgi-bin/show_log.pl?nm=lapwing=2022-09-12%2016%3A40%3A18.
Snapper is also failing with
Hamid Akhtar writes:
> Attached is the rebased version of the patch
> (pageinspect_btree_multipagestats_03.patch) for the master branch.
I looked through this and cleaned up the code a little (attached).
There are still some issues before it could be considered committable:
1. Where's the
> On 12 Sep 2022, at 18:18, Julien Rouhaud wrote:
>
> That being
> said I don't know if adding a timeout would be too expensive for the lwlock
> infrastructure.
Implementation itself is straightforward, but we need to add 3 impls of waiting
for semaphore with timeout.
POSIX have
Hi,
On Mon, Sep 12, 2022 at 05:59:09PM +0200, Peter Eisentraut wrote:
>
> committed, thanks
FTR lapwing is complaining about this commit:
https://brekka.postgresql.org/cgi-bin/show_log.pl?nm=lapwing=2022-09-12%2016%3A40%3A18.
Snapper is also failing with similar problems:
On 9/1/22 9:10 PM, Jonathan S. Katz wrote:
New version attached.
Here is a (penultimate?) draft that includes URLs. Please provide any
additional feedback no later than 2022-09-14 0:00 AoE. After that, we
will begin the translation process.
Thanks,
Jonathan
The PostgreSQL Global
On Fri, 2022-09-09 at 12:14 -0500, Justin Pryzby wrote:
> On Sat, Sep 03, 2022 at 11:40:03PM -0400, Reid Thompson wrote:
> > > > + 0, 0, INT_MAX,
> > > > + NULL, NULL, NULL
> > > I think this needs a maximum like INT_MAX/1024/1024
> >
> > Is this noting that we'd set a
See attached simple patch to fix $SUBJECT; the old link generates a Not Found.
Thanks,
James Coleman
v1-0001-Fix-FreeBSD-DocProj-link.patch
Description: Binary data
On Mon, Sep 12, 2022 at 11:29:12AM -0400, Tom Lane wrote:
> Lev Kokotov writes:
> >> 3. Do we gain anything besides compiler hints? Postgres development is
> >> hard due to interference of complex subsystems. It will be even harder if
> >> those systems will be implemented in different languages.
On 08.09.22 11:26, Aleksander Alekseev wrote:
3. Go with your patch and just fix up the warnings about uninitialized
variables. But that seems the least principled to me.
IMO the 3rd option is the lesser evil. Initializing four bools/ints in
order to make Clang 11 happy doesn't strike me as
On 09.09.22 21:23, Heikki Linnakangas wrote:
So I fear we're optimizing for a case that stopped being mainstream
a decade or more back. I could get behind switching the code back
to using $(INSTALL) for this, and then offering some way to inject
user-selected switches into the $(INSTALL)
On 31.08.22 14:56, Robert Haas wrote:
In some circumstances, it may be desirable to control this behavior.
For example, if we GRANT pg_read_all_settings TO seer, we do want the
seer to be able to read all the settings, else we would not have
granted the role. But we might not want the seer to be
Peter Eisentraut writes:
> On 02.09.22 01:39, Tom Lane wrote:
>> find_my_exec() wants to obtain an absolute, symlink-free path
>> to the program's own executable, for what seem to me good
>> reasons.
> I still think they are bad reasons, and we should kill all that code.
> Just sayin' ...
Are
Lev Kokotov writes:
>> 3. Do we gain anything besides compiler hints? Postgres development is
>> hard due to interference of complex subsystems. It will be even harder if
>> those systems will be implemented in different languages.
> Rust gives many things we wanted for decades:
> 1. No
On 02.09.22 01:39, Tom Lane wrote:
find_my_exec() wants to obtain an absolute, symlink-free path
to the program's own executable, for what seem to me good
reasons.
I still think they are bad reasons, and we should kill all that code.
Just sayin' ...
On 02.09.22 17:52, Robert Haas wrote:
Attached are a couple of hastily-written patches implementing this.
There might be good arguments for more thoroughly renaming some of the
things these patches touch, but I thought that doing any more renaming
would make it less clear what the core of the
Greetings,
* Drouvot, Bertrand (bdrou...@amazon.com) wrote:
> On 9/9/22 7:08 PM, Justin Pryzby wrote:
> >On Fri, Sep 09, 2022 at 12:34:15PM -0400, Stephen Frost wrote:
> >>>While we are at it, what do you think about also recording the max memory
> >>>allocated by a backend? (could be useful and
> You can write Postgres extensions in Rust. And Postgres extensions are
really powerful. What kind of features are you interested in?
Agreed, I've been writing one in Rust using tcdi/pgx [0]. Some features
can't be done there though, e.g. adding ON CONFLICT support to COPY.
> 1. Is Rust
On 2022-Mar-28, Yugo NAGATA wrote:
> On Fri, 25 Mar 2022 16:19:54 -0400
> Tom Lane wrote:
> > I am not convinced this is a great idea. The current behavior is that
> > a statement is not prepared until it's about to be executed, and I think
> > we chose that deliberately to avoid semantic
On 12.09.22 06:03, Etsuro Fujita wrote:
On Thu, Sep 8, 2022 at 9:13 PM Peter Eisentraut
wrote:
Attached is the plain-text list of acknowledgments for the PG15 release
notes, current through REL_15_BETA4. Please check for problems such as
wrong sorting, duplicate names in different variants,
Thank you for looking at it.
> I looked this over briefly. I think you are correct to charge an
> initial-search cost per searchEntries count, but don't we also need to
> scale up by arrayScans, similar to the "corrections for cache effects"?
>
> + * We model index descent costs similarly
Op 12-09-2022 om 16:00 schreef Erik Rijkers:
Op 12-09-2022 om 09:58 schreef Daniel Gustafsson:
On 9 Sep 2022, at 11:00, Andrew Dunstan wrote:
On Sep 9, 2022, at 5:53 PM, John Naylor
wrote:
[v4-0001-Add-include-exclude-filtering-via-file-in-pg_dump.patch]
I noticed that pg_restore
Attached is an updated patch with the following changes:
1. rebased (including solved merge conflict)
2. fixed failing tests in CI
3. changed the commit message a little bit
4. addressed the two remarks from Micheal
5. changed the prng_state from a global to a connection level value for
On Sat, 10 Sept 2022 at 07:32, Amit Kapila wrote:
>
> On Fri, Sep 9, 2022 at 8:48 PM Robert Haas wrote:
> >
> > On Fri, Sep 9, 2022 at 10:29 AM houzj.f...@fujitsu.com
> > wrote:
> > > IIRC, the feature currently works almost the same as you described. It
> > > doesn't
> > > create entry for
Op 12-09-2022 om 09:58 schreef Daniel Gustafsson:
On 9 Sep 2022, at 11:00, Andrew Dunstan wrote:
On Sep 9, 2022, at 5:53 PM, John Naylor wrote:
[v4-0001-Add-include-exclude-filtering-via-file-in-pg_dump.patch]
I noticed that pg_restore --filter cannot, or at last not always, be
used
Peter Eisentraut writes:
> On 09.09.22 22:13, Tom Lane wrote:
>> I think serious consideration should be given to back-patching the
>> 0001 part (that is, addition of the macros). Otherwise we'll have
>> to remember not to use these macros in code intended for back-patch,
>> and that'll be
On Mon, Sep 12, 2022 at 05:32:55PM +0500, Andrey Borodin wrote:
>
> > On 12 Sep 2022, at 13:40, Julien Rouhaud wrote:
> >
> > I'm not a fan of that patch as it now silently ignores entries if the lwlock
> > can't be acquired *immediately*, without any way to avoid that if your
> > configuration
po 12. 9. 2022 v 9:59 odesílatel Daniel Gustafsson napsal:
> > On 9 Sep 2022, at 11:00, Andrew Dunstan wrote:
> >
> >> On Sep 9, 2022, at 5:53 PM, John Naylor
> wrote:
> >>
> >> Note that the grammar has shift-reduce conflicts.
>
> > Looks like the last rule for Filters should not be there.
>
> On 12 Sep 2022, at 13:40, Julien Rouhaud wrote:
>
> I'm not a fan of that patch as it now silently ignores entries if the lwlock
> can't be acquired *immediately*, without any way to avoid that if your
> configuration and/or workload doesn't lead to this problem, or any way to know
> that
On Mon, Sep 12, 2022 at 12:30 PM Michael Paquier wrote:
>
> On Sat, Sep 10, 2022 at 07:52:01AM +0530, Bharath Rupireddy wrote:
> > Today, I spent some more time on this issue, I modified the v1 patch
> > posted upthread a bit - now resetting the InstallXLogFileSegmentActive
> > only when the WAL
On Mon, Sep 12, 2022 at 1:12 PM Michael Paquier wrote:
>
> On Thu, Aug 11, 2022 at 09:55:13AM +0530, Bharath Rupireddy wrote:
> > Here's the v2 patch, no change from v1, just rebased because of commit
> > a8c012869763c711abc9085f54b2a100b60a85fa (Move basebackup code to new
> > directory
Hi, it looks like the commit [1] renamed pg_stop_backup() to
pg_backup_stop() but forgot to rename the associated
PG_STOP_BACKUP_V2_COLS macro. While this is harmless, here's a patch
to rename the macro to be in sync with the function name.
Thoughts?
[1]
commit
Thank you for the commit.
regards,
Ranier Vilela
Dear Hou-san,
Thank you for updating the patch! Followings are comments for v28-0001.
I will dig your patch more, but I send partially to keep the activity of the
thread.
===
For applyparallelworker.c
01. filename
The word-ordering of filename seems not good
because you defined the new worker
September 12, 2022 7:51 AM, "Tom Lane" wrote:
> Julien Rouhaud writes:
>
>> On Sun, Sep 11, 2022 at 06:22:21PM +, andrey.ara...@nixaid.com wrote:
>>> Everyone using containerized postgresql image cannot use /var/lib/postgresql
>>> as the mountpoint but has to use /var/lib/postgresql/data
On Sat, Sep 10, 2022 at 10:00 AM Thomas Munro wrote:
> On Sat, Sep 10, 2022 at 9:45 AM Tom Lane wrote:
> > Masahiko Sawada writes:
> > > It's likely that the commit f6c5edb8abcac04eb3eac6da356e59d399b2bcef
> > > is relevant.
> >
> > Noting that the errors have only appeared in the past couple
po 12. 9. 2022 v 10:29 odesílatel John Naylor
napsal:
> On Mon, Sep 12, 2022 at 12:44 PM Pavel Stehule
> wrote:
> > This is not a critical issue, really. On second thought, I don't see
> the point in releasing fresh Postgres with this bug, where there is know
> bugfix - and this bugfix should
Other than this correction, the parts that can be put together in OR
were corrected in fix_tab_completion_merge_v4.patch.
Kotaro Kawamotodiff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index 62a39779b9..8b498f6a86 100644
--- a/src/bin/psql/tab-complete.c
+++
September 11, 2022 12:18 PM, "Julien Rouhaud" wrote:
> Hi,
>
> On Sat, Sep 10, 2022 at 07:14:59PM +, andrey.ara...@nixaid.com wrote:
>
>> Have slightly improved the logic so that it does not report an error
>> "directory \"%s\" exists but is not empty"
>> when it is only supposed to warn
On 2022-Sep-09, Justin Pryzby wrote:
> 4) I was simultaneously compiling pg14b4 to run with with
>-DRELCACHE_FORCE_RELEASE and installing it into /usr/local. I don't
> *think*
>running libraries would've been overwritten, and that shouldn't have
>affected the running instance
Hi,
The commit 4fb5c794e5 eliminates the ginbulkdelete() test coverage
provided by the commit 4c51a2d1e4 two years ago.
With the following Assert added:
@@ -571,7 +571,7 @@ ginbulkdelete(IndexVacuumInfo *info,
IndexBulkDeleteResult *stats,
Buffer buffer;
BlockNumber
Hi,
On Mon, Sep 12, 2022 at 11:52:28AM +0500, Andrey Borodin wrote:
>
> === How to fix ===
> pgss uses LWLock to protect hashtable.
> When the hashtable is reset or new user query is inserted in pgss_store() -
> exclusive lock is used.
> When stats are updated for known query or
On Mon, Sep 12, 2022 at 12:44 PM Pavel Stehule wrote:
> This is not a critical issue, really. On second thought, I don't see the
> point in releasing fresh Postgres with this bug, where there is know bugfix -
> and this bugfix should be compatible (at this moment) with 16.
I agree the actual
On 09.09.22 05:51, Bharath Rupireddy wrote:
On Thu, Sep 8, 2022 at 5:23 PM Peter Eisentraut
wrote:
The pg_walinspect function pg_get_wal_stats() has output arguments
declared as float4 (count_percentage, record_size_percentage, etc.), but
the internal computations are all done in type double.
Thanks for updating!
Compile errors have occurred, so can you fix them?
And I think we can eliminate similar redundancies in MERGE tab
completion and I would like you to fix them.
For example,
else if (TailMatches("WHEN", "MATCHED"))
COMPLETE_WITH("THEN", "AND");
On Tue, 6 Sept 2022 at 11:25, Ibrar Ahmed wrote:
>
>
> On Mon, Aug 1, 2022 at 11:29 PM Naeem Akhter
> wrote:
>
>> The following review has been posted through the commitfest application:
>> make installcheck-world: tested, passed
>> Implements feature: tested, passed
>> Spec compliant:
On the other hand, it seems pretty silly that it's GUC_REPORT if
we want to consider it private. I've not checked the git history,
but I bet that flag was added later with no thought about context.
If we are going to document this then we should at least remove
the GUC_NO_SHOW_ALL flag and
1 - 100 of 111 matches
Mail list logo
