On 2022/09/21 12:01, Japin Li wrote:
Hi hackers,
In 6c2003f8a1bbc7c192a2e83ec51581c018aa162f, we change the snapshot name
when exporting snapshot, however, there is one place we missed update the
snapshot name in documentation. Attach a patch to fix it.
Thanks for the patch! Looks good
On Sat, Sep 03, 2022 at 10:06:58AM +0900, Michael Paquier wrote:
> Ohoh. This sounds like a good idea to me, close to what John has
> applied lately. I'll take a closer look..
So, the two code paths patched here are rather isolated. The one in
TransactionIdIsInProgress() requires an overflowed
On 2022/09/21 0:51, Alvaro Herrera wrote:
The rules starting at line 4111 make me a bit nervous, since nowhere
we're restricting them to operating only on MERGE lines. I don't think
it's a real problem since USING is not terribly common anyway. Likewise
for the ones with WHEN [NOT] MATCHED.
On Tue, Sep 20, 2022 at 2:06 PM Aleksander Alekseev
wrote:
>
> Hi Amit,
>
> > I think it is better to use Size. Even though, it may not fail now as
> > the size of names for origin will always be much lesser but it is
> > better if we are consistent. If we agree with this, then as a first
> >
Hi,
On 2022-09-21 09:52:48 +0700, John Naylor wrote:
> On Wed, Sep 21, 2022 at 7:11 AM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2022-09-19 19:16:30 -0700, Andres Freund wrote:
> > > To have some initial "translation" for other developers I've started a
> wiki
> > > page with a translation
On Wed, Sep 21, 2022 at 10:31:47AM +0900, Michael Paquier wrote:
> Did you just run an aclupdate()? 4% for aclitem[] sounds like quite a
> number to me :/ It may be worth looking at if these operations could
> be locally optimized more, as well. I'd like to think that we could
> live with that
Hi,
On Wed, Sep 21, 2022 at 01:58:47PM +1000, James Sewell wrote:
> Hello Hackers!
>
> Is it possible to get the current virtual txid from C somehow?
>
> I've looked through the code, but can't seem to find anything other than
> getting a NULL when there is no (real) xid assigned. Maybe I'm
HI,
On Sep 21, 2022, 11:59 +0800, James Sewell , wrote:
> Hello Hackers!
>
> Is it possible to get the current virtual txid from C somehow?
>
> I've looked through the code, but can't seem to find anything other than
> getting a NULL when there is no (real) xid assigned. Maybe I'm missing
>
On Wed, 21 Sep 2022 at 11:58, James Sewell wrote:
> Hello Hackers!
>
> Is it possible to get the current virtual txid from C somehow?
>
The virtual txid is consisted of MyProc->backendId and MyProc->lxid. Do you
mean a C function that returns virtual txid?
> I've looked through the code, but
Hello Hackers!
Is it possible to get the current virtual txid from C somehow?
I've looked through the code, but can't seem to find anything other than
getting a NULL when there is no (real) xid assigned. Maybe I'm missing
something?
Cheers,
James
Hi hackers,
In 6c2003f8a1bbc7c192a2e83ec51581c018aa162f, we change the snapshot name
when exporting snapshot, however, there is one place we missed update the
snapshot name in documentation. Attach a patch to fix it.
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
>From
On Wed, Sep 21, 2022 at 7:11 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-09-19 19:16:30 -0700, Andres Freund wrote:
> > To have some initial "translation" for other developers I've started a
wiki
> > page with a translation table. Still very WIP:
> > https://wiki.postgresql.org/wiki/Meson
> >
> >
On Wednesday, September 21, 2022 4:06 AM Mark Dilger
wrote:
> > On Sep 20, 2022, at 12:36 PM, Jonathan S. Katz
> wrote:
> >
> > This behavior exists "FOR ALL TABLES" without the "IN SCHEMA" qualifier.
> This was discussed multiple times on the original thread[1].
>
> Yes, nobody is debating
On 2022/09/20 15:15, bt22nakamorit wrote:
I thought that this action is rather unexpected since, based on the
word """ON_ERROR_STOP""", ones may expect that failures of shell
scripts should halt the incoming instructions as well.
One clear solution is to let failures of shell script stop
On Fri, Aug 19, 2022 at 5:27 PM Bharath Rupireddy
wrote:
>
> Please review the attached v6 patch.
I'm attaching the v7 patch rebased on to the latest HEAD.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From
> One last thing - do you think there is any need to mention this
> behaviour in the pgdocs, or is OK just to be a hidden performance
> improvement?
FYI - I put my opinion.
We have following sentence in the logical-replication.sgml:
```
...
If the table does not have any suitable key, then it
[personal views, not RMT]
On 9/20/22 4:06 PM, Mark Dilger wrote:
I don't complain that it is buidling on the existing behavior. I'm *only*
concerned about the keywords we're using for this. Consider the following:
-- AS ADMIN
CREATE USER bob NOSUPERUSER;
GRANT ALL PRIVILEGES ON
> FYI -
>
> The latest patch 30-0001 fails to apply, it seems due to a recent commit [1].
>
> [postgres@CentOS7-x64 oss_postgres_misc]$ git apply
> ../patches_misc/v30-0001-Perform-streaming-logical-transactions-by-
> parall.patch
> error: patch failed: src/include/replication/logicalproto.h:246
FYI -
The latest patch 30-0001 fails to apply, it seems due to a recent commit [1].
[postgres@CentOS7-x64 oss_postgres_misc]$ git apply
../patches_misc/v30-0001-Perform-streaming-logical-transactions-by-parall.patch
error: patch failed: src/include/replication/logicalproto.h:246
error:
On Tue, 2 Aug 2022 at 03:37, Simon Riggs wrote:
> Using the above test case, I'm getting a further 4-7% improvement on
> already committed code with the attached patch, which follows your
> proposal.
>
> The patch passes info via a state object, useful to avoid API churn in
> later patches.
Hi
On Tue, Sep 20, 2022 at 04:50:10PM -0700, Nathan Bossart wrote:
> On Tue, Sep 20, 2022 at 04:31:17PM -0700, Nathan Bossart wrote:
>> On Tue, Sep 20, 2022 at 11:05:33AM -0700, Nathan Bossart wrote:
>>> On Tue, Sep 20, 2022 at 02:45:52PM +0900, Michael Paquier wrote:
Any impact for the column
On Tue, Sep 20, 2022 at 08:01:20AM -0400, James Coleman wrote:
> I don't have access to a Windows machine for testing, but re-reading
> the documentation it looks like the issue is that our noreturn macro
> is used after the definition while the MSVC equivalent is used before.
A CI setup would do
Hi,
On 2022-09-20 12:45:24 +0300, Aleksander Alekseev wrote:
> > I'm not sure how to avoid any undefined behaviour without locks though.
> > Even with locks, performance is much better. But is it good enough for
> > production?
>
> Potentially you could avoid taking locks by utilizing atomic
>
Hi Onder,
Thanks for addressing all my previous feedback. I checked the latest
v12-0001, and have no more comments at this time.
One last thing - do you think there is any need to mention this
behaviour in the pgdocs, or is OK just to be a hidden performance
improvement?
--
Kind Regards,
Hi,
On 2022-09-19 19:16:30 -0700, Andres Freund wrote:
> To have some initial "translation" for other developers I've started a wiki
> page with a translation table. Still very WIP:
> https://wiki.postgresql.org/wiki/Meson
>
> For now, a bit of polishing aside, I'm just planning to add a minimal
On Tue, Sep 20, 2022 at 04:31:17PM -0700, Nathan Bossart wrote:
> On Tue, Sep 20, 2022 at 11:05:33AM -0700, Nathan Bossart wrote:
>> On Tue, Sep 20, 2022 at 02:45:52PM +0900, Michael Paquier wrote:
>>> Any impact for the column sizes of the catalogs holding ACL
>>> information? Just asking while
Zhihong Yu writes:
> I was looking at this check in src/backend/parser/parse_utilcmd.c w.r.t.
> constraint:
> ...
> If the index has DESC sorting order, why it cannot be used to back a
> constraint ?
> Some concrete sample would help me understand this.
Please read the nearby comments,
On Tue, Sep 20, 2022 at 11:05:33AM -0700, Nathan Bossart wrote:
> On Tue, Sep 20, 2022 at 02:45:52PM +0900, Michael Paquier wrote:
>> Any impact for the column sizes of the catalogs holding ACL
>> information? Just asking while browsing the patch set.
>
> Since each aclitem requires 16 bytes
Hi Mahendrakar, thanks for your interest and for the patch!
On Mon, Sep 19, 2022 at 10:03 PM mahendrakar s
wrote:
> The changes for each component are summarized below.
>
> 1. Provider-specific extension:
> Each OAuth provider implements their own token validator as an
> extension.
On Tue, Sep 20, 2022 at 04:00:26PM -0700, Nathan Bossart wrote:
> On Mon, Aug 08, 2022 at 06:10:23PM +0530, Bharath Rupireddy wrote:
>> I'm attaching v5 patch-set. I've addressed review comments received so
>> far and fixed a compiler warning that CF bot complained about.
>>
>> Please review it
On Mon, Aug 08, 2022 at 06:10:23PM +0530, Bharath Rupireddy wrote:
> I'm attaching v5 patch-set. I've addressed review comments received so
> far and fixed a compiler warning that CF bot complained about.
>
> Please review it further.
0001 looks reasonable to me.
+errno = 0;
+rc
On Tue, Sep 20, 2022 at 5:08 PM James Coleman wrote:
> - A safe explain (e.g., disallow catalog access) that is potentially
> missing information.
This would be pretty useless I think, because you'd be missing all
relation names.
> - A safe way to interrupt queries such as "safe shutdown" of a
On Mon, Sep 12, 2022 at 2:01 PM Peter Geoghegan wrote:
> I'd like to talk about one such technique on this thread. The attached
> WIP patch reduces the size of xl_heap_freeze_page records by applying
> a simple deduplication process.
Attached is v2, which I'm just posting to keep CFTester happy.
On Tue, Sep 20, 2022 at 3:06 PM Robert Haas wrote:
>
> On Tue, Sep 20, 2022 at 2:35 PM James Coleman wrote:
> > Either I'm missing something (and/or this was fixed in a later PG
> > version), but I don't think this is how it works. We have this
> > specific problem now: we set
On Mon, Sep 19, 2022 at 11:36 PM Peter Geoghegan wrote:
> Attached revision v4 fixes those pg_dump patch items.
>
> It also breaks out the ecpg changes into their own patch.
I pushed much of this just now. All that remains to bring the entire
codebase into compliance is the ecpg patch and the
> On Sep 20, 2022, at 12:36 PM, Jonathan S. Katz wrote:
>
> This behavior exists "FOR ALL TABLES" without the "IN SCHEMA" qualifier. This
> was discussed multiple times on the original thread[1].
Yes, nobody is debating that as far as I can see. And I do take your point
that this stuff
(RMT hat on, unless otherwise noted)
On 9/20/22 9:42 AM, Robert Haas wrote:
On Mon, Sep 19, 2022 at 11:03 PM Jonathan S. Katz wrote:
For #1 (allowing calls that have schema/table overlap...), there appears
to be both a patch that allows this (reversing[8]), and a suggestion for
dealing with a
On 9/20/22 10:55 AM, Mark Dilger wrote:
On Sep 19, 2022, at 8:03 PM, Jonathan S. Katz wrote:
"When a partitioned table is added to a publication, all of its existing and future
partitions are implicitly considered to be part of the publication."[10]
Additionally, this is the behavior that
Hello,
I’m working on a patch to support logical replication of large objects
(LOBs). This is a useful feature when a database in logical
replication has lots of tables, functions and other objects that
change over time, such as in online cross major version upgrade. As
an example, this lets
On Tue Sep 20, 2022 at 11:34 AM PDT, James Coleman wrote:
> On Tue, Sep 20, 2022 at 2:12 PM Gurjeet wrote:
> >
> > For someone who would like to achieve this in the field today, I believe
> > they can set auto_explain.log_min_duration equal to, or less than,
> > statement_timeout.
>
> Either I'm
On Tue, Sep 20, 2022 at 2:35 PM James Coleman wrote:
> Either I'm missing something (and/or this was fixed in a later PG
> version), but I don't think this is how it works. We have this
> specific problem now: we set auto_explain.log_min_duration to 200 (ms)
> and statement_timeout set to 30s,
Alvaro Herrera writes:
> After spending way too much time editing this line, I ended up with
> exactly what Tom proposed, so +1 for his version. I think "This
> controls" adds nothing very useful, and we don't have it anywhere else,
> except tcp_keepalives_count from where I also propose to
On Tue, Sep 20, 2022 at 11:01 AM Jacob Champion wrote:
> Well, I'm working on a next version, but it's ballooning in complexity
> as I try to navigate the fix for OpenSSL 1.0.1 (which is currently
> failing the tests, unsurprisingly).
To be more specific: I think I'm hitting the case that Heikki
On Tue, Sep 20, 2022 at 2:12 PM Gurjeet wrote:
>
> On Tue Sep 20, 2022 at 10:34 AM PDT, James Coleman wrote:
> > Hopefully I'm not missing something obvious, but as far as I know
> > there's no way to configure auto explain to work fire
> > statement_timeout fires.
>
> I believe you're correct.
>
Here is a rebased patch for cfbot.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 9ae1f5409ddeee17b99a9565247da885cbb86be9 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 22 Mar 2022 15:35:34 -0700
Subject: [PATCH v6 1/1] Disallow setting XMAX_COMMITTED and
On Tue Sep 20, 2022 at 10:34 AM PDT, James Coleman wrote:
> Hopefully I'm not missing something obvious, but as far as I know
> there's no way to configure auto explain to work fire
> statement_timeout fires.
I believe you're correct.
> I'd like to look into this at some point, but I'm wondering
On Tue, Sep 20, 2022 at 02:45:52PM +0900, Michael Paquier wrote:
> I have gone through the thread, and I'd agree with getting more
> granularity when it comes to assigning ACLs to relations rather than
> just an on/off switch for the objects of a given type would be nice.
> I've been looking at
On Mon, Sep 19, 2022 at 5:54 PM Michael Paquier wrote:
> X509_get_signature_nid() has been introduced in 1.0.2.
> SSL_export_keying_material() is older than that, being present since
> 1.0.1. Considering the fact that we want to always have
> tls-server-end-point as default, it seems to me that
On Tue, 2022-08-02 at 13:30 -0700, Mary Xu wrote:
> > Right, same thing I'm saying. I also think we should discourage
> > people from doing cowboy CCIs inside their OAT hooks, because that
> > makes the testability problem even worse. Maybe that means we
> > need to uniformly move the CREATE
On Thu, Sep 8, 2022 at 2:34 PM Jacob Champion wrote:
> I still have yet to update the section "5 to 7 days before end of CF"
> and onward.
Well, I've saved the hardest part for last...
Ibrar, Hamid, have the checklist rewrites been helpful so far? Are you
planning on doing an (optional!)
For publication schemas (OBJECT_PUBLICATION_NAMESPACE) and user
mappings (OBJECT_USER_MAPPING), pg_get_object_address() checked the
array length of the second argument, but not of the first argument.
If the first argument was too long, it would just silently ignore
everything but the first
Hopefully I'm not missing something obvious, but as far as I know
there's no way to configure auto explain to work fire
statement_timeout fires.
I'd like to look into this at some point, but I'm wondering if anyone
has thought about it before, and, if so, is there any obvious
impediment to doing
On 2022-Sep-16, Amit Kapila wrote:
> We only want to commit the changes to 15 (a) if those fixes a problem
> introduced in 15, or (b) those are for a bug fix. I think the error
> message improvements fall into none of those categories, we can map it
> to (b) but I feel those are an improvement in
On Mon, Sep 19, 2022 at 9:09 PM Tom Lane wrote:
> You have to assume that somebody (a) has a role or DB name starting
> with slash, (b) has an explicit reference to that name in their
> pg_hba.conf, (c) doesn't read the release notes, and (d) doesn't
> notice that things are misbehaving until
On Fri, Sep 9, 2022 at 6:02 AM Dilip Kumar wrote:
> [ new patch ]
+typedef pg_int64 RelFileNumber;
This seems really random to me. First, why isn't this an unsigned
type? OID is unsigned and I don't see a reason to change to a signed
type. But even if we were going to change to a signed type,
On Tue, Sep 20, 2022 at 10:39 AM Alvaro Herrera wrote:
> That said, the patch I posted for this ~10 years ago used a separate
> contype and was simpler than what I ended up with now, but amusingly
> enough it was returned at the time with the argument that it would be
> better to treat them as
Hi,
I was looking at this check in src/backend/parser/parse_utilcmd.c w.r.t.
constraint:
if (indclass->values[i] != defopclass ||
attform->attcollation != index_rel->rd_indcollation[i]
||
attoptions != (Datum) 0 ||
On 2022-Sep-14, Kyotaro Horiguchi wrote:
> At Tue, 13 Sep 2022 22:38:46 -0400, Tom Lane wrote in
> > Kyotaro Horiguchi writes:
> > > I saw the following message recently modified.
> > >> This controls the maximum distance we can read ahead in the WAL to
> > >> prefetch referenced data blocks.
I wrote:
> (That verbiage is from the gcc manual; clang seems to act the same
> except that -Wcast-function-type is selected by -Wall, or perhaps is
> even on by default.)
Nah, scratch that: the reason -Wcast-function-type is on is that
we explicitly enable it, and have done so since de8feb1f3
On 2022-Sep-18, Fujii Masao wrote:
> The tab-completion code for MERGE was added in the middle of that for LOCK
> TABLE.
> This would be an oversight of the commit that originally supported
> tab-completion
> for MERGE. I fixed this issue.
Argh, thanks.
> "MERGE" was tab-completed with just
On 2022-Sep-20, Matthias van de Meent wrote:
> Allow me to add: compressability
>
> In the thread surrounding [0] there were complaints about the size of
> catalogs, and specifically the template database. Significant parts of
> that (688kB of 8080kB a fresh PG14 database) are in pg_rewrite,
> On Sep 19, 2022, at 8:03 PM, Jonathan S. Katz wrote:
>
> "When a partitioned table is added to a publication, all of its existing and
> future partitions are implicitly considered to be part of the
> publication."[10]
>
> Additionally, this is the behavior that is already present in "FOR
On 2022-09-19 17:47, Алена Рыбакина wrote:
Thanks for your review and comments!
Hi,
I'm sorry,if this message is duplicated previous this one, but I'm not
sure that the previous message is sent correctly. I sent it from email
address a.rybak...@postgrespro.ru and I couldn't send this one email
On 2022-Sep-20, Isaac Morland wrote:
> On Tue, 20 Sept 2022 at 06:56, Alvaro Herrera
> wrote:
>
> > .. though I'm now wondering if there's additional overhead from checking
> > the constraint twice on each row: first the attnotnull bit, then the
> > CHECK itself. Hmm. That's probably quite
On Fri, Sep 9, 2022 at 3:32 PM Dilip Kumar wrote:
>
> On Thu, Sep 8, 2022 at 4:10 PM Dilip Kumar wrote:
>
> > On a separate note, while reviewing the latest patch I see there is some
> > risk of using the unflushed relfilenumber in GetNewRelFileNumber()
> > function. Basically, in the current
On Tue, 20 Sept 2022 at 06:56, Alvaro Herrera
wrote:
The NULL checks would still be mostly done by the attnotnull checks
> internally, so there shouldn't be too much of a difference.
>
> .. though I'm now wondering if there's additional overhead from checking
> the constraint twice on each row:
> On 20 Sep 2022, at 15:43, Sergey Shinderuk wrote:
>
> On 02.09.2022 18:36, Daniel Gustafsson wrote:
>> This had bitrotted a fair bit, attached is a rebase along with (mostly)
>> documentation fixes. 0001 adds a generic GUC for ignoring event triggers and
>> 0002 adds the login event with
On 2022-Sep-13, Kyotaro Horiguchi wrote:
> At Mon, 12 Sep 2022 04:26:48 +, "houzj.f...@fujitsu.com"
> wrote in
> > I feel we'd better compare the syntax with the existing publication command:
> > FOR ALL TABLES. If you create a publication FOR ALL TABLES, it means
> > publishing
> > all
On 02.09.2022 18:36, Daniel Gustafsson wrote:
This had bitrotted a fair bit, attached is a rebase along with (mostly)
documentation fixes. 0001 adds a generic GUC for ignoring event triggers and
0002 adds the login event with event trigger support, and hooks it up to the
GUC such that broken
On Mon, Sep 19, 2022 at 11:03 PM Jonathan S. Katz wrote:
> For #1 (allowing calls that have schema/table overlap...), there appears
> to be both a patch that allows this (reversing[8]), and a suggestion for
> dealing with a corner-case that is reasonable, i.e. disallowing adding
> schemas to a
On Tue, Sep 20, 2022 at 5:00 AM Himanshu Upadhyaya
wrote:
> Please find it attached.
This patch still has no test cases. Just as we have test cases for the
existing corruption checks, we should have test cases for these new
corruption checks, showing cases where they actually fire.
I think I
Hi,
On Sep 20, 2022, 20:49 +0800, Melih Mutlu , wrote:
> Hi Zhang,
>
> Those are two different locks.
> The locks that are taken in the patch are for buffer headers. This locks only
> the current buffer and makes that particular buffer's info consistent within
> itself.
>
> However, the lock
Hi Zhang,
Those are two different locks.
The locks that are taken in the patch are for buffer headers. This locks
only the current buffer and makes that particular buffer's info consistent
within itself.
However, the lock mentioned in the doc is for buffer manager which would
prevent changes on
Hi,
Regards,
Zhang Mingli
On Sep 20, 2022, 20:43 +0800, Aleksander Alekseev ,
wrote:
>
> Correct, the procedure doesn't take the locks of the buffer manager.
> It does take the locks of every individual buffer.
Ah, now I get it, thanks.
Hi Zhang,
> The doc says we don’t take lock during pg_buffercache_summary, but I see
> locks in the v8 patch, Isn’t it?
>
> ```
> Similar to pg_buffercache_pages function
> pg_buffercache_summary doesn't take buffer manager
> locks [...]
> ```
Correct, the procedure doesn't take the locks of
Hi,
Correct me if I’m wrong.
The doc says we don’t take lock during pg_buffercache_summary, but I see locks
in the v8 patch, Isn’t it?
```
Similar to pg_buffercache_pages function
pg_buffercache_summary doesn't take buffer manager
locks, thus the result is not consistent across all buffers.
On Mon, Sep 19, 2022 at 4:42 PM Dmitry Koval wrote:
> Thanks for comments and advice!
> I thought about this problem and discussed about it with colleagues.
> Unfortunately, I don't know of a good general solution.
Yeah, me neither.
> But for specific situation like this (certain partition is
On Tue, Sep 20, 2022 at 12:57 PM Alvaro Herrera wrote:
>
> On 2022-Sep-19, Bharath Rupireddy wrote:
>
> > We have a bunch of messages [1] that have an offset, but not LSN in
> > the error message. Firstly, is there an easiest way to figure out LSN
> > from offset reported in the error messages?
Hi,
Seems like cfbot tests are passing now:
https://cirrus-ci.com/build/4727923671302144
Best,
Melih
Melih Mutlu , 20 Eyl 2022 Sal, 14:00 tarihinde şunu
yazdı:
> Aleksander Alekseev , 20 Eyl 2022 Sal, 13:57
> tarihinde şunu yazdı:
>
>> There was a missing empty line in pg_buffercache.out which
On Tue, Sep 20, 2022 at 9:02 AM Nathan Bossart wrote:
>
> On Mon, Sep 19, 2022 at 03:16:42PM -0700, Nathan Bossart wrote:
> > It seems like you want the opposite of pg_walfile_name_offset(). Perhaps
> > we could add a function like pg_walfile_offset_lsn() that accepts a WAL
> > file name and
On Mon, Sep 19, 2022 at 11:21 PM Michael Paquier wrote:
>
> On Mon, Sep 19, 2022 at 08:51:37PM -0400, James Coleman wrote:
> > Yes, fixed.
>
> The CF bot is failing compilation on Windows:
> http://commitfest.cputube.org/james-coleman.html
>
On Tue, Sep 20, 2022 at 2:57 PM Alvaro Herrera wrote:
>
> On 2022-Sep-20, Amit Kapila wrote:
>
> > On Mon, Sep 19, 2022 at 8:46 PM Alvaro Herrera
> > wrote:
>
> > > This seems a pretty arbitrary restriction. It feels like you're adding
> > > this restriction precisely so that you don't have to
On Tue, Sep 20, 2022 at 7:20 AM Michael Paquier wrote:
>
> The main regression test suite should not include direct calls to
> pg_backup_start() or pg_backup_stop() as these depend on wal_level,
> and we spend a certain amount of resources in keeping the tests a
> maximum portable across such
On Mon, Sep 19, 2022 at 8:19 PM Ashutosh Sharma wrote:
>
> Hi All,
>
> Currently, we have pg_current_wal_insert_lsn and pg_walfile_name sql
> functions which gives us information about the next wal insert
> location and the WAL file that the next wal insert location belongs
> to. Can we have a
On Tue, 20 Sept 2022 at 12:00, Alexander Korotkov wrote:
> On Tue, Sep 20, 2022 at 7:48 AM Tom Lane wrote:
> > Peter Geoghegan writes:
> > > On Mon, Sep 19, 2022 at 8:39 PM Tom Lane wrote:
> > >> Our existing format is certainly not great on those metrics, but
> > >> I do not see how "let's
Thank you!
Il mar 20 set 2022, 12:29 Michael Paquier ha scritto:
> On Tue, Sep 20, 2022 at 08:41:56AM +0200, Florin Irion wrote:
> > OK, patch only for the docs attached.
>
> Thanks, applied.
> --
> Michael
>
Hi,
On 9/20/22 6:30 AM, Michael Paquier wrote:
On Tue, Sep 20, 2022 at 12:09:33AM -0400, Tom Lane wrote:
You have to assume that somebody (a) has a role or DB name starting
with slash, (b) has an explicit reference to that name in their
pg_hba.conf, (c) doesn't read the release notes, and (d)
Aleksander Alekseev , 20 Eyl 2022 Sal, 13:57
tarihinde şunu yazdı:
> There was a missing empty line in pg_buffercache.out which made the
> tests fail. Here is a corrected v8 patch.
>
I was just sending a corrected patch without the missing line.
Thanks a lot for all these reviews and the
Hi hackers,
> Here is a corrected patch v7. To me it seems to be in pretty good
> shape, unless cfbot and/or other hackers will report any issues.
There was a missing empty line in pg_buffercache.out which made the
tests fail. Here is a corrected v8 patch.
--
Best regards,
Aleksander Alekseev
On 2022-Sep-19, Matthias van de Meent wrote:
> I'm not sure on the 'good' part of this alternative, but we could go
> with a single row-based IS NOT NULL to reduce such clutter, utilizing
> the `ROW() IS NOT NULL` requirement of a row only matching IS NOT NULL
> when all attributes are also IS
On 2022-Sep-19, Isaac Morland wrote:
> I thought I saw some discussion about the SQL standard saying that there is
> a difference between putting NOT NULL in a column definition, and CHECK
> (column_name NOT NULL). So if we're going to take this seriously,
Was it Peter E.'s reply to this thread?
On 2022-Sep-19, Robert Haas wrote:
> On Wed, Aug 17, 2022 at 2:12 PM Alvaro Herrera
> wrote:
> > 55489 16devel 1776237=# \d tab
> > Tabla «public.tab»
> > Columna │ Tipo │ Ordenamiento │ Nulable │ Por omisión
> >
On Tue, Sep 20, 2022 at 08:41:56AM +0200, Florin Irion wrote:
> OK, patch only for the docs attached.
Thanks, applied.
--
Michael
signature.asc
Description: PGP signature
Hi Peter,
>
> 1. src/backend/executor/execReplication.c - build_replindex_scan_key
>
> - * This is not generic routine, it expects the idxrel to be replication
> - * identity of a rel and meet all limitations associated with that.
> + * This is not generic routine, it expects the idxrel to be
Hi Peter,
Thanks for the quick response.
> 1. Commit message
>
> It looks like some small mistake happened. You wrote [1] that my
> previous review comments about the commit message were fixed, but it
> seems the v11 commit message is unchanged since v10.
>
>
Oops, yes you are right, I forgot
On Tue, Sep 20, 2022 at 1:00 PM Alexander Korotkov wrote:
> On Tue, Sep 20, 2022 at 7:48 AM Tom Lane wrote:
> > Peter Geoghegan writes:
> > > On Mon, Sep 19, 2022 at 8:39 PM Tom Lane wrote:
> > >> Our existing format is certainly not great on those metrics, but
> > >> I do not see how "let's
On Tue, Sep 20, 2022 at 7:48 AM Tom Lane wrote:
> Peter Geoghegan writes:
> > On Mon, Sep 19, 2022 at 8:39 PM Tom Lane wrote:
> >> Our existing format is certainly not great on those metrics, but
> >> I do not see how "let's use JSON!" is a route to improvement.
>
> > The existing format was
On 17.09.22 10:33, Marina Polyakova wrote:
Thanks to Kyotaro Horiguchi review we found out that there're
interesting cases due to the order of some ICU checks:
1. ICU locale vs supported encoding:
1.1.
On 2022-09-15 09:52, Kyotaro Horiguchi wrote:
If I executed initdb as follows, I would be
Hi Melih,
> I changed these names and updated the patch.
Thanks for the updated patch!
> Aleksander, do you still think the average usagecount is a bit useless? Or
> does it make sense to you to keep it like this?
I don't mind keeping the average.
> I'm not sure how to avoid any undefined
Hi,
On Sep 20, 2022, 17:26 +0800, Justin Pryzby , wrote:
> On Tue, Sep 20, 2022 at 03:37:47PM +0800, Zhang Mingli wrote:
> > I want to have a look at these patches, but apply on master failed:
>
> Yeah, it's likely to break every week or more often.
>
> You have a few options:
>
> 0) resolve the
1 - 100 of 122 matches
Mail list logo
