Le lundi 6 septembre 2021, 06:22:30 CEST Michael Paquier a écrit :
> On Fri, Sep 03, 2021 at 11:58:27AM +0200, Ronan Dunklau wrote:
> > 0002 for pg_receivewal tried to simplify the logic of information to
> > return, by using a dedicated struct for this. This accounts for Bahrath's
> > demands to r
> If DeleteFile() is automatically using
> FILE_DISPOSITION_POSIX_SEMANTICS by default when possible on recent
> releases as per the SO link that Andres posted above ("18363.657
> definitely has the new behavior"), then that's great news and maybe we
> shouldn't even bother to try to request that m
On Tue, Aug 31, 2021 at 8:54 PM vignesh C wrote:
>
> On Tue, Aug 31, 2021 at 2:00 PM Kyotaro Horiguchi
> wrote:
> >
>
> Thanks for the comments, the attached v3 patch has the changes for the same.
>
I think this bug should be fixed in back branches (till v10). OTOH, as
this is not reported by an
On Sat, Sep 4, 2021 at 12:24 PM Amit Kapila wrote:
>
> On Fri, Sep 3, 2021 at 2:15 AM Mark Dilger
> wrote:
> >
> > > On Aug 30, 2021, at 12:06 AM, Masahiko Sawada
> > > wrote:
> > >
> > > I've attached rebased patches.
> > For the v12-0003 patch:
> >
> > I believe this feature is needed, but i
On Mon, Sep 6, 2021 at 1:58 AM Andres Freund wrote:
> On 2021-09-05 14:22:51 +0530, Dilip Kumar wrote:
> But these directly operate on the buffers and In my patch, whether we are
> > reading the pg_class for identifying the relfilenode or we are copying
> the
> > relation block by block we are a
On Sat, Sep 04, 2021 at 09:58:08AM -0400, Andrew Dunstan wrote:
> On 9/4/21 2:19 AM, Noah Misch wrote:
>> plperl uses PostgreSQL:: as the first component of its Perl module namespace.
>> We shouldn't use both PostgreSQL:: and Postgres:: in the same source tree, so
>> this change should not use Post
On Sunday, September 5, 2021 1:42 AM, Tom Lane wrote:
>I particularly question why we'd offer both
>single- and multiple-character versions, as the single-character
>version seems entirely useless from a completion standpoint.
I generally agreed with your opinion. But I'm not sure if there's some
On Thursday, September 2, 2021 2:36 PM vignesh C wrote:
>
> On Wed, Sep 1, 2021 at 11:14 AM tanghy.f...@fujitsu.com
> wrote:
> >
> > 3. When using '\dn+', I noticed that the list of publications only contains
> > the
> > publications for "SCHEMA", "FOR ALL TABLES" publications are not shown. Is
On Fri, Sep 03, 2021 at 11:58:27AM +0200, Ronan Dunklau wrote:
>
> 0002 for pg_receivewal tried to simplify the logic of information to return,
> by using a dedicated struct for this. This accounts for Bahrath's demands to
> return every possible field.
> In particular, an is_logical field simpl
On 9/5/21, 7:28 PM, "Michael Paquier" wrote:
> On Fri, Sep 03, 2021 at 05:36:43PM +, Bossart, Nathan wrote:
>> On 9/2/21, 6:46 PM, "Michael Paquier" wrote:
>>> 0001, that refactors the calculation of the shmem size into a
>>> different routine, is fine as-is, so I'd like to move on and apply
Dear Ikeda-san,
> I agree that this feature is useful. Thanks for working this.
Thanks :-).
> 1)
>
> Why does postgres_fdw.application_name override the server's option?
>
> > + establishes a connection to a foreign server. This overrides
> > + application_name option of the server
Thank you !
Regards,
Amul
On Mon, Sep 6, 2021 at 7:58 AM Michael Paquier wrote:
>
> On Fri, Sep 03, 2021 at 04:03:36PM +0900, Michael Paquier wrote:
> > Indeed. Let's clean up that. Thanks!
>
> And done.
> --
> Michael
On Sat, Sep 4, 2021 at 8:11 PM Alvaro Herrera wrote:
>
> On 2021-Sep-04, Amit Kapila wrote:
>
> > On Thu, Sep 2, 2021 at 2:19 PM Alvaro Herrera
> > wrote:
> > >
> > > On 2021-Sep-02, Rahila Syed wrote:
> > >
> > > > After thinking about this, I think it is best to remove the entire table
> > > >
On Sun, Sep 5, 2021 at 12:23 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Mon, Apr 19, 2021 at 10:32 AM Peter Smith wrote:
> >> Yes, if there were dozens of list items then I would agree that they
> >> should be grouped somehow. But there aren't.
>
> > I think this list is going to grow in
On Wed, Aug 18, 2021 at 03:00:59PM +, Jelte Fennema wrote:
> I ran into some segfaults when using Postgres that was compiled with LLVM 7.
> According to the backtraces these crashes happened during the call to
> llvm_shutdown, during cleanup after another out of memory condition. It seems
>
On Fri, Sep 03, 2021 at 04:03:36PM +0900, Michael Paquier wrote:
> Indeed. Let's clean up that. Thanks!
And done.
--
Michael
signature.asc
Description: PGP signature
On Fri, Sep 03, 2021 at 05:36:43PM +, Bossart, Nathan wrote:
> On 9/2/21, 6:46 PM, "Michael Paquier" wrote:
> You bring up an interesting point about _PG_init(). Presently, you
> can safely assume that the data directory is locked during _PG_init(),
> so there's no need to worry about breakin
Hi, Kuroda-san, Fujii-san
I agree that this feature is useful. Thanks for working this.
I've tried to use the patches and read them. I have some questions.
1)
Why does postgres_fdw.application_name override the server's option?
+ establishes a connection to a foreign server. This overri
在 2021/9/5 下午10:51, Sasasu 写道:
For AES-GCM, a predictable IV is fine. I think we can decrypt and
re-encrypt the user data in pg_upgrade. this will allows us to use
relfile oid + block number as nonce.
relfile oid + block number + some counter for heap table IV. I mean.
OpenPGP_0x4E72AF09
Dear Fujii-san,
Thank you for updating! Your modification is very interesting and
I learn something new.
> Attached is the updated version of the patch. I removed the test
> for case (1). And I arranged the regression tests so that they are based
> on debug_discard_caches, to simplify them. Also
From Sun, Sep 5, 2021 9:58 PM Masahiko Sawada :
> On Thu, Sep 2, 2021 at 8:37 PM houzj.f...@fujitsu.com
> wrote:
> >
> > From Mon, Aug 30, 2021 3:07 PM Masahiko Sawada
> > wrote:
> > > I've attached rebased patches. 0004 patch is not the scope of this
> > > patch. It's borrowed from another thr
From Thur, Sep 2, 2021 7:42 PM Amit Kapila wrote:
> On Thu, Sep 2, 2021 at 11:58 AM vignesh C wrote:
> >
>
> Below are few comments on v23. If you have already addressed anything in v24,
> then ignore it.
>
> 1. The commit message says: A new system table "pg_publication_schema"
> has been adde
From Thur, Sep 2, 2021 2:33 PM vignesh C wrote:
> On Wed, Sep 1, 2021 at 6:58 AM houzj.f...@fujitsu.com
> wrote:
> >
> > Here are some other comments for v23-000x patches.
> > 3)
> >
> > + .description =
> "PUBLICATION SCHEMA",
> > +
Hi all,
Running the recovery tests in a parallel run, enough to bloat a
machine in resources, sometimes leads me to the following failure:
ok 19 - walsender termination logged
# poll_query_until timed out executing this query:
# SELECT wal_status FROM pg_replication_slots WHERE slot_name = 'rep3'
On Wed, Aug 18, 2021 at 11:08:57PM -0400, Tom Lane wrote:
> Peter Smith writes:
> > On Thu, Aug 19, 2021 at 4:29 AM Justin Pryzby wrote:
> >> - state->oneCol = (origTupdesc->natts == 1) ? true : false;
> >> + state->oneCol = origTupdesc->natts == 1;
>
> FWIW, I am definitely not a fa
Thank you for your quick response.
I understood the specifications from your explanation.
Regards,
Noriyoshi Shinoda
From: Stephen Frost [mailto:sfr...@snowman.net]
Sent: Sunday, September 5, 2021 8:50 PM
To: Shinoda, Noriyoshi (PN Japan FSIP)
Cc: Anastasia Lubennikova ; Michael Banck
; gkokola
"Dian M Fay" writes:
> [ 0001-Suppress-explicit-casts-of-text-constants-in-postgre.patch ]
I took a quick look at this. The restriction to type text seems like
very obviously a hack rather than something we actually want; wouldn't
it mean we fail to act in a large fraction of the cases where we'
On Mon, Sep 6, 2021 at 9:55 AM Tom Lane wrote:
> Andres Freund writes:
> > I'd be ok to only fix these bugs on e.g. Win10, Win Server 2019, Win Server
> > 2016 or such.
>
> Yeah, particularly if the fix is trivial on the newer systems and
> incredibly complicated otherwise. Between the effort ne
Andres Freund writes:
> On 2021-09-06 01:32:55 +1200, Thomas Munro wrote:
>> The best idea is probably to set FILE_DISPOSITION_DELETE |
>> FILE_DISPOSITION_POSIX_SEMANTICS before unlinking. This appears to be
>> a silver bullet, but isn't available on ancient Windows releases that
>> we support,
Hi,
On 2021-09-06 01:32:55 +1200, Thomas Munro wrote:
> It's a good idea. I tested it and it certainly does fix the
> basebackup problem I've seen (experimental patch attached). But,
> yeah, I'm also a bit worried that that path could be fragile and need
> special handling in lots of places.
It
On 2021-09-05 14:22:51 +0530, Dilip Kumar wrote:
> On Sat, Sep 4, 2021 at 3:24 AM Andres Freund wrote:
>
> > Hi,
> >
> > On 2021-09-03 14:25:10 +0530, Dilip Kumar wrote:
> > > Yeah, we can surely lock the relation as described by Robert, but IMHO,
> > > while creating the database we are already
Andrew Dunstan writes:
> On 8/10/21 11:27 PM, 孙诗浩(思才) wrote:
>> we can use regular expressions (<>|!=) to cover "<>" and "!=".
> I don't understand the problem being solved here. This looks like a
> change with no discernable benefit. I don't agree that the current code
> is substantially mo
Peter Eisentraut writes:
> Makes sense. I think we could do it without hardcoding those library
> names, as in the attached patch. But it comes out to the same result
> AFAICT.
This has been pushed, but the CF entry is still open, which is
making the cfbot unhappy. Were you leaving it open p
On 9/5/21, 12:14 PM, "Tom Lane" wrote:
> "Bossart, Nathan" writes:
>> Is there a specific style you have in mind for this change, or is your
>> point that the CASE statement should only be reserved for when
>> is_default_acl is true?
>
> I'd be inclined to split this logic out into a separate if-
Hi,
On 03.09.2021 15:25, Georgios Kokolatos wrote:
On a high level I will recommend the addition of tests. There are similar tests
Tests added.
Applying the patch, generates several whitespace warnings. It will be helpful
if those warnings are removed.
I know this is a silly mistake, and a
"Bossart, Nathan" writes:
> On 9/5/21, 10:08 AM, "Tom Lane" wrote:
>> I'm kind of allergic to this SQL coding style, too. It expects the
>> backend to expend many thousands of cycles parsing and then optimizing
>> away a useless CASE, to save a couple of lines of code and a few cycles
>> on the
Aleksander Alekseev writes:
>>> [ timetz_zone is VOLATILE ]
>> I wasn't excited enough about it personally to change it, and I'm
>> still not --- but if you want to, send a patch.
> Here is the patch.
I looked at this patch, and felt unhappy about the fact that it left
timetz_zone() still depend
On 2021-Sep-03, Kyotaro Horiguchi wrote:
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> index 24165ab03e..b621ad6b0f 100644
> --- a/src/backend/access/transam/xlog.c
> +++ b/src/backend/access/transam/xlog.c
> @@ -12496,9 +12496,21 @@ retry:
>*
>
On 9/5/21, 10:08 AM, "Tom Lane" wrote:
> "Bossart, Nathan" writes:
>> I've attached a quick hack that seems to fix this by adjusting the
>> pg_dump query to use NULL instead of acldefault() for non-global
>> entries. I'm posting this early in order to gather thoughts on the
>> approach and to ma
"Bossart, Nathan" writes:
> The problem appears to be that pg_dump is comparing the entries in
> pg_default_acl to the default ACL (i.e., acldefault()). This is fine
> for "global" entries (i.e., entries with no schema specified), but it
> doesn't work for "non-global" entries (i.e., entries with
Hi, community,
It looks like we are still considering AES-CBC, AES-XTS, and
AES-GCM(-SIV). I want to say something that we don't think about.
For AES-CBC, the IV should be not predictable. I think LSN or HASH(LSN,
block number or something) is predictable. There are many CVE related to
AES-C
On Fri, Sep 3, 2021 at 3:46 PM Greg Nancarrow wrote:
>
> On Mon, Aug 30, 2021 at 5:07 PM Masahiko Sawada wrote:
> >
> > I've attached rebased patches. 0004 patch is not the scope of this
> > patch. It's borrowed from another thread[1] to fix the assertion
> > failure for newly added tests. Please
On Thu, Sep 2, 2021 at 8:37 PM houzj.f...@fujitsu.com
wrote:
>
> From Mon, Aug 30, 2021 3:07 PM Masahiko Sawada wrote:
> > I've attached rebased patches. 0004 patch is not the scope of this
> > patch. It's borrowed from another thread[1] to fix the assertion
> > failure for newly added tests. Ple
On Thu, Sep 2, 2021 at 5:41 PM houzj.f...@fujitsu.com
wrote:
>
> From Mon, Aug 30, 2021 3:07 PM Masahiko Sawada wrote:
> > I've attached rebased patches. 0004 patch is not the scope of this patch.
> > It's
> > borrowed from another thread[1] to fix the assertion failure for newly added
> > tests
On Thu, Sep 2, 2021 at 9:03 PM Greg Nancarrow wrote:
>
> On Mon, Aug 30, 2021 at 5:07 PM Masahiko Sawada wrote:
> >
> > I've attached rebased patches. 0004 patch is not the scope of this
> > patch. It's borrowed from another thread[1] to fix the assertion
> > failure for newly added tests. Please
On Thu, Sep 2, 2021 at 2:55 PM Greg Nancarrow wrote:
>
> On Mon, Aug 30, 2021 at 5:07 PM Masahiko Sawada wrote:
> >
> >
> > I've attached rebased patches. 0004 patch is not the scope of this
> > patch. It's borrowed from another thread[1] to fix the assertion
> > failure for newly added tests. Pl
On Thu, Sep 2, 2021 at 12:06 PM Greg Nancarrow wrote:
>
> On Mon, Aug 30, 2021 at 5:07 PM Masahiko Sawada wrote:
> >
> >
> > I've attached rebased patches. 0004 patch is not the scope of this
> > patch. It's borrowed from another thread[1] to fix the assertion
> > failure for newly added tests. P
On Fri, Sep 3, 2021 at 2:01 PM Kyotaro Horiguchi
wrote:
> Might be stupid, if a delete-pending'ed file can obstruct something,
> couldn't we change unlink on Windows to rename to a temporary random
> name then remove it? We do something like it explicitly while WAL
> file removal. (It may cause d
Windows 10 supports Unix sockets as reported, e.g., here
https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/
We run the tests on MobilityDB using an ephemeral instance that is created
by the test suite and torn down afterwards.
https://github.com/MobilityDB/MobilityDB/blob/develop
Greetings,
On Sun, Sep 5, 2021 at 07:43 Shinoda, Noriyoshi (PN Japan FSIP) <
noriyoshi.shin...@hpe.com> wrote:
> I have tested this new feature with PostgreSQL 14 Beta 3 environment.
> I created a user granted with pg_write_all_data role and executed UPDATE
> and DELETE statements on tables owned
Hi hackers,
I have tested this new feature with PostgreSQL 14 Beta 3 environment.
I created a user granted with pg_write_all_data role and executed UPDATE and
DELETE statements on tables owned by other users.
If there is no WHERE clause, it can be executed as expected, but if the WHERE
clause is
On Sat, Sep 4, 2021 at 3:24 AM Andres Freund wrote:
> Hi,
>
> On 2021-09-03 14:25:10 +0530, Dilip Kumar wrote:
> > Yeah, we can surely lock the relation as described by Robert, but IMHO,
> > while creating the database we are already holding the exclusive lock on
> > the database and there is no
On 03.09.21 01:00, Tom Lane wrote:
> Mario Emmenlauer writes:
>> The idea to switch to dup(2) sounds very good to me.
>
> I poked at this some more, and verified that adding "fclose(stdin);"
> at the head of PostmasterMain is enough to trigger the reported
> failure. However, after changing fd.c
53 matches
Mail list logo
