On 2021/01/26 16:39, Fujii Masao wrote:
On 2021/01/26 16:33, Bharath Rupireddy wrote:
On Tue, Jan 26, 2021 at 12:54 PM Fujii Masao
wrote:
On 2021/01/26 16:05, Tom Lane wrote:
Fujii Masao writes:
Thanks for the review! I fixed them and pushed the patch!
Buildfarm is very not happy
On 2021/01/26 16:33, Bharath Rupireddy wrote:
On Tue, Jan 26, 2021 at 12:54 PM Fujii Masao
wrote:
On 2021/01/26 16:05, Tom Lane wrote:
Fujii Masao writes:
Thanks for the review! I fixed them and pushed the patch!
Buildfarm is very not happy ...
Yes I'm investigating that.
--
On Tue, Jan 26, 2021 at 12:54 PM Fujii Masao
wrote:
> On 2021/01/26 16:05, Tom Lane wrote:
> > Fujii Masao writes:
> >> Thanks for the review! I fixed them and pushed the patch!
> >
> > Buildfarm is very not happy ...
>
> Yes I'm investigating that.
>
> -- Return false as connections are
On 2021/01/26 16:05, Tom Lane wrote:
Fujii Masao writes:
Thanks for the review! I fixed them and pushed the patch!
Buildfarm is very not happy ...
Yes I'm investigating that.
-- Return false as connections are still in use, warnings are issued.
SELECT
On Mon, Jan 25, 2021 at 11:27:28PM -0500, Bruce Momjian wrote:
> On Mon, Jan 25, 2021 at 10:23:30PM -0600, Kenneth Marshall wrote:
>> +1 I know that it has been deprecated, but it can be very useful when
>> working with data from pre-deprecation. :) It is annoying to have to
>> resort to plperl or
At Sat, 26 Dec 2020 01:56:02 +, "tsunakawa.ta...@fujitsu.com"
wrote in
> From: Michael Paquier
> > On Wed, Dec 09, 2020 at 09:52:17AM -0300, Alvaro Herrera wrote:
> > > Well, that definition seems unfriendly to me. I prefer the stance
> > > that if you change the value for the parent,
Fujii Masao writes:
> Thanks for the review! I fixed them and pushed the patch!
Buildfarm is very not happy ...
regards, tom lane
On Mon, Jan 25, 2021 at 11:11:38PM +0300, Alexey Kondratov wrote:
> I updated comment with CCI info, did pgindent run and renamed new function
> to SetRelationTableSpace(). New patch is attached.
>
> [...]
>
> Yeah, all these checks we complicated from the beginning. I will try to find
> a better
Hi, David.
Thanks for your comments.
On 2021-01-26 08:48, David G. Johnston wrote:
On Mon, Jan 25, 2021 at 8:03 AM Masahiko Sawada
wrote:
On Mon, Jan 25, 2021 at 4:51 PM Masahiro Ikeda
wrote:
Hi, thanks for the reviews.
I updated the attached patch.
Thank you for updating the patch!
Thanks for having a look at this.
On Tue, 26 Jan 2021 at 15:48, Zhihong Yu wrote:
> bq. within this range. Table AMs where scanning ranges of TIDs does not make
> sense or is difficult to implement efficiently may choose to not implement
>
> Is there criterion on how to judge efficiency ?
For
On Sat, Jan 23, 2021 at 5:27 AM Peter Geoghegan wrote:
>
> On Thu, Jan 21, 2021 at 9:23 PM Amit Kapila wrote:
> > > Slowing down non-HOT updaters in these extreme cases may actually be a
> > > good thing, even when bottom-up deletion finally becomes ineffective.
> > > It can be thought of as
On 2021/01/26 12:08, Bharath Rupireddy wrote:
On Tue, Jan 26, 2021 at 12:38 AM Fujii Masao
wrote:
Attaching v17 patch set, please review it further.
Thanks for updating the patch!
Attached is the tweaked version of the patch. I didn't change any logic,
but I updated some comments and
On Mon, Jan 25, 2021 at 10:12:28PM +0900, Michael Paquier wrote:
> Hi all,
>
> SHA-1 is now an option available for cryptohashes, and like the
> existing set of functions of SHA-2, I don't really see a reason why we
> should not have a SQL function for SHA1. Attached is a patch doing
> that.
On Tue, Jan 12, 2021 at 6:33 PM Bharath Rupireddy
wrote:
>
> On Tue, Jan 12, 2021 at 9:40 AM Masahiko Sawada wrote:
> >
> > On Mon, Jan 11, 2021 at 4:46 PM Bharath Rupireddy
> > wrote:
> > >
> > > On Mon, Jan 11, 2021 at 10:56 AM Masahiko Sawada
> > > wrote:
> > > > Agreed. Attached the
Hi, Bharath
Thanks for your reviewing.
On Tue, 26 Jan 2021 at 12:55, Bharath Rupireddy
wrote:
> On Tue, Jan 26, 2021 at 9:25 AM japin wrote:
>> > I think it's more convenient. Any thoughts?
>>
>> Sorry, I forgot to attach the patch.
>
> As I mentioned earlier in [1], +1 from my end to have
From: Hou, Zhijie
> IMO, max_parallel_hazard() only check the parent table's default expressions,
> But if the table has partitions and its partition have its own default
> expressions,
> max_parallel_hazard() seems does not check that.
> And we seems does not check that too.
>
> I am not sure
On Tue, Jan 26, 2021 at 9:25 AM japin wrote:
> > I think it's more convenient. Any thoughts?
>
> Sorry, I forgot to attach the patch.
As I mentioned earlier in [1], +1 from my end to have the new syntax
for adding/dropping publications from subscriptions i.e. ALTER
SUBSCRIPTION ... ADD/DROP
At Wed, 28 Oct 2020 19:03:14 +0900, Masahiko Sawada
wrote in
> On Wed, 29 Jul 2020 at 10:37, Justin Pryzby wrote:
> >
> > On Mon, Jul 27, 2020 at 05:39:02AM -0500, Justin Pryzby wrote:
> > > On Mon, Jul 27, 2020 at 08:00:46PM +1200, Thomas Munro wrote:
> > > > Why can't tuplesort_end do it?
>
út 26. 1. 2021 v 4:33 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > [ plpgsql-plan-cache-for-call-3.patch ]
>
> Pushed with some additional cleanup.
>
Thank you
Pavel
> It strikes me that we ought to get rid of SPI_execute_with_receiver
> (which has been added since v13) in favor
On Mon, Jan 25, 2021 at 10:23:30PM -0600, Kenneth Marshall wrote:
> On Tue, Jan 26, 2021 at 01:06:29PM +0900, Michael Paquier wrote:
> > On Mon, Jan 25, 2021 at 10:42:25PM -0500, Sehrope Sarkuni wrote:
> > > +1 to adding a SHA1 SQL function. Even if it's deprecated, there's plenty
> > > of
On Tue, Jan 26, 2021 at 01:06:29PM +0900, Michael Paquier wrote:
> On Mon, Jan 25, 2021 at 10:42:25PM -0500, Sehrope Sarkuni wrote:
> > +1 to adding a SHA1 SQL function. Even if it's deprecated, there's plenty
> > of historical usage that I can see it being useful.
>
> Let's wait for more
Hi,
I have an issue of the check about column default expressions.
+ if (command_type == CMD_INSERT)
+ {
+ /*
+* Column default expressions for columns in the target-list are
+* already being checked for parallel-safety in the
+
On Mon, Jan 25, 2021 at 9:34 PM Guillaume Lelarge
wrote:
>
> "Anytime soon" was a long long time ago, and I eventually completely forgot
> this, sorry. As nobody worked on it yet, I took a shot at it. See attached
> patch.
Great!
I didn't reviewed it thoroughly yet, but after a quick look it
On Mon, Jan 25, 2021 at 10:42:25PM -0500, Sehrope Sarkuni wrote:
> +1 to adding a SHA1 SQL function. Even if it's deprecated, there's plenty
> of historical usage that I can see it being useful.
Let's wait for more opinions to see if we agree that this addition is
helpful or not. Even if this is
On Mon, 25 Jan 2021 at 21:55, Bharath Rupireddy
wrote:
> On Mon, Jan 25, 2021 at 5:18 PM japin wrote:
>> > Do you mean when we drop publications from a subscription? If yes, do
>> > we have a way to drop a publication from the subscription? See below
>> > one of my earlier questions on this.
On Tue, 26 Jan 2021 at 11:47, japin wrote:
> Hi, hackers
>
> When I read the discussion in [1], I found that update subscription's
> publications
> is complicated.
>
> For example, I have 5 publications in subscription.
>
> CREATE SUBSCRIPTION mysub1 CONNECTION 'host=localhost port=5432
>
Hi, hackers
When I read the discussion in [1], I found that update subscription's
publications
is complicated.
For example, I have 5 publications in subscription.
CREATE SUBSCRIPTION mysub1 CONNECTION 'host=localhost port=5432
dbname=postgres'
PUBLICATION mypub1, mypub2, mypub3,
+1 to adding a SHA1 SQL function. Even if it's deprecated, there's plenty
of historical usage that I can see it being useful.
Either way, the rest of the refactor can be improved a bit to perform a
single palloc() and remove the memcpy(). Attached is a diff for
cryptohashfuncs.c that does that by
Pavel Stehule writes:
> [ plpgsql-plan-cache-for-call-3.patch ]
Pushed with some additional cleanup.
It strikes me that we ought to get rid of SPI_execute_with_receiver
(which has been added since v13) in favor of a "SPI_execute_extended"
that shares the same options struct as
On Mon, Jan 25, 2021 at 10:12:28PM +0900, Michael Paquier wrote:
> SHA-1 is now an option available for cryptohashes, and like the
> existing set of functions of SHA-2, I don't really see a reason why we
> should not have a SQL function for SHA1.
NIST deprecated SHA1 over ten years ago. It's too
On Tue, Jan 26, 2021 at 12:38 AM Fujii Masao
wrote:
> > Attaching v17 patch set, please review it further.
>
> Thanks for updating the patch!
>
> Attached is the tweaked version of the patch. I didn't change any logic,
> but I updated some comments and docs. Also I added the regresssion test
> to
Hi,
bq. within this range. Table AMs where scanning ranges of TIDs does not
make
sense or is difficult to implement efficiently may choose to not implement
Is there criterion on how to judge efficiency ?
+ if (tidopexpr->exprtype == TIDEXPR_LOWER_BOUND)
...
+ if
On Mon, Jan 18, 2021 at 5:08 PM Tom Lane wrote:
> (1) other platforms weren't safe-by-default either. Perhaps the
> state of the art is better now, though?
Generally the answer seems to be yes, but there are still some systems
out there that don't send flushes when volatile write cache is
Hi Alexander,
On Mon, Jan 25, 2021 at 11:25 PM Alexander Korotkov
wrote:
>
> BTW, you mentioned you read the documentation. Do you think it needs
> to be adjusted accordingly to the patch?
>
>
Yes, I checked section 8.11, section 9.13 and Chapter 12 of the document.
The change of this patch did
On Thu, 21 Jan 2021 at 18:16, David Rowley wrote:
> I've implemented this in the attached.
The bug fix in 0001 is now committed, so I'm just attaching the 0002
patch again after having rebased... This is mostly just to keep the
CFbot happy.
David
From e459b522d0599602188fcb1cc9ee6062ac8a4aee
On Mon, Jan 25, 2021 at 08:12:01PM -0300, Álvaro Herrera wrote:
> In patch 1,
>
> * The docs are not clear on what happens if --auth-prompt is not given
> but an auth prompt is required for the program to work. Should it exit
> with a status other than 0?
Uh, I think the docs talk about this:
On Mon, Jan 25, 2021 at 4:37 PM Masahiro Ikeda
wrote:
>
> I agree with your comments. I think it should report when
> reaching the end of WAL too. I add the code to report the stats
> when finishing the current WAL segment file when timeout in the
> main loop and when reaching the end of WAL.
>
On Mon, Jan 25, 2021 at 8:03 AM Masahiko Sawada
wrote:
> On Mon, Jan 25, 2021 at 4:51 PM Masahiro Ikeda
> wrote:
> >
> > Hi, thanks for the reviews.
> >
> > I updated the attached patch.
>
> Thank you for updating the patch!
>
Your original email with "total number of times" is more correct,
On 2021-01-26 00:03, Masahiko Sawada wrote:
On Mon, Jan 25, 2021 at 4:51 PM Masahiro Ikeda
wrote:
Hi, thanks for the reviews.
I updated the attached patch.
Thank you for updating the patch!
The summary of the changes is following.
1. fix document
I followed another view's comments.
In patch 1,
* The docs are not clear on what happens if --auth-prompt is not given
but an auth prompt is required for the program to work. Should it exit
with a status other than 0?
* BootStrapKmgr claims it is called by initdb, but that doesn't seem to
be the case.
* Also, BootStrapKmgr is
On Thu, Jan 21, 2021 at 9:47 AM Amul Sul wrote:
> It is not like that, let me explain. When a user backend requests to alter WAL
> prohibit state by using ASRO/ASRW DDL with the previous patch or calling
> pg_alter_wal_prohibit_state() then WAL prohibit state in shared memory will be
> set to the
Hi,
On 2021-01-25 12:00:08 -0800, Andres Freund wrote:
> > > /*
> > >* For backward compatibility reasons this has to be stored in the
> > > wrongly
> > >* named field. Will be fixed in next major version.
> > >*/
> > > return builder->was_running.was_xmax;
> >
> > We could fix
On 2021-01-25 11:07, Michael Paquier wrote:
On Fri, Jan 22, 2021 at 05:07:02PM +0300, Alexey Kondratov wrote:
I have updated patches accordingly and also simplified tablespaceOid
checks
and assignment in the newly added SetRelTableSpace(). Result is
attached as
two separate patches for an ease
Hi,
Thomas, CCing you because of the condvar bit below.
On 2021-01-25 19:28:33 +0200, Heikki Linnakangas wrote:
> In SnapBuildFinalSnapshot(), we have this comment:
> > /*
> > * c) transition from START to BUILDING_SNAPSHOT.
> > *
> > * In START state, and a xl_running_xacts
Jacob Champion writes:
> On Mon, 2021-01-25 at 14:36 -0500, Tom Lane wrote:
>> Also, it looks like the test causes /tmp/krb5cc_ to get
>> created or updated despite this setting.
> Huh. I wonder, if you run `klist -A` after running the tests, do you
> get anything more interesting?
"klist -A"
Jacob Champion writes:
> On Mon, 2021-01-25 at 14:04 -0500, Tom Lane wrote:
>> True, but if it did try to access the cache, accessing the user's
>> normal cache would be strictly worse than accessing the test cache.
> That's fair. Attached is a v2 that just sets KRB5CCNAME globally. Makes
> for
On Mon, 2021-01-25 at 14:36 -0500, Tom Lane wrote:
> However, this doesn't seem to explain why the test script isn't
> causing a global state change. Whether the state is held in a
> file or the sssd daemon shouldn't matter, it seems like.
>
> Also, it looks like the test causes /tmp/krb5cc_ to
I wrote:
> Jacob Champion writes:
>> Interesting. I'm running Ubuntu 20.04:
> Hmm. I'll poke harder.
Ah ... on both RHEL8 and Fedora 33, I find this:
--- snip ---
$ cat /etc/krb5.conf.d/kcm_default_ccache
# This file should normally be installed by your distribution into a
# directory that is
On Mon, Jan 18, 2021 at 8:48 AM Drouvot, Bertrand
wrote:
>
> 3 and 4 were failing because the
ResolveRecoveryConflictWithLogicalSlots() call was missing in
ResolveRecoveryConflictWithSnapshot(): the new version attached adds it.
>
> The new version attached also provides a few changes to make it
On Mon, 2021-01-25 at 14:04 -0500, Tom Lane wrote:
> Jacob Champion writes:
> > On Mon, 2021-01-25 at 13:49 -0500, Tom Lane wrote:
> > > Also, why are you only setting the ENV variable within narrow parts
> > > of the test script? I'd be inclined to enforce it throughout.
> > I considered it and
On 24.01.2021 11:39, Noah Misch wrote:
On Thu, Jan 21, 2021 at 01:03:58AM +0300, Anastasia Lubennikova wrote:
On 03.01.2021 14:29, Noah Misch wrote:
Overall, this patch predicts a subset of cases where pg_dump will emit a
failing GRANT or REVOKE that targets a pg_catalog object. Can you write
On 25/01/2021 18:56, Robert Haas wrote:
I attach a series of proposed patches to slightly improve some minor
things related to the CLOG code.
[patches 0001 - 0003]
Makes sense.
0004 - In StartupCLOG(), correct an off-by-one error. Currently, if
the nextXid is exactly a multiple of the
On 2021/01/26 0:12, Bharath Rupireddy wrote:
On Mon, Jan 25, 2021 at 7:28 PM Bharath Rupireddy
wrote:
I will provide the updated patch set soon.
Attaching v17 patch set, please review it further.
Thanks for updating the patch!
Attached is the tweaked version of the patch. I didn't
Jacob Champion writes:
> On Mon, 2021-01-25 at 13:49 -0500, Tom Lane wrote:
>> Yeah, changing global state is just awful. However, I don't
>> actually see any change here (RHEL8):
> Interesting. I'm running Ubuntu 20.04:
Hmm. I'll poke harder.
>> Also, why are you only setting the ENV
On Mon, 2021-01-25 at 13:49 -0500, Tom Lane wrote:
> Yeah, changing global state is just awful. However, I don't
> actually see any change here (RHEL8):
Interesting. I'm running Ubuntu 20.04:
$ klist
klist: No credentials cache found (filename: /tmp/krb5cc_1000)
$ make check
...
$ klist
Stephen Frost writes:
> * Jacob Champion (pchamp...@vmware.com) wrote:
>> I was running tests with a GSS-enabled stack, and ran into some very
>> long psql timeouts after running the Kerberos test suite. It turns out
>> the suite pushes test credentials into the user's global cache, and
>> these
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> I was running tests with a GSS-enabled stack, and ran into some very
> long psql timeouts after running the Kerberos test suite. It turns out
> the suite pushes test credentials into the user's global cache, and
> these no-longer-useful
Hi all,
I was running tests with a GSS-enabled stack, and ran into some very
long psql timeouts after running the Kerberos test suite. It turns out
the suite pushes test credentials into the user's global cache, and
these no-longer-useful credentials persist after the suite has
finished. (You can
"Joel Jacobson" writes:
> Attached patch adds "(references pg_type.oid)" to the documentation for
> pg_proc.protrftypes.
Agreed, pushed. I also stumbled over a backend core dump while
testing it :-(. So this whole area seems a bit spongy ...
regards, tom lane
Hi
út 22. 12. 2020 v 4:20 odesílatel wenjing napsal:
> HI all
>
> I rebased patch, fix OID conflicts, fix some comments.
> Code updates to v41.
>
Please, can you do rebase?
Regards
Pavel
>
> Wenjing
>
>
Hi Stephen
> ... can set vacuum options on a table level which autovacuum should
respect,
> such as vacuum_index_cleanup and vacuum_truncate. For skip locked,
> autovacuum already will automatically release it's attempt to acquire a
> lock if someone backs up behind it for too long.
This is
On Mon, Jan 18, 2021 at 5:18 PM Tom Lane wrote:
> Yeah. Digging further, it looks like I oversimplified things above:
> we once launched special background-worker-like processes for checkpoints,
> and there could be more than one at a time.
Thanks. I updated the commit message to mention some
In SnapBuildFinalSnapshot(), we have this comment:
/*
* c) transition from START to BUILDING_SNAPSHOT.
*
* In START state, and a xl_running_xacts record with running xacts is
* encountered. In that case, switch to BUILDING_SNAPSHOT state, and
Hi Jonah,
On Mon, Jan 25, 2021 at 10:18 AM Jonah H. Harris
wrote:
> On Mon, Jan 25, 2021 at 10:07 AM Jan Wieck wrote:
>
>> The following is a request for discussion and comments, not a refined
>> proposal accompanied by a working patch.
>>
>
> After implementing this three different ways
On Thu, Jan 21, 2021 at 5:14 AM Heikki Linnakangas wrote:
> Here you can see that as numsnaps increases, the test becomes slower,
> but then it becomes faster again at 64-66, when it switches to the hash
> table. So 64 seems too much. 32 seems to be the sweet spot here, that's
> where scanning
On Wed, Jan 20, 2021 at 9:24 PM Craig Ringer
wrote:
> I know lots of this stuff can seem like a pointless sidetrack because the
> utility of it is not obvious on dev systems or when you're doing your own
> hands-on expert support on systems you own and operate yourself. These sorts
> of things
On Mon, Jan 25, 2021 at 3:07 PM Dilip Kumar wrote:
>
> On Mon, Jan 25, 2021 at 2:48 PM Bharath Rupireddy
> wrote:
> >
> > On Mon, Jan 25, 2021 at 2:42 PM Dilip Kumar
wrote:
> > >
> > > On Mon, Jan 25, 2021 at 1:10 PM vignesh C wrote:
> > > >
> > > > On Thu, Jan 21, 2021 at 10:21 PM Bharath
On Mon, Jan 25, 2021 at 5:18 PM japin wrote:
>
>
> On Mon, 25 Jan 2021 at 17:18, Bharath Rupireddy
> wrote:
> > On Mon, Jan 25, 2021 at 2:42 PM Dilip Kumar wrote:
> >>
> >> On Mon, Jan 25, 2021 at 1:10 PM vignesh C wrote:
> >> >
> >> > On Thu, Jan 21, 2021 at 10:21 PM Bharath Rupireddy
> >> >
On Sat, Jan 23, 2021 at 6:10 AM Bharath Rupireddy
wrote:
> +1 to just show the recovery pause state in the output of
> pg_is_wal_replay_paused. But, should the function name
> "pg_is_wal_replay_paused" be something like
> "pg_get_wal_replay_pause_state" or some other? To me, when "is" exists
> in
I attach a series of proposed patches to slightly improve some minor
things related to the CLOG code.
0001 - Always call StartupCLOG() just after initializing
ShmemVariableCache. Right now, the hot_standby=off code path does this
at end of recovery, and the hot_standby=on code path does it at the
Apologies, I should have checked again to make sure the patch applied.
This one does and passes tests.
Dave Cramer
www.postgres.rocks
On Mon, 25 Jan 2021 at 09:09, Dave Cramer wrote:
> Rebased against head
>
> Here's my summary of the long thread above.
>
> This change is in keeping with the
Hi,
bq. We can mention in the commit log that since the commit changes
MaxHeapTuplesPerPage the encoding in gin posting list is also changed.
Yes - this is fine.
Thanks
On Mon, Jan 25, 2021 at 12:28 AM Masahiko Sawada
wrote:
> (Please avoid top-posting on the mailing lists[1]: top-posting
On Mon, 25 Jan 2021 14:53:18 +0530
Dilip Kumar wrote:
> I have changed as per other functions for consistency.
Thank you for updating the patch. Here are a few comments:
(1)
- SetRecoveryPause(true);
+ SetRecoveryPause(RECOVERY_PAUSE_REQUESTED);
On Sun, Jan 24, 2021 at 02:20:58PM +0100, Magnus Hagander wrote:
> > I found man pages for mkid online --- it's apparently a ctags-like
> > code indexing tool, not something for patches. So maybe Bruce still
> > uses it, or maybe not. But as long as we've also got make_ctags and
> > make_etags
On Fri, Jan 22, 2021 at 01:07:36PM -0500, Tom Lane wrote:
> > There's also src/tools/make_mkid which use this mkid tool. +1 for removing.
> > If anything, it seems better replaced by extended documentation on the
> > existing
> > wiki article [0] on how to use "git format-patch".
>
> I found
On Thu, Jan 21, 2021 at 4:35 PM Alvaro Herrera wrote:
> On 2021-Jan-21, Alexander Korotkov wrote:
>
> > Requiring strict mode for ** is a solution, but probably too restrictive...
> >
> > What do you think about making just subsequent accessor after ** not
> > to unwrap arrays. That would be a
On Thu, Jan 21, 2021 at 12:38 PM Thomas Kellerer wrote:
> Alexander Korotkov schrieb am 20.01.2021 um 18:13:
> > We have a bug report which says that jsonpath ** operator behaves strangely
> > in the lax mode [1].
> That report was from me ;)
>
> Thanks for looking into it.
>
> > At first sight,
Hi, Neil!
On Mon, Jan 25, 2021 at 11:45 AM Neil Chen wrote:
>
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:not
On Mon, Jan 25, 2021 at 10:07 AM Jan Wieck wrote:
> The following is a request for discussion and comments, not a refined
> proposal accompanied by a working patch.
>
After implementing this three different ways inside the backend over the
years, I landed on almost this identical approach for
On Mon, Jan 25, 2021 at 7:28 PM Bharath Rupireddy
wrote:
> I will provide the updated patch set soon.
Attaching v17 patch set, please review it further.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
v17-0001-postgres_fdw-function-to-discard-cached-connecti.patch
The following is a request for discussion and comments, not a refined
proposal accompanied by a working patch.
As recently publicly announced Amazon Web Services is working on Babelfish,
a set of extensions that will allow PostgreSQL to be compatible with other
database systems. One part of this
On Mon, Jan 25, 2021 at 4:51 PM Masahiro Ikeda wrote:
>
> Hi, thanks for the reviews.
>
> I updated the attached patch.
Thank you for updating the patch!
> The summary of the changes is following.
>
> 1. fix document
>
> I followed another view's comments.
>
>
> 2. refactor issue_xlog_fsync()
>
On 2021/01/22 18:11, Fujii Masao wrote:
On 2021/01/22 14:37, torikoshia wrote:
On 2021-01-21 12:48, Fujii Masao wrote:
Thanks for updating the patch! I think that this is really useful feature!!
Thanks for reviewing!
I have two minor comments.
+
+ wait_start timestamptz
Rebased against head
Here's my summary of the long thread above.
This change is in keeping with the SQL spec.
There is an argument (Tom) that says that this will annoy more people than
it will please. I presume this is due to the fact that libpq behaviour will
change.
As the author of the JDBC
On Mon, Jan 25, 2021 at 7:20 PM Fujii Masao wrote:
> On 2021/01/25 19:28, Bharath Rupireddy wrote:
> > On Mon, Jan 25, 2021 at 3:17 PM Fujii Masao
> > wrote:
> >>> Yes, if required backends can establish the connection again. But my
> >>> worry is this - a non-super user disconnecting all or a
On Mon, Jan 25, 2021 at 5:18 PM japin wrote:
> > Do you mean when we drop publications from a subscription? If yes, do
> > we have a way to drop a publication from the subscription? See below
> > one of my earlier questions on this.
> > "I wonder, why isn't dropping a publication from a list of
>
On 2021/01/25 19:28, Bharath Rupireddy wrote:
On Mon, Jan 25, 2021 at 3:17 PM Fujii Masao wrote:
Yes, if required backends can establish the connection again. But my
worry is this - a non-super user disconnecting all or a given
connection created by a super user?
Yes, I was also worried
On Mon, Jan 25, 2021 at 2:53 PM Dilip Kumar wrote:
> I have changed as per other functions for consistency.
Thanks for the v7 patch. Here are some quick comments on it:
[1] I think we need to change return value from boolean to text in
documentation:
pg_is_wal_replay_paused
On Mon, Jan 25, 2021 at 5:19 PM Masahiko Sawada wrote:
>
> On Thu, Jan 21, 2021 at 11:24 PM Masahiko Sawada
> wrote:
> >
> > On Wed, Jan 20, 2021 at 7:58 AM Peter Geoghegan wrote:
> > >
> > > On Sun, Jan 17, 2021 at 9:18 PM Masahiko Sawada
> > > wrote:
> > > > After more thought, I think
Hi,
Le sam. 23 mai 2020 à 14:53, Guillaume Lelarge a
écrit :
> Le mer. 20 mai 2020 à 16:39, Tom Lane a écrit :
>
>> Guillaume Lelarge writes:
>> > Le mer. 20 mai 2020 à 11:26, Daniel Gustafsson a
>> écrit :
>> >> The question is what --extensions should do: only dump any
>> >> extensions
Hello,
Thank you for review.
My answers are inside.
On 21.01.2021 15:30, Yugo NAGATA wrote:
Hello,
On Thu, 26 Mar 2020 18:49:51 +0300
Konstantin Knizhnik wrote:
Attached please find new version of the patch with more comments and
descriptions added.
Adaptive query optimization is very
On Mon, Jan 25, 2021 at 10:40 PM Hou, Zhijie wrote:
>
> Hi,
>
> When reading the code of rel_max_parallel_hazard_for_modify in 0001.
>
> I thought there are so many places call table_close().
> Personally, It's a little confused to me.
>
> Do you think it's better to do the table_open/close
Hi all,
SHA-1 is now an option available for cryptohashes, and like the
existing set of functions of SHA-2, I don't really see a reason why we
should not have a SQL function for SHA1. Attached is a patch doing
that.
The same code pattern was repeated 4 times on HEAD for the SHA-2
functions for
On 2021-Jan-25, tsunakawa.ta...@fujitsu.com wrote:
> Iwata-san,
[...]
> Considering these and the compilation error Kirk-san found, I'd like
> you to do more self-review before I resume this review.
Kindly note that these errors are all mine.
Thanks for the review
--
Álvaro Herrera
On Mon, Jan 25, 2021 at 05:07:29PM +0900, Michael Paquier wrote:
> On Fri, Jan 22, 2021 at 05:07:02PM +0300, Alexey Kondratov wrote:
> > I have updated patches accordingly and also simplified tablespaceOid checks
> > and assignment in the newly added SetRelTableSpace(). Result is attached as
> >
>
> I don't think we can use \d+ on a temporary table here, because the
> backend ID appears in the namespace, which is causing a failure on one
> of the CI OSes due to nondeterminism:
>
> CREATE TEMP TABLE temp_parted (a char) PARTITION BY LIST (a)
> CONFIGURATION (VALUES IN ('a') DEFAULT
On Mon, 25 Jan 2021 at 17:18, Bharath Rupireddy
wrote:
> On Mon, Jan 25, 2021 at 2:42 PM Dilip Kumar wrote:
>>
>> On Mon, Jan 25, 2021 at 1:10 PM vignesh C wrote:
>> >
>> > On Thu, Jan 21, 2021 at 10:21 PM Bharath Rupireddy
>> > wrote:
>> > >
>> > > On Thu, Jan 21, 2021 at 6:56 PM vignesh C
On Mon, Jan 25, 2021 at 4:48 PM Amit Kapila wrote:
>
> On Mon, Jan 25, 2021 at 8:03 AM Peter Smith wrote:
> >
> > Hi Amit.
> >
> > PSA the v19 patch for the Tablesync Solution1.
> >
>
> I see one race condition in this patch where we try to drop the origin
> via apply process and
On Mon, Jan 25, 2021 at 2:54 PM Amit Kapila wrote:
>
> On Mon, Jan 25, 2021 at 8:23 AM Peter Smith wrote:
> >
> > On Sat, Jan 23, 2021 at 11:26 PM Amit Kapila
> > wrote:
> > >
> > > 2.
> > > @@ -98,11 +102,16 @@
> > > #include "miscadmin.h"
> > > #include "parser/parse_relation.h"
> > >
On Mon, Jan 25, 2021 at 1:58 PM Amit Kapila wrote:
>
> On Sun, Jan 24, 2021 at 12:24 PM Peter Smith wrote:
> >
> > On Sat, Jan 23, 2021 at 11:26 PM Amit Kapila
> > wrote:
> > >
> > >
> > > Few comments:
> > > =
> > > 1.
> > > - * So the state progression is always: INIT ->
1 - 100 of 130 matches
Mail list logo
