On Tue, Jun 7, 2016 at 12:31 PM, Michael Paquier
wrote:
> On Tue, Jun 7, 2016 at 12:28 AM, Alvaro Herrera
> wrote:
>> Tom Lane wrote:
>>> Alvaro Herrera writes:
>>
>>> > I can't imagine that the server is avoiding
On Fri, Jun 3, 2016 at 11:25 PM, Tom Lane wrote:
> Michael Paquier writes:
>> Actually, the docs could be more polished.
>
> I think the docs could stand to be rewritten from scratch ;-). But
> upthread there was an offer to work on them if we made
On Fri, Jun 03, 2016 at 12:31:44PM -0400, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
> > On Fri, Jun 3, 2016 at 8:57 PM, Thom Brown wrote:
> > > If a database with the bloom extension installed is dumped and restored,
> > > there's an error with
On Tue, Jun 7, 2016 at 7:35 AM, Alvaro Herrera wrote:
> In looking at the DROP ACCESS METHOD completion I noticed that the
> words_after_create gadget is a bit buggy: for things with more than one
> word in the thing name (such as MATERIALIZED VIEW, USER MAPPING FOR,
>
Thanks for this patch. I have reviewed it:
On Sun, May 15, 2016 at 12:53:13PM +, Clément Prévost wrote:
> After some experiments, I found out that, for my setup (9b7bfc3a88ef7b), a
> parallel seq scan is used given both parallel_setup_cost
> and parallel_tuple_cost are set to 0 and given
At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane wrote in
<17504.1465225...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane wrote in
> > <11515.1464961...@sss.pgh.pa.us>
> >> I
On Fri, Apr 22, 2016 at 1:25 AM, David G. Johnston
wrote:
> On Wed, Apr 20, 2016 at 9:18 PM, Amit Langote
> wrote:
>> I agree it's unclear. Does the following make it any better (updated
>> patch attached):
I have sent a patch to
Existing application code written to call function in Oracle which return
no.of rows in out parameter and return-values is cursor-result
this need migrate to PostgreSQL, need help here
example: (actual function declaration only)
*Oracle:*
CREATE OR REPLACE PROCEDURE sc_getapppermissionlist (
On Sat, Jun 4, 2016 at 1:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yeah, but what if somebody doesn't want to store scopes?
>
> [ shrug... ] We can invent a "strip_scope()" sort of function,
> analogous to the weight-stripping function for
On Tue, Jun 7, 2016 at 6:55 AM, Michael Paquier
wrote:
> On Tue, Jun 7, 2016 at 12:01 AM, Robert Haas wrote:
>> On Fri, Jun 3, 2016 at 12:31 PM, Stephen Frost wrote:
Stephen, something is smelling wrong in
On Tue, Jun 7, 2016 at 12:28 AM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Alvaro Herrera writes:
>
>> > I can't imagine that the server is avoiding hash aggregation on a 1MB
>> > work_mem limit for data that's a few dozen of bytes. Is it
Bruce Momjian wrote:
> OK, updated version attached. I added "potential" to the first
> paragraph, and added "estimated cost" to the later part, fixed the
> "cheaper than", and clarified that we add the plan time cost to the
> non-generic plan, which is how it can be cheaper than the generic
On Mon, Jun 6, 2016 at 5:44 PM, Masahiko Sawada wrote:
> On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada wrote:
>> On Sat, Jun 4, 2016 at 12:59 AM, Robert Haas wrote:
>>> On Fri, Jun 3, 2016 at 11:21 AM, Masahiko Sawada
On Mon, Jun 6, 2016 at 6:34 PM, Robert Haas wrote:
> On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier
> wrote:
>>> Attached is a sample patch that controls full page vacuum by new GUC
>>> parameter.
>>
>> Don't we want a reloption for that? Just
On Sun, Jun 5, 2016 at 11:16 PM, Tom Lane wrote:
> Michael Paquier writes:
>> Still, on back branches I think that it would be a good idea to have a
>> better error message for the ones that already throw an error, like
>> "trigger with OID %u does
Hi all,
With a low value of work_mem, like 1MB, I am noticing that the new
psql_crosstab is generating a couple of diffs with installcheck
(tested only on OSX 10.11):
***
*** 127,134
\crosstabview v h i
v | h0 | h1 | h2 | h4 | #null#
On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier
wrote:
>> Attached is a sample patch that controls full page vacuum by new GUC
>> parameter.
>
> Don't we want a reloption for that? Just wondering...
Why? Just for consistency? I think the bigger question here is
On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada wrote:
> On Sat, Jun 4, 2016 at 12:59 AM, Robert Haas wrote:
>> On Fri, Jun 3, 2016 at 11:21 AM, Masahiko Sawada
>> wrote:
Can you submit that part as a separate patch?
>>>
How about silencing the workers on termination?
# Build on Windows (with VC?) is very time consuming...
At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane wrote in
<11515.1464961...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > For sure, any of
On Sat, Jun 4, 2016 at 1:53 AM, Robert Haas wrote:
>
> On Thu, May 12, 2016 at 2:07 PM, Tom Lane wrote:
> >> Err, wow. That makes my head hurt. Can you explain why this case
> >> only arises for appendrel children, and not for plain rels?
> >
> >
There appears to be a problem with how client encoding is handled in the
communication from parallel workers. In a parallel worker, the client
encoding setting is inherited from its creating process as part of the
GUC setup. So any plain-text stuff the parallel worker sends to its
leader is
On Mon, Jun 6, 2016 at 7:46 AM, Robert Haas wrote:
> On Sat, Jun 4, 2016 at 12:18 AM, Masahiko Sawada
> wrote:
>> Attached updated patch.
>
> The error-checking enhancements here look good to me, except that you
> forgot to initialize
On Sat, Jun 4, 2016 at 12:18 AM, Masahiko Sawada wrote:
> Attached updated patch.
The error-checking enhancements here look good to me, except that you
forgot to initialize totalBytesRead. I've committed those changes
with a fix for that problem and will look at the rest
Hi
Is there any option in PGPLSQL which can RETURNS table or SETOF rows along
with an OUT parameter?
please
Thanks
Sridhar
OpenText
On Mon, Jun 6, 2016 at 7:17 AM, Sridhar N Bamandlapally <
sridhar@gmail.com> wrote:
> Hi
>
> Is there any option in PGPLSQL which can RETURNS table or SETOF rows along
> with an OUT parameter?
>
>
No, there would be no point given the internals of how functions work.
What is it you are
On Sat, Jun 4, 2016 at 10:45 PM, David G. Johnston
wrote:
> On Tuesday, March 22, 2016, Merlin Moncure wrote:
>>
>>
>> Anyways, here's the patch with documentation adjustments as promised.
>> I ended up keeping the 'without result' section because
On Sun, Jun 5, 2016 at 4:39 PM, Jim Nasby wrote:
> I'm pretty sure this is a typo...
Sure is. Thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Masahiko Sawada writes:
> On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada wrote:
>> So other idea is to have GUC parameter, vacuum_even_frozen_page for example.
>> If this parameter is set true (false by default), we do vacuum whole
>> table forcibly
On Tue, May 31, 2016 at 2:19 PM, Peter Eisentraut
wrote:
> On 5/31/16 1:47 PM, Jaime Casanova wrote:
>>
>> Are we going to change synchronous_standby_names? Certainly the GUC is
>> not *only* a list of names anymore.
>>
>> synchronous_standby_config?
>>
On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
> We should consider single and multiple SRFs in a targetlist as distinct
> use-cases; only the latter has got weird properties.
>
> There are several things we could potentially do with multiple SRFs in
> the same targetlist.
Michael Paquier wrote:
> I know that we guarantee that make installcheck may not work on many
> target servers as a lot of tests are very GUC-sensitive, but this
> looks a bit oversensitive to me, especially knowing that it is the
> only diff generated by the whole test suite.
> Don't you think
Robert Haas wrote:
> My gut feeling on this is to either do nothing or add a VACUUM option
> (not a GUC, not a reloption) called even_frozen_pages, default false.
> What is your opinion?
+1 for that approach -- I thought that was already agreed weeks ago and
the only question was what to name
On Thu, Jun 2, 2016 at 4:48 PM, Corey Huinker wrote:
> A while back, there was a push to make COPY gzip-aware. That didn't happen,
> but COPY FROM PROGRAM did, and it scratches the same itch.
>
> I have a similar need, but with file_fdw foreign tables. I have .csv.gz
>
Kyotaro HORIGUCHI writes:
> At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane wrote in
> <11515.1464961...@sss.pgh.pa.us>
>> I think that this one:
>>> If the target thread is allocating memory from the heap, the heap
>>> lock will not be
On Mon, Jun 6, 2016 at 07:19:37AM +, Albe Laurenz wrote:
> Bruce Momjian wrote:
> > OK, updated version attached. I added "potential" to the first
> > paragraph, and added "estimated cost" to the later part, fixed the
> > "cheaper than", and clarified that we add the plan time cost to the
>
On Mon, Jun 6, 2016 at 11:28 AM, Andres Freund wrote:
> On 2016-06-06 05:34:32 -0400, Robert Haas wrote:
>> On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier
>> wrote:
>> >> Attached is a sample patch that controls full page vacuum by new GUC
>> >>
On 2016-06-06 11:37:25 -0400, Robert Haas wrote:
> On Mon, Jun 6, 2016 at 11:28 AM, Andres Freund wrote:
> > Except that we right now don't have any realistic way to figure out
> > whether this new feature actually does the right thing. Which makes
> > testing this
On Mon, Jun 6, 2016 at 9:53 AM, Tom Lane wrote:
> Masahiko Sawada writes:
>> On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada
>> wrote:
>>> So other idea is to have GUC parameter, vacuum_even_frozen_page for example.
>>> If this
Alvaro Herrera writes:
> Michael Paquier wrote:
>> I know that we guarantee that make installcheck may not work on many
>> target servers as a lot of tests are very GUC-sensitive, but this
>> looks a bit oversensitive to me, especially knowing that it is the
>> only diff
Noah Misch wrote:
> The above-described topic is currently a PostgreSQL 9.6 open item. Álvaro,
> since you committed the patch believed to have created it, you own this open
> item. If some other commit is more relevant or if this does not belong as a
> 9.6 open item, please let us know.
On Mon, Jun 6, 2016 at 10:18 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> My gut feeling on this is to either do nothing or add a VACUUM option
>> (not a GUC, not a reloption) called even_frozen_pages, default false.
>> What is your opinion?
>
> +1 for that approach
On Thu, Jun 2, 2016 at 12:35 PM, Andreas 'ads' Scherbaum
wrote:
> the TESTING file in src/bin/pg_upgrade talks about a "check.sh script", but
> this seems to be a binary (check) now.
Nope:
[rhaas pgsql]$ git grep -F check.sh
[rhaas pgsql]$
--
Robert Haas
EnterpriseDB:
Hello!
Why we don't have checksums on clog files.
We have checksum on pg_control, optional checksumming on data files,
some form of checksumming on wal's. But why we don't have any
checksumming on clogs. Corruptions on clogs lead to transaction
visisbility problems and database consistency
Tom Lane wrote:
> Alvaro Herrera writes:
> > Michael Paquier wrote:
> >> I know that we guarantee that make installcheck may not work on many
> >> target servers as a lot of tests are very GUC-sensitive, but this
> >> looks a bit oversensitive to me, especially knowing
Robert Haas writes:
> I'm intuitively sympathetic to the idea that we should have an option
> for this, but I can't figure out in what case we'd actually tell
> anyone to use it. It would be useful for the kinds of bugs listed
> above to have VACUUM (rebuild_vm) to blow
On Fri, Jun 3, 2016 at 12:31 PM, Stephen Frost wrote:
>> Stephen, something is smelling wrong in checkExtensionMembership()
>> since 5d58999, an access method does not have ACLs and I would have
>> expected that when this routine is invoked in
>> selectDumpableAccessMethod()
Hi all,
I found that the tab completion for USER MAPPING doesn't work fine.
For example,
The below is no problem.
postgres=# create user[TAB]
user user mapping for
But this doesn't work fine. (Note that there is a white space between
'user' and [TAB])
postgres=# create user [TAB]
Tom Lane wrote:
> Alvaro Herrera writes:
> > I can't imagine that the server is avoiding hash aggregation on a 1MB
> > work_mem limit for data that's a few dozen of bytes. Is it really doing
> > that?
>
> Yup:
Aha. Thanks for testing.
> Now that you mention it,
Robert Haas writes:
> On Mon, Jun 6, 2016 at 11:28 AM, Andres Freund wrote:
>> Except that we right now don't have any realistic way to figure out
>> whether this new feature actually does the right thing.
> I just don't see how running VACUUM on the
I wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> Presumably what is happening is that the planner is switching from hash
>>> to sort aggregation.
>> I can't imagine that the server is avoiding hash aggregation on a 1MB
>> work_mem limit for data that's a few
On 2016-06-06 05:34:32 -0400, Robert Haas wrote:
> On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier
> wrote:
> >> Attached is a sample patch that controls full page vacuum by new GUC
> >> parameter.
> >
> > Don't we want a reloption for that? Just wondering...
>
> Why?
Tomas Vondra writes:
> One of the recent issues with the current design was handling of
> inheritance / appendrels. ISTM the proposed design has the same issue,
> no? What happens if the relations are partitioned?
I haven't thought about inheritance in this
... BTW, another thought occurred to me yesterday: it seems like the
existing code hasn't thought through its behavior for multiple foreign
keys very carefully. That is, suppose we have both "A.J references B.K"
and "A.X references B.Y", as separate FKs not a single multicolumn FK.
The current
On 06/06/16 18:30, David G. Johnston wrote:
> To clarify, the present behavior is basically a combination of both of
> Robert's results.
>
> If the SRFs return the same number of rows the first (zippered) result
> is returned without an NULL padding.
>
> If the SRFs return a different number of
"David G. Johnston" writes:
> If the SRFs return a different number of rows the LCM behavior kicks in and
> you get Robert's second result.
Only if the periods of the SRFs are relatively prime. That is, neither of
his examples demonstrate the full weirdness of the
On 06/06/2016 06:15 PM, Tom Lane wrote:
Tomas Vondra writes:
On 06/04/2016 08:15 PM, Tom Lane wrote:
* Make RelationGetFKeyList cache a list of ForeignKeyOptInfo structs,
not just constraint OIDs. It's insane that the relcache scans
pg_constraint to collect
Robert Haas writes:
> On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
>> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would
>> have the same behavior as before if the SRFs all return the same number
>> of rows, and otherwise would
On Mon, Jun 6, 2016 at 11:45 AM, Bruce Momjian *EXTERN*
wrote:
>
> One more thing --- there was talk of moving some of this into chapter
> 66, but as someone already mentioned, there are no subsections there
> because it is a dedicated topic:
>
> 66. How the Planner
On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
> >> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would
> >> have the same behavior as
I'm fine with the code being released under the PostgreSQL license.
Thanks,
Adam
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tomas Vondra writes:
> On 06/04/2016 08:15 PM, Tom Lane wrote:
>> * Make RelationGetFKeyList cache a list of ForeignKeyOptInfo structs,
>> not just constraint OIDs. It's insane that the relcache scans
>> pg_constraint to collect those OIDs and then the planner
Robert Haas writes:
> On Mon, Jun 6, 2016 at 9:53 AM, Tom Lane wrote:
>> Taking out GUCs is not
>> easier than taking out statement parameters; you risk breaking
>> applications either way.
> Agreed, but that doesn't really answer the question of which
On Fri, Jun 3, 2016 at 11:41 PM, Robert Haas wrote:
> (Status update for Noah: I expect Masahiko Sawada will respond
> quickly, but if not I'll give some kind of update by Monday COB
> anyhow.)
I believe this open item is now closed, unless Andres has more
comments or
Alvaro Herrera writes:
> Tom Lane wrote:
>> Presumably what is happening is that the planner is switching from hash
>> to sort aggregation.
> I can't imagine that the server is avoiding hash aggregation on a 1MB
> work_mem limit for data that's a few dozen of bytes. Is
Robert Haas writes:
> ... I guess I'd prefer #2 to #2.5, #2.5 to #3, and #3 to #1.
> I really don't like #1 much - I think I'd almost rather do nothing.
FWIW, that's about my evaluation of the alternatives as well. I fear
that #1 would get a lot of pushback. If we think
On Mon, Jun 6, 2016 at 2:35 PM, Andres Freund wrote:
>> > Why would they have to write the complex query? Wouldn't they just
>> > need to run that we wrote for them?
>
> Then write that query. Verify that that query performs halfway
> reasonably fast. Document that it should
On Mon, Jun 6, 2016 at 2:31 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
> > On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote:
> > > Robert Haas writes:
> > >> On Mon, May 23, 2016 at 4:15 PM, Tom Lane
On Mon, Jun 6, 2016 at 2:53 PM, Tom Lane wrote:
> Now, if we decide to try to rewrite tlist SRFs as LATERAL, it would likely
> behoove us to do that rewrite before expanding * not after, so that we can
> eliminate the multiple evaluation of foo() that happens currently. (That
On Fri, Jun 3, 2016 at 11:13 PM, Robert Haas wrote:
>> I think the workers should stop processing tuples after the tuple queues got
>> detached. This will not only handle above situation gracefully, but will
>> allow to speed up the queries where Limit clause is present on
I wrote:
> Tomasz Ostrowski writes:
>> I suppose this is a bug - an analyze, which does not analyze all
>> columns, should not reset pg_stat_user_tables(n_mod_since_analyze). What
>> do you think?
> I'm inclined to think that this is a reasonable complaint. A usage
>
Hi,
On 2016-06-06 15:16:10 -0400, Robert Haas wrote:
> On Mon, Jun 6, 2016 at 2:35 PM, Andres Freund wrote:
> >> > Why would they have to write the complex query? Wouldn't they just
> >> > need to run that we wrote for them?
> >
> > Then write that query. Verify that that
On Sat, Jun 4, 2016 at 2:57 AM, Amit Kapila wrote:
> In the above change, you are first adding bytes_written and then doing the
> SHM_MQ_DETACHED check, whereas other place the check is done first which
> seems to be right. I think it doesn't matter either way, but it is
Alvaro Herrera writes:
> Robert Haas wrote:
>> On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote:
>>> No, because then you get the cross-product of multiple SRFs, not the
>>> run-in-lockstep behavior.
>> Oh. I assumed that was the expected behavior.
On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
>>> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would
>>> have the same behavior as before
On Fri, Jun 3, 2016 at 7:58 AM, Korbin Hoffman wrote:
>
> Hi there-
>
> I've attached a small patch exposing HS_COUNT to the user as
> "hstore_length(hstore)". Documentation, upgrade sql files, and a few
> tests are also included.
>
> Almost every hstore function calls HS_COUNT, but I
Robert Haas wrote:
> On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
> >>> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would
> >>>
On 06/06/2016 07:40 PM, Tom Lane wrote:
Tomas Vondra writes:
On 06/06/2016 06:15 PM, Tom Lane wrote:
This checks that you found a joinclause mentioning foreignrel. But
foreignrel need have nothing to do with the foreign key; it could be any
table in the query.
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jun 6, 2016 at 11:44 AM, Andres Freund wrote:
> >> In terms of diagnostic tools, you can get the VM bits and
> >> page-level bits using the pg_visibility extension; I wrote it
> >> precisely because of concerns like the
On 2016-06-06 14:24:14 -0400, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Mon, Jun 6, 2016 at 11:44 AM, Andres Freund wrote:
> > >> In terms of diagnostic tools, you can get the VM bits and
> > >> page-level bits using the pg_visibility
Tomas Vondra writes:
> On 06/06/2016 06:15 PM, Tom Lane wrote:
>> This checks that you found a joinclause mentioning foreignrel. But
>> foreignrel need have nothing to do with the foreign key; it could be any
>> table in the query.
> I don't follow. How could it
[ redirecting to -hackers ]
Tomasz Ostrowski writes:
> I'm routinely bulk inserting data to a PostgreSQL table and then
> analyzing a single column of the table, because it contains data which
> significantly changes histogram of this column values - for example
>
Tomas Vondra writes:
> When it comes to improving multiple (multi-column) foreign keys, I think
> it may get way more complicated that it might seem. What if the foreign
> keys overlap, for example? Or what if the keys go in opposite directions
> (cycle). And so
On 06/06/2016 06:34 PM, Tom Lane wrote:
... BTW, another thought occurred to me yesterday: it seems like the
existing code hasn't thought through its behavior for multiple foreign
keys very carefully. That is, suppose we have both "A.J references B.K"
and "A.X references B.Y", as separate FKs
On Mon, Jun 6, 2016 at 11:44 AM, Andres Freund wrote:
>> In terms of diagnostic tools, you can get the VM bits and
>> page-level bits using the pg_visibility extension; I wrote it
>> precisely because of concerns like the ones you raise here. If you
>> want to cross-check the
On Mon, Jun 6, 2016 at 4:06 PM, Andres Freund wrote:
>> I do appreciate you reviewing this code, very much, and genuinely, and
>> it would be great if more people wanted to review it.
>
>> But this kind of reads like you think that I'm being a jerk, which I'm
>> trying pretty
On Mon, Jun 6, 2016 at 2:35 PM, Andres Freund wrote:
>> > Why would they have to write the complex query? Wouldn't they just
>> > need to run that we wrote for them?
>
> Then write that query. Verify that that query performs halfway
> reasonably fast. Document that it should
On Mon, Jun 6, 2016 at 4:27 PM, Andres Freund wrote:
> On 2016-06-06 16:18:19 -0400, Stephen Frost wrote:
>> That could be as simple as a query with the right things installed, or
>> it might be an independent tool, but not having any way to check isn't
>> good. That said,
On 06/06/2016 01:38 PM, Tom Lane wrote:
> Also, I'd be a bit inclined to disable the counter reset whenever a column
> list is specified, disregarding the corner case where a list is given but
> it includes all the table's analyzable columns. It doesn't really seem
> worth the effort to account
On Mon, Jun 6, 2016 at 11:35 AM, Andres Freund wrote:
>> We need a read-only utility which checks that the system is in a correct
>> and valid state. There are a few of those which have been built for
>> different pieces, I believe, and we really should have one for the
>>
On Mon, Jun 6, 2016 at 5:06 PM, Andres Freund wrote:
> On 2016-06-06 16:41:19 -0400, Robert Haas wrote:
>> I really don't understand how you can not weigh in on the original
>> thread leading up to my mid-March commits and say "hey, this needs a
>> better testing tool", and
Hi,
On 2016-06-06 17:22:38 -0400, Robert Haas wrote:
> > I'd also be ok with adding & documenting (beta release notes)
> > CREATE EXTENSION pg_visibility;
> > SELECT relname FROM pg_class WHERE relkind IN ('r', 'm') AND NOT
> > pg_check_visibility(oid);
> > or something olong those lines.
>
>
On Mon, Jun 6, 2016 at 3:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... I guess I'd prefer #2 to #2.5, #2.5 to #3, and #3 to #1.
>> I really don't like #1 much - I think I'd almost rather do nothing.
>
> FWIW, that's about my evaluation of the
On 2016-06-06 16:41:19 -0400, Robert Haas wrote:
> I really don't understand how you can not weigh in on the original
> thread leading up to my mid-March commits and say "hey, this needs a
> better testing tool", and then when you finally get around to
> reviewing it in May, I'm supposed to drop
Hi,
On 2016-06-06 17:00:19 -0400, Robert Haas wrote:
> 1. I think it is pretty misleading to say that those checks aren't
> reachable any more. It's not like we freeze every page when we mark
> it all-visible.
True. What I mean is that you can't force the checks (and some that I
think should
Andres, all,
* Andres Freund (and...@anarazel.de) wrote:
> On 2016-06-06 15:16:10 -0400, Robert Haas wrote:
> > On Mon, Jun 6, 2016 at 2:35 PM, Andres Freund wrote:
> > and like you have the right to tell assign me arbitrary work, which I
> > think you don't.
>
> It's not
On 2016-06-06 16:18:19 -0400, Stephen Frost wrote:
> That could be as simple as a query with the right things installed, or
> it might be an independent tool, but not having any way to check isn't
> good. That said, trying to make VACUUM do that doesn't make sense to me
> either.
The point is
On Mon, Jun 6, 2016 at 3:26 PM, Tom Lane wrote:
> Robert Haas writes:
> > ... I guess I'd prefer #2 to #2.5, #2.5 to #3, and #3 to #1.
> > I really don't like #1 much - I think I'd almost rather do nothing.
>
> FWIW, that's about my evaluation of the
On Tue, Jun 7, 2016 at 12:01 AM, Robert Haas wrote:
> On Fri, Jun 3, 2016 at 12:31 PM, Stephen Frost wrote:
>>> Stephen, something is smelling wrong in checkExtensionMembership()
>>> since 5d58999, an access method does not have ACLs and I would have
Michael Paquier wrote:
> On Thu, Jun 2, 2016 at 3:42 PM, Michael Paquier
> wrote:
> > On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier
> > wrote:
> >> I have added an open item for 9.6 regarding this patch, that would be
> >> good to complete
Thanks for the review, Fabrízio.
Attached is the updated patch, rebased and tested against master.
I integrated feedback from your first point and am no longer
HS_POLLUTE'ing the namespace for the new function.
With regards to your second point- I've been maintaining consistency
with the rest
100 matches
Mail list logo