On Fri, Jan 10, 2020 at 05:39:40PM +0100, Fabien COELHO wrote:
> So IMHO the current situation is fine, but the __variable name. So ISTM that
> the attached is the simplest and more reasonable option to fix this.
I'd rather hear more from others at this point. Peter's opinion, as
the main author
On 2020-01-06 21:00, Magnus Hagander wrote:
+0.5 to avoid calling OidInputFunctionCall()
Or just directly using atol() instead of atoi()? Well maybe not
directly but in a small wrapper that verifies it's not bigger than an
unsigned?
Unlike in cases where we use oidin etc, we are dealing with
On 2020-01-10 06:23, Michael Paquier wrote:
On Thu, Jan 09, 2020 at 11:15:08AM +0100, Peter Eisentraut wrote:
You mean put he subsequent GrantLock() calls into LockCheckConflicts()? That
would technically save some duplicate code, but it seems weird, because
LockCheckConflicts() is notionally a
On 2020-01-10 13:20, Sergei Kornilov wrote:
Thank you, but I am late: patch has another merge conflict.
Conflict seems trivial and patch looks fine for me.
Here is another patch version. I have resolved the conflict and also
added a check that you don't drop the generation expression from
Amit Kapila writes:
> On Fri, Jan 10, 2020 at 9:31 AM Amit Kapila wrote:
>> ... So, we have the below
>> options:
>> (a) remove this test entirely from all branches and once we found the
>> memory leak problem in back-branches, then consider adding it again
>> without max_files_per_process
On Fri, Jan 10, 2020 at 9:31 AM Amit Kapila wrote:
>
> On Fri, Jan 10, 2020 at 6:10 AM Tom Lane wrote:
> >
> > I wrote:
> > > ReorderBuffer: 223302560 total in 26995 blocks; 7056 free (3
> > > chunks); 223295504 used
> >
> > > The test case is only inserting 50K fairly-short rows, so
Here's a draft patch that cleans up all the logic errors I could find.
I also expanded the previous patch for the kerberos test so that it
verifies that we can upload a nontrivial amount of data to the server,
as well as download.
I also spent a fair amount of effort on removing cosmetic
On Fri, 10 Jan 2020 at 20:54, Mahendra Singh Thalor
wrote:
>
> On Fri, 10 Jan 2020 at 15:51, Sergei Kornilov wrote:
> >
> > Hi
> > Thank you for update! I looked again
> >
> > (vacuum_indexes_leader)
> > + /* Skip the indexes that can be processed by parallel
workers */
> > +
On Fri, Jan 10, 2020 at 12:01:36AM +0100, Daniel Gustafsson wrote:
> I looked into this and it turns out that OpenSSL does nothing to prevent the
> caller from setting a nonsensical protocol range like min=tlsv1.3,max=tlsv1.1.
> Thus, it's quite easy to screw up the backend server config and get
On 2020-Jan-10, Alvaro Herrera wrote:
> From 7d671806584fff71067c8bde38b2f642ba1331a9 Mon Sep 17 00:00:00 2001
> From: Dilip Kumar
> Date: Wed, 20 Nov 2019 16:41:13 +0530
> Subject: [PATCH v6 10/12] Enable streaming for all subscription TAP tests
This patch turns a lot of test into the streamed
On Thu, Jan 2, 2020 at 10:26:16PM +0500, Andrey Borodin wrote:
>
>
> > 2 янв. 2020 г., в 19:13, Robert Haas написал(а):
> >
> > On Sun, Dec 29, 2019 at 4:13 AM Andrey Borodin wrote:
> >> Not loosing data - is a nice property of the database either.
> >
> > Sure, but there's more than one
Hi,
I wonder what is the status of this patch/thread. There was quite a bit
of discussion about possible approaches, but we currently don't have any
patch for review, AFAICS. Not sure what's the plan?
So "needs review" status seems wrong, and considering we haven't seen
any patch since August
Hi,
On Thu, Sep 26, 2019 at 01:47:28PM +, Luis Carril wrote:
I don't disagree with adding FOREIGN, though.
Your patch is failing the pg_dump TAP tests. Please use
configure --enable-tap-tests, fix the problems, then resubmit.
Fixed, I've attached a new version.
This seems like a
On Thu, Sep 12, 2019 at 10:16:12AM -0300, Alvaro Herrera wrote:
On 2019-Sep-12, Andrey Borodin wrote:
This patch violates one of amcheck design principles: current code
does not ever take more than one page lock. I do not know: should we
hold this rule or should we use more deep check?
The
On Fri, Jan 10, 2020 at 05:54:21PM +0530, Mahendra Singh Thalor wrote:
> Thanks for the patch. I am not getting any crash but \d is not showing
> any temp table if we drop temp schema and create again temp table.
That's expected. As discussed on this thread, the schema has been
dropped by a
On Fri, Jan 10, 2020 at 11:01:13AM +0530, Dilip Kumar wrote:
> On Fri, Jan 10, 2020 at 10:31 AM Michael Paquier wrote:
>> and there is a gap with the regression
>> tests. So combining all that I get the attached patch (origin point
>> is 665d1fa). Thoughts?
>
> LGTM
Thanks for the lookup.
Hi,
I've been looking at the last version (v14) of this patch series,
submitted way back in July and unfortunately quiet since then. Antonin
is probably right one of the reasons for the lack of reviews is that it
requires interest/experience with planner.
Initially it was also a bit hard to
On Thu, Jan 9, 2020 at 12:07 PM Robert Haas wrote:
>
> On Thu, Dec 12, 2019 at 2:26 PM David Fetter wrote:
> > > I wonder if you might add information about table size, table changes,
> > > and bloat to your RelFrozenXidAge struct and modify rfxa_comparator to
> > > use a heuristic to cost the
LIMIT clause without ORDER BY should be prohibited when creating
incremental materialized views.
In SQL, the result of a LIMIT clause without ORDER BY is undefined.
If the LIMIT clause is allowed when creating an incremental materialized
view, incorrect results will be obtained when the view is
On Fri, Jan 10, 2020 at 7:36 PM Alexander Korotkov
wrote:
>
> On Fri, Jan 10, 2020 at 6:31 PM Tom Lane wrote:
>>
>> Alexander Korotkov writes:
>> > So, I think v10 is a version of patch, which can be committed after
>> > some cleanup. And we can try doing better nulls handling in a separate
>>
On Fri, Jan 10, 2020 at 09:50:58AM -0500, Tom Lane wrote:
> This doesn't seem like a very good idea to me. Is there any
> evidence that it's fixing an actual problem? What if the table
> you're skipping is holding back datfrozenxid?
That's the point I wanted to make sure: we don't because
Stephen Frost writes:
> To be clear, I was advocating for a NEW DB-level privilege ('INSTALL' or
> 'CREATE EXTENSION' if we could make that work), so that we have it be
> distinct from CREATE (which, today, really means 'CREATE SCHEMA').
I still say this is wrong, or at least pointless, because
Here's a rebase of this patch series. I didn't change anything except
1. disregard what was 0005, since I already pushed it.
2. roll 0003 into 0002.
3. rebase 0007 (now 0005) to account for the reorderbuffer changes.
(I did notice that 0005 adds a new boolean any_data_sent, which is
silly -- it
On Fri, Jan 10, 2020 at 12:59:09PM -0500, Tom Lane wrote:
! [ redirecting to -hackers ]
! I modified the kerberos test so that it tries a query with a less
! negligible amount of data, and what I find is:
!
! * passes on Fedora 30, with either default or 1500 mtu
! * passes on FreeBSD 12.0 with
Greetings,
On Fri, Jan 10, 2020 at 15:58 Tom Lane wrote:
> Stephen Frost writes:
> > Ah-hah. Not sure if that was Robbie or myself (probably me, really,
> > since I rewrote a great deal of that code). I agree that the regression
> > tests don't test with very much data, but I tested pushing
Stephen Frost writes:
> Ah-hah. Not sure if that was Robbie or myself (probably me, really,
> since I rewrote a great deal of that code). I agree that the regression
> tests don't test with very much data, but I tested pushing quite a bit
> of data through and didn't see any issues with my
I pushed 0005 (the rbtxn flags thing) after some light editing.
It's been around for long enough ...
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 10, 2020 at 2:40 PM Tom Lane wrote:
> > Well, the other direction we could go here, which I guess is what
> > you are arguing for, is to forget the new default role and just
> > say that marking an extension trusted allows it
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I wrote:
> > I haven't run it further to ground than that, but there's definitely
> > something fishy here. Based on just these results one would be hard
> > pressed to say if it's our bug or FreeBSD's, but your report that you
> > don't see
On Fri, Jan 10, 2020 at 2:40 PM Tom Lane wrote:
> Well, the other direction we could go here, which I guess is what
> you are arguing for, is to forget the new default role and just
> say that marking an extension trusted allows it to be installed by
> DB owners, full stop. That's nice and
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 10, 2020 at 9:30 AM Tom Lane wrote:
> > If somebody comes up with a patch
> > that causes "pg_dumpall -g" to include ALTER SYSTEM SET commands for
> > whatever is in postgresql.auto.conf (not an unreasonable idea BTW),
> >
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Don't see how this follows. It's somewhat accidental I think that
>> the existing behavior is tied to DB ownership. That's just because
>> at the time, that's the only sort of privilege we had that seemed
>> intermediate between
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> > ... and that backs up my position that we are setting up this
> > privilege at the wrong level by using a default role which a superuser must
> > grant independently from DB ownership.
>
> Don't see how this follows. It's somewhat accidental
I wrote:
> I haven't run it further to ground than that, but there's definitely
> something fishy here. Based on just these results one would be hard
> pressed to say if it's our bug or FreeBSD's, but your report that you
> don't see the failure with PG 11 makes it sound like our problem.
Ah, I
On Fri, Jan 10, 2020 at 9:30 AM Tom Lane wrote:
> If somebody comes up with a patch
> that causes "pg_dumpall -g" to include ALTER SYSTEM SET commands for
> whatever is in postgresql.auto.conf (not an unreasonable idea BTW),
> will you then decide that ALTER SYSTEM SET is no longer read-only?
>
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > So I'm at a loss for why there is this insistence on a default role and
> > a superuser-explicit-granting based approach that goes beyond "is it
> > installed on the filesystem?" and "is it marked as trusted?".
>
>
[ redirecting to -hackers ]
Peter writes:
> But I just recognize something of interest (which I had taken for
> granted when importing the database): the flaw does NOT appear when
> accessing the database from the server's local system (with TCP and
> GSSAPI encryption active). Only from remote
On Fri, Jan 10, 2020 at 8:16 PM Michael Paquier wrote:
>
> On Fri, Jan 10, 2020 at 06:50:12PM +0900, Fujii Masao wrote:
> > I changed the doc that way. Thanks for the review!
Thanks for the review!
> +
> + pg_file_sync fsyncs the specified file or directory
> + named by filename. Returns
Michaël,
So I think that the current situation is a good thing at least for debug.
If you look at some of my messages on other threads, you would likely
notice that my mood of the day is to not design things which try to
outsmart a user's expectations :)
I'm not following you.
ISTM that
On Fri, Jan 10, 2020 at 6:31 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > So, I think v10 is a version of patch, which can be committed after
> > some cleanup. And we can try doing better nulls handling in a separate
> > patch.
>
> The cfbot reports that this doesn't pass regression
Dent John wrote:
> Yes. That’s at least true if unnest(x) is used in the FROM. If it’s used in
> the SELECT, actually it can get the performance benefit right away
At a quick glance, I don't see it called in the select-list in any
of the regression tests. When trying it, it appears to
Alexander Korotkov writes:
> So, I think v10 is a version of patch, which can be committed after
> some cleanup. And we can try doing better nulls handling in a separate
> patch.
The cfbot reports that this doesn't pass regression testing.
I haven't looked into why not.
Peter Eisentraut writes:
> On 2020-01-09 15:17, Tom Lane wrote:
>> 1) Changing from an "|"-style dependency to a plain dependency seems
>> like a semantics change. I've never been totally clear on the
>> difference though. I think Peter introduced our use of the "|" style,
>> so maybe he can
Michael Paquier writes:
> [ patch to skip tables if get_namespace_name fails ]
This doesn't seem like a very good idea to me. Is there any
evidence that it's fixing an actual problem? What if the table
you're skipping is holding back datfrozenxid?
regards, tom lane
Peter Eisentraut writes:
> I don't really remember, but that was basically the opinion I had
> arrived at as I was reading through this current thread. Roughly
> speaking, anything that changes the database state (data or schema) in a
> way that would be reflected in a pg_dump output is not
A customer of ours complained that if you have an inactive primary,
monitoring the apply lag on a standby reports monotonically increasing
lag. The reason for this is that the apply lag is only updated on
COMMIT records, which of course don't occur in inactive servers.
But CHECKPOINT records do
On 2020-Jan-09, Alvaro Herrera wrote:
> I looked at this a little while and was bothered by the perl changes; it
> seems out of place to have RecursiveCopy be thinking about tablespaces,
> which is way out of its league. So I rewrote that to use a callback:
> the PostgresNode code passes a
On Fri, Jan 10, 2020 at 7:23 AM Peter Eisentraut
wrote:
> I don't really remember, but that was basically the opinion I had
> arrived at as I was reading through this current thread. Roughly
> speaking, anything that changes the database state (data or schema) in a
> way that would be reflected
Hello
> Yes, we should improve this. I tried to fix this. Attaching a delta
> patch that is fixing both the comments.
Thank you, I have no objections.
I think that status of CF entry is outdated and the most appropriate status for
this patch is "Ready to Commiter". Changed. I also added an
On 2020-01-09 15:17, Tom Lane wrote:
1) Changing from an "|"-style dependency to a plain dependency seems
like a semantics change. I've never been totally clear on the
difference though. I think Peter introduced our use of the "|" style,
so maybe he can comment.
If you have a phony target as
On 09.01.2020 19:30, Tomas Vondra wrote:
3 Still no one commented on GTT's transaction information
processing, they include
3.1 Should gtt's frozenxid need to be care?
3.2 gtt’s clog clean
3.3 How to deal with "too old" gtt data
No idea what to do about this.
I wonder what is
On Fri, 10 Jan 2020 at 16:37, Michael Paquier wrote:
>
> On Fri, Jan 10, 2020 at 05:01:25PM +0900, Michael Paquier wrote:
> > This makes me wonder how much we should try to outsmart somebody which
> > puts the catalogs in such a inconsistent state. Hmm. Perhaps at the
> > end autovacuum should
On 2020-01-09 21:52, Tom Lane wrote:
Peter might remember more clearly, but I have a feeling that we
concluded that the intent of the spec was for read-only-ness to
disallow globally-visible changes in the visible database contents.
I don't really remember, but that was basically the opinion I
Updated the chg_to_date_wwd.patch with additional tests (because it
works not only for 'D' pattern but also for all day patterns like 'Day'
or 'DY'). Added the necessary documentation change.
(The fix_to_char_wwd.patch from
f4e740a8de3ad1e762a28f6ff253ea4f%40four-two.de is still
Hello
Thank you, but I am late: patch has another merge conflict.
Conflict seems trivial and patch looks fine for me.
regards, Sergei
Hi Amit,
Can you please rebase the patches as they don't apply on latest master?
Thank you,
Rahila Syed
On Thu, 26 Dec 2019 at 16:36, Amit Khandekar wrote:
> On Tue, 24 Dec 2019 at 14:02, Amit Khandekar
> wrote:
> >
> > On Thu, 19 Dec 2019 at 01:02, Rahila Syed
> wrote:
> > >
> > > Hi,
> >
On Fri, 10 Jan 2020 at 15:51, Sergei Kornilov wrote:
>
> Hi
> Thank you for update! I looked again
>
> (vacuum_indexes_leader)
> + /* Skip the indexes that can be processed by parallel workers
> */
> + if (!skip_index)
> + continue;
>
> Does the
On Fri, Jan 10, 2020 at 10:50 AM Fujii Masao wrote:
>
> On Thu, Jan 9, 2020 at 10:39 PM Julien Rouhaud wrote:
> >
> > I think that pg_write_server_files should be allowed to call that
> > function by default.
>
> But pg_write_server_files users are not allowed to execute
> other functions like
On Fri, Jan 10, 2020 at 06:50:12PM +0900, Fujii Masao wrote:
> I changed the doc that way. Thanks for the review!
+
+ pg_file_sync fsyncs the specified file or directory
+ named by filename. Returns true on success,
+ an error is thrown otherwise (e.g., the specified file is not present).
+
On Fri, Jan 10, 2020 at 05:01:25PM +0900, Michael Paquier wrote:
> This makes me wonder how much we should try to outsmart somebody which
> puts the catalogs in such a inconsistent state. Hmm. Perhaps at the
> end autovacuum should just ignore such entries and just don't help the
> user at all
Hi
Thank you for update! I looked again
(vacuum_indexes_leader)
+ /* Skip the indexes that can be processed by parallel workers */
+ if (!skip_index)
+ continue;
Does the variable name skip_index not confuse here? Maybe rename to something
like
On Thu, Jan 9, 2020 at 10:39 PM Julien Rouhaud wrote:
>
> On Thu, Jan 9, 2020 at 7:31 AM Fujii Masao wrote:
> >
> > On Mon, Jan 6, 2020 at 3:42 PM Michael Paquier wrote:
> > >
> > > On Mon, Jan 06, 2020 at 03:20:13PM +0900, Arthur Zakirov wrote:
> > > > It isn't case if a file doesn't exist.
Hi
so 4. 1. 2020 v 6:29 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Fri, Dec 20, 2019 at 11:29 AM Alvaro Herrera
> wrote:
> > > Should I just give up on implicit casts and require you to specify
> > > one? That makes it a little more annoying to mix range &
On 09.01.2020 19:48, Tomas Vondra wrote:
The most complex and challenged task is to support GTT for all kind
of indexes. Unfortunately I can not proposed some good universal
solution for it.
Just patching all existed indexes implementation seems to be the only
choice.
I haven't looked
On Fri, Jan 10, 2020 at 08:52:17AM +0100, Fabien COELHO wrote:
> Compared to dealing with the level inside the call, the use of the level
> variable avoids a call-test-return cycle in this case, and the unlikely
> should help the compiler reorder instructions so that no actual branch is
> taken
On Fri, Jan 10, 2020 at 11:56:37AM +0530, Mahendra Singh Thalor wrote:
> I reviewed and tested the patch. After applying patch, I am getting other
> assert failure.
>
> I think, before committing 1st patch, we should fix this crash also and
> then we should commit all the patches.
I have somewhat
66 matches
Mail list logo
