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
>>
>>
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
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,
> >
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
=?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.
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
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
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
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
>
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
>
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
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
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
> > +*
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 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
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 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
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:
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
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.
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
On Tue, Jul 23, 2019 at 8:12 PM Amit Khandekar wrote:
>
> On Tue, 23 Jul 2019 at 08:48, Amit Kapila wrote:
> >
> >
> > > --
> > >
> > > + if (!InsertRequestIntoErrorUndoQueue(urinfo))
> > > I was thinking what happens if for some reason
> > > InsertRequestIntoErrorUndoQueue() itself
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
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
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
>
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
Tsunakawa-san
Thank you for your comment.
I understand the sense. I don't require an explicit rule.
Regards
Ryo Matsumura
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,
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
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 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 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
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);
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
> + *
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
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
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
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
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.
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
The patch requires to rebase on the master branch.
The new status of this patch is: Waiting on Author
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
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
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)
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
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
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
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
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:
> 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
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
> >
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,
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
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
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
Fabien COELHO writes:
>> |...] So I'll mark this ready for committer.
> Ok, thanks for the review.
LGTM, pushed.
regards, tom lane
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.
>>
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
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
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
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
61 matches
Mail list logo