On 2019-12-04 11:30, Peter Eisentraut wrote:
On 2019-12-03 06:03, Tom Lane wrote:
Peter Eisentraut writes:
Currently, configure puts the configure args into the makefiles and
then have the makefiles pass them to the build of pg_config. That looks
like an unnecessary redirection, and indeed
On Sun, Dec 22, 2019 at 1:03 AM Tomas Vondra
wrote:
>
> On Sat, Dec 21, 2019 at 04:25:05PM -0500, Tom Lane wrote:
> >Nikolay Samokhvalov writes:
> >> Here is what ORMs do:
> >> select length('SELECT "column_name_1001", "column_name_1002",
> >> "column_name_1003", "column_name_1004",
Forking thread "WAL logging problem in 9.4.3?" for this tangent:
On Mon, Dec 09, 2019 at 06:04:06PM +0900, Kyotaro Horiguchi wrote:
> I don't understand why mdclose checks for (v->mdfd_vfd >= 0) of open
> segment but anyway mdimmedsync is believing that that won't happen and
> I follow the
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, failed
Spec compliant: not tested
Documentation:tested, failed
Hi Pavel,
First of all, I would like to congratulate you for
On Mon, Dec 2, 2019 at 2:02 PM Dilip Kumar wrote:
>
> On Sun, Dec 1, 2019 at 7:58 AM Michael Paquier wrote:
> >
> > On Fri, Nov 22, 2019 at 01:18:11PM +0530, Dilip Kumar wrote:
> > > I have rebased the patch on the latest head and also fix the issue of
> > > "concurrent abort handling of the
SELECT statement that is not IMMUTABLE must not be specified when creating
a view.
An expression SELECT statement that is not IMMUTABLE must not be specified
when creating a view.
In the current implementation, a SELECT statement containing an expression
that is not IMMUTABLE can be specified
On Wed, 27 Nov 2019 at 17:09, Tom Lane wrote:
> Good idea, but I think you need to account for "visible" (ie, if the
> newline is inside RL_PROMPT_START_IGNORE, it shouldn't change the width).
> It might be best to add logic inside the existing "if (visible)" instead
> of making a new top-level
Hi all,
I am not aware enough in the Postgres internals to give advice about the
implementation.
But my feeling is that there is another big interest for this feature: simplify
the Oracle to PostgreSQL migration of applications that use global termporary
tables. And this is quite common when
On Sat, 2019-12-14 at 18:32 +0100, Tomas Vondra wrote:
> So I think we're not costing the batching properly / at all.
Thank you for all of the testing! I think the results are good: even
for cases where HashAgg is the wrong choice, it's not too bad. You're
right that costing is not done, and when
I wrote:
> Now as far as point 1 goes, I think it's not really that awful to use
> CheckAttributeType() with a dummy attribute name. The attached
> incomplete patch uses "partition key" which causes it to emit errors
> like
> regression=# create table fool (a int, b int) partition by list
I noticed a buildfarm failure here:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skate=2019-12-22%2007%3A49%3A22
== pgsql.build/src/test/regress/regression.diffs
==
***
Hi
ne 22. 12. 2019 v 13:04 odesÃlatel Philippe BEAUDOIN
napsal:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, failed
> Spec compliant: not tested
> Documentation:
On Mon, Dec 23, 2019 at 09:33:29AM +1300, Thomas Munro wrote:
> On Sun, Dec 22, 2019 at 10:19 PM Noah Misch wrote:
> > Assert(segno == reln->md_num_open_segs[forknum]);
> > _fdvec_resize(reln, forknum, segno + 1);
>
> Oh yeah, I spotted that part too but didn't follow up.
>
>
On Tue, 2019-12-10 at 13:34 -0800, Adam Lee wrote:
> Melanie and I tried this, had a installcheck passed patch. The way
> how
> we verify it is composing a wide table with long unnecessary text
> columns, then check the size it writes on every iteration.
>
> Please check out the attachment, it's
From: Tatsuo Ishii
> > The following IVM wiki page returns an error. Does anybody know what's
> wrong?
> >
> > https://wiki.postgresql.org/wiki/Incremental_View_Maintenance
>
> I don't have any problem with the page. Maybe temporary error?
Yeah, I can see it now. I could see it on the
From: legrand legrand
> For each insert into a base table there are 3 statements:
> - ANALYZE pg_temp_3.pg_temp_81976
> - WITH updt AS ( UPDATE public.mv1 AS mv SET __ivm_count__ = ...
> - DROP TABLE pg_temp_3.pg_temp_81976
Does it also include CREATE TEMPORARY TABLE, because there's DROP?
I
On Wed, Dec 04, 2019 at 09:54:47AM -0800, Andres Freund wrote:
> Well, _Static_assert has an error message, so we got to pass
> something. And having something like "array length mismatch", without
> referring again to the variable, doesn't strike me as that bad. We could
> of course just again
Michael Paquier writes:
> On Sun, Dec 22, 2019 at 07:24:09PM -0500, Tom Lane wrote:
>> This test is passing in the newer branches --- evidently due to
>> the 9.5-era commit 1a629c1b1, which removed this TAP script's
>> dependency on "rm -rf". So we should either back-patch that
>> commit into
On Sun, 22 Dec 2019 20:54:41 +0900
nuko yokohama wrote:
> SELECT statement that is not IMMUTABLE must not be specified when creating
> a view.
>
> An expression SELECT statement that is not IMMUTABLE must not be specified
> when creating a view.
>
> In the current implementation, a SELECT
Buildfarm member drongo has been failing the initdb TAP test in the
9.4 branch for the last week or two:
# Running: rm -rf
'C:\prog\bf\root\REL9_4_STABLE\pgsql.build\src\bin\initdb\tmp_check\tmp_testAHN7'/*
'rm' is not recognized as an internal or external command,
operable program or batch
> Could you give some concrete use cases, so that I can have a clearer image of
> the target data? In the discussion, someone referred to master data with low
> update frequency, because the proposed IVM implementation adds triggers on
> source tables, which limits the applicability to
On Thu, Dec 19, 2019 at 07:26:19PM +0100, Peter Eisentraut wrote:
> macOS does not support the socket option TCP_USER_TIMEOUT. Yet, I can start
> a server with postgres -D ... --tcp-user-timeout=100 without a diagnostic.
> Only when I connect I get a log entry
>
> LOG:
On Fri, Dec 20, 2019 at 9:14 PM Robert Haas wrote:
> On Fri, Dec 20, 2019 at 8:24 AM Suraj Kharage
> wrote:
> > Thank you for review comments.
>
> Thanks for the new version.
>
> + --verify-backup
>
> Whitespace.
>
> +struct manifesthash_hash *hashtab;
>
> Uh, I had it in mind that you
Hi all,
I was working on some stuff for table AMs, and I got to wonder it we
had better rename amapi.h to indexam.h and amapi.c to indexam.c, so as
things are more consistent with table AM. It is a bit annoying to
name the files dedicated to index AMs with what looks like now a too
generic name.
On Tue, Nov 19, 2019 at 01:34:21PM -0600, Justin Pryzby wrote:
> Tom implemented "Planner support functions":
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a391ff3c3d418e404a2c6e4ff0865a107752827b
> https://www.postgresql.org/docs/12/xfunc-optimization.html
>
> I wondered
On Sun, Dec 22, 2019 at 07:24:09PM -0500, Tom Lane wrote:
> This test is passing in the newer branches --- evidently due to
> the 9.5-era commit 1a629c1b1, which removed this TAP script's
> dependency on "rm -rf". So we should either back-patch that
> commit into 9.4 or undo whatever
On Sun, Dec 22, 2019 at 07:57:34PM -0500, Tom Lane wrote:
> Michael Paquier writes:
>> On Sun, Dec 22, 2019 at 07:24:09PM -0500, Tom Lane wrote:
>>> This test is passing in the newer branches --- evidently due to
>>> the 9.5-era commit 1a629c1b1, which removed this TAP script's
>>> dependency on
On Fri, Dec 20, 2019 at 11:14:28AM +0100, Jehan-Guillaume de Rorthais wrote:
> Yes, that would be great but sadly, it would introduce a regression on various
> tools relying on them. At least, the one doing "select *" or most
> probably "select func()".
>
> But anyway, adding 5 funcs is not a big
On Sun, Dec 22, 2019 at 01:19:30AM -0800, Noah Misch wrote:
> I am inclined to fix this by decrementing md_num_open_segs before modifying
> md_seg_fds (second attachment).
That leaked memory, since _fdvec_resize() assumes md_num_open_segs is also the
allocated array length. The alternative is
Hello,
First of all many thanks for this Great feature
replacing so many triggers by a so simple syntax ;o)
I was wondering about performances and add a look
at pg_stat_statements (with track=all) with IVM_v9.patch.
For each insert into a base table there are 3 statements:
- ANALYZE
On Sun, Dec 22, 2019 at 10:19 PM Noah Misch wrote:
> Assert(segno == reln->md_num_open_segs[forknum]);
> _fdvec_resize(reln, forknum, segno + 1);
Oh yeah, I spotted that part too but didn't follow up.
On Mon, Dec 23, 2019 at 7:51 AM Yugo Nagata wrote:
>
> On Mon, 23 Dec 2019 02:26:09 +
> "tsunakawa.ta...@fujitsu.com" wrote:
>
> > From: legrand legrand
> > > For each insert into a base table there are 3 statements:
> > > - ANALYZE pg_temp_3.pg_temp_81976
> > > - WITH updt AS ( UPDATE
On Fri, 20 Dec 2019 at 17:17, Prabhat Sahu
wrote:
>
> Hi,
>
> While testing this feature with parallel vacuum on "TEMPORARY TABLE", I got a
> server crash on PG Head+V36_patch.
> Changed configuration parameters and Stack trace are as below:
>
> autovacuum = on
> max_worker_processes = 4
>
From: Tatsuo Ishii
> the target data? In the discussion, someone referred to master data with low
> update frequency, because the proposed IVM implementation adds triggers on
> source tables, which limits the applicability to update-heavy tables.
>
> But if you want to get always up-to-data you
On Mon, 23 Dec 2019 02:26:09 +
"tsunakawa.ta...@fujitsu.com" wrote:
> From: legrand legrand
> > For each insert into a base table there are 3 statements:
> > - ANALYZE pg_temp_3.pg_temp_81976
> > - WITH updt AS ( UPDATE public.mv1 AS mv SET __ivm_count__ = ...
> > - DROP TABLE
35 matches
Mail list logo
