On Tue, Nov 9, 2021 at 8:28 PM Rafia Sabih wrote:
>
> On Tue, 2 Nov 2021 at 09:00, Dilip Kumar wrote:
> >
> > About the patch, IIUC earlier all the idle time was accumulated in the
> > "pgStatTransactionIdleTime" counter, now with your patch you have
> > introduced one more counter which specifi
At Tue, 09 Nov 2021 17:05:49 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Tue, 9 Nov 2021 12:51:15 +0900, Michael Paquier
> wrote in
> > Look at Utils.pm where we have dir_symlink, then. symlink() does not
> > work on WIN32, so we have a wrapper that uses junction points. FWIW,
> > I don't
On Wed, 10 Nov 2021 at 09:05, Dilip Kumar wrote:
>
> On Tue, Nov 9, 2021 at 8:28 PM Rafia Sabih wrote:
> >
> > On Tue, 2 Nov 2021 at 09:00, Dilip Kumar wrote:
> > >
>
> > > About the patch, IIUC earlier all the idle time was accumulated in the
> > > "pgStatTransactionIdleTime" counter, now with
Thanks for your time Pavel
> On 09-Nov-2021, at 13:32, Pavel Stehule wrote:
>
>
> Hi
>
> po 8. 11. 2021 v 9:57 odesílatel Dinesh Chemuduru
> napsal:
>> Thanks Zhihong/Pavel,
>>
>>> On Mon, 8 Nov 2021 at 10:03, Pavel Stehule wrote:
>>>
>>>
>>> po 8. 11. 2021 v 5:24 odesílatel Pavel Stehu
Greetings hackers.
It seems that PostgreSQL 14 allows using the AT TIME ZONE operator within
generated column definitions; according to the docs, that means the
operator is considered immutable. However, unless I'm mistaken, the result
of AT TIME ZONE depends on the time zone database, which is ex
> On 10 Nov 2021, at 08:12, Greg Nancarrow wrote:
>
> On Fri, Nov 5, 2021 at 3:03 PM Greg Nancarrow wrote:
>>
>> +1
>> The arguments given are pretty convincing IMHO, and I agree that the
>> additions made in the v20 patch are not a good idea, and are not needed.
>
> If there are no objection
On Wednesday, November 10, 2021 3:43 PM Dilip Kumar
wrote:
> On Tue, Nov 9, 2021 at 5:05 PM osumi.takami...@fujitsu.com
> wrote:
> > On Tuesday, November 9, 2021 12:08 PM Greg Nancarrow
> wrote:
> > > On Fri, Nov 5, 2021 at 7:11 PM osumi.takami...@fujitsu.com
> > > wrote:
> > > >
> > >
> > > I
On Fri, Oct 22, 2021 at 11:08 AM Masahiko Sawada wrote:
>
> On Wed, Oct 20, 2021 at 9:27 AM Masahiko Sawada wrote:
>
> I agree to copy statusFlags in ProcArrayInstallRestoredXmin(). I've
> updated the patch accordingly.
>
1.
@@ -2663,7 +2677,16 @@ ProcArrayInstallRestoredXmin(TransactionId
xmin,
On Wed, Oct 27, 2021 at 1:02 AM Mahendra Singh Thalor
wrote:
> On Mon, 3 Aug 2020 at 15:02, Daniel Gustafsson wrote:
>>
>> This thread has stalled and the patch no longer applies, so I'm marking this
>> Returned with Feedback. Please feel free to open a new entry if this patch
>> is
>> revived.
On 01.11.21 00:24, Andres Freund wrote:
Hi,
Attached is an updated version of the meson patchset.
Nanoreview: I think the patch
Subject: [PATCH v5 11/16] meson: prereq: Handle DLSUFFIX in msvc builds
similar to other build envs.
is good to go. It's not clear why it's needed in this contex
On Tue, Nov 9, 2021 at 5:05 PM osumi.takami...@fujitsu.com
wrote:
> Yes. I've rebased and updated the patch, paying attention to this point.
> Attached the updated version.
Thanks for the updated patch, few comments:
1) you could rename PgStat_StatSubWorkerPreparedXact to
PgStat_SW_PreparedXactKe
Hello,
after plain ./configure without options (including noticeable absence of
--with-openssl) and make,
make -C contrib COPT=-Werror gives error with gcc-11 on REL_9_6_STABLE,
REL_10_STABLE or REL_11_STABLE.
The warning/error is about misleading indent in
contrib/pgcrypto/imath.c's CLAMP m
On Wed, Sep 29, 2021 at 4:48 PM Daniel Gustafsson wrote:
> > Other places in the code just refers to the background process as "the
> > background process". The term "WAL receiver" is new from this patch.
> > While I agree it's in many ways a better term, I think (1) we should
> > try to be consi
Hello postgresql uses hba_file configuration parameter: https://www.postgresql.org/docs/current/runtime-config-file-locations.htmlSo could be changed in postgresql.conf regards, Sergei
On Fri, Oct 15, 2021 at 11:31 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 14 Oct 2021 10:53:06 -0700, Andres Freund wrote
> in
> > Hi,
> >
> > On 2021-10-14 17:28:34 +0900, Kyotaro Horiguchi wrote:
> > > At Wed, 13 Oct 2021 19:52:52 +0900 (JST), Kyotaro Horiguchi
> > > wrote in
> > > > Although ne
On Fri, Nov 5, 2021 at 8:16 PM Matthias van de Meent
wrote:
>
> On Fri, 22 Oct 2021 at 07:38, Masahiko Sawada wrote:
> >
> > On Wed, Oct 20, 2021 at 9:27 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Oct 20, 2021 at 3:07 AM Alvaro Herrera
> > > wrote:
> > > >
> > > > On 2021-Oct-19, Alvar
Thanks Dilip and Bharath for the review.
I am working on review comments and will post an updated patch.
On Wed, 10 Nov 2021 at 15:31, Bharath Rupireddy
wrote:
>
> On Wed, Oct 27, 2021 at 1:02 AM Mahendra Singh Thalor
> wrote:
> > On Mon, 3 Aug 2020 at 15:02, Daniel Gustafsson wrote:
> >>
> >>
On 04.11.21 20:54, Andres Freund wrote:
Finally, morally related, there is some Python 2/3 compat code in
contrib/unaccent/generate_unaccent_rules.py that could be removed. Also,
arguably, change the shebang line in that script.
Hm. So far the python used for plpython and python for code genera
I'm currently working on a GiST extension for PostgreSQL and I ran into strange
ORDER BY results during my queries.
Because I can't find the problem in my source code, I want to investigate the
issue by looking at the PostgreSQL source,
maybe inserting extra log messages.
While trying to do this
Wow, thanks so much, I checked it and there is a config on postgresql.conf.
Regards,
Chris
On 11/10/2021 18:38，Sergei Kornilov wrote：
Hello
postgresql uses hba_file configuration parameter:
https://www.postgresql.org/docs/current/runtime-config-file-locations.html
So could be changed in postgr
On Mon, Nov 1, 2021 at 2:31 PM Fujii Masao wrote:
> On 2021/10/21 23:55, Bharath Rupireddy wrote:
> >> Also how about adding wait events for other commands like
> >> archive_cleanup_command, restore_command and recovery_end_command?
> >
> > +1 for the wait event.
>
> Thanks!
> I added the wait eve
Great, so great. Thanks you
Bharath Rupireddy schrieb am Mi.,
10. Nov. 2021, 12:20:
> On Mon, Nov 1, 2021 at 2:31 PM Fujii Masao
> wrote:
> > On 2021/10/21 23:55, Bharath Rupireddy wrote:
> > >> Also how about adding wait events for other commands like
> > >> archive_cleanup_command, restore_co
On Wed, Nov 10, 2021 at 12:42 PM tanghy.f...@fujitsu.com
wrote:
>
> Hi
>
> I think I found a bug related to logical replication(REPLICA IDENTITY in
> specific).
> If I change REPLICA IDENTITY after creating publication, the DELETE/UPDATE
> operations won't be replicated as expected.
>
> For exa
On Mon, Nov 1, 2021 at 2:31 PM Fujii Masao wrote:
> > The following activitymsg that are being set to ps display in
> > XLogFileRead and pgarch_archiveXlog have come up for one of our
> > internal team discussions recently:
> >
> > snprintf(activitymsg, sizeof(activitymsg), "waiting f
On Wed, 10 Nov 2021 at 11:57, Sajti Zsolt Zoltán wrote:
>
> I'm currently working on a GiST extension for PostgreSQL and I ran into
> strange ORDER BY results during my queries.
>
> Because I can't find the problem in my source code, I want to investigate the
> issue by looking at the PostgreSQL
On 2021-Nov-09, Tom Lane wrote:
> This is still happening off and on, which makes it look like a
> timing-sensitive problem. Confirming that, I can make it fail
> every time by adding a long sleep just ahead of where
> 026_overwrite_contrecord.pl captures $initfile. On reflection
> I think the p
On Wed, 10 Nov 2021 at 11:51, Amit Kapila wrote:
>
> On Fri, Nov 5, 2021 at 8:16 PM Matthias van de Meent
> wrote:
>
> AFAICU, in the thread referred by you, it seems that the main reported
> issue will be resolved by this patch but there is a discussion about
> xmin moving backward which seems t
On 2021-Nov-10, Kyotaro Horiguchi wrote:
> I bumped into the good-old 100-byte limit of the (v7?) tar format on
> which pg_basebackup is depending. It is unlikely in the real world but
> I think it is quite common in developping environment. The tablespace
> directory path in my dev environment w
On 2021-Nov-10, Michael Paquier wrote:
> I would not have bothered changing things if the names of the modules
> were the same across stable branches to minimize merge conflicts.
>
> However, everything has changed on HEAD, so there is a good argument
> for simplifying the tests as you are propos
On Tue, Nov 09, 2021 at 03:12:39PM +0100, Daniel Gustafsson wrote:
> 2800: CLUSTER on partitioned table
> ==
> The the patch above, it too spawned off from the REINDEX CONCURRENTLY thread
> but seems to have stalled awaiting more review. There was scepticism raised
> On 10 Nov 2021, at 13:37, Alvaro Herrera wrote:
>
> On 2021-Nov-10, Michael Paquier wrote:
>
>> I would not have bothered changing things if the names of the modules
>> were the same across stable branches to minimize merge conflicts.
>>
>> However, everything has changed on HEAD, so there is
Tom Lane writes:
> Also, I think we want
>
> -ok($initfile != $endfile, "$initfile differs from $endfile");
> +ok($initfile ne $endfile, "$initfile differs from $endfile");
>
> The existing coding works as long as all characters of these
> WAL segment names happen to be decimal digits, but ...
E
On Tue, Oct 19, 2021 at 08:02:02PM +0900, Michael Paquier wrote:
> 0001 and 0002, the refactoring bits, are in a rather committable
> shape, so I'd like to apply that as the last refactoring pieces I know
> of for this thread. 0003 still needs a closer lookup, and one part I
> do not like much in
> On 10 Nov 2021, at 11:14, Anton Voloshin wrote:
> The warning/error is about misleading indent in contrib/pgcrypto/imath.c's
> CLAMP macro:
This is upstream code in a stable branch formatted by pgindent at the time of
the release, I'm not sure the churn is worth it for fixing warnings for
non
Dear all,
thanks for the feedback!
We had a closer look at the previous patches and the CustomScan
infrastructure.
Compared to the previous patch, we do not (directly) focus on joins
with the overlap (&&) condition in this patch. Instead we consider
joins with containment (@>) between a range an
On Wed, Nov 10, 2021 at 6:07 PM Alvaro Herrera wrote:
>
> On 2021-Nov-10, Michael Paquier wrote:
>
> > I would not have bothered changing things if the names of the modules
> > were the same across stable branches to minimize merge conflicts.
> >
> > However, everything has changed on HEAD, so the
Shay Rojansky writes:
> It seems that PostgreSQL 14 allows using the AT TIME ZONE operator within
> generated column definitions; according to the docs, that means the
> operator is considered immutable. However, unless I'm mistaken, the result
> of AT TIME ZONE depends on the time zone database,
On Tue, Nov 9, 2021 at 7:41 PM Michael Paquier wrote:
> On Tue, Nov 09, 2021 at 02:15:51PM -0500, Robert Haas wrote:
> > That's a good point. However, since I think newTLI is already in use
> > in some of the functions StartupXLOG() calls, and since I think it
> > would be good to use the same nam
Daniel Gustafsson writes:
>> On 10 Nov 2021, at 13:37, Alvaro Herrera wrote:
>> ..but I wonder what's the *benefit* of removing those includes. IOW, what's
>> the reason not to simply drop the patch?
> I think the value is mostly neatnikism, the actual effect on runtime is
> unlikely to be meas
On Mon, Nov 8, 2021 at 6:36 PM Jeff Davis wrote:
> Extensible rmgr would enable the table AM to support its own
> redo/decode hooks and WAL format, so that it could support crash
> recovery, physical replication, and logical replication.
Without taking a position on your implementation, which I h
On Thu, Nov 4, 2021 at 1:49 PM Bharath Rupireddy
wrote:
> Please review the attached v2 patch.
It looks OK to me.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Nov 9, 2021 at 5:20 PM Tom Lane wrote:
> 1. The distinction between "error" and "fatal" levels seems squishy
> to the point of uselessness.
>
> 2. What is the preferred style for adding extra lines to log messages?
I agree with this list of problems. I think that the end game here is
get
Tom Lane writes:
> Daniel Gustafsson writes:
>>> On 10 Nov 2021, at 13:37, Alvaro Herrera wrote:
>>> ..but I wonder what's the *benefit* of removing those includes. IOW, what's
>>> the reason not to simply drop the patch?
>
>> I think the value is mostly neatnikism, the actual effect on runtim
> Daniel Gustafsson writes:
>
>> 2773: libpq compression
>> ===
>> This patch intended to provide libpq connection compression to "replace SSL
>> compression" which was doomed when the patch was written, and have since been
>> removed altogether. The initial approach didn't
Thread starting here:
https://www.postgresql.org/message-id/20201001021609.GC8476%40telsasoft.com
On Fri, Dec 18, 2020 at 05:56:07PM -0600, Justin Pryzby wrote:
> I'm 99% sure the "bad_alloc" is from LLVM. It happened multiple times on
> different servers (running a similar report) after setting
On Wed, Nov 10, 2021 at 9:53 AM Tom Lane wrote:
> Yeah, that last was pretty much my reaction. I don't know enough about
> Perl to be sure how much an unused import costs, but I suspect you're
> right that it won't be measurable in context, considering that most of
> these test scripts run at lea
On 11/7/21 1:04 AM, Fujii Masao wrote:
On 2021/11/03 0:03, Bossart, Nathan wrote:
On 11/1/21, 9:44 PM, "Fujii Masao" wrote:
What is the main motivation of this patch? I was thinking that
it's for parallelizing WAL archiving. But as far as I read
the patch very briefly, WAL file name is still
Robert Haas writes:
> I agree with this list of problems. I think that the end game here is
> getting to be able to use ereport() and friends in the frontend, which
> would require confronting both of these issues at a deep level. We
> don't necessarily have to do that now, though, but I think it'
st 10. 11. 2021 v 10:11 odesílatel Daniel Gustafsson
napsal:
> > On 10 Nov 2021, at 08:12, Greg Nancarrow wrote:
> >
> > On Fri, Nov 5, 2021 at 3:03 PM Greg Nancarrow
> wrote:
> >>
> >> +1
> >> The arguments given are pretty convincing IMHO, and I agree that the
> additions made in the v20 patc
Modulo other issues/discussions, here is a version of this patch that
implements CREATE OR REPLACE ROLE just by handing off to AlterRole if it's
determined that the role already exists; presumably any/all additional
considerations would need to be added in both places were there a separate
code pat
On 11/4/21, 3:24 AM, "Daniel Gustafsson" wrote:
> As no update has been posted, the patch still doesn't apply. I'm marking this
> patch Returned with Feedback, feel free to open a new entry for an updated
> patch.
Thanks. I have been working on this intermittently, and I hope to
post a more com
Hi,
As discussed in [1], isn't it a better idea to add some of activity
messages [2] such as recovery, archive, backup, streaming etc. to
server logs at LOG level? They are currently being set into ps display
which is good if the postgres is being run on a standalone box/VM
where users can see the
On Wed, Nov 10, 2021 at 5:00 PM Bharath Rupireddy
wrote:
>
> On Mon, Nov 1, 2021 at 2:31 PM Fujii Masao
> wrote:
> > > The following activitymsg that are being set to ps display in
> > > XLogFileRead and pgarch_archiveXlog have come up for one of our
> > > internal team discussions recently:
> >
On 11/8/21, 2:19 PM, "Joshua Brindle" wrote:
> Thanks for the review, attached is an update with that comment fixed
> and also sgml documentation changes that I missed earlier.
I think there are a number of documentation changes that are still
missing. I did a quick scan and saw the "is member o
On Mon, Nov 1, 2021 at 12:30 AM Andres Freund wrote:
> > Here are a few thoughts on how we could go about doing this. I
> > proposed them earlier in [1],
> > 1) capture and write recovery stats into a file
> > 2) capture and emit recovery stats via a new hook
> > 3) capture and write into a new sy
On 11/10/21 09:53, Tom Lane wrote:
> Daniel Gustafsson writes:
>>> On 10 Nov 2021, at 13:37, Alvaro Herrera wrote:
>>> ..but I wonder what's the *benefit* of removing those includes. IOW, what's
>>> the reason not to simply drop the patch?
>> I think the value is mostly neatnikism, the actual
On 11/10/21, 8:10 AM, "David Steele" wrote:
> On 11/7/21 1:04 AM, Fujii Masao wrote:
>> It's helpful if you share how much this approach reduces
>> the amount of overhead.
>
> FWIW we have a test for this in pgBackRest. Running
> `archive_command=pgbackrest archive-push ...` 1000 times via system(
On 11/10/21, 9:43 AM, "Bharath Rupireddy"
wrote:
> As discussed in [1], isn't it a better idea to add some of activity
> messages [2] such as recovery, archive, backup, streaming etc. to
> server logs at LOG level? They are currently being set into ps display
> which is good if the postgres is be
On 11/10/21 1:22 PM, Bossart, Nathan wrote:
On 11/10/21, 8:10 AM, "David Steele" wrote:
I would prefer this module to be in core as our standard implementation
and load by default in a vanilla install.
Hm. I think I disagree with putting it in contrib and with making it
the default archive
On 11/10/21, 10:42 AM, "David Steele" wrote:
> OK, I haven't had to go over the patch in detail so I didn't realize the
> module was not backwards compatible. I'll have a closer look soon.
It's backward-compatible in the sense that you'd be able to switch
archive_library to "shell" to continue us
On 11/9/21 10:39 PM, Noah Misch wrote:
On Tue, Nov 09, 2021 at 11:25:37AM -0500, Jonathan S. Katz wrote:
Attached please find a draft of the release announcement for 2021-11-11.
Please provide any feedback no later than Thu, Nov 11, 2021 0:00 AoE[1].
Bug Fixes and Improvements
---
I wrote:
> Hmm, interesting. Taking up my point #2, I'd been thinking about
> proposing that we convert
> pg_log_error("query failed: %s", PQerrorMessage(conn));
> pg_log_error("query was: %s", todo);
> to
> pg_log_error("query failed: %s", PQerrorMessage(
On Wed, Nov 10, 2021, at 2:51 PM, Bharath Rupireddy wrote:
> On Mon, Nov 1, 2021 at 12:30 AM Andres Freund wrote:
> > I'm not sure that the new log messages aren't sufficient. But if they
> > aren't, it seems better to keep additional data in the stats system, and
> > make them visible via views,
"Jonathan S. Katz" writes:
> On 11/9/21 10:39 PM, Noah Misch wrote:
>> Please add something like:
>> * Fix REINDEX CONCURRENTLY to preserve operator class parameters that were
>> attached to the target index
> Happy to be convinced otherwise (maybe this is used more than I
> realize?), but I'm n
On 10/28/21, 5:42 AM, "Bharath Rupireddy"
wrote:
> Thanks all for reviewing this. Here's the CF entry -
> https://commitfest.postgresql.org/35/3378/
I've marked this one as ready-for-committer.
Nathan
On 10/1/21, 10:40 PM, "Michael Paquier" wrote:
> On Fri, Oct 01, 2021 at 05:47:45PM +, Bossart, Nathan wrote:
>> I'm inclined to agree that anything that calls update_controlfile()
>> should update the timestamp.
>
> pg_control.h tells that:
> pg_time_t time; /* time stamp of last
postgres=# SELECT log_time , database, user_name, error_severity sev,
left(message,99) FROM postgres_log_2021_11_10_0800 WHERE log_time BETWEEN
'2021-11-10 08:57' AND '2021-11-10 08:58' AND database IS NULL;
log_time | database | user_name | sev |
On Wed, Nov 10, 2021, at 2:38 PM, Bharath Rupireddy wrote:
> As discussed in [1], isn't it a better idea to add some of activity
> messages [2] such as recovery, archive, backup, streaming etc. to
> server logs at LOG level? They are currently being set into ps display
> which is good if the postgr
Justin Pryzby writes:
> I'm surprised that not a single message was logged at PANIC, even though it's
> defined to mean:
The backend you killed didn't get a chance to log anything.
Or to put it another way: a PANIC ereport is the trigger for a database
restart, not a response to some other event
Fujii Masao writes:
> Since PQrequestCancel() is marked as deprecated, I don't think that
> we need to add the feature into it.
Not absolutely necessary, agreed, but it looks like it's pretty
easy to make that happen, so why not? I'd suggest dropping the
separate implementation and turning PQreq
On Wed, Dec 30, 2020 at 8:17 PM Michael Paquier wrote:
> On Tue, Dec 29, 2020 at 04:16:06PM -0500, Tom Lane wrote:
> > Hmph, no, a look at explain.c shows that the "Execution Time" is just
> > based on the difference of INSTR_TIME_SET_CURRENT measurements taken
> > within the current process. It'
> > It seems that PostgreSQL 14 allows using the AT TIME ZONE operator
within
> > generated column definitions; according to the docs, that means the
> > operator is considered immutable. However, unless I'm mistaken, the
result
> > of AT TIME ZONE depends on the time zone database, which is extern
> I'd suggest dropping the separate implementation and turning
> PQrequestCancel() into a thin wrapper around PQgetCancel,
> PQcancel, PQfreeCancel.
Fine by me. I didn't want to change behavior of a deprecated
function.
> I find this patch fairly scary, because it's apparently been coded
> with l
"wangsh.f...@fujitsu.com" writes:
> I don't know this. After some test, I think it's better to consider
> '/hoge/foo/bar'
> as a absolute path.
Agreed. I think we are considering "absolute path" here as a
syntactic concept; Windows' weird rules about drive letters
don't really matter for the p
Shay Rojansky writes:
>> Yeah, we generally don't take such hazards into account. The poster
>> child here is that if we were strict about this, text comparisons
>> couldn't be immutable, because the underlying collation rules can
>> (and do) change from time to time. That's obviously unworkable
On Wed, Nov 10, 2021 at 11:07 AM Jonathan S. Katz wrote:
> > * Fix causes of `CREATE INDEX CONCURRENTLY` and `REINDEX CONCURRENTLY`
> > writing
> > corrupt indexes. You should reindex any concurrently-built indexes.
>
> Done.
As far as I know (correct me if I'm mistaken), all of the CIC/RC bugs
On Thu, Nov 11, 2021 at 10:23:06AM +1300, Thomas Munro wrote:
> If I'm reading this right, it might be further evidence of
> CLOCK_MONOTONIC going backwards on OpenBSD, this time by quite a lot
> (the regular expression doesn't tolerate a leading minus sign, so the
> test failed):
>
> https://buil
On Wed, Nov 10, 2021 at 02:56:00PM +0100, Daniel Gustafsson wrote:
> This is upstream code in a stable branch formatted by pgindent at the time of
> the release, I'm not sure the churn is worth it for fixing warnings for
> non-standard compiler options here. I don't see any of these warnings
> sk
On Thu, Nov 11, 2021 at 1:15 PM Michael Paquier wrote:
> morepork uses 6.9 now, but it has been recently upgraded from 5.4 or
> a version close to that, right? I am wondering if 7.0 may help
> regarding this issue. Postgres is not wrong here.
I dunno. Clocks on virtualised systems and even met
On Wed, Nov 10, 2021 7:29 PM Amit Kapila wrote:
> On Wed, Nov 10, 2021 at 12:42 PM tanghy.f...@fujitsu.com
> wrote:
> >
> > Hi
> >
> > I think I found a bug related to logical replication(REPLICA IDENTITY in
> specific).
> > If I change REPLICA IDENTITY after creating publication, the
> DELETE/U
Hi,
On 2020-11-25 17:03:58 -0300, Alvaro Herrera wrote:
> On 2020-Nov-23, Andres Freund wrote:
>
> > On 2020-11-23 12:30:05 -0300, Alvaro Herrera wrote:
>
> > > In other words, my conclusion is that there definitely is a bug here and
> > > I am going to restore the use of exclusive lock for sett
At Wed, 10 Nov 2021 14:25:08 -0500, Tom Lane wrote in
> I wrote:
> > Hmm, interesting. Taking up my point #2, I'd been thinking about
> > proposing that we convert
> > pg_log_error("query failed: %s", PQerrorMessage(conn));
> > pg_log_error("query was: %s", todo);
> > to
At Wed, 10 Nov 2021 09:14:30 -0300, Alvaro Herrera
wrote in
> Can you use PostgreSQL::Test::Utils::tempdir_short() for those
> tablespaces?
Thanks for the suggestion!
It works for a live cluster. But doesn't work for backups, since I
find no way to relate a tablespace directory with a backup d
Kyotaro Horiguchi writes:
> Aren't DETAIL and HINT expected to be hidden at the targetted cutoff
> level? In other words, I suspect that people want to hide non-primary
> messages for a lower verbosity level. On the other hand I'm not sure
> it is a proper behavior that log_level = WARNING cause
Dear Fujita-san,
I love your proposal because it will remove a bottleneck
for PostgreSQL build-in sharding.
I read your patch briefly and I think basically it's good.
Currently I have only one comment.
In your patch, postgres_fdw sends a COMMIT command to all entries in the hash
table
and wait
On Tue, Nov 9, 2021 at 9:53 PM Masahiko Sawada wrote:
>
> On Fri, Nov 5, 2021 at 4:00 AM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2021-11-01 10:44:34 +0900, Masahiko Sawada wrote:
> > > On Sun, Oct 31, 2021 at 6:21 AM Andres Freund wrote:
> > > > But even though we have this space optimized
On Wed, Nov 10, 2021 at 07:35:21AM +0900, Michael Paquier wrote:
> Tom has suggested that we could add -Wno-compound-token-split-by-macro
> to take care of the issue on our side, and attached is a patch to do
> so.
>
> Any objections? I'd like to get this back-patched.
Backpatched this one as of
Michael Paquier writes:
> Backpatched this one as of 9ff47ea. That should allow the addition of
> -Werror on dangomushi.
Cool. I have also enabled -Werror on florican.
regards, tom lane
Hi,
On 2021-11-10 11:07:02 +0100, Peter Eisentraut wrote:
> On 01.11.21 00:24, Andres Freund wrote:
> > Hi,
> >
> > Attached is an updated version of the meson patchset.
>
> Nanoreview: I think the patch
Thanks for looking!
> Subject: [PATCH v5 11/16] meson: prereq: Handle DLSUFFIX in msvc b
On Wed, Nov 10, 2021 at 6:14 PM Amit Kapila wrote:
>
> On Fri, Oct 22, 2021 at 11:08 AM Masahiko Sawada
> wrote:
> >
> > On Wed, Oct 20, 2021 at 9:27 AM Masahiko Sawada
> > wrote:
> >
> > I agree to copy statusFlags in ProcArrayInstallRestoredXmin(). I've
> > updated the patch accordingly.
> >
Hi,
On 2021-11-11 14:15:33 +1300, Thomas Munro wrote:
> Some starter questions for Mikael would be: could you please check
> which clock source it's using?, is it under a hypervisor, and if so
> which?, what is the CPU model?, what are other kernels choosing when
> running as guests on the same hy
Hi,
On 2021-11-11 12:22:42 +0900, Masahiko Sawada wrote:
> > 2.
> > LWLockAcquire(ProcArrayLock, LW_SHARED);
> >
> > + flags = proc->statusFlags;
> > +
> > + /*
> > + * If the source xact has any statusFlags, we re-grab ProcArrayLock
> > + * on exclusive mode so we can copy it to MyProc->statusF
On Wed, Nov 10, 2021 at 02:07:43PM -0500, Jonathan S. Katz wrote:
> On 11/9/21 10:39 PM, Noah Misch wrote:
> >On Tue, Nov 09, 2021 at 11:25:37AM -0500, Jonathan S. Katz wrote:
> >>Attached please find a draft of the release announcement for 2021-11-11.
> >>Please provide any feedback no later than
On Thu, Nov 11, 2021 at 9:11 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-11-11 12:22:42 +0900, Masahiko Sawada wrote:
> > > 2.
> > > LWLockAcquire(ProcArrayLock, LW_SHARED);
> > >
> > > + flags = proc->statusFlags;
> > > +
> > > + /*
> > > + * If the source xact has any statusFlags, we re-grab P
On Thu, Nov 11, 2021 at 7:07 AM houzj.f...@fujitsu.com
wrote:
>
> On Wed, Nov 10, 2021 7:29 PM Amit Kapila wrote:
> >
> > I don't understand the purpose of idx_b in the above test case, why is it
> > required to reproduce the problem?
> > @@ -15488,6 +15488,7 @@ relation_mark_replica_identity(Rel
On Thu, Nov 11, 2021 at 9:37 AM Amit Kapila wrote:
>
> On Thu, Nov 11, 2021 at 7:07 AM houzj.f...@fujitsu.com
> wrote:
> >
> > On Wed, Nov 10, 2021 7:29 PM Amit Kapila wrote:
> > >
> > > I don't understand the purpose of idx_b in the above test case, why is it
> > > required to reproduce the pro
On Mon Nov 8, 2021 at 4:50 PM EST, Tom Lane wrote:
> Um. I doubt that that's any safer than the v5 patch. As an example,
> casting between int4 and oid is just a RelabelType, but the comparison
> semantics change completely (signed vs. unsigned); so there's not a
> good reason to think this is cons
On Thu, 30 Sept 2021 at 10:54, Tom Lane wrote:
> Actually, the more I look at this the more unhappy I get, because
> it's becoming clear that you have made unfounded semantic
> assumptions. The hash functions generally only promise that they
> will distinguish values that are distinguishable by t
On Thu, Nov 11, 2021 at 12:53 PM Amit Kapila wrote:
>
> On Thu, Nov 11, 2021 at 9:11 AM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2021-11-11 12:22:42 +0900, Masahiko Sawada wrote:
> > > > 2.
> > > > LWLockAcquire(ProcArrayLock, LW_SHARED);
> > > >
> > > > + flags = proc->statusFlags;
> > > >
On Thu, Oct 21, 2021 at 8:27 AM Andres Freund wrote:
> On 2021-10-21 07:55:54 +1300, Thomas Munro wrote:
> > I wonder if we really need signals to implement interrupts. Given
> > that they are non-preemptive/cooperative (work happens at the next
> > CFI()), why not just use shared memory flags an
1 - 100 of 111 matches
Mail list logo
