On Sat, Dec 20, 2014 at 07:28:33PM +0100, Tomas Vondra wrote:
On 20.12.2014 19:05, Tom Lane wrote:
Locale cs_CZ.WIN-1250 is evidently marked with a codeset property of
ANSI_X3.4-1968 (which means old-school US-ASCII). That's certainly
wrong. I believe the correct thing would be CP1250.
23.12.2014, 05:00, Amit Kapila kirjoitti:
On Tue, Dec 23, 2014 at 4:10 AM, Oskari Saarenmaa wrote:
08.11.2014, 04:03, Peter Eisentraut kirjoitti:
It errors when the file
name is too long and adds tests for that. This could be applied to 9.5
and backpatched, if we so choose. It might
13.11.2014, 23:50, Andres Freund kirjoitti:
On November 13, 2014 10:23:41 PM CET, Peter Eisentraut pete...@gmx.net
wrote:
On 11/12/14 7:31 PM, Andres Freund wrote:
Yes, it sucks. But it beats not being able to reindex a relation with
a
primary key (referenced by a fkey) without waiting
It seems that these two patches are being reviewed together. Should I
just combine them into one? My understanding was that some wanted to
review the memory accounting patch separately.
On Sun, 2014-12-21 at 20:19 +0100, Tomas Vondra wrote:
That's the only conflict, and after fixing it it
hi all,
Is postgres source code compatible with mysql database?? If it is, could
someone could give me some links so that I can do that.
I want to hack into the postgres source code, but as I am comfortable with
mysql, I want to use the mysql database not postgres.
any references would be
On Tue, Dec 23, 2014 at 3:06 PM, Ravi Kiran ravi.kolanp...@gmail.com
wrote:
hi all,
Is postgres source code compatible with mysql database?? If it is, could
someone could give me some links so that I can do that.
I want to hack into the postgres source code, but as I am comfortable with
On 12/16/2014 07:48 PM, Teodor Sigaev wrote:
/*
* This struct is what we actually keep in index-rd_amcache. It includes
* static configuration information as well as the lastUsedPages cache.
*/
typedef struct SpGistCache
{
spgConfigOut config;/* filled in by opclass
On 12/07/2014 03:54 AM, Tomas Vondra wrote:
The one interesting case is the 'step skew' with statistics_target=10,
i.e. estimates based on mere 3000 rows. In that case, the adaptive
estimator significantly overestimates:
values currentadaptive
--
Oh, that makes sense. Though I wonder if you need to clear the caches at all
when calling tbm_lossify(). Surely it never becomes un-lossified and plus, at
least for lossy_page it would never be set to the current page anyway, it's
either going to be set to InvalidBlockNumber, or some other
Amit,
* Amit Kapila (amit.kapil...@gmail.com) wrote:
There is a new column added in pg_authid (rolbypassrls)
and the updation for same is missed in below places:
a. System catalog page for pg_authid
http://www.postgresql.org/docs/devel/static/catalog-pg-authid.html
Yup, thanks, will fix.
On 23.12.2014 09:19, Noah Misch wrote:
On Sat, Dec 20, 2014 at 07:28:33PM +0100, Tomas Vondra wrote:
On 20.12.2014 19:05, Tom Lane wrote:
Locale cs_CZ.WIN-1250 is evidently marked with a codeset property of
ANSI_X3.4-1968 (which means old-school US-ASCII). That's certainly
wrong. I believe
On 23.12.2014 10:16, Jeff Davis wrote:
It seems that these two patches are being reviewed together. Should
I just combine them into one? My understanding was that some wanted
to review the memory accounting patch separately.
I think we should keep the patches separate. Applying two patches is
Now that the input data type and leaf data type can be different, which one is
attType? It's the leaf data type, as the patch stands. I renamed that to
attLeafType, and went fixing all the references to it. In most places it's just
a matter of search replace, but what about the reconstructed
Adam Brightwell wrote:
Alvaro and Stephen,
I propose this patch on top of Adam's v5. Also included is a full patch
against master.
I have attached an updated patch for review
(role-attribute-bitmask-v7.patch).
This patch incorporates the 'v5a' patch proposed by Alvaro, input
On Mon, Dec 22, 2014 at 5:00 PM, Jim Nasby jim.na...@bluetreble.com wrote:
I would MUCH rather that we find a way to special-case executing
non-transactional commands dynamically, because VACUUM isn't the only one
that suffers from this problem.
Is pg_background a solution to this problem?
--
On Mon, Dec 22, 2014 at 5:04 PM, Peter Geoghegan p...@heroku.com wrote:
If you're dead set on having an escape hatch, maybe we should just get
over it and add a way of specifying a unique index by name. As I said,
these under-served use cases are either exceedingly rare or entirely
On Mon, Dec 22, 2014 at 6:57 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
In the case of cube(a,b,c,d), our code currently gives:
b,d,a,c: (b,d,a,c),(b,d)
a,b,d:(a,b,d),(a,b)
d,a,c:(d,a,c),(d,a),(d)
c,d: (c,d),(c)
b,c,d:(b,c,d),(b,c),(b)
a,c,b:
On Mon, Dec 22, 2014 at 11:51 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Multi-table CLUSTER uses multiple transactions, so this should not be an
issue. That said, I don't think there's much point in CLUSTER SCHEMA,
much less TRUNCATE SCHEMA. Do you normally organize your schemas so
On Wed, Jul 9, 2014 at 9:53 PM, MauMau maumau...@gmail.com wrote:
But the source tree contains as many as 206 Makefiles. I'm worried that it
will waste the install time. Should all these Makefiles be examined, or 16
Makefiles in src/interfaces/?
Not really. IMO the best solution is to extract
On 12/23/2014 07:14 AM, Tomas Vondra wrote:
On 23.12.2014 09:19, Noah Misch wrote:
On Sat, Dec 20, 2014 at 07:28:33PM +0100, Tomas Vondra wrote:
On 20.12.2014 19:05, Tom Lane wrote:
Locale cs_CZ.WIN-1250 is evidently marked with a codeset property of
ANSI_X3.4-1968 (which means old-school
On 12/23/2014 04:36 AM, Ravi Kiran wrote:
hi all,
Is postgres source code compatible with mysql database?? If it is,
could someone could give me some links so that I can do that.
I want to hack into the postgres source code, but as I am comfortable
with mysql, I want to use the mysql
On 23.12.2014 15:21, Andrew Dunstan wrote:
No, config_opts is what's passed to configure. Try something like:
if ($branch eq 'REL9_0_STABLE')
{
$skip_steps{'pl-install-check'} = 1;
}
Applied to all three animals.
Tomas
--
Sent via pgsql-hackers mailing list
On Mon, Dec 22, 2014 at 6:55 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's a completely different idea. How about we add an option that
means vacuum this table before running the test (can be given several
times); by default the set of vacuumed tables is the current pgbench_*
On Mon, Dec 22, 2014 at 8:02 PM, Jim Nasby jim.na...@bluetreble.com wrote:
On 12/21/14, 8:55 PM, Fabrízio de Royes Mello wrote:
And why that, but not
say schema-wide ANALYZE, CLUSTER, TRUNCATE, ...
+1. I can write patches for each of this
Alvarao,
Pushed with a couple of small changes (Catalog.pm complained about the
lack of a CATALOG() line in the new acldefs.h file; you had
pg_role_all_attributes as returning bool in the table, but it returns
text[]; and I added index entries for the new functions.)
That's fantastic!
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
Use a bitmask to represent role attributes
The previous representation using a boolean column for each attribute
would not scale as well as we want to add further attributes.
Extra auxilliary functions are added to go along with this change, to
Tom Lane wrote:
Again, I suppose I should have objected earlier, but I really seriously
doubt that this is a good idea.
Ugh. I thought we had a consensus that this was the accepted way
forward; that's my reading of the old thread,
Robert Haas wrote:
On Mon, Dec 22, 2014 at 11:51 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Multi-table CLUSTER uses multiple transactions, so this should not be an
issue. That said, I don't think there's much point in CLUSTER SCHEMA,
much less TRUNCATE SCHEMA. Do you normally
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
Use a bitmask to represent role attributes
The previous representation using a boolean column for each attribute
would not scale as well as we want to add further attributes.
Extra auxilliary functions
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Again, I suppose I should have objected earlier, but I really seriously
doubt that this is a good idea.
Ugh. I thought we had a consensus that this was the accepted way
forward; that's my reading of the old thread,
On Tue, Dec 23, 2014 at 10:26 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Tom Lane wrote:
Again, I suppose I should have objected earlier, but I really seriously
doubt that this is a good idea.
Ugh. I thought we had a consensus that this was the accepted way
forward; that's my
Robert Haas wrote:
On Mon, Dec 22, 2014 at 6:55 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's a completely different idea. How about we add an option that
means vacuum this table before running the test (can be given several
times); by default the set of vacuumed tables is the
On 2014-12-23 10:40:15 -0500, Robert Haas wrote:
On Tue, Dec 23, 2014 at 10:26 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Tom Lane wrote:
Again, I suppose I should have objected earlier, but I really seriously
doubt that this is a good idea.
Ugh. I thought we had a consensus
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I have to apologize for not having paid more attention, but ... is this
*really* such a great idea? You've just broken any client-side code
that looks directly at pg_authid.
Anything which looks at pg_authid for
Robert Haas robertmh...@gmail.com writes:
I would have preferred (and I believe argued for) keeping the existing
catalog representation for existing attributes and using a bitmask for
new ones, to avoid breaking client code. But I am not sure if that's
actually the best decision. I find
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Again, I suppose I should have objected earlier, but I really seriously
doubt that this is a good idea.
Ugh. I thought we had a consensus that this was the accepted way
forward;
On 12/23/2014 04:46 PM, Andres Freund wrote:
[snip]
I find Tom's concern about needing more
than 64 attributes to be ill-founded; I can't really see that
happening on any timescale that matters.
Hmm... most probably, not (or so I hope)... Unless we begin to add many
differerent capabilities,
On Tue, Dec 23, 2014 at 10:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Meh. To the extent that users look at pg_roles rather than pg_authid,
it's going to look like another 15 boolean columns to them anyway ...
except that now, those columns are suddenly a lot more expensive to read.
Ugh. I
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I'd have gone with just adding more bool columns as needed.
I don't think I was the only one concerned that adding a bunch of new
columns would bloat the size of pg_authid and the C structure behind it,
but I'm
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2014-12-23 10:40:15 -0500, Robert Haas wrote:
I would have preferred (and I believe argued for) keeping the existing
catalog representation for existing attributes and using a bitmask for
new ones, to avoid breaking client code. But I am
José Luis Tallón wrote:
On 12/23/2014 04:46 PM, Andres Freund wrote:
I personally would prefer a 'custom' type to represent the
permissions. Internally that could very well be current bitmask, but the
external representation could be more complex (i.e. some textual
representation). That'd
On 12/22/2014 10:41 PM, Peter Eisentraut wrote:
On 12/22/14 7:56 PM, Andrew Dunstan wrote:
Currently the buildfarm animal crake (my development instance) is
running the bin check, but not any other animal. These tests still take
for too long, not least because each set of tests requires a
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Dec 23, 2014 at 10:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Meh. To the extent that users look at pg_roles rather than pg_authid,
it's going to look like another 15 boolean columns to them anyway ...
except that now, those columns are
Hello,
I've found myself needing two role capabilities? as of lately, when
thinking about restricting some roles to the barely minimum allowed
permissions needed to perform their duties ... as opposed to having a
superuser role devoted to these task.
The capabilities would be:
*
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I'd have gone with just adding more bool columns as needed.
I don't think I was the only one concerned that adding a bunch of new
columns would bloat the size of
* José Luis Tallón (jltal...@adv-solutions.net) wrote:
I've found myself needing two role capabilities? as of lately,
when thinking about restricting some roles to the barely minimum
allowed permissions needed to perform their duties ... as opposed to
having a superuser role devoted to
Stephen Frost sfr...@snowman.net writes:
If that's the only consideration for this, well, that's certainly quite
straight-forward to change in the other direction too. The new function
suggested by Andres actually makes it really easy to get a textual list
of all the role attributes which a
Looking forward to the new patch. I'll give it a more complete testing
when you post it.
Mike
__
*Mike Blackwell | Technical Analyst, Distribution Services/Rollout
Management | RR Donnelley*
1750 Wallace Ave | St
On Tue, Dec 23, 2014 at 11:34:09AM -0500, Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
If that's the only consideration for this, well, that's certainly quite
straight-forward to change in the other direction too. The new function
suggested by Andres actually makes it really
On 12/23/2014 05:29 PM, Stephen Frost wrote:
* José Luis Tallón (jltal...@adv-solutions.net) wrote:
I've found myself needing two role capabilities? as of lately,
when thinking about restricting some roles to the barely minimum
allowed permissions needed to perform their duties ... as
On 2014-12-22 10:35:35 +0530, Amit Kapila wrote:
On Fri, Dec 19, 2014 at 9:36 PM, Andres Freund and...@2ndquadrant.com
wrote:
Hi,
When debugging lwlock issues I found PRINT_LWDEBUG/LOG_LWDEBUG rather
painful to use because of the amount of elog contexts/statements
emitted. Given the
On 12/23/2014 06:06 PM, Bruce Momjian wrote:
On Tue, Dec 23, 2014 at 11:34:09AM -0500, Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
If that's the only consideration for this, well, that's certainly quite
straight-forward to change in the other direction too. The new function
José Luis Tallón-2 wrote
On 12/23/2014 05:29 PM, Stephen Frost wrote:
* José Luis Tallón (
jltallon@
) wrote:
* IMPERSONATE --- Ability to do SET AUTHORIZATION TO some_role;
and RESET AUTHORIZATION
This might be further refined to provide a way to say This role
is authorized to
José Luis Tallón-2 wrote
On 12/23/2014 06:06 PM, Bruce Momjian wrote:
On Tue, Dec 23, 2014 at 11:34:09AM -0500, Tom Lane wrote:
Stephen Frost lt;
sfrost@
gt; writes:
If that's the only consideration for this, well, that's certainly quite
straight-forward to change in the other direction
Bruce Momjian wrote:
I am with Tom on this --- there is more wasted space in the 'name'
column pg_authid.rolname than by shoving 40 boolean values into a
bitmap. Adding the complexity of a bitmap doesn't make sense here. I
also apologize for the late feedback.
Okay, it seems we have a
I have pushed patches 0001 through 0004, with some revisions. Only the
final part is missing.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
--
Sent via pgsql-hackers mailing list
* Bruce Momjian (br...@momjian.us) wrote:
I am with Tom on this --- there is more wasted space in the 'name'
column pg_authid.rolname than by shoving 40 boolean values into a
bitmap.
I agree that we waste a lot of space in 'name' but I don't think there's
an easy solution to that problem.
On 12/23/2014 07:01 PM, David G Johnston wrote:
Hmm the current documentation states that: The specified
role_name must be a role that the current session user is a member
of. I can see use cases where making the login role a member of every
other used role quickly becomes a burden, and
* José Luis Tallón (jltal...@adv-solutions.net) wrote:
On 12/23/2014 05:29 PM, Stephen Frost wrote:
The capabilities would be:
* MAINTENANCE --- Ability to run
VACUUM [ANALYZE | FREEZE] (but not VACUUM FULL),
ANALYZE (including SET LOCAL statistics_target TO 1),
There's
On Tue, Dec 23, 2014 at 01:43:47PM -0500, Stephen Frost wrote:
Offtopic, what I would really _love_ to see improved is our display of
object permissions:
That's a whole different discussion and really belongs on a new thread.
I'm certainly curious what ideas you have regarding how to fix
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Bruce Momjian wrote:
I am with Tom on this --- there is more wasted space in the 'name'
column pg_authid.rolname than by shoving 40 boolean values into a
bitmap. Adding the complexity of a bitmap doesn't make sense here. I
also
On 12/23/2014 11:11 AM, Andrew Dunstan wrote:
On 12/22/2014 10:41 PM, Peter Eisentraut wrote:
On 12/22/14 7:56 PM, Andrew Dunstan wrote:
Currently the buildfarm animal crake (my development instance) is
running the bin check, but not any other animal. These tests still take
for too long, not
On 12/17/2014 03:41 PM, Simon Riggs wrote:
All of this is just a replay of the earlier conversations about
reducing lock levels.
My original patch did reduce lock levels for CREATE TRIGGER, but we
stepped back from doing that in 9.4 until we had feedback as to
whether the whole idea of reducing
On 12/23/2014 07:01 PM, David G Johnston wrote:
[snip]
So you want to say:
GRANT IMPERSONATE TO bouncer; --covers the ALL requirement
instead of
GRANT victim1 TO bouncer;
GRANT victim2 TO bouncer;
etc...
-- these would still be used to cover the limited users requirement
?
|GRANT
* David G Johnston (david.g.johns...@gmail.com) wrote:
I'd rather there be better, more user friendly, SQL-based APIs to the
permissions system that would facilitate performing and reviewing grants.
This would be *really* nice, I agree. I've heard tale of people writing
functions that go
* José Luis Tallón (jltal...@adv-solutions.net) wrote:
On 12/23/2014 07:01 PM, David G Johnston wrote:
[snip]
So you want to say:
GRANT IMPERSONATE TO bouncer; --covers the ALL requirement
instead of
GRANT victim1 TO bouncer;
GRANT victim2 TO bouncer;
etc...
-- these would still
Hi,
Attached is a new version of the patchset which I intend to commit soon.
Stuff changed since 0.9:
* Greatly simplified locking logic - the whole concept that a lock could
be spuriously acquired is gone. That cost a small bit of performance
(0.5%, I thought it'd be much bigger) on x86,
I noticed this when looking at the allocated shared memory structures in
head:
shared memory alignment 64-byte of CommitTs Ctl: 0
shared memory alignment 64-byte of CommitTs shared: 0
I thought we got rid of the idea that 'Ts' means timestamp. Was this
part forgotten?
--
On Tue, Dec 23, 2014 at 11:30 AM, Peter Geoghegan p...@heroku.com wrote:
I tend to agree. I think we should just live with the fact that not
every conceivable use case will be covered, at least initially.
To be clear: I still think I should go and make the changes that will
make the feature
On 12/12/14 16:34, Alex Shulgin wrote:
Alex Shulgin a...@commandprompt.com writes:
Alex Shulgin a...@commandprompt.com writes:
Here's an attempt to revive this patch.
Here's the patch rebased against current HEAD, that is including the
recently committed action_at_recovery_target option.
* Peter Geoghegan (p...@heroku.com) wrote:
On Tue, Dec 23, 2014 at 5:46 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 22, 2014 at 5:04 PM, Peter Geoghegan p...@heroku.com wrote:
If you're dead set on having an escape hatch, maybe we should just get
over it and add a way of
On 12/23/2014 07:52 PM, Stephen Frost wrote:
[snip]
Manually performing VACUUM / VACUUM ANALYZE on the (few) affected
tables every 12h or so fixes the performance problem for the
particular queries without impacting the other users too much ---
the tables and indexes in question have been moved
On Tue, Dec 23, 2014 at 11:44 AM, Stephen Frost [via PostgreSQL]
ml-node+s1045698n5831875...@n5.nabble.com wrote:
It would be great to figure out a way to get feedback like this earlier
on in the development. This patch has been floating around for quite a
while, with intentional breaks for
On Thu, Dec 18, 2014 at 9:20 AM, Jeff Janes jeff.ja...@gmail.com wrote:
I've put this through an adaptation of my usual torture test, and it ran
fine until wraparound shutdown. I'll poke at it more later.
Could you elaborate, please? What are the details of the torture test
you're performing?
On 23/12/14 22:36, Ravi Kiran wrote:
hi all,
Is postgres source code compatible with mysql database?? If it is, could
someone could give me some links so that I can do that.
I want to hack into the postgres source code, but as I am comfortable
with mysql, I want to use the mysql database not
On 2014-12-23 16:42:41 -0500, Robert Haas wrote:
I don't think I have anything to say about the substance of the patch.
If fetch-and-add is faster than a spinlock cycle, then it is. And
it's good to be fast.
I don't think the primary advantage is that it's fast (even though it
should be as
On 12/22/2014 11:47 PM, Oskari Saarenmaa wrote:
__int128_t and __uint128_t are GCC extensions and are not related to
stdint.h.
[...]
These changes don't match what my autoconf does. Not a big deal I guess,
but if this is merged as-is the next time someone runs autoreconf it'll
write these
On 12/23/14, 8:54 AM, Fabrízio de Royes Mello wrote:
Right now a lot of people just work around this with things like DO blocks,
but as mentioned elsewhere in the thread that fails for commands that can't be in
a transaction.
I use dblink to solve it. :-)
So... how about instead of
On 12/23/14, 7:44 AM, Robert Haas wrote:
On Mon, Dec 22, 2014 at 5:00 PM, Jim Nasby jim.na...@bluetreble.com wrote:
I would MUCH rather that we find a way to special-case executing
non-transactional commands dynamically, because VACUUM isn't the only one
that suffers from this problem.
Is
Em terça-feira, 23 de dezembro de 2014, Jim Nasby jim.na...@bluetreble.com
escreveu:
On 12/23/14, 8:54 AM, Fabrízio de Royes Mello wrote:
Right now a lot of people just work around this with things like DO
blocks, but as mentioned elsewhere in the thread that fails for commands
that can't
On 12/16/2014 11:04 AM, David Rowley wrote: These are some very
promising performance increases.
I've done a quick pass of reading the patch. I currently don't have a
system with a 128bit int type, but I'm working on that.
Sorry for taking some time to get back. I have been busy before
On Thu, Apr 17, 2014 at 11:23:24AM +0200, Andres Freund wrote:
On 2014-04-16 19:18:02 -0400, Bruce Momjian wrote:
On Thu, Feb 6, 2014 at 09:40:32AM +0100, Andres Freund wrote:
On 2014-02-05 12:36:42 -0500, Robert Haas wrote:
It may well be that your proposal is spot on. But I'd like
On Mon, Dec 22, 2014 at 2:05 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Peter, could it be possible to merge this patch with its MSVC portion
for simplicity? I think that it would more readable to do all the
changes at the same time once and for all. Also, that's still a bug,
so are
On 12/20/14, 2:13 PM, Jim Nasby wrote:
On 12/20/14, 11:51 AM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-12-19 22:03:55 -0600, Jim Nasby wrote:
What I am thinking is not using all of those fields in their raw form to
calculate the hash value. IE: something analogous
On 12/24/14, 12:27 AM, Jim Nasby wrote:
There were several select-only runs on both to warm shared_buffers (set to
512MB for this test, and fsync is off).
BTW, presumably this ~380M database isn't big enough to show any problems with
hash collisions, and I'm guessing you'd need way more
Hello, sorry for the absense,
Thank you for committing.
On 8/29/14 4:01 PM, Peter Eisentraut wrote:
On 8/28/14 9:01 AM, Kyotaro HORIGUCHI wrote:
I found this issue when trying per-pg_user (role) loading of
auto_analyze and some tweaking tool. It is not necessarily set by
the user by
Hello, thank you for the comment, Ashutosh.
I'll return after the New Year holidays. Very sorry not
addressing them sooner but then I will have more time on this.
Have a happy holidays.
regards,
=
Hi Horiguchi-san,
Here are my comments for the patches together
Sanity
1. The patch
87 matches
Mail list logo
