po 25. 1. 2021 v 8:47 odesílatel Joel Jacobson napsal:
> On Mon, Jan 25, 2021, at 08:14, Pavel Stehule wrote:
> >you should to use TRANSFORM clause in CREATE FUNCTION statement
>
> Thanks, it worked, and like expected it references the pg_type.oid of the
> transform.
>
> Attached patch adds "(ref
Hello, Alvaro san , Tsunakawa san
Thank you for your help. It was very helpful.
> Please integrate Alvaro-san's patch with yours. Next week is the last week
> in this CF, so do your best to post the patch by next Monday or so (before
> Alvaro-san loses interest or time.) Then I'll review it
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 of review, but no objections to merge them
Iwata-san, all,
Strangely, Iwata-san's latest mail she sent today at 10:34 JST hasn't appeared
on pgsql-hackers yet after more than 6 hours. It is not reflected in the CF
entry [1]. So, I'm putting her original mail below. The v13 patch attached to
the original mail is attached to this mail
On Sun, Jan 24, 2021, at 21:46, Mark Rofail wrote:
>Thank you for this find, please find the fix below
Many thanks for fixing. I can confirm it now works like expected for the
reported case:
CREATE SCHEMA catalog_clone;
CREATE TABLE catalog_clone.pg_proc AS SELECT * FROM pg_catalog.pg_proc;
CREA
Hi
On Monday, January 25, 2021 5:13 AM Laurenz Albe
wrote:
> On Thu, 2021-01-21 at 15:30 +0100, I wrote:
> > On Thu, 2021-01-21 at 13:09 +, osumi.takami...@fujitsu.com wrote:
> >
> > > > My vote is that we should not have a GUC for such an unlikely
> > > > event, and that stopping recovery
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 that ambulkdelete needs to be able to
> > > refer the answer to amvacuumstrateg
Hello,
I have not tested nor review the latest patch changes yet, but I am reporting
the compiler errors.
I am trying to compile the patch since V12 (Alvaro's version), but the
following needs to
be fixed too because of the complaints: doc changes and undeclared INT_MAX
libpq.sgml:5893: parser
(Please avoid top-posting on the mailing lists[1]: top-posting breaks
the logic of a thread.)
On Tue, Jan 19, 2021 at 12:02 AM Zhihong Yu wrote:
>
> Hi, Masahiko-san:
Thank you for reviewing the patch!
>
> For v2-0001-Introduce-IndexAM-API-for-choosing-index-vacuum-s.patch :
>
> For blvacuumstr
Tsunakawa san,
> Strangely, Iwata-san's latest mail she sent today at 10:34 JST hasn't appeared
> on pgsql-hackers yet after more than 6 hours. It is not reflected in the CF
> entry [1]. So, I'm putting her original mail below. The v13 patch attached
> to
> the original mail is attached to th
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 tested
Greetings,
Although I am not an expert in this field, I carefully re
On Mon, 2021-01-25 at 08:19 +, osumi.takami...@fujitsu.com wrote:
> > I think you should pst another patch where the second, now superfluous,
> > error
> > message is removed.
>
> Updated. This patch showed no failure during regression tests
> and has been aligned by pgindent.
Looks good to m
On Wed, Jan 20, 2021 at 7:03 PM Amit Langote wrote:
> On Wed, Jan 20, 2021 at 4:13 PM Peter Eisentraut
> > Could you summarize here what you are trying to do with respect to what
> > was decided before? I'm a bit confused, looking through the patches you
> > have posted. The first patch you post
Hi, Amit-san,
Nice patch. I have confirmed that this solves the problem in [1] with
INSERT/UPDATE.
HEAD + patch
name | bytes | pg_size_pretty
--+---+
CachedPlanQuery | 10280 | 10 kB
CachedPlanSource | 14616 | 14 kB
CachedPlan | 13168 | 13
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 wrote:
> > >
> > > Hi,
> > >
> > > Creating/altering subscription is successful when we specify a
> > > publication which does not ex
On Mon, Jan 25, 2021 at 1:20 PM Fujii Masao wrote:
> > Yeah, connections can be discarded by non-super users using
> > postgres_fdw_disconnect_all and postgres_fdw_disconnect. Given the
> > fact that a non-super user requires a password to access foreign
> > tables [1], IMO a non-super user changi
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 wrote:
> > > >
> > > > Hi,
> > > >
> > > > Creating/altering subscr
On Mon, Jan 25, 2021 at 9:24 AM Corey Huinker wrote:
> On Sun, Jan 24, 2021 at 6:51 AM Amit Langote wrote:
>> Here's v5.
>
> v5 patches apply to master.
> Suggested If/then optimization is implemented.
> Suggested case merging is implemented.
> Passes make check and make check-world yet again.
>
Iwata-san,
(25)
+ conn->fe_msg = malloc(sizeof(offsetof(pqFrontendMessage,
fields)) +
+ DEF_FE_MSGFIELDS *
sizeof(pqFrontendMessageField));
It's incorrect that offsetof() is nested in sizeof(). See my original review
comme
On Sun, Jan 24, 2021 at 12:17 PM Bharath Rupireddy
wrote:
>
> On Sun, Jan 24, 2021 at 11:29 AM Dilip Kumar wrote:
> > > Some comments on the v6 patch:
>
> > > [2] Typo - it's "requested" + * 'paused requested' - if pause is
> > > reqested but recovery is not yet paused
>
> Here I meant the typo "
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 Rupireddy
> > > wrote:
> > > >
> > > > On Thu, Jan 21, 2021 at 6:56 PM vi
On 2021/01/25 18:13, Bharath Rupireddy wrote:
On Mon, Jan 25, 2021 at 1:20 PM Fujii Masao wrote:
Yeah, connections can be discarded by non-super users using
postgres_fdw_disconnect_all and postgres_fdw_disconnect. Given the
fact that a non-super user requires a password to access foreign
tab
Kuroda-san,
On Mon, Jan 25, 2021 at 6:06 PM Keisuke Kuroda
wrote:
> Hi, Amit-san,
>
> Nice patch. I have confirmed that this solves the problem in [1] with
> INSERT/UPDATE.
Thanks for testing.
> HEAD + patch
>name | bytes | pg_size_pretty
> --+---+-
On Mon, Jan 25, 2021 at 3:07 PM Dilip Kumar wrote:
> > > So basically, the create subscription will throw an error if the
> > > publication does not exist. So will you throw an error if we try to
> > > drop the publication which is subscribed by some subscription? I mean
> > > basically, you are
On Mon, Jan 25, 2021 at 3:38 PM Bharath Rupireddy
wrote:
>
> On Mon, Jan 25, 2021 at 3:07 PM Dilip Kumar wrote:
> > > > So basically, the create subscription will throw an error if the
> > > > publication does not exist. So will you throw an error if we try to
> > > > drop the publication which
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 about that. But I found that there are o
Hi Amit.
PSA the v20 patch for the Tablesync Solution1.
Main differences from v19:
+ Updated TAP test [ak0123-7]
+ Fixed comment [ak0125-1]
+ Removed redundant header [ak0125-2]
+ Protection against race condition [ak0125-race]
[ak0123-7]
https://www.postgresql.org/message-id/CAA4eK1JhpuwujrV6A
On Mon, Jan 25, 2021 at 7:01 PM Amit Langote wrote:
> On Mon, Jan 25, 2021 at 6:06 PM Keisuke Kuroda
> wrote:
> > However, as already mentioned, the problem of memory bloat on DELETE
> > remains.
> > This can be solved by the patch in [1], but I think it is too much to apply
> > this patch only
On Thu, Jan 21, 2021 at 9:17 PM Amit Kapila wrote:
> 7.
> +# check for occurrence of the expected error
> +poll_output_until("replication slot \"$slotname\" already exists")
> +or die "no error stop for the pre-existing origin";
>
> In this test, isn't it better to check for datasync state lik
Sorry for the dealy. I started to look this.
At Fri, 25 Sep 2020 12:25:24 +0300, Surafel Temesgen
wrote in
> Hi Michael
> On Thu, Sep 24, 2020 at 6:58 AM Michael Paquier wrote:
>
> > On Mon, Aug 10, 2020 at 01:23:44PM +0300, Surafel Temesgen wrote:
> > > I also Implement PERCENT WITH TIES opt
On Fri, Jan 22, 2021 at 7:52 PM tsunakawa.ta...@fujitsu.com
wrote:
>
>
> (1)
> -* (Note that we do allow CREATE TABLE AS, SELECT INTO, and CREATE
> -* MATERIALIZED VIEW to use parallel plans, but as of now, only the
> leader
> -* backend writes into a completely new table.
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 outside of
rel_max_parallel_hazard_for_modify ?
Like:
static bool rel_m
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 -> DATASYN
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"
> > > #inc
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 DropSubscription
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
>
> 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 PARTITIO
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
> > tw
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
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 t
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 outsid
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 int
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 tha
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 that
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 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 ab
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 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 g
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 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
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()
>
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 w
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
De
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 ha
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 tes
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,
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 bi
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 man
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 in
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);
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 brea
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
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
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
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 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 Rupi
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 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 the
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 inside
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
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 of
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 good
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
>
>
"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 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
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 c
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 n
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
Ticket
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 variabl
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 change
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 number
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 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 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 c
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, 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 g
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 a
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" pr
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 re
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,
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 t
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
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 the
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.
2.
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, re
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 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 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 Mon
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 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
enable
1 - 100 of 132 matches
Mail list logo
