>
> So, is there any idea how we will handle NULL and empty array in
> array_agg(anyarray)?
> I propose we just reject those input because the output will make no sense:
> - array_agg(NULL::int[]) --> the result will be indistinguished from
> array_agg of NULL ints.
> - array_agg('{}'::int[]) --> h
On 10/9/14, 4:19 PM, Andres Freund wrote:
On 2014-10-09 18:16:46 -0300, Alvaro Herrera wrote:
>Andres Freund wrote:
> >On 2014-10-09 18:03:00 -0300, Alvaro Herrera wrote:
> > >Bruce Momjian wrote:
> > >
> > > >I agree this is a serious problem. We have discussed various options,
> > > >but h
> But TBH I suspect 95% of the problems here would vanish if smart
> shutdown weren't the default ...
But for your repeated objections, we would have changed the default to fast
years ago. AFAICT everyone else is in favor of that.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hacker
On 10/17/14, 11:19 PM, David E. Wheeler wrote:
On Oct 17, 2014, at 3:18 PM, Tom Lane wrote:
Yeah, exactly. Personally I'm *not* for this, but if we do it we should
do it consistently: every comma-separated list in the SQL syntax should
work the same.
PL/pgSQL, too, I presume.
Yes.
The on
On 10/17/14, 10:16 PM, Tom Lane wrote:
I wrote:
Because it needs up-to-date min/max values in order to avoid being
seriously misled about selectivities of values near the endpoints.
See commit 40608e7f949fb7e4025c0ddd5be01939adc79eec.
BTW, on re-reading that code I notice that it will happily
Hi,
On 16.10.2014 03:26, Jeff Davis wrote:
> On Fri, 2014-08-29 at 10:12 -0400, Tom Lane wrote:
>> What about removing the callback per se and just keeping the
>> argument, as it were. That is, a MemoryContext has a field of type
>> "size_t *" that is normally NULL, but if set to non-NULL, then we
BRUSSER Michael writes:
> initdb failed
> FATAL: unexpected data beyond EOF in block 19 of relation base/1/2609
> HINT: This has been seen to occur with buggy kernels; consider updating your
> system.
> STATEMENT: COMMENT ON FUNCTION euc_jis_2004_to_shift_jis_2004
> (INTEGER, INTEGER, C
On 2014-10-18 14:30:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Interestingly we already set PROC_IN_ANALYZE - but we never actually
> > look at it. I wonder what it'd take to ignore analyze in
> > GetSnapshotData()/GetOldestXmin()... At first sight it looks quite
> > doable to not have
Andres Freund writes:
> Interestingly we already set PROC_IN_ANALYZE - but we never actually
> look at it. I wonder what it'd take to ignore analyze in
> GetSnapshotData()/GetOldestXmin()... At first sight it looks quite
> doable to not have a snapshot around (or setup to be ignored) while
> acqui
Hi,
One of our sites ran into a problem with database installation:
initdb failed
FATAL: unexpected data beyond EOF in block 19 of relation base/1/2609
HINT: This has been seen to occur with buggy kernels; consider updating your
system.
STATEMENT: COMMENT ON FUNCTION euc_jis_2004_to_shift_jis_20
On Sat, Oct 18, 2014 at 06:15:03PM +0200, Marko Tiikkaja wrote:
> On 10/18/14, 5:46 PM, Tom Lane wrote:
> >Marko Tiikkaja writes:
> >>Yes, exactly; if I had had the option to disable the index from the
> >>optimizer's point of view, I'd have seen that it's not used for looking
> >>up any data by a
On Sat, Oct 18, 2014 at 5:27 AM, Greg Stark wrote:
> That's interesting but I think it's mostly a quirk of your example.
> Afaics the difference is only that the en_US locale ignores
> punctuation like : and / (or at least treats them as less significant
> than alphabetic characters). If you had
Hi,
I've noticed an interesting phenomenon. Look at the following pgbench -c
32 -j 32 -P 1 output on a scale 200 database. Then guess where I've
started
SET vacuum_cost_delay = '20ms';
ANALYZE pgbench_accounts;
and when it finished. The cost_delay is to simulate a autovac triggered
analyze.
progr
All,
> I'll break them into three pieces- superuser() cleanup, GetUserId() ->
> has_privs_of_role(), and the additional-role-attributes patch will just
> depend on the others.
>
Attached is a patch for the GetUserId() -> has_privs_of_role() cleanup for
review.
-Adam
--
Adam Brightwell - adam.
I looked into bug #11703,
http://www.postgresql.org/message-id/20141017162236.2523.74...@wrigleys.postgresql.org
What is happening here is that the FieldSelect optimization in
eval_const_expressions fails to play nice with the logic that determines
which Vars need to be available from a relation s
On 10/18/14, 5:46 PM, Tom Lane wrote:
Marko Tiikkaja writes:
Yes, exactly; if I had had the option to disable the index from the
optimizer's point of view, I'd have seen that it's not used for looking
up any data by any queries, and thus I would have known that I can
safely drop it without slow
Marko Tiikkaja writes:
> On 10/18/14, 4:33 PM, Bruce Momjian wrote:
>> Well, if the index is there, why not use it? I thought the problem was
>> just that you had no visibility into how those statistics were being
>> accessed.
> Yes, exactly; if I had had the option to disable the index from the
Bruce Momjian writes:
> How many other cases do we have where the statistics are getting
> incremented and there is no user visibility into the operation?
* system catalog accesses
* vacuum/analyze/cluster/etc
The fact that system-initiated accesses get counted in the statistics
is a feature, no
On Sat, Oct 18, 2014 at 04:38:37PM +0200, Marko Tiikkaja wrote:
> On 10/18/14, 4:33 PM, Bruce Momjian wrote:
> >On Sat, Oct 18, 2014 at 04:29:41PM +0200, Marko Tiikkaja wrote:
> >>Another idea had was some way to tell the optimizer not to use that
> >>particular index for stats lookups, but probabl
> Does someone know what other DBMSs do in this regard? I.e., do they
> put anything in INFORMATION_SCHEMA.VIEWS for matviews? What TABLE_TYPE
> do they use in INFORMATION_SCHEMA.TABLES?
I can only speak for Oracle.
Oracle doesn't have INFORMATION_SCHEMA but their JDBC driver treats mviews
as t
On 10/18/14, 4:33 PM, Bruce Momjian wrote:
On Sat, Oct 18, 2014 at 04:29:41PM +0200, Marko Tiikkaja wrote:
Another idea had was some way to tell the optimizer not to use that
particular index for stats lookups, but probably the use case for
such a feature would be a bit narrow.
Well, if the in
On Fri, Oct 17, 2014 at 02:36:55PM -0400, Bruce Momjian wrote:
> On Fri, Oct 17, 2014 at 12:56:52PM -0400, Tom Lane wrote:
> > David G Johnston writes:
> > > The question is whether we explain the implications of not being
> > > WAL-logged
> > > in an error message or simply state the fact and le
On Sat, Oct 18, 2014 at 04:29:41PM +0200, Marko Tiikkaja wrote:
> On 10/18/14, 5:16 AM, Tom Lane wrote:
> >BTW, on re-reading that code I notice that it will happily seize upon
> >the first suitable index ("first" in OID order), regardless of how many
> >lower-order columns that index has got. Thi
On Mon, Oct 13, 2014 at 07:38:39PM -0400, Bruce Momjian wrote:
> I think the basic problem is that the original author had the idea of
> doing:
>
> SELECT INTERVAL (2) '100. seconds';
>interval
> --
>00:01:41
>
> and using (2) in that location as a short-ha
On 10/18/14, 5:16 AM, Tom Lane wrote:
BTW, on re-reading that code I notice that it will happily seize upon
the first suitable index ("first" in OID order), regardless of how many
lower-order columns that index has got. This doesn't make any difference
I think for get_actual_variable_range's own
On Mon, Oct 13, 2014 at 12:17:54PM -0400, Bruce Momjian wrote:
> On Wed, Aug 27, 2014 at 06:39:21AM -0700, David G Johnston wrote:
> > > Is there a doc patch to make here?
> >
> > 1. Last sentence change suggestion: "The target tablespace must be empty."
> >
> > 2. Based on Robert's comments it s
On Fri, Oct 17, 2014 at 11:03:04PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Oct 17, 2014 at 06:15:37PM -0400, Tom Lane wrote:
> >> Those stats were perfectly valid: what the planner is looking for is
> >> accurate minimum and maximum values for the index's leading column, and
> >
2014-10-18 Stephen Frost :
> * Peter Eisentraut (pete...@gmx.net) wrote:
>
>> More subtly, if we claim that a materialized view is a view, then we
>> cannot have asynchronously updated materialized views, because then we
>> have different semantics.
>
> This is, at least, a reason I can understand
On Sat, Oct 18, 2014 at 3:10 AM, Peter Geoghegan wrote:
> So the first eight bytes of the first string is 0x131F1F1B221E,
> and the second 0x131F1F1B220C. The last byte is different.
That's interesting but I think it's mostly a quirk of your example.
Afaics the difference is only that the
On 18 October 2014 05:13, MauMau wrote:
> [requirement]
> 10.6 Review logs and security events for
> all system components to identify
> anomalies or suspicious activity.
> Note: Log harvesting, parsing, and
> alerting tools may be used to meet this
> Requirement.
> The log review process does no
On 18/10/14 06:13, MauMau wrote:
[requirement]
10.2.3 Verify access to all audit trails is logged.
Malicious users often attempt to alter audit logs to
hide their actions, and a record of access allows
an organization to trace any inconsistencies or
potential tampering of the logs to an individ
Hi Mark,
Vitesse DB won't be open-sourced, or it would have been a contrib
module to postgres. We should take further discussions off this list.
People should contact me directly if there is any questions.
Thanks,
ck...@vitessedata.com
On Fri, Oct 17, 2014 at 10:55 PM, Mark Kirkwood
wrote:
>
32 matches
Mail list logo
