Hello,
On 2019/12/05 11:31, Michael Paquier wrote:
On Wed, Dec 04, 2019 at 06:15:52PM +0900, Arthur Zakirov wrote:
Ah, I thought that pg_identify_object() gives properly quoted identity, and
it could be used to make SQL script.
It depends on the object type. For columns I can see in your pat
On Wed, Dec 11, 2019 at 11:13 AM vignesh C wrote:
>
>
> It sets the final_lsn here so that it can iterate from the start_lsn
> to final_lsn and cleanup the serialized files in
> ReorderBufferRestoreCleanup function. One solution We were thinking
> was to store the lsn of the last serialized change
Hi,
It seems to me that we currently allow expressions that are anonymous
and self-referencing composite type records as partition key, but
shouldn't. Allowing them leads to this:
create table foo (a int) partition by list ((row(a, b)));
create table foo1 partition of foo for values in ('(1)'::f
út 17. 12. 2019 v 6:36 odesílatel Michael Paquier
napsal:
> On Fri, Dec 13, 2019 at 10:28:33AM +0100, Josef Šimánek wrote:
> > I have prepared patch to improve documentation for REINDEX. It
> > should be more inline with another documentation pages.
> >
> > You can see the change applied in attac
út 17. 12. 2019 v 6:36 odesílatel Michael Paquier
napsal:
> On Fri, Dec 13, 2019 at 10:28:33AM +0100, Josef Šimánek wrote:
> > I have prepared patch to improve documentation for REINDEX. It
> > should be more inline with another documentation pages.
> >
> > You can see the change applied in attac
Uggg. I must apologyze for the last bogus comment.
At Fri, 13 Dec 2019 21:24:36 +, "Bossart, Nathan"
wrote in
> On 12/12/19, 8:08 PM, "Kyotaro Horiguchi" wrote:
> > As the result the patch doesn't seem to save anything than setting up
> > and operating correctly.
>
> Disregarding the beha
On 2019-12-17 05:40, Stephen Frost wrote:
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
The idea is that if you connect over a Unix-domain socket and the local
(effective) user is the same as the server's (effective) user, then
access should be granted immediately without any chec
Thank you Alvaro for the comment (on my comment).
At Fri, 13 Dec 2019 18:33:44 -0300, Alvaro Herrera
wrote in
> On 2019-Dec-13, Kyotaro Horiguchi wrote:
>
> > At Thu, 12 Dec 2019 22:50:20 +, "Bossart, Nathan"
> > wrote in
>
> > > The crux of the issue seems to be that XLogWrite() does
On 2019-12-17 07:30, Michael Paquier wrote:
The patch looks pretty clean. I have a few minor comments.
- if (/^AC_INIT\(\[PostgreSQL\], \[([^\]]+)\]/)
+ if (/^AC_INIT\(\[([^\]]+)\], \[([^\]]+)\], \[([^\]]+)\]/)
{
Why did you remove the bit about "PostgreSQL"?
Just to make
> On Tue, Jul 16, 2019 at 06:49:10PM -0700, Melanie Plageman wrote:
>
> We implemented Approach B in the attached patch set (patch 0001) and
> then implemented Approach A (patch 0002) to sanity check the pruned
> list of columns to scan we were getting at plan-time.
> We emit a notice in SeqNext()
At Mon, 16 Dec 2019 11:49:56 +0900, Michael Paquier wrote
in
> On Sun, Dec 15, 2019 at 10:27:12AM -0600, Justin Pryzby wrote:
> > I named it so because it calls both lazy_vacuum_index
> > ("PROGRESS_VACUUM_PHASE_VACUUM_INDEX") and
> > lazy_vacuum_heap("PROGRESS_VACUUM_PHASE_VACUUM_HEAP")
> >
>
While following an old link to
https://www.postgresql.org/docs/10/auth-methods.html
I see a list of links to authentication methods. However:
When I hit the current version
https://www.postgresql.org/docs/current/auth-methods.html
There are absolutely no links...
Dave Cramer
On Tue, Dec 17, 2019 at 12:43 PM Dave Cramer wrote:
> While following an old link to
> https://www.postgresql.org/docs/10/auth-methods.html
>
> I see a list of links to authentication methods. However:
>
> When I hit the current version
> https://www.postgresql.org/docs/current/auth-methods.html
On Tue, 17 Dec 2019 at 06:53, Magnus Hagander wrote:
> On Tue, Dec 17, 2019 at 12:43 PM Dave Cramer wrote:
>
>> While following an old link to
>> https://www.postgresql.org/docs/10/auth-methods.html
>>
>> I see a list of links to authentication methods. However:
>>
>> When I hit the current vers
On Tue, Dec 17, 2019 at 1:02 PM Dave Cramer wrote:
> On Tue, 17 Dec 2019 at 06:53, Magnus Hagander wrote:
>
>> On Tue, Dec 17, 2019 at 12:43 PM Dave Cramer
>> wrote:
>>
>>> While following an old link to
>>> https://www.postgresql.org/docs/10/auth-methods.html
>>>
>>> I see a list of links to a
On Mon, 16 Dec 2019 at 16:52, Amit Kapila wrote:
>
> On Mon, Dec 16, 2019 at 3:26 PM Amit Khandekar wrote:
> >
> > On Sat, 14 Dec 2019 at 11:59, Amit Kapila wrote:
> > >
> > > I have also made minor changes related to below code in patch:
> > > - else if (readBytes != sizeof(ReorderBufferDiskCha
On Tue, Dec 17, 2019 at 10:09 AM Amit Kapila wrote:
>
> On Mon, Dec 16, 2019 at 9:16 PM Jehan-Guillaume de Rorthais
> wrote:
> >
> > On Mon, 16 Dec 2019 13:27:43 +0100
> > Peter Eisentraut wrote:
> >
> > > On 2019-12-16 11:11, Amit Kapila wrote:
> > > > I agree that this is a timing issue. I al
On Fri, 13 Dec 2019 at 15:50, Amit Kapila wrote:
>
> On Fri, Dec 13, 2019 at 11:08 AM Masahiko Sawada
> wrote:
> >
> > On Fri, 13 Dec 2019 at 14:19, Amit Kapila wrote:
> > >
> > > > > >
> > > > > > How about adding an additional argument to ReinitializeParallelDSM()
> > > > > > that allows the n
On Tue, Dec 17, 2019 at 1:31 AM Kyotaro Horiguchi
wrote:
> The patch can cause removal of a wrong cleanup function on non-cassert
> build. That might be unwanted. But I think the assertion is needed
> anyway.
I agree with the first part of this critique, but not necessarily with
the second part.
De: Michael Paquier
Enviadas: Terça-feira, 17 de Dezembro de 2019 04:45
>And if you actually group things together so as any individual looking
>at your patches does not have to figure out which piece applies to
>what, that's also better.
I'm still trying to find the best way.
>Anyway, the patch f
## Tomas Zubiri (m...@tomaszubiri.com):
> We already established that a tcp connection was subpar in terms of
> latency, we shall note then that a tcp connection is subpar in terms
> of security.
It's an entirely different thing, I'd argue. I'm not even convinced
that an error message is a bad th
On Fri, Dec 13, 2019 at 3:00 AM Michael Paquier wrote:
> Agreed, that's an issue and do_pg_abort_abort should not touch
> sessionBackupState, so you should keep cancel_before_shmem_exit after
> pg_stop_backup().
I don't understand this comment, because that can't possibly work. It
assumes either
De: Michael Paquier
Enviadas: Terça-feira, 17 de Dezembro de 2019 04:34
>So, this basically matches with what the MS documents tell us, and my
>impression: this API is available down to at least MSVC 2008, which is
>much more than what we support on HEAD where one can use MSVC 2013 and
>newer versi
Magnus Hagander writes:
> This was changed by Peter in
> commit 56811e57323faa453947eb82f007e323a952e1a1 along with the
> restructuring. It used to say "the following subsections". So techically I
> think that change is correct, but that doesn't necessarily make it helpful.
> But based on how it
Amit Langote writes:
> I wonder if it's worthwhile to fix the following not-so-friendly error
> message:
> create index on foo ((row(a)));
> ERROR: column "" has pseudo-type record
Ugh. That used to work more nicely:
regression=# create index fooi on foo ((row(a)));
ERROR: column "pg_expres
> Then, URLs pointing to that page (such as Dave evidently has bookmarked)
> would break entirely, which doesn't seem like an improvement.
>
it was linked to in a bug report.
Dave Cramer
Amit Langote writes:
> It seems to me that we currently allow expressions that are anonymous
> and self-referencing composite type records as partition key, but
> shouldn't. Allowing them leads to this:
Hm. Seems like the restrictions here ought to be just about the same
as on index columns, no
On Tue, Dec 17, 2019 at 8:38 AM Robert Haas wrote:
> Since there doesn't seem to be any opposition to my original fix,
> except for the fact that I included a bug in it, I'm going to go see
> about getting that committed.
Perhaps I spoke too soon: I'm not sure whether Michael's comments
amount to
Robert Haas writes:
> Perhaps I spoke too soon: I'm not sure whether Michael's comments
> amount to an objection. While I give him a chance to respond, here's
> an updated patch.
Took a quick look. I agree that this seems a lot cleaner than the
alternative proposals. I'd suggest however that th
On Fri, 8 Nov 2019 at 14:38, Michael Paquier wrote:
>
> On Thu, Nov 07, 2019 at 12:02:04PM -0500, Tom Lane wrote:
> > I don't think it'd be a great idea to change parallel_schedule like
> > that. Independently adding test scripts to the same parallel batch
> > probably won't end well: you might e
On Thu, Dec 12, 2019 at 2:54 PM Andres Freund wrote:
> I'd either add a test (if we have some) or placeholder kind
> initially. But I'd also be ok with going for either of the other
> versions directly - but it seems harder to tackle the patches together.
OK. I have committed 0001-0003 as I had m
On Tue, 17 Dec 2019 at 18:07, Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
>
> On Fri, 13 Dec 2019 at 15:50, Amit Kapila wrote:
> >
> > On Fri, Dec 13, 2019 at 11:08 AM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, 13 Dec 2019 at 14:19, Amit Kapila
wrote:
> > > >
> > > > > > >
> >
Hello
> Stellar. If nobody objects in the meantime, I plan to commit 0001-0003
> next week.
My compiler (gcc 8.3.0) is not happy with recent
5910d6c7e311f0b14e3d3cb9ce3597c01d3a3cde commit:
autovacuum.c:831:1: error: ‘AutoVacLauncherShutdown’ was used with no prototype
before its definition [-
On Tue, Dec 17, 2019 at 1:44 PM Sergei Kornilov wrote:
> > Stellar. If nobody objects in the meantime, I plan to commit 0001-0003
> > next week.
>
> My compiler (gcc 8.3.0) is not happy with recent
> 5910d6c7e311f0b14e3d3cb9ce3597c01d3a3cde commit:
>
> autovacuum.c:831:1: error: ‘AutoVacLauncherS
Hi
> Andrew Gierth complained about this too over on -committers, and I saw
> his message first and pushed a fix. It includes the first and third
> hunks from your proposed patch, but not the second one.
Yep, I received his email just after sending mine. Thanks, my build is clean
now.
regards,
On Sat, Dec 14, 2019 at 10:24 PM Robert Haas wrote:
> On Thu, Dec 12, 2019 at 2:33 PM Andres Freund wrote:
> > I was basically just thinking that we could pass the context to use via
> > CurrentMemoryContext, instead of explicitly passing it in.
>
> I thought about that, but as a general rule, re
On Tue, Dec 17, 2019 at 7:05 PM Tom Lane wrote:
> Robert Haas writes:
> > Perhaps I spoke too soon: I'm not sure whether Michael's comments
> > amount to an objection. While I give him a chance to respond, here's
> > an updated patch.
>
> Took a quick look. I agree that this seems a lot cleaner
On Tue, Dec 17, 2019 at 5:01 PM Tom Lane wrote:
> Magnus Hagander writes:
> > This was changed by Peter in
> > commit 56811e57323faa453947eb82f007e323a952e1a1 along with the
> > restructuring. It used to say "the following subsections". So techically
> I
> > think that change is correct, but tha
Magnus Hagander writes:
> On Tue, Dec 17, 2019 at 5:01 PM Tom Lane wrote:
>> I suggest changing the sect1's contents to be a list of available auth
>> methods, linked to their subsections. That would provide approximately
>> the same quality-of-use as the subsection TOC that used to be there.
>
I wrote:
> Took a quick look. I agree that this seems a lot cleaner than the
> alternative proposals. I'd suggest however that the header comment
> for do_pg_abort_backup could do with more work, perhaps along the
> lines of "The odd-looking signature allows this to be registered
> directly as a
On Fri, Nov 22, 2019 at 10:41 AM Robert Haas wrote:
> Thanks for the review. Updated patches attached. This version is more
> complete than the last set of patches I posted. It looks like this:
>
> 0001 - Lets a table AM that needs a toast table choose the AM that
> will be used to implement the
On Thu, Dec 12, 2019 at 06:21:20PM -0800, Peter Geoghegan wrote:
> On Tue, Dec 3, 2019 at 12:13 PM Peter Geoghegan wrote:
> > The new criteria/heuristic for unique indexes is very simple: If a
> > unique index has an existing item that is a duplicate on the incoming
> > item at the point that we m
On Tue, Dec 17, 2019 at 1:58 PM Bruce Momjian wrote:
> > Attached is v26, which adds this new criteria/heuristic for unique
> > indexes. We now seem to consistently get good results with unique
> > indexes.
>
> In the past we tried to increase the number of cases where HOT updates
> can happen but
On Tue, Dec 17, 2019 at 12:52:05PM -0500, Robert Haas wrote:
> On Tue, Dec 17, 2019 at 8:38 AM Robert Haas wrote:
>> Since there doesn't seem to be any opposition to my original fix,
>> except for the fact that I included a bug in it, I'm going to go see
>> about getting that committed.
>
> Perha
On Fri, Sep 7, 2018 at 9:17 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 05/09/2018 18:46, Peter Eisentraut wrote:
> > On 01/09/2018 06:33, Shinoda, Noriyoshi (PN Japan GCS Delivery) wrote:
> >> Certainly the PQconndefaults function specifies Debug flag for the
> "options" o
On Mon, Nov 25, 2019 at 8:21 AM Ranier Vilela wrote:
> >Where are you getting this stuff from? Are you using a static analysis tool?
> Yes,two static tools, but reviewed by me.
If you're working on/with static code analysis tools, I have some
requests :-) How could we automate the discovery of
On Tue, Dec 17, 2019 at 03:30:33PM -0800, Peter Geoghegan wrote:
> With many real world unique indexes, the true reason behind most or
> all B-Tree page splits is "version churn". I view these page splits as
> a permanent solution to a temporary problem -- we *permanently*
> degrade the index struc
On Tue, Dec 17, 2019 at 09:36:13AM +0900, Michael Paquier wrote:
> As that's a confusion I introduced with d9fadbf, I would like to fix
> that and backpatch this change down to 11. (Ranier gets the
> authorship per se as that's extracted from a larger patch).
Committed that part.
I got to look a
On Tue, Dec 17, 2019 at 5:18 PM Bruce Momjian wrote:
> On Tue, Dec 17, 2019 at 03:30:33PM -0800, Peter Geoghegan wrote:
> > With many real world unique indexes, the true reason behind most or
> > all B-Tree page splits is "version churn". I view these page splits as
> > a permanent solution to a t
On Sat, Nov 23, 2019 at 10:44:47AM +0100, Andreas Karlsson wrote:
> On 11/22/19 10:58 PM, Ranier Vilela wrote:
> > Remove redutant test.
>
> Yeah, this test does look redundant since we already check for if parent is
> NULL earlier in the function. Any optimizing compiler should see this too,
> bu
On Tue, Dec 17, 2019 at 11:40:17PM +0530, Mahendra Singh wrote:
> I found some inconsistency in alphabetical order in
> src/backend/tsearch/Makefile, src/backend/utils/Makefile and
> src/pl/plpython/Makefile files. Attached patch is fixing those order
> related inconsistency.
Thanks, committed.
On Tue, Dec 17, 2019 at 10:23:51AM +0100, Josef Šimánek wrote:
> For me this is the default way how to reindex whole table manually in psql
> since you get some "progress". Anyway I can remove it if you don't see any
> benefit in extending this example.
I have thought more about this one through t
On Tue, Dec 17, 2019 at 02:20:20PM +, Ranier Vilela wrote:
> As concern [1], at src/include/port/win32.h, the comments still
> references Windows XP and claims about possible MingW break.
This looks like a leftover of d9dd406, which has made the code to
require C99. As we don't support compil
On Wed, Dec 18, 2019 at 1:21 AM Tom Lane wrote:
> Haven't read the patch in any detail yet, but that seems like
> an improvement. And I guess we need a test case, or we'll
> break it again :-(
Thanks for adding the test case.
Regards,
Amit
On Wed, 18 Dec 2019 at 07:23, Michael Paquier wrote:
>
> On Tue, Dec 17, 2019 at 11:40:17PM +0530, Mahendra Singh wrote:
> > I found some inconsistency in alphabetical order in
> > src/backend/tsearch/Makefile, src/backend/utils/Makefile and
> > src/pl/plpython/Makefile files. Attached patch is f
On Tue, Dec 17, 2019 at 6:01 PM vignesh C wrote:
>
> On Tue, Dec 17, 2019 at 10:09 AM Amit Kapila wrote:
> >
> > Attached patch with updated commit message based on suggestions. I am
> > planning to commit this tomorrow unless there are more comments.
> >
>
> While testing the patch on back vers
On Tue, Dec 17, 2019 at 6:40 PM Michael Paquier wrote:
> So that's how you prevent piling up multiple registrations of this
> callback compared to v1. FWIW, I think that it is a cleaner approach
> to remove the callback once a non-exclusive backup is done, because a
> session has no need for it o
On Thu, Dec 12, 2019 at 6:21 PM Peter Geoghegan wrote:
> Still waiting for some review of the first patch, to get it out of the
> way. Anastasia?
I plan to commit this first patch [1] in the next day or two, barring
any objections.
It's clear that the nbtree "pin scan" VACUUM code is totally
unn
On Wed, Dec 18, 2019 at 12:19 PM Robert Haas wrote:
>
> On Tue, Dec 17, 2019 at 6:40 PM Michael Paquier wrote:
> > So that's how you prevent piling up multiple registrations of this
> > callback compared to v1. FWIW, I think that it is a cleaner approach
> > to remove the callback once a non-exc
At Tue, 17 Dec 2019 15:48:40 -0500, Tom Lane wrote in
> I wrote:
> > Took a quick look. I agree that this seems a lot cleaner than the
> > alternative proposals. I'd suggest however that the header comment
> > for do_pg_abort_backup could do with more work, perhaps along the
> > lines of "The o
On Fri, Dec 13, 2019 at 7:50 AM Bossart, Nathan wrote:
>
> Hi hackers,
>
> I believe I've uncovered a bug that may cause archive status ".ready"
> files to be created too early, which in turn may cause an incorrect
> version of the corresponding WAL segment to be archived.
>
> The crux of the issu
Hi Amit-san,
>>> 1)
For now, I'm not sure it should be set current_child_table_relid to zero
when the current phase is changed from "acquiring inherited sample rows" to
"computing stats". See bellow.
In the upthread discussion [1], Robert asked to *not* do such things,
that is, resetting
On Tue, Dec 17, 2019 at 6:07 PM Masahiko Sawada
wrote:
>
> On Fri, 13 Dec 2019 at 15:50, Amit Kapila wrote:
> >
> > > > I think it shouldn't be more than the number with which we have
> > > > created a parallel context, no? If that is the case, then I think it
> > > > should be fine.
> > >
> > >
On Wed, Dec 18, 2019 at 2:12 AM Tom Lane wrote:
> Amit Langote writes:
> > It seems to me that we currently allow expressions that are anonymous
> > and self-referencing composite type records as partition key, but
> > shouldn't. Allowing them leads to this:
>
> Hm. Seems like the restrictions
On Wed, 18 Dec 2019 at 15:03, Amit Kapila wrote:
>
> On Tue, Dec 17, 2019 at 6:07 PM Masahiko Sawada
> wrote:
> >
> > On Fri, 13 Dec 2019 at 15:50, Amit Kapila wrote:
> > >
> > > > > I think it shouldn't be more than the number with which we have
> > > > > created a parallel context, no? If tha
On Wed, 18 Dec 2019 at 03:39, Mahendra Singh wrote:
>
>
> Thanks for updated patches. I verified my all reported issues and all are
> fixed in v36 patch set.
>
> Below are some review comments:
> 1.
> + /* cap by max_parallel_maintenace_workers */
> + parallel_workers = Min(parallel_workers,
On Thu, Sep 26, 2019 at 1:56 PM Amit Langote wrote:
> On Wed, Sep 4, 2019 at 10:45 AM Amit Langote wrote:
> > On Fri, Aug 9, 2019 at 10:51 AM Amit Langote
> > wrote:
> > To avoid losing track of this, I've added this to November CF.
> >
> > https://commitfest.postgresql.org/25/2277/
> >
> > Str
On Tue, 10 Dec 2019 at 00:30, Mahendra Singh wrote:
>
> On Fri, 6 Dec 2019 at 10:50, Amit Kapila wrote:
> >
> > On Thu, Dec 5, 2019 at 7:44 PM Robert Haas wrote:
> > >
> > > I think it might be a good idea to change what we expect index AMs to
> > > do rather than trying to make anything that th
On Wed, Dec 18, 2019 at 11:46 AM Masahiko Sawada
wrote:
>
> On Wed, 18 Dec 2019 at 15:03, Amit Kapila wrote:
> >
> > I was analyzing your changes related to ReinitializeParallelDSM() and
> > it seems like we might launch more number of workers for the
> > bulkdelete phase. While creating a para
[please trim extra text before responding]
On Wed, Dec 18, 2019 at 12:01 PM Mahendra Singh wrote:
>
> On Tue, 10 Dec 2019 at 00:30, Mahendra Singh wrote:
> >
> >
> > 3.
> > After v35 patch, vacuum.sql regression test is taking too much time due to
> > large number of inserts so by reducing numb
Hi,
It seems that d986d4e87f6 forgot to update a comment upon renaming a variable.
Attached fixes it.
Thanks,
Amit
diff --git a/src/backend/commands/trigger.c b/src/backend/commands/trigger.c
index faeea16d21..99cb5bf557 100644
--- a/src/backend/commands/trigger.c
+++ b/src/backend/commands/trig
On Tue, 17 Dec 2019 at 17:40, Amit Khandekar wrote:
> By the way, the backport patch is turning out to be simpler. It's
> because in pre-12 versions, the file offset is part of the Vfd
> structure, so all the offset handling is not required.
Please have a look at the attached backport patch for P
On Tue, Dec 17, 2019 at 01:54:27PM +0900, Amit Langote wrote:
> Thanks for the updated patch. I don't have any comments, except that
> the text I suggested couple of weeks ago no longer reads clear:
I have spent a couple of extra hours on the patch, and committed it.
There was one issue in logica
On Wed, Dec 18, 2019 at 11:23:17AM +0900, Amit Langote wrote:
> Thanks for adding the test case.
For the archives: this has been applied as of 2acab05.
--
Michael
signature.asc
Description: PGP signature
74 matches
Mail list logo
