I propose the attached patch, aligning the help message with the docs. Any
reason not to?
(yes, I confused myself by trying --wal-segsize=1MB instead of just
--wal-segsize=1. I blame just stepping off an intercontinental flight and a
very early morning :P)
--
Magnus Hagander
Me: https://www.ha
On 11 March 2018 at 12:11, Tomas Vondra wrote:
> On 03/05/2018 04:51 AM, David Rowley wrote:
>> On 5 March 2018 at 04:54, Tomas Vondra wrote:
>> Consider the following slightly backward-looking case;
>>
>> select string_agg(',', x::text) from generate_Series(1,10)x;
>> string_agg
>> ---
On Sat, Mar 10, 2018 at 9:22 PM, Pavan Deolasee
wrote:
> Ok. I will look at it. I think it shouldn't be too difficult and the
> original restriction was mostly a fallout of expecting CHECK constraint
> style expressions there.
Good, thanks.
> Ok. OVERRIDING is done. I think we can support ruleut
On Sat, Mar 10, 2018 at 12:11 AM, Claudio Freire
wrote:
> On Fri, Mar 9, 2018 at 2:54 PM, Pavan Deolasee
> wrote:
> >
> >
>
> >
> > So yes, the benefits of the patch go down with higher number of clients,
> but
> > it does not entirely vanish.
>
> What if you implement my suggestion?
>
> That sh
On Sun, Mar 11, 2018 at 9:27 AM, Peter Geoghegan wrote:
>
> >>
> >> We're talking about the scantuple here. It's not like excluded.*.
>
> I often care about things like system columns not because of the
> user-visible functionality, but because it reassures me that the
> design is robust.
>
>
Ok.
On Fri, Mar 9, 2018 at 6:55 AM, Pavan Deolasee wrote:
>> * Is this actually needed at all?:
>>
>> > + /* In MERGE when and condition, no system column is allowed */
>> > + if (pstate->p_expr_kind == EXPR_KIND_MERGE_WHEN_AND &&
>> > + attnum < InvalidAttrNumber &&
>> > +
On 3/9/18 09:06, Magnus Hagander wrote:
> What platform does that actually work out of the box on? I have
> customers who actively want to use it (for compression, not security --
> replication across limited and metered links), and the amount of
> workarounds they have to put in place OS level to
On Sun, Mar 11, 2018 at 9:49 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Why does VACUUM FULL cause the size of this table with a single
>> dropped column (1 out of 1000) cause the table size to double?
>
> VACUUM FULL will rewrite the tuples with a null bitmap where they
> had none before (c
Andrew Dunstan writes:
> Why does VACUUM FULL cause the size of this table with a single
> dropped column (1 out of 1000) cause the table size to double?
VACUUM FULL will rewrite the tuples with a null bitmap where they
had none before (cf reform_and_rewrite_tuple). That's only a rather
marginal
On 03/05/2018 04:51 AM, David Rowley wrote:
> On 5 March 2018 at 04:54, Tomas Vondra wrote:
>> 1) There seems to be forgotten declaration of initArrayResultInternal in
>> arrayfuncs.c. I suppose you've renamed it to initArrayResultWithSize and
>> moved it to a header file, and forgotten to remov
The buildfarm's Windows members occasionally show weird pg_ctl failures,
for instance this recent case:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2018-03-10%2020%3A30%3A20
### Restarting node "master"
# Running: pg_ctl -D
G:/prog/bf/root/HEAD/pgsql.build/src/test/recov
While doing some testing I noticed this, which seems somewhat perverse:
create table t();
insert into t select from generate_series(1,1);
select 'alter table t ' || string_agg(' add column c'||x::text||' int
default ' ||x::text,',')
from generate_series(1,1000) x \gexec
create table t_dropped
OK, here is an updated patch fixing breakage caused by 5564c11815.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
0001-Keep-information-about-already-estimated-clauses.patch.gz
Description: application/g
I wrote:
> Whilst fooling about with predtest.c, I noticed a rather embarrassing
> error. Consider the following, rather silly, CHECK constraint:
> ...
> So, what to do? We have a few choices, none ideal:
I'd been assuming that we need to back-patch a fix for this, but after
further reflection,
On 03/10/2018 04:43 PM, legrand legrand wrote:
> +1
> Having the time of first occurence of a statement is very usefull
> for trouble shouting, it permits for exemple to retrieve the order of
> operations in some complex cases (and thoses informations aren't
> taken by any third party collecting
I just came across the following paper and project and thought I would
share:
It seems some incremental graph query extensions to SQL could add some
powerful capabilities to PostgreSQL (without having to think about a
complete query language replacement). The incremental change could include:
path
Hello,
Would the following custom solution:
- a pre-loaded table rows being sorted by id and ts
containing null values for other columns,
enough free space per block to permit updates in place,
- having a (btree or brin) index on (id,ts),
- loaded using UPDATEs in spite of INSERTs
On Sat, Mar 10, 2018 at 6:42 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Thu, Mar 8, 2018 at 2:49 AM, Tomas Vondra > wrote:
> Thank you very much for testing and benchmarking. I'll investigate
> the regressions you found.
>
>
>> Now, there's a caveat in those tests - the data
On Thu, Mar 8, 2018 at 2:49 AM, Tomas Vondra
wrote:
> OK, the revised patch works fine - I've done a lot of testing and
> benchmarking, and not a single segfault or any other crash.
>
> Regarding the benchmarks, I generally used queries of the form
>
> SELECT * FROM (SELECT * FROM t ORDER BY
+1
Having the time of first occurence of a statement is very usefull for
trouble shouting,
it permits for exemple to retrieve the order of operations in some complex
cases (and thoses informations aren't taken by any third party collecting
tool, that will only be able to provide a time range of occ
Hi,
I had a closer look at v3 of the patch now.
On Sat, Mar 03, 2018 at 07:23:31PM +0100, Magnus Hagander wrote:
> Attached is a rebased patch which removes this optimization, updates the
> pg_proc entry for the new format, and changes pg_verify_checksums to use -r
> instead of -o for relfilenode
On Fri, Mar 9, 2018 at 9:40 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Fri, Mar 9, 2018 at 3:12 PM, Masahiko Sawada
> wrote:
>
>> Attached an updated patch
>>
> fixed these issue. Will review the patch again.
>
>
> Thank you!
>
I've fixed a bug: _bt_vacuum_needs_cleanup() di
Hello.
Andrey, Tels - thanks for review.
> It could be named "SkipTuples" (e.g. this is the number of tuples we need
> to skip, not the number we have skipped), and the other one then
> "iss_SkipTuplesRemaining" so they are consistent with each other.
Agreed, done.
> Also, I think that this che
On 03/10/2018 02:08 PM, Mark Dilger wrote:
>
>> On Mar 3, 2018, at 2:40 PM, Tomas Vondra
>> wrote:
>>
>> An updated patch version, fixing the breakage caused by fd1a421fe6
>> twiddling with pg_proc.
>
> Hi Tomas, thanks again for this most useful patch!
>
> Perhaps this is intentional, but the
Hi,
I've looked at this patch today. I like the idea / intent in general, as
it helps with some investigation tasks. That being said, I have a couple
of questions/comments based on read through the patch:
1) I see you've renamed the .sql script from 1.4 to 1.6. I thought we've
abandoned that app
On 9 March 2018 at 14:17, Gasper Zejn wrote:
> On 09. 03. 2018 06:24, Craig Ringer wrote:
>
> I'm totally unconvinced by the threat posed by exploiting a client by
> tricking it into requesting protocol compression - or any other protocol
> change the client lib doesn't understand - with a connec
> On Mar 3, 2018, at 2:40 PM, Tomas Vondra wrote:
>
> An updated patch version, fixing the breakage caused by fd1a421fe6
> twiddling with pg_proc.
Hi Tomas, thanks again for this most useful patch!
Perhaps this is intentional, but there seems to be a place in
src/backend/parser/parse_utilcmd.
On Thu, Mar 8, 2018 at 4:55 PM, Amit Khandekar wrote:
> (Mail subject changed; original thread : [1])
>
> On 8 March 2018 at 11:57, Amit Khandekar wrote:
>>> Clearly, ExecUpdate() while moving rows between partitions is missing out on
>>> re-constructing the to-be-updated tuple, based on the late
Hi,
On Mon, Mar 05, 2018 at 11:09:02AM +0100, Magnus Hagander wrote:
> On Mon, Mar 5, 2018 at 10:43 AM, Michael Banck
> wrote:
> > I still find that confusing, but maybe it's just me. I thought the one
> > in the pageheader is the "expected" checksum, and we compare the "found"
> > or "computed/c
On 02/26/2018 07:23 AM, Michael Paquier wrote:
> On Mon, Feb 26, 2018 at 12:45:48AM -0500, Tom Lane wrote:
>> Michael Paquier writes:
>>> On Sat, Feb 24, 2018 at 10:21:44PM -0500, Tom Lane wrote:
We've discussed that at least twice before, and not pulled the trigger
for fear of breakin
On Fri, Mar 9, 2018 at 3:18 PM, amul sul wrote:
> On Thu, Mar 8, 2018 at 12:31 PM, Amit Kapila wrote:
>> On Thu, Mar 8, 2018 at 11:04 AM, Pavan Deolasee
>>
>>> This is just one example. I am almost certain there are many such cases that
>>> will require careful attention.
>>>
>>
>> Right, I think
Hello
My patch does not apply after commit 5748f3a0aa7cf78ac6979010273bd9d50869bb8e.
Here is update to current master. Not null constraint is immutable too, so here
is no changes in PartConstraintImpliedByRelConstraint excepts rename and
comments fix.
In this patch version i also revert tests t
On Fri, Mar 09, 2018 at 04:55:38PM +0900, Michael Paquier wrote:
> --- a/src/backend/catalog/information_schema.sql
> +++ b/src/backend/catalog/information_schema.sql
> @@ -186,7 +186,7 @@ CREATE FUNCTION _pg_interval_type(typid oid, mod int4)
> RETURNS text
> AS
> $$SELECT
>CASE WHEN $1
On Fri, Mar 09, 2018 at 09:35:22AM -0500, David Steele wrote:
> These look sane to me. Did you check the back branches for anything
> that might not exist in HEAD?
I did, but I have not spotted anything extra. Impossible to say that I
did not miss one though, such scanning is tiring.
--
Michael
34 matches
Mail list logo
