On 2/2/19 3:05 AM, Michael Paquier wrote:
+files created by initdb. This option is irrelevant
+on Windows as it does not support
+POSIX-style group permissions.
How about:
+files created by initdb. This option is ignored
+on Windows, which does not sup
On Thu, Jan 31, 2019 at 05:09:09PM +0100, Michael Banck wrote:
> Sorry, I didn't look at it during that (November) commitfest cause it
> was submitted late, and then forgot about it.
>
> I think the changes are fine and I've marked it Ready for Committer.
Agreed, so committed.
--
Michael
signat
On Fri, Feb 01, 2019 at 10:43:37PM +, Bossart, Nathan wrote:
> I would suggest adding this option to vacuumdb in this patch set as
> well.
Doing it would be simple enough, for now I have moved it to next CF.
--
Michael
signature.asc
Description: PGP signature
On Fri, Feb 1, 2019 at 2:49 AM Masahiko Sawada wrote:
>
> On Wed, Jan 30, 2019 at 2:06 AM Haribabu Kommi
> wrote:
>
> Thank you. I'll submit the updated patch set.
>
I don't see any chance of getting this committed in the next few days,
so, moved to next CF. Thanks for working on this and I h
On Sat, Feb 2, 2019 at 4:42 AM Chengchao Yu wrote:
>
> Hi Amit, Thomas,
>
> Thank you very much for your feedbacks! Apologizes but I just saw both
> messages.
>
> > We generally reserve the space in a relation before attempting to write, so
> > not sure how you are able to hit the disk full situ
On 2019-Jan-31, Lætitia Avrot wrote:
> Hi,
>
> Thanks to Emil Iggland's kind review, I added precision on documentation
> for hyperbolic functions.
Hello
I see that in dtanh() you set errno to 0 before calling tanh(), but 1)
you don't check for it afterwards (seems like you should be checking f
On Wed, Jan 23, 2019 at 10:59 AM Peter Geoghegan wrote:
> > The fix here must be to normalize index tuples that are compressed
> > within amcheck, both during initial fingerprinting, and during
> > subsequent probes of the Bloom filter in bt_tuple_present_callback().
>
> I happened to talk to Andr
On Mon, Jan 28, 2019 at 4:40 PM Amit Kapila wrote:
>
> On Mon, Jan 28, 2019 at 10:03 AM John Naylor
> wrote:
> >
> > On Mon, Jan 28, 2019 at 4:53 AM Amit Kapila wrote:
> > > There are a few buildfarm failures due to this commit, see my email on
> > > pgsql-committers. If you have time, you can
On Thu, Jan 31, 2019 at 12:08:18PM +0100, Oleksii Kliukin wrote:
> Thanks, set it to RFC.
Oh, I have just noticed this patch when doing my vacuum homework. I
have just added my name as committer, just wait a bit until the CF is
closed before I begin looking at it..
--
Michael
signature.asc
Desc
Hi all,
Based on the latest emails exchanged, the patch got some feedback from
Pavan which has not been addressed. So I am marking the patch as
returned with feedback.
--
Michael
signature.asc
Description: PGP signature
On Fri, Feb 01, 2019 at 10:29:11AM +0100, Michael Meskes wrote:
> I have no idea where the footnote comes from, but I agree that it doesn't seem
> to make sense. The datatype varchar in the C code is handled by the
> preprocessor and replaced by a struct definition anyway.
>
> Feel free to remove.
On Fri, Feb 01, 2019 at 11:07:02AM +0900, Michael Paquier wrote:
> On Thu, Jan 31, 2019 at 04:53:49AM -0800, Andres Freund wrote:
> > My impression is that this patch ought to marked as rejected?
>
> I may be missing something, but I have the same impression.
Re-reading the thread I think that's
On Sat, Nov 24, 2018 at 05:58:38PM +0100, Fabien COELHO wrote:
>> Unfortunately, there was no activity over the last few commitfests and the
>> proposed patch pgbench-tap-progress-6 can't be applied anymore without
>> conflicts. Fabien, what are your plans about it, could you please post a
>> rebas
On Fri, Nov 16, 2018 at 01:35:15PM -0500, Tom Lane wrote:
> I wonder whether we'd be better off thinking of a way to let FDWs
> invent additional system column IDs for their tables, so that
> something like a remote table OID could be represented in the
> natural way as a Var with negative varattno
On Thu, Jan 31, 2019 at 04:26:31PM +0100, Pavel Stehule wrote:
> I'll mark this patch as ready for commiters.
For now I have moved the patch to the next CF, with the same status.
--
Michael
signature.asc
Description: PGP signature
On Sun, Dec 02, 2018 at 04:41:06PM -0800, Noah Misch wrote:
> Here's a version fixing that test for post-cfdf4dc backends.
This patch set still applies and needs review, so moved to next CF.
--
Michael
signature.asc
Description: PGP signature
On Thu, Oct 25, 2018 at 08:21:27AM +0200, Fabien COELHO wrote:
> Thanks for the hint. Here is an updated patch using this marker.
>
> I noticed that some instances use a closing "*-" sequence, but it does
> not seem useful, so I left it out.
>
> I have also tried to improve a few comments, an
On Fri, Feb 01, 2019 at 07:14:19PM +0200, David Steele wrote:
> Hrm, seems like I missed that. Do you mind writing something that makes
> sense to Windows users and I'll have a look?
Perhaps something like the attached?
--
Michael
diff --git a/doc/src/sgml/ref/initdb.sgml b/doc/src/sgml/ref/initd
On Sat, 2 Feb 2019 at 13:43, Tomas Vondra wrote:
>
> On 2/1/19 2:51 PM, Robert Haas wrote:
> >> (I admit to not having the best grasp on how all this works, so feel
> >> free to shoot this down)
> >>
> > I think the key question here is whether or not you can cope with
> > someone having done arbi
On 2/1/19 2:51 PM, Robert Haas wrote:
>> (I admit to not having the best grasp on how all this works, so feel
>> free to shoot this down)
>>
> I think the key question here is whether or not you can cope with
> someone having done arbitrary AEL-requiring modifications to the
> delaylocked partition
> On 2 Feb 2019, at 00:21, Andres Freund wrote:
> In https://postgr.es/m/20190201162404.onngi77f26baem4g%40alap3.anarazel.de
> I noticed that composite_to_json() deforms column-by-column. Given that
> it always processes all columns, that seems quite the waste of resources.
>
> In some quick'n d
On Sat, Feb 2, 2019 at 9:25 AM Graham Leggett wrote:
> On 25 Sep 2018, at 04:09, Thomas Munro wrote:
> > Some people like to use DNS SRV records to advertise LDAP servers on
> > their network. Microsoft Active Directory is usually (always?) set up
> > that way. Here is a patch to allow our LDAP
Hi,
In https://postgr.es/m/20190201162404.onngi77f26baem4g%40alap3.anarazel.de
I noticed that composite_to_json() deforms column-by-column. Given that
it always processes all columns, that seems quite the waste of resources.
In some quick'n dirty dirty testing this gives a ~4% benefit in a table
Hi Amit, Thomas,
Thank you very much for your feedbacks! Apologizes but I just saw both messages.
> We generally reserve the space in a relation before attempting to write, so
> not sure how you are able to hit the disk full situation via mdwrite. If you
> see the description of the function,
Hi,
On 2019-02-01 08:24:04 -0800, Andres Freund wrote:
> While working on the patch to slotify trigger.c I got somewhat confused
> by the need to expand tuples in trigger.c:
>
> static HeapTuple
> GetTupleForTrigger(EState *estate,
>EPQState *epqstate,
>Res
On 1/21/19, 2:23 AM, "Masahiko Sawada" wrote:
> Understood and Agreed. I've attached the new version patch
> incorporated the review comments.
I took a look at the latest version of the patch.
+
+DISABLE_INDEX_CLEANUP
+
+
+ VACUUM removes dead tuples and prunes HOT-updated
On 25 Sep 2018, at 04:09, Thomas Munro wrote:
> Some people like to use DNS SRV records to advertise LDAP servers on
> their network. Microsoft Active Directory is usually (always?) set up
> that way. Here is a patch to allow our LDAP auth module to support
> that kind of discovery.
Does this
On 2019-02-01 16:04:58 -0500, James Coleman wrote:
> On Thu, Jan 31, 2019 at 1:32 AM Kyotaro HORIGUCHI
> wrote:
> > Also as mentioned upthread by Peter Geoghegan, this could easly
> > give worse plan by underestimation. So I also suggest that this
> > has dynamic fallback function. In such perspe
On Thu, Jan 31, 2019 at 1:32 AM Kyotaro HORIGUCHI
wrote:
> Also as mentioned upthread by Peter Geoghegan, this could easly
> give worse plan by underestimation. So I also suggest that this
> has dynamic fallback function. In such perspective it is not
> suitable for AM API level feature.
>
> If a
On Fri, Feb 1, 2019 at 9:00 AM Robert Haas wrote:
> I don't think we'd be using pqmq here, or shm_mq either, but I think
> the bigger issues is that starting a parallel query is already a
> pretty heavy operation, and so the added overhead of this is probably
> not very noticeable. I agree that i
Hi,
On 1/31/19 1:31 AM, Kyotaro HORIGUCHI wrote:
At Wed, 30 Jan 2019 18:19:05 +0100, Dmitry Dolgov <9erthali...@gmail.com> wrote in
A bit of adjustment after nodes/relation -> nodes/pathnodes.
I had a look on this.
The name "index skip scan" is a different feature from the
feature with the
Hi,
On 2/1/19 4:58 AM, Alvaro Herrera wrote:
On 2019-Feb-01, Jamison, Kirk wrote:
I'm not sure if misunderstood the purpose of $VACUUMDB_OPTS. I thought what
the other developers suggested is to utilize it so that --jobs for vacuumdb
would be optional and just based from user-specified option
On Fri, Feb 1, 2019 at 7:27 AM Peter Eisentraut
wrote:
> This patch will probably make a reappearance when we consider making ICU
> available as the database-wide default collation.
Somebody recently reported that an ICU locale was over 2000x faster
than the equivalent glibc locale with their que
On Fri, Feb 1, 2019 at 8:29 PM Michael Goldshteyn wrote:
>
> I just read an article about the advantages of zheap over the heap that
> PostgreSQL currently uses and there were several posts on this list about it
> being more compact as well as more performant. I am hopeful that it makes it
> in
On 2/1/19 10:14 AM, Michael Paquier wrote:
On Fri, Feb 01, 2019 at 05:34:05PM +1100, Haribabu Kommi wrote:
As Microsoft windows doesn't support POSIX style of permissions, we
always set for the permissions GUC's as not supported in
windows. Even the new GUC that is added with --allow-group-acces
Hi,
While working on the patch to slotify trigger.c I got somewhat confused
by the need to expand tuples in trigger.c:
static HeapTuple
GetTupleForTrigger(EState *estate,
EPQState *epqstate,
ResultRelInfo *relinfo,
ItemPointer tid,
Hi,
This patch series is to add support for spgist quadtree @<(point,circle)
operator. The first two patches are to refactor existing code before
implemention the new feature. The third commit is the actual implementation
provided with a set of simple unit tests.
Matwey V. Kornilov (3):
Introdu
This helper function makes spg_quad_inner_consistent() more readable when
changes from the next commit is introduced.
Signed-off-by: Matwey V. Kornilov
---
src/backend/access/spgist/spgquadtreeproc.c | 63 ++---
1 file changed, 31 insertions(+), 32 deletions(-)
diff --gi
Signed-off-by: Matwey V. Kornilov
---
src/backend/access/spgist/spgquadtreeproc.c | 65 ---
src/include/catalog/pg_amop.dat | 3 +
src/test/regress/expected/create_index.out | 96 +
src/test/regress/sql/create_index.sql | 32
Use shorter variable name instead of repeating in->scankeys[i] in
spg_quad_leaf_consistent() and spg_quad_inner_consistent().
Signed-off-by: Matwey V. Kornilov
---
src/backend/access/spgist/spgquadtreeproc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/s
> On Fri, Feb 1, 2019 at 4:55 PM Alvaro Herrera
> wrote:
>
> On 2019-Feb-01, Dmitry Dolgov wrote:
>
> > The moment was longer than I expected, but here is the rebased version,
> > where
> > all the individual patches can be applied and compiled cleanly (although
> > there
> > is still functiona
On 2019-Feb-01, Dmitry Dolgov wrote:
> The moment was longer than I expected, but here is the rebased version, where
> all the individual patches can be applied and compiled cleanly (although there
> is still functional dependency between 0002 and 0003, since the former
> introduces a new subscrip
On Sat, Feb 2, 2019 at 2:23 AM REIX, Tony wrote:
> Hu I have an issue here:
>
> # cd /home2/freeware/src/packages/BUILD/postgresql-11.1/64bit/doc/src/sgml
> # gmake
> /opt/freeware/bin/xmllint --path . --noout --valid postgres.sgml
> /opt/freeware/bin/xsltproc --path . --stringparam pg.version
> "Tom" == Tom Lane writes:
>> Is there some reason why ld_library_path_var is defined using a
>> bunch of $(if) constructs rather than putting the value (if not
>> LD_LIBRARY_PATH) in the individual port makefiles?
Tom> I might be wrong, but I think that code is Peter's. I agree that
On 31/01/2019 13:45, Andres Freund wrote:
> So, what's the plan here? Should the CF entry be closed?
Set to RwF.
This patch will probably make a reappearance when we consider making ICU
available as the database-wide default collation.
--
Peter Eisentraut http://www.2ndQuadrant.com
Hi Thomas,
Thanks for the patch !
I've started to work with it. It is now compiling.
Hu I have an issue here:
# cd /home2/freeware/src/packages/BUILD/postgresql-11.1/64bit/doc/src/sgml
# gmake
/opt/freeware/bin/xmllint --path . --noout --valid postgres.sgml
/opt/freeware/bin/xsltproc --pa
Hi,
On 2019-01-29 12:23:51 -0800, Andres Freund wrote:
> On 2019-01-29 11:25:41 -0800, Andres Freund wrote:
> > On 2019-01-28 22:37:53 -0500, Tom Lane wrote:
> > > Andres Freund writes:
> > > > I did that now. I couldn't reproduce it locally, despite a lot of
> > > > runs. Looking at the buildfar
On Tue, Jan 22, 2019 at 2:17 PM Tomas Vondra
wrote:
> I think there are essentially two ways:
>
> (a) Define max amount of memory available for shared dictionarires, and
> come up with an eviction algorithm. This will be tricky, because when
> the frequently-used dictionaries need a bit more memor
On Thu, 31 Jan 2019 at 11:49, David Rowley wrote:
> Here's another version, same as before but with tests this time.
Hi Fabien,
Wondering if you have anything else here? I'm happy for the v13
version to be marked as ready for committer.
--
David Rowley http://www.2ndQuadrant
I just read an article about the advantages of zheap over the heap that
PostgreSQL currently uses and there were several posts on this list about
it being more compact as well as more performant. I am hopeful that it
makes it into PostgreSQL 12.0, but it is unclear what the current status of
this c
On Thu, Jan 24, 2019 at 6:42 PM Thomas Munro
wrote:
> Yes, this is essentially the same thing that you were arguing against
> above. Perhaps you are right, and there are no people who would want
> synchronous replay, but not synchronous commit.
Maybe I'm misunderstanding the terminology here, bu
On 2019-Feb-01, Dmitry Dolgov wrote:
> > On Fri, Feb 1, 2019 at 12:33 PM Alvaro Herrera
> > wrote:
> > > * Use NULL as a default value where it was an empty string before (this
> > > required few minor changes for some part of the code outside
> > > ArchiveEntry)
> >
> > I would rename the f
On Fri, Feb 1, 2019 at 9:16 AM David Rowley
wrote:
> On Sat, 2 Feb 2019 at 03:07, Robert Haas wrote:
> > I'm now wondering whether the same issues discussed in
> > https://www.postgresql.org/message-id/CA%2BTgmoZN-80143F8OhN8Cn5-uDae5miLYVwMapAuc%2B7%2BZ7pyNg%40mail.gmail.com
> > also need discus
Andrew Gierth writes:
> Is there some reason why ld_library_path_var is defined using a bunch of
> $(if) constructs rather than putting the value (if not LD_LIBRARY_PATH)
> in the individual port makefiles?
I might be wrong, but I think that code is Peter's. I agree that
having the per-port make
> On Fri, Feb 1, 2019 at 12:33 PM Alvaro Herrera
> wrote:
>
> pgindent didn't like your layout with two-space indents for the struct
> members :-( I thought it was nice, but oh well. This means we can do
> away with the newline at each callsite, and I didn't like the trailing
> comma (and I hav
On Sat, 2 Feb 2019 at 03:07, Robert Haas wrote:
> I'm now wondering whether the same issues discussed in
> https://www.postgresql.org/message-id/CA%2BTgmoZN-80143F8OhN8Cn5-uDae5miLYVwMapAuc%2B7%2BZ7pyNg%40mail.gmail.com
> also need discussion with respect to this patch. But I haven't
> thought ab
On Fri, 1 Feb 2019 at 23:01, Alvaro Herrera wrote:
> Please rebase.
I had a short list of other things I noticed when making a partial
pass over the patch again.
I may as well send these now if there's a new version on the way:
1. I think it's okay to convert the following:
/*
* Adjust all_bas
On Fri, 1 Feb 2019 at 22:52, Alvaro Herrera wrote:
>
> On 2019-Jan-31, David Rowley wrote:
> >
> > I think we could make the 0001 patch a bit smaller if we were to apply
> > the attached first.
> >
> > Details in the commit message.
> >
> > What do you think?
>
> Amit didn't say what he thinks, bu
On Thu, Jan 31, 2019 at 4:48 PM David Rowley
wrote:
> On Fri, 1 Feb 2019 at 07:46, Robert Haas wrote:
> > I have reviewed this patch and I am in favor of it. I think it likely
> > needs minor rebasing because of the heap_open -> table_open renaming.
>
> Many thanks for looking at it. The v2 pa
On Thu, Jan 31, 2019 at 6:00 PM Alvaro Herrera wrote:
> > - 0003 doesn't have any handling for parallel query at this point, so
> > even though within a single backend a single query execution will
> > always get the same PartitionDesc for the same relation, the answers
> > might not be consistent
On Thu, Jan 31, 2019 at 8:29 PM David Rowley
wrote:
> I think perhaps accepting invalidations at the start of the statement
> might appear to fix the problem in master, but I think there's still a
> race condition around CheckCachedPlan() since we'll ignore
> invalidation messages when we perform
Bonjour Tony,
On Sat, Jan 5, 2019 at 3:35 AM REIX, Tony wrote:
> Thanks for the 2 patches!
>
> I've seen also the discussion around this subject. Very interesting. Should I
> wait for a decision been taken? or should I study and experiment your patches
> before?
I am planning to commit the 000
On 2019-Feb-01, Dmitry Dolgov wrote:
> Can you please point out for me what exactly doesn't build? I just tried to
> build contrib and ran all the tests, everything finished succesfully, which is
> also confirmed by bot [1].
Well, this is strange: I removed the changes then re-applied the diff,
a
> On Fri, Feb 1, 2019 at 12:54 PM Alvaro Herrera
> wrote:
>
> On 2019-Feb-01, Alvaro Herrera wrote:
>
> > On 2019-Feb-01, Alvaro Herrera wrote:
> >
> > ... and you're going to need "git format-patch -v19", because contrib
> > doesn't build with 18.
>
> And that suggests that maybe we should keep
> On 25 Sep 2018, at 04:09, Thomas Munro wrote:
> Some people like to use DNS SRV records to advertise LDAP servers on
> their network. Microsoft Active Directory is usually (always?) set up
> that way. Here is a patch to allow our LDAP auth module to support
> that kind of discovery. It copie
On 2019-Feb-01, Alvaro Herrera wrote:
> On 2019-Feb-01, Alvaro Herrera wrote:
>
> > I think it's worth pointing out that "git format-patch -v" exists :-)
>
> ... and you're going to need "git format-patch -v19", because contrib
> doesn't build with 18.
And that suggests that maybe we should kee
On 2019-Feb-01, Alvaro Herrera wrote:
> I think it's worth pointing out that "git format-patch -v" exists :-)
... and you're going to need "git format-patch -v19", because contrib
doesn't build with 18.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 S
I think it's worth pointing out that "git format-patch -v" exists :-)
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-Feb-01, Alvaro Herrera wrote:
> ... so this code
>
> if (!ropt->noOwner)
> sanitized_owner = replace_line_endings(te->owner);
> else
> sanitized_owner = pg_strdup("-");
>
> can become
> sanitized_owner
pgindent didn't like your layout with two-space indents for the struct
members :-( I thought it was nice, but oh well. This means we can do
away with the newline at each callsite, and I didn't like the trailing
comma (and I have vague recollections that some old compilers might
complain about the
Thanks a lot, Amul.
-
--
Thanks,
Rajan.
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
here is a rebased version of previous patch with planner
comment included
regards
Surafel
On Wed, Jan 30, 2019 at 9:07 AM Surafel Temesgen
wrote:
>
>
> On Mon, Jan 28, 2019 at 1:28 AM Tomas Vondra
> wrote:
>
>>
>>
>> OK. Does that mean you agree the incremental approach is reasonable?
>>
>
> "Tom" == Tom Lane writes:
>> At least on my FreeBSD 11 box, the current definition of
>> $(with_temp_install) is not sufficient to ensure that the various .so
>> files are loaded from tmp_install and not from the compiled rpath (which
>> will be the final install dir, which may of cours
You forgot to quote pg_toast_22345, try this:
psql -c " select * from pg_class where relname = 'pg_toast_22345' "
Regards,
Amul
On Fri, Feb 1, 2019 at 4:05 PM rajan wrote:
> postgres@Server2[DEV][backup] $ psql -c 'select * from pg_class where
> relname
> = pg_toast_22345'
> ERROR: column "
postgres@Server2[DEV][backup] $ psql -c 'select * from pg_class where relname
= pg_toast_22345'
ERROR: column "pg_toast_16387" does not exist
LINE 1: select * from pg_class where relname = pg_toast_22345
-
--
Thanks,
Rajan.
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers
> On 24 Jan 2019, at 13:12, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Here is another version, where I accumulated all the suggestions:
Nothing sticks out during review and AFAICT all comments have been addressed.
Everything works as expected during (light) testing between master and an old
Please rebase.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-Feb-01, Jamison, Kirk wrote:
> I'm not sure if misunderstood the purpose of $VACUUMDB_OPTS. I thought what
> the other developers suggested is to utilize it so that --jobs for vacuumdb
> would be optional and just based from user-specified option $VACUUMDB_OPTS.
> By which it would not uti
On 2019-Jan-31, David Rowley wrote:
> On Tue, 29 Jan 2019 at 22:32, Amit Langote
> wrote:
> > Attached updated patches.
>
> I think we could make the 0001 patch a bit smaller if we were to apply
> the attached first.
>
> Details in the commit message.
>
> What do you think?
Amit didn't say wh
Matsumura-san,
> Sorry to bother you, but I would be grateful if you would comment to me.
Sorry, I didn't know you were waiting on a reply by me.
> > I have a question about ecpg manual when I add article for bytea.
> > I wonder what does the following about VARCHAR mean.
> > ...
> > I think, if
On 01.02.2019 12:09, Arthur Zakirov wrote:
Thanks for sharing your ideas, Tomas. Unfortunately I won't manage to
develop new version of the patch till the end of the commitfest due to
lack of time. I'll think about the second approach. Tracking timestamp
of the last time a dict was used may be
On 22.01.2019 22:17, Tomas Vondra wrote:
On 1/22/19 7:36 PM, Arthur Zakirov wrote:
max_shared_dictionaries_size can be renamed to
shared_dictionaries_cleanup_threshold.
That really depends on what exactly the threshold does. If it only
triggers cleanup but does not enforce maximum amount of me
On January 31, 2019, 9:29PM +, Jesper Pedersen wrote:
>>> I added most of the documentation back, as requested by Kirk.
>>
>> Actually, I find it useful to be documented. However, major contributors
>> have higher opinions in terms of experience, so I think it's alright with me
>> not to in
Hello.
At Fri, 1 Feb 2019 06:31:40 +, "Tsunakawa, Takayuki"
wrote in
<0A3221C70F24FB45833433255569204D1FB927B1@G01JPEXMBYT05>
> Thanks for a cool feature with nice UI. Can I expect it to work for
> background processes? For troubleshooting, I wanted to investigate how
> autovacuum launc
On Fri, Feb 01, 2019 at 09:11:50AM +0100, Laurenz Albe wrote:
> Jamison, Kirk wrote:
>> I wonder if there is a better reloption name for
>> shrink_enabled. (truncate_enabled, vacuum_enabled? Hmm. No?)
>> On the other hand, shrink_enabled seems to describe well what it's
>> supposed to do when vac
On Fri, Jan 18, 2019 at 09:50:40AM -0500, Stephen Frost wrote:
> Yes, we should update the documentation in this regard, though it's
> really an independent thing as that documentation should have been
> updated in the original group-access patch, so I'll see about fixing
> it and back-patching it.
Sorry, I lost previous mail[1].
On Fri, 28 Dec 2018 at 20:36, Tsunakawa, Takayuki
wrote:
> Although I may say the same thing as you, I think a natural idea would be to
> create a generic plan gradually. The starting simple question is "why do we
> have to touch all partitions at first?" That
On Fri, Feb 01, 2019 at 05:34:05PM +1100, Haribabu Kommi wrote:
> As Microsoft windows doesn't support POSIX style of permissions, we
> always set for the permissions GUC's as not supported in
> windows. Even the new GUC that is added with --allow-group-access
> feature also mentioned the same.
>
Jamison, Kirk wrote:
> On February 1, 2019, Tsunakawa, Takayuki wrote:
>
> > > As most people seem to agree adding the reloption, here's the patch.
> > > It passes make check, and works like this:
> > Sorry, I forgot to include the modified header file. Revised patch
> > attached.
>
> I wond
89 matches
Mail list logo
