On 2019-07-25 16:33, Daniel Gustafsson wrote:
> Fair enough, those are both excellent points. I’ve shuffled the code around
> to
> move back the check for exec_path to setup (albeit earlier than before due to
> where we perform directory checking). This does mean that the directory
> checking in
On Thu, Jul 25, 2019 at 10:39:36AM +0900, Kyotaro Horiguchi wrote:
> No substantial change have been made by this rebasing.
Thanks. I'll likely review this on 2019-08-20. If someone opts to review it
earlier, I welcome that.
On 2019-07-25 17:09, Rafia Sabih wrote:
> But on the other hand emitting the right error message atleast would
> be good for the sake of correctness if nothing else. But yes that
> definitely should be weighed against what is the effort required for
> this.
I think if you want to make this more ro
On Sat, Jul 27, 2019 at 8:29 AM Thomas Munro wrote:
>
> On Fri, Jul 26, 2019 at 4:13 PM Amit Kapila wrote:
> > On Tue, Jul 23, 2019 at 5:28 PM Amit Kapila wrote:
> > > Right, that will be lesser code churn and it can also work. However,
> > > one thing that needs some thought is till now es_top
pá 26. 7. 2019 v 22:53 odesílatel Tom Lane napsal:
> I wrote:
> > TBH, I don't like this proposal one bit. As far as I can see, the idea
> > is to let a function's support function redefine the function's declared
> > argument and result types on-the-fly according to no predetermined rules,
> >
pá 26. 7. 2019 v 22:03 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > so 9. 3. 2019 v 7:22 odesílatel Pavel Stehule
> > napsal:
> >> Tom introduced supported functions for calculation function's
> selectivity.
> >> Still I have similar idea to use supported function for calculation
> >
On Fri, Jun 7, 2019 at 12:13 PM Tom Lane wrote:
> didier writes:
> > c.h defines a C Min macro conflicting with llvm new class
> > llvm:ElementCount Min member
>
> Really? Well, we will hardly be the only code they broke with that.
> I think we can just wait for them to reconsider.
FYI This is
On Fri, Jul 26, 2019 at 4:13 PM Amit Kapila wrote:
> On Tue, Jul 23, 2019 at 5:28 PM Amit Kapila wrote:
> > Right, that will be lesser code churn and it can also work. However,
> > one thing that needs some thought is till now es_top_eflags is only
> > set in ExecutorStart and same is mentioned
Hi,
On 2019-07-25 17:51:33 +1200, Thomas Munro wrote:
> 1. WAL's use of fdatasync(): The reason we fill and then fsync()
> newly created WAL files up front is because we want to make sure the
> blocks are definitely on disk. The comment doesn't spell out exactly
> why the author considered late
On Fri, Jul 26, 2019 at 6:58 PM Peter Geoghegan wrote:
> I found this part of your approach confusing:
>
> > + /*
> > +* Number of bits in subnet. e.g. An IPv4 that's /24 is 32 - 24 = 8.
> > +*
> > +* However, only some of the bits may have made it into the fixed sized
> > +* dat
On Fri, Feb 8, 2019 at 10:20 AM Brandur Leach wrote:
> Attached a V2 patch: identical to V1 except rebased and
> with a new OID selected.
Attached is a revised version that I came up with, based on your v2.
I found this part of your approach confusing:
> + /*
> +* Number of bits in subnet
Hi,
When specifying a config a PGC_POSTMASTER variable on the commandline
(i.e. -c something=other) the config processing blurts a wrong warning
about not being able to change that value. E.g. when specifying
shared_buffers via -c, I get:
2019-07-26 16:28:04.795 PDT [14464][] LOG: 0: receive
Hi,
Petr, Simon, see the potential issue related to fast forward at the
bottom.
On 2019-07-26 18:46:35 -0400, Alvaro Herrera wrote:
> On 2019-Jul-09, Masahiko Sawada wrote:
>
> > I think the cause of this bug would be that a ReorderBufferTXN entry
> > of sub transaction is created as top-level t
Hi Kyotaro,
Thank you so much for your valued feedback and suggestions!
> I assume that we are in a consensus about the problem we are to fix here.
>
> > 0a 0004`8080cc30 0004`80dcf917 postgres!PGSemaphoreLock+0x65
> > [d:\orcasqlagsea10\14\s\src\backend\port\win32_sema.c @ 158] 0b
>
Andres Freund writes:
> On 2019-07-26 18:05:38 -0400, Alvaro Herrera wrote:
>> Hello, is anybody looking into this issue?
> I guess this is on Robert's docket otherwise. He's on vacation till
> early next week...
I think this is a sufficiently obvious bug, and a sufficiently
obvious fix, that we
=?UTF-8?Q?Filip_Rembia=C5=82kowski?= writes:
> Still no hash table fallback is implemented, so this is *not* a
> performance improvement. Only a little more flexibility.
I think that we'd probably be better off fixing the root performance issue
than adding semantic complexity to bypass it. Espec
Hi,
On 2019-07-26 18:05:38 -0400, Alvaro Herrera wrote:
> On 2019-Jul-04, Rui Hai Jiang wrote:
>
> > I'll try to figure out some scenarios to do the test. A parallel process
> > group is needed for the test.
Rui, have you made any progress on this?
> > Actually I was trying to do some testing
On 2019-Jul-09, Masahiko Sawada wrote:
> I think the cause of this bug would be that a ReorderBufferTXN entry
> of sub transaction is created as top-level transaction. And this
> happens because we skip to decode ASSIGNMENT during the state of
> snapshot builder < SNAPBUILD_FULL.
That explanation
On 2019-Jul-03, Amit Langote wrote:
> Thanks for the report. This seems like a bug. Documentation claims
> that the child tables inherit column storage options from the parent
> table. That's actually enforced in only some cases.
> To fix this, MergeAttributesIntoExisting() should check that t
On 2019-Jul-04, Rui Hai Jiang wrote:
> I'll try to figure out some scenarios to do the test. A parallel process
> group is needed for the test.
>
> Actually I was trying to do some testing against the locking mechanism. I
> happened to see this issue.
Hello, is anybody looking into this issue?
On Fri, Jul 26, 2019 at 07:03:41AM +, Jamison, Kirk wrote:
On Sat, July 20, 2019 8:12 AM (GMT+9), Tomas Vondra wrote:
>+ /* XXX What if the target is set to 0? Reset the statistic?
*/
>
>This also makes me wonder. I haven't looked deeply into the code, but
>since 0 is a valid valu
On 2019-Jul-25, Michael Paquier wrote:
> On Wed, Jul 24, 2019 at 11:23:30AM -0400, Alvaro Herrera wrote:
> > Heh, yesterday I revised the original patch as attached and was about to
> > push when the bell rang. I like this one because it keeps the comment
> > to one line and it mentions the funct
On Wed, Jul 24, 2019 at 11:01 PM Thomas Munro wrote:
>
> On Thu, Jul 25, 2019 at 2:39 AM Merlin Moncure wrote:
> > Server is generally running pretty well, and is high volume. This
> > query is not new and is also medium volume. Database rebooted in
> > about 4 seconds with no damage; fast enou
I wrote:
> TBH, I don't like this proposal one bit. As far as I can see, the idea
> is to let a function's support function redefine the function's declared
> argument and result types on-the-fly according to no predetermined rules,
> and that seems to me like it's a recipe for disaster. How will
Attached v3 fixes strcasecmp non portability on windows, per postgresql
patch tester.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 816f9cc4c7..3e8e292e39 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -306,6 +306,
Hi Konstantin,
I've started reviewing this patch and experimenting with it, so let me
share some initial thoughts.
1) not handling session state (yet)
I understand handling session state would mean additional complexity, so
I'm OK with not having it in v1. That being said, I think this is the
Pavel Stehule writes:
> so 9. 3. 2019 v 7:22 odesílatel Pavel Stehule
> napsal:
>> Tom introduced supported functions for calculation function's selectivity.
>> Still I have similar idea to use supported function for calculation
>> function's parameter's types and function return type.
>> Motivat
Thomas Munro wrote:
> This doesn't apply -- to attract reviewers, could we please have a rebase?
To help the review go forward, I have rebased the patch on 27cd521e6e.
It passes `make check` for me, but that's as far as I've verified the
correctness.
I squashed the changes into a single patch, so
Fabien COELHO writes:
>> |...] So I'll mark this ready for committer.
> Ok, thanks for the review.
LGTM, pushed.
regards, tom lane
I wrote:
> * It would be useful for the commentary to point out that in principle we
> could pull up any immutable (or, probably, even just stable) expression;
> but we don't, (a) for fear of multiple evaluations of the result costing
> us more than we can save, and (b) because a primary goal is to
Anastasia Lubennikova writes:
> New version is in attachments.
I took a quick look at this and I have a couple of gripes ---
* The naming and documentation of transform_const_function_to_result
seem pretty off-point to me. ISTM the real goal of that function is to
pull up constant values from R
On 7/1/19 5:20 PM, Alexey Kondratov wrote:
Hi Thomas,
On 01.07.2019 15:02, Thomas Munro wrote:
Hi Alexey,
This no longer applies. Since the Commitfest is starting now, could
you please rebase it?
Thank you for a reminder. Rebased version of the patch is attached.
I've also modified my log
I attached a patch to apply after your latest patch [2] with my
suggested changes to the docs. I tried to make things read smoother
without altering your meaning. I don't think the connection pooler
chapter fits in The SQL Language section, it seems more like Server
Admin functionality so I
On Fri, 26 Jul 2019 at 12:25, Amit Kapila wrote:
> I agree with all your other comments.
Thanks for addressing the comments. Below is the continuation of my
comments from 0014-Allow-execution-and-discard-of-undo-by-background-wo.patch
:
+ * Perform rollback request. We need to connect to the d
On Fri, 26 Jul 2019 10:02:58 +0200
Jehan-Guillaume de Rorthais wrote:
> On Fri, 26 Jul 2019 16:49:53 +0900 (Tokyo Standard Time)
> Kyotaro Horiguchi wrote:
[...]
> > We have an LSN reporting function each for several objectives.
> >
> > pg_current_wal_lsn
> > pg_current_wal_insert_lsn
> > pg
> I attached new version of the patch with fixed indentation problems and
> Win32 specific fixes.
Great, this latest patch applies cleanly to master. installcheck world
still passes.
> "connections_proxies" is used mostly to toggle connection pooling.
> Using more than 1 proxy is be needed only
FETCH_COUNT does not work with combined queries, and probably has never
worked since 2006.
For the record, this bug has already been reported & discussed by Daniel
Vérité a few months back, see:
https://www.postgresql.org/message-id/flat/a0a854b6-563c-4a11-bf1c-d6c6f924004d%40manitou-mail.o
On Fri, Jul 26, 2019 at 10:57 AM Jonathan S. Katz wrote:
>
> Hi,
>
> Before my reply, I wanted to say that I've been lurking on this thread
> for a bit as I've tried to better inform myself on encryption at rest
> and how it will apply to what we want to build. I actually built a
> (poor) prototyp
23.07.2019 14:36, Anastasia Lubennikova :
08.07.2019 4:18, Thomas Munro:
The July Commitfest is here. Could we please have a rebase of this
patch?
Updated patch is in attachments.
I've only resolved one small cosmetic merge conflict.
Later this week I'm going to send a more thoughtful review.
On 7/23/19 6:48 PM, Nikita Glukhov wrote:
> Some concrete pieces of review:
>> +
>> +FF1
>> +decisecond (0-9)
>> +
>>
>> Let's not use such weird terms as "deciseconds". We could say
>> "fractional seconds, 1 digit" etc. or something like that.
> And what about "ten
On 7/24/19 4:25 PM, Peter Eisentraut wrote:
> On 2019-07-24 00:48, Nikita Glukhov wrote:
>> It seems that our YY works like RR should:
>>
>> SELECT to_date('69', 'YY');
>> to_date
>>
>> 2069-01-01
>> (1 row)
>>
>> SELECT to_date('70', 'YY');
>> to_date
>>
>>
On 7/10/19 9:38 AM, Alvaro Herrera wrote:
> On 2019-Apr-11, Iwata, Aya wrote:
>
>> In the above document, why not write a description after the function name?
>> I think it is better to write the function name first and then the
>> description.
>> In your code;
>> #Checks if all the tests passe
The patch requires to rebase on the master branch.
The new status of this patch is: Waiting on Author
Fabien COELHO wrote:
> sh> /usr/bin/psql
> psql (12beta2 ...)
> fabien=# \set FETCH_COUNT 2
> fabien=# SELECT 1234 \; SELECT 5432 ;
> fabien=#
>
> same thing with pg 11.4, and probably down to every version of postgres
> since the feature was implemented...
>
> I think that
On Fri, Jul 26, 2019 at 1:34 PM Heikki Linnakangas wrote:
>
> There seems to be consensus on the going with the approach from the
> original patch, so I had a closer look at it.
>
> The patch first does this:
>
> >
> > /*
> >* Obtain some data from the index itself, if possible. Oth
On 27/06/2019 23:09, Alvaro Herrera wrote:
On 2019-Jun-27, Tom Lane wrote:
Dunno, I just can't get excited about exposing REVMAP_PAGE_MAXITEMS.
Especially not since we seem to agree on the long-term solution here,
and what you're suggesting to Julien doesn't particularly fit into
that long-term
Hello Peter,
I have committed this with some additions.
Thanks for the push. It was really a pain to write a small libpq app
without navigation.
Also, due to some mysterious problems with the PDF toolchain I had to
remove some links. Your script would find those, so I won't list them
he
Hello devs,
As pointed out by Kyotaro Horiguchi in
https://www.postgresql.org/message-id/20190726.131704.86173346.horikyota@gmail.com
FETCH_COUNT does not work with combined queries, and probably has never
worked since 2006.
What seems to happen is that ExecQueryUsingCursor is hardcoded
On 2019-07-22 22:56, Fabien COELHO wrote:
> Attached script does, hopefully, the expected transformation. It adds ids
> to occurrences when the id is not defined elsewhere.
>
> Attached v3 is the result of applying your kindly provided xslt patch plus
> the script on "libpq.sgml".
>
> Three fun
On Wed, Jul 24, 2019 at 10:00 AM Dilip Kumar wrote:
>
> On Mon, Jul 22, 2019 at 3:51 PM Dilip Kumar wrote:
> >
> Please find my review comments for
> 0013-Allow-foreground-transactions-to-perform-undo-action
>
>
> + * We can't postpone applying undo actions for subtransactions as the
> + * modifi
Hi All,
I'm able to insert data into a table column marked as GENERATED ALWAYS
using COPY command however, it fails with INSERT command. Isn't that a
bug with COPY command?
Here is the test-case for more clarity.
postgres=# create table tab_always (i int generated always as identity, j int);
CR
On Fri, 26 Jul 2019 17:21:20 +0900 (Tokyo Standard Time)
Kyotaro Horiguchi wrote:
> Hello.
>
> While looking [1], I noticed that pg_walfile_name_offset behaves
> somewhat oddly at segment boundary.
>
> select * from (values ('0/16ff'), ('0/1700'), ('0/1701')) as
> t(lsn), lateral pg
Hello.
While looking [1], I noticed that pg_walfile_name_offset behaves
somewhat oddly at segment boundary.
select * from (values ('0/16ff'), ('0/1700'), ('0/1701')) as
t(lsn), lateral pg_walfile_name_offset(lsn::pg_lsn);
lsn |file_name | file_offset
Hello Kyotaro-san,
Attached a v2 for the always-show-all-results variant. Thanks for the
debug!
I have some comments on this patch.
I'm +1 for always output all results without having knobs.
That makes 4 opinions expressed towards this change of behavior, and none
against.
Documentatio
On Fri, Jul 26, 2019 at 10:53:03AM +0300, Sergei Kornilov wrote:
> Explicit is better than implicit, so I am +1 to commit both patches.
Hence my count is incorrect:
- Forbid --jobs and --index: Michael P, Sergei K.
- Enforce --jobs=1 with --index: Julien R.
- Have no restrictions: 0.
--
Michael
On Fri, 26 Jul 2019 16:49:53 +0900 (Tokyo Standard Time)
Kyotaro Horiguchi wrote:
> Hi.
>
> At Thu, 25 Jul 2019 19:38:08 +0200, Jehan-Guillaume de Rorthais
> wrote in <20190725193808.1648ddc8@firost>
> > On Wed, 24 Jul 2019 14:33:27 +0200
> > Jehan-Guillaume de Rorthais wrote:
> >
> > > On
On Fri, Jul 26, 2019 at 11:21 AM Jeevan Ladhe
wrote:
> Hi Vignesh,
>
> Please find my comments inline below:
>
> 1) If relation file has changed due to truncate or vacuum.
>> During incremental backup the new files will be copied.
>> There are chances that both the old file and new file
Hi
> So here we go:
> - 0001 is your original thing, with --jobs enforced to 1 for the index
> part.
> - 0002 is my addition to forbid --index with --jobs.
>
> I am fine to be outvoted regarding 0002, and it is the case based on
> the state of this thread with 2:1. We could always revisit this
> d
Hi.
At Thu, 25 Jul 2019 19:38:08 +0200, Jehan-Guillaume de Rorthais
wrote in <20190725193808.1648ddc8@firost>
> On Wed, 24 Jul 2019 14:33:27 +0200
> Jehan-Guillaume de Rorthais wrote:
>
> > On Wed, 24 Jul 2019 09:49:05 +0900
> > Michael Paquier wrote:
> >
> > > On Tue, Jul 23, 2019 at 06:05:
On Fri, Jul 26, 2019 at 09:36:32AM +0200, Julien Rouhaud wrote:
> I see that you iterate over the SimpleStringList after it's generated.
> Why not computing that while building it in get_parallel_object_list
> (and keep the provided table list count) instead?
Yeah. I was hesitating to do that, or
On Fri, Jul 26, 2019 at 5:27 AM Michael Paquier wrote:
>
> On Thu, Jul 25, 2019 at 01:00:34PM +0200, Julien Rouhaud wrote:
> > The problem is that a user doing something like:
> >
> > reindexdb -j48 -i some_index -S s1 -S s2 -S s3
> >
> > will probably be disappointed to learn that he has to r
On Sat, July 20, 2019 8:12 AM (GMT+9), Tomas Vondra wrote:
> >+/* XXX What if the target is set to 0? Reset the statistic?
> */
> >
> >This also makes me wonder. I haven't looked deeply into the code, but
> >since 0 is a valid value, I believe it should reset the stats.
>
> I agree re
62 matches
Mail list logo
