On 2022/09/12 17:13, bt22kawamotok wrote:
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 l
At Mon, 12 Sep 2022 14:51:56 -0700, Andres Freund wrote in
> 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 abcf0a0e0b3e2de9927d8943a3e
Hi hackers!
Jacob, I agree that the bytea toaster makes a bad example due to core
modification,
and actually is not a good example of an extension.
The vtable concept is intended for less invasive additional functionality -
like providing
detoast iterators in addition to standard detoast mechanic
On Tue, Sep 13, 2022 at 11:52 AM Kyotaro Horiguchi
wrote:
>
> Thanks for raizing this up, Robert and the comment, Andres.
>
> At Tue, 13 Sep 2022 07:00:42 +0530, Dilip Kumar wrote
> in
> > On Tue, Sep 13, 2022 at 3:22 AM Andres Freund wrote:
> >
> > >
> > > It's not obvious to me that it's the
On 03.09.22 06:30, Nathan Bossart wrote:
On Fri, Sep 02, 2022 at 10:06:54PM -0400, Tom Lane wrote:
I think the distance limit of 5 is too loose though. I see that
it accommodates examples like "passfile" for "password", which
seems great at first glance; but it also allows fundamentally
silly s
On Tue, Sep 13, 2022 at 8:52 AM Noah Misch wrote:
>
> > > > [1] -
> > > > https://www.postgresql.org/message-id/flat/20220909.172949.2223165886970819060.horikyota.ntt%40gmail.com
>
> I plan to use that message's patch, because it guarantees WALRCV_STOPPED at
> the code location being changed. To
Thanks for raizing this up, Robert and the comment, Andres.
At Tue, 13 Sep 2022 07:00:42 +0530, Dilip Kumar wrote
in
> 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
On Tue, Sep 13, 2022 at 10:38:13AM +0500, Andrey Borodin wrote:
>
> And the other way is refactoring towards partitioned hashtable, namely
> dshash. But I don't see how partitioned locking can save us from a locking
> disaster. Problem is caused by reading all the pgss view colliding with
> reset(
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 ha
> 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 "en_US.UTF-8
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 kno
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.
$ git
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.
> > >>
> > >> The
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 norm
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 end-of-recove
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 w
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 Mingli
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 thanks
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 test
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 tr
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 w
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 th
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 pg15b
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, yo
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 valu
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 the
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'
finge
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 we'r
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 J
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
> +++ b/sr
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:
> https://github.com/postgrespro/postgres/tree/toast
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
--- a/doc/src/sgml/release-15.
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 io_concurr
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 conte
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
> WAL](https://www.postgresql.org/docs/15/runtime-config-wal.html#GUC-RECOVERY-PREFETCH
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 th
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 r
=?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 ne
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 things,
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 figur
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 resolving
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
user
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 qu
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 cod
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. I
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" ?
> certa
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, we
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 don
> 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 ba
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 d
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 t
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 "lightweigh
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&dt=2022-09-12%2016%3A40%3A18.
Snapper is also failing with s
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 docume
> 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 sem_timedwai
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&dt=2022-09-12%2016%3A40%3A18.
Snapper is also failing with similar problems:
https://brekka.postg
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 Developm
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 su
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) invocat
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 y
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 undefine
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 cha
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 w
> 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 compatib
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 diffe
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, or
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 t
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 --f
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
thread-saf
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 tab
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 wit
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 mighty
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 an
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 en
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 s
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 src/backe
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 39969e2a1e4d7f5a37f3ef37d53bbfe171e
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 a
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 in
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 of
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 b
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
+++ b/src/bin/psql
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 th
1 - 100 of 115 matches
Mail list logo