On 10/31/18, Robert Haas wrote:
> It seems important to me that before anybody thinks
> about committing this, we construct some kind of destruction case
> where repeated scans of the whole table are triggered as frequently as
> possible, and then run that test with varying thresholds. I might be
On 1 November 2018 at 22:39, Amit Langote wrote:
> On 2018/11/01 10:30, David Rowley wrote:
>> It's great to know the patch is now so perfect that we've only the
>> macro naming left to debate ;-)
>
> I looked over v12 again and noticed a couple minor issues.
>
> + * table then we sto
The patch attached add additional option for multi values insert statement
with a default values of 100 row per statement so the row lose during error
is at most 100 rather than entire table.
Patch does not seem to apply anymore, could you rebase?
--
Fabien.
Hello Peter,
Attached is a rebased patch set. No functionality changes.
Patch applies cleanly, compile, global make check ok, doc gen ok.
Shouldn't psql tab completion be updated as well?
About the code:
I must admit that do not like much the three global variables &
Save/Restore functio
> On Sun, 1 Apr 2018 at 19:58, Yura Sokolov wrote:
>
> I didn't change serialized format. Therefore is no need to change
> SerializeSnapshot.
> But in-memory representation were changed, so RestoreSnapshot is changed.
This patch went through the last tree commit fests without any noticeable
activ
> On Mon, 9 Apr 2018 at 14:16, Ashutosh Bapat
> wrote:
>
> On Mon, Apr 9, 2018 at 5:34 PM, Kyotaro HORIGUCHI
> wrote:
> >
> > The new code doesn't seem to work as written.
> >
> >> arg = eval_const_expressions_mutator((Node *) cre->arg,
> >>context);
> >
>On Sun, 15 Apr 2018 at 09:09, Sergei Kornilov wrote:
>
> Attached updated patch follows recent Reorganize partitioning code commit.
> regards, Sergei
This patch went through the last tree commit fests without any noticeable
activity, but cfbot says it still applies and doesn't break any tests. T
I wouldn't mind if this page:
https://www.postgresql.org/community/contributors/
contained a link to (contributors v11):
https://www.postgresql.org/docs/11/static/release-11.html#id-1.11.6.5.6
and to (contributors v10)
https://www.postgresql.org/docs/current/static/release-11.html#id-1.
> "Dmitry" == Dmitry Dolgov <9erthali...@gmail.com> writes:
Dmitry> This patch went through the last tree commit fests without any
Dmitry> noticeable activity, but cfbot says it still applies and
Dmitry> doesn't break any tests. The patch itself is rather small, and
Dmitry> I could reprodu
> On Sun, 4 Nov 2018 at 15:48, Andrew Gierth
> wrote:
>
> > "Dmitry" == Dmitry Dolgov <9erthali...@gmail.com> writes:
>
> Dmitry> This patch went through the last tree commit fests without any
> Dmitry> noticeable activity, but cfbot says it still applies and
> Dmitry> doesn't break any te
Pavel Stehule writes:
> so 3. 11. 2018 v 22:47 odesílatel Tom Lane napsal:
>> So while looking at that ... isn't the behavior for non-writable output
>> parameters basically insane? It certainly fails to accord with the
>> plpgsql documentation, which shows an example that would throw an error:
ne 4. 11. 2018 v 16:54 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > so 3. 11. 2018 v 22:47 odesílatel Tom Lane napsal:
> >> So while looking at that ... isn't the behavior for non-writable output
> >> parameters basically insane? It certainly fails to accord with the
> >> plpgsql do
Pavel Stehule writes:
> ne 4. 11. 2018 v 16:54 odesilatel Tom Lane napsal:
>> In short, I think it's a bug that we allow the above. If you
>> want to keep the must-be-a-variable error then it should apply in
>> this case too.
> I agree. This should be prohibited from PLpgSQL.
OK. In that case
On 04.11.2018 9:31, Peter Geoghegan wrote:
On Sat, Nov 3, 2018 at 8:52 PM Andrey Lepikhov
wrote:
I applied your patches at top of master. After tests corrections
(related to TID ordering in index relations DROP...CASCADE operation)
'make check-world' passed successfully many times.
In the ca
ne 4. 11. 2018 v 17:14 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > ne 4. 11. 2018 v 16:54 odesilatel Tom Lane napsal:
> >> In short, I think it's a bug that we allow the above. If you
> >> want to keep the must-be-a-variable error then it should apply in
> >> this case too.
>
> > I
Pavel Stehule writes:
> I am not sure how safe is read argmodes from syscache after procedure
> execution. Theoretically, the procedure pg_proc tuple can be modified from
> procedure, and can be committed from procedure. Isn't better to safe
> argmodes before execution?
Hm. That would mean throw
Le ven. 2 nov. 2018 à 08:37, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> a écrit :
> On 26/10/2018 15:53, Jean-Christophe Arnu wrote:
> > Exemple on CREATE DATABASE (without defining a template database) :
> > rmgr: Databaselen (rec/tot): 42/42, tx:568, lsn:
> > 0/0186
On 04.11.18 02:53, LAM JUN RONG wrote:
Hi,
I have made some changes based on Andreas’ suggestions.
> + then one or more of the packages
PostgreSQL requires is not installed.
> + See for the required
packages.
>
> How about:
> then packages which are required to build
> PostgreS
Hello
> This patch went through the last tree commit fests without any noticeable
> activity
Well, last two CF. During march commitfest patch has activity and was marked as
ready for committer. But at end of july CF was no further activity and patch
was reverted back to "need review" with reaso
On Sun, Nov 4, 2018 at 8:21 AM Andrey Lepikhov
wrote:
> I mean that your code have not any problems that I can detect by
> regression tests and by the retail index tuple deletion patch.
> Difference in amount of dropped objects is not a problem. It is caused
> by pos 2293 - 'else if (thisobj->obje
I wrote:
> BTW, it looks to me like ExecuteCallStmt trashes the passed-in CallStmt
> in cases where expand_function_arguments is not a no-op. Is that
> really safe? Seems to me it'd cause problems if, for example, dealing
> with a CallStmt that's part of a prepared stmt or cached plan.
I dug int
On Mon, Oct 29, 2018 at 04:18:23PM +0100, Vik Fearing wrote:
> A use case that I see quite a lot of is needing to do reports and other
> calculations on data per day/hour/etc but in the user's time zone. The
> way to do that is fairly trivial, but it's not obvious what it does so
> reading queries
On 1 November 2018 at 22:05, Antonin Houska wrote:
> I think these conditions are too restrictive:
>
> /*
> * Determine if these pathkeys match the partition order, or reverse
> * partition order. It can't match both, so only go to the trouble of
> * checking th
Hi folks,
I had a crack at this, and it was pretty simple to get something working to
play around with, and it seems like it might be useful.
I developed it against 10.1, as that's what I happened to be working with at
the time. The patch is pretty small, and I hoped it would apply cleanly
agains
denty wrote
> (Seems I can't attach via the web interface, so copy/paste patch below.)
>
> --
> Sent from:
> http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
Sending attachments from this web site (that is not an official postgres
website)
has been disabled as requested by postg
On Fri, Nov 02, 2018 at 04:39:07PM +0900, Amit Langote wrote:
> Agreed that they're two independent issues, although it wouldn't be such a
> bad idea to fix them in one go, as they're both issues related to the
> handling of ON COMMIT actions on tables in inheritance trees.
I have pushed 0001 whic
I happened to notice that the pg_opfamily entry with OID 4035
(jsonb_ops for GIST) is not referenced anywhere; apparently it
was put in in anticipation of support that never materialized.
We still pass make check-world if it's removed.
Getting rid of it seems like a no-brainer, but it surprised me
On Sun, Nov 04, 2018 at 08:02:25PM -0500, Tom Lane wrote:
> We should, therefore, at least add an oprsanity check for
> opfamilies without opclasses. I wonder how far it's worth
> going to check for other orphaned catalog entries.
+1.
--
Michael
signature.asc
Description: PGP signature
On Wed, Oct 17, 2018 at 03:05:28PM -0400, Stephen Frost wrote:
> The point of it is that it makes loading into other RDBMS faster. Yes,
> it has many of the same issues as our COPY does, but we support it
> because it's much faster. The same is true here, just for other
> databases, so I'm +1 on
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Wed, Oct 17, 2018 at 03:05:28PM -0400, Stephen Frost wrote:
> > The point of it is that it makes loading into other RDBMS faster. Yes,
> > it has many of the same issues as our COPY does, but we support it
> > because it's much faster
On Sat, Nov 3, 2018 at 9:30 AM Amit Kapila wrote:
> On Fri, Nov 2, 2018 at 6:41 PM Tomas Vondra
> wrote:
> > I'm sure
> > it's not the only place where we do something like this, and the other
> > places don't trigger the valgrind warning, so how do those places do
> > this? heapam seems to call
Thank Tom!
We will check it.
On Fri, Nov 2, 2018 at 10:35 PM Tom Lane wrote:
> Haozhou Wang writes:
> > We meet a corner case that related to the behavior of Vacuum Full.
> > ...
> > If we run both sql scripts on same database in parallel, the "VACUUM FULL
> > a;" will not release the disk spac
On 2018/11/05 9:19, Michael Paquier wrote:
> On Fri, Nov 02, 2018 at 04:39:07PM +0900, Amit Langote wrote:
>> Agreed that they're two independent issues, although it wouldn't be such a
>> bad idea to fix them in one go, as they're both issues related to the
>> handling of ON COMMIT actions on table
Hi,
On 2018/11/03 17:28, Vincent Mirian wrote:
> Hi Amit,
>
> Thank you for your response. Chapters 51, 57 and 59 (Overview of PostgreSQL
> Internals, Writing A Foreign Data Wrapper and Writing A Custom Scan
> Provider) seem to be relevant. Aside from the source code snippets in the
> document, i
On Mon, Nov 5, 2018 at 5:49 AM Michael Paquier wrote:
> On Fri, Nov 02, 2018 at 04:39:07PM +0900, Amit Langote wrote:
> > Agreed that they're two independent issues, although it wouldn't be such
> a
> > bad idea to fix them in one go, as they're both issues related to the
> > handling of ON COMMI
Hi,
Michael pointed out a problem with specifying different ON COMMIT actions
on a temporary inheritance parent and its children:
https://www.postgresql.org/message-id/20181102051804.GV1727%40paquier.xyz
The problem is that when PreCommit_on_commit_actions() executes an ON
COMMIT DROP action on
On Fri, Nov 2, 2018 at 7:42 PM Alvaro Herrera
wrote:
> Here's a patch to allow partitioned tables to be referenced by foreign
> keys. Current state is WIP, but everything should work; see below for
> the expected exception.
>
> The design is very simple: have one pg_constraint row for each parti
During make --silent, I occasionally see these lines:
Writing postgres.bki
Writing schemapg.h
Writing postgres.description
Writing postgres.shdescription
I can't seem to find where these lines are being output, perhaps from a
Perl library. I would like to suppress
Bruce Momjian writes:
> During make --silent, I occasionally see these lines:
> Writing postgres.bki
> Writing schemapg.h
> Writing postgres.description
> Writing postgres.shdescription
> I can't seem to find where these lines are being output, perhaps from a
> Perl librar
On 11/5/18, Bruce Momjian wrote:
> During make --silent, I occasionally see these lines:
>
> Writing postgres.bki
> Writing schemapg.h
> Writing postgres.description
> Writing postgres.shdescription
>
> I can't seem to find where these lines are being output, perhaps from a
On 2018/11/04 4:58, Pavel Stehule wrote:
> here is a patch
Thank you, Pavel.
Here are some comments.
I mentioned it during the last review, but maybe you missed it due to the
other discussion.
+the pattern are listed. If the form \dP+
+is used, a sum of size of related partitio
On Mon, Nov 5, 2018 at 01:01:47PM +0700, John Naylor wrote:
> On 11/5/18, Bruce Momjian wrote:
> > During make --silent, I occasionally see these lines:
> >
> > Writing postgres.bki
> > Writing schemapg.h
> > Writing postgres.description
> > Writing postgres.shdescription
> >
> >
On 2018/11/04 19:07, David Rowley wrote:
> On 1 November 2018 at 22:39, Amit Langote
> wrote:
> I've attached v13 which hopefully addresses these.
Thank you for updating the patch.
>> The macro naming discussion got me thinking today about the macro itself.
>> It encapsulates access to the vari
On Thu, Nov 01, 2018 at 01:03:00PM +0900, Amit Langote wrote:
> Done a few moments ago. :)
From the file size this move is actually negative. From what I can see
partcache decreases to 400 lines, while partbounds increases to 3k
lines.
There are a couple of things that this patch is doing:
1) Mo
On Tue, Sep 25, 2018 at 06:22:19PM +1200, Thomas Munro wrote:
> On Sat, Sep 22, 2018 at 4:52 PM Amit Kapila wrote:
>> I went through and check the original proposal [1] to see if any use
>> case is mentioned there, but nothing related has been discussed. I
>> couldn't think of much use of this f
On Wed, Oct 31, 2018 at 05:44:26PM +0100, Fabien COELHO wrote:
> Patch v4 applies cleanly, compiles, doc generation ok, global & local tests
> ok.
+# also fails for -r and -t, but it seems pointless to add more tests
for those.
+command_fails_like(
+ [ 'pg_dumpall', '--exclude-database=foo',
46 matches
Mail list logo
