From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp]
> Sent: Friday, February 08, 2019 3:52 PM
> Hmm, I had rebased v20 over HEAD as of yesterday evening. CF bot seemed
> to be happy with it too:
>
> http://cfbot.cputube.org/amit-langote.html
>
> Also, I rebased the patches again on the
On 08.02.2019 10:14, Andres Freund wrote:
Hi,
On 2018-03-30 15:53:39 +0300, Konstantin Knizhnik wrote:
Taken in account that vulnerability was found in SSL compression and so
SSLComppression is considered to be deprecated and insecure
On Thu, Feb 7, 2019 at 6:53 PM David Fetter wrote:
> [some style suggestions]
I've included these in v2, and also some additional tweaks for consistency.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From
Hi,
On 2019-02-08 12:18:32 +0530, Ashutosh Sharma wrote:
> When "ON SELECT" rule is created on a table without columns, it
> successfully converts a table into the view. However, when the same is
> done using CREATE VIEW command, it fails with an error saying: "view
> must have at least one
Hi,
On 2018-03-30 15:53:39 +0300, Konstantin Knizhnik wrote:
> Taken in account that vulnerability was found in SSL compression and so
> SSLComppression is considered to be deprecated and insecure
> (http://www.postgresql-archive.org/disable-SSL-compression-td6010072.html),
> it will be nice to
On Fri, Feb 8, 2019 at 12:18 PM Ashutosh Sharma
wrote:
> Hi All,
>
> When "ON SELECT" rule is created on a table without columns, it
> successfully converts a table into the view. However, when the same is
> done using CREATE VIEW command, it fails with an error saying: "view
> must have at
Hi,
On 2019-02-08 07:01:01 +, Iwata, Aya wrote:
> > I still not sure whether it is good idea to make it possible to user to
> > explicitly specify compression algorithm.
> > Right now used streaming compression algorithm is hardcoded and depends on
> > --use-zstd ort --use-zlib configuration
Hi,
I am sorry for my late reply.
> I fixed all issues you have reported except using list of supported
> compression
> algorithms.
Sure. I confirmed that.
> It will require extra round of communication between client and server to
> make a decision about used compression algorithm.
In
Tsunakawa-san,
On 2019/02/08 15:40, Tsunakawa, Takayuki wrote:
> Hi Amit,
>
> I'm afraid v20-0001 fails to apply to the current HEAD (precisely,
> ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.gz). Could you
> check it?
Hmm, I had rebased v20 over HEAD as of yesterday evening.
Hi All,
When "ON SELECT" rule is created on a table without columns, it
successfully converts a table into the view. However, when the same is
done using CREATE VIEW command, it fails with an error saying: "view
must have at least one column". Here is what I'm trying to say:
-- create table t1
Hi Amit,
I'm afraid v20-0001 fails to apply to the current HEAD (precisely,
ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.gz). Could you
check it?
I'm trying to reproduce what Imai-san hit with my patch. His environment is
master@Jan/28 + v18 of your patches. When he added my
Hi,
On 2019-02-08 09:19:31 +0900, Michael Paquier wrote:
> On Thu, Feb 07, 2019 at 11:06:27PM +0100, Peter Eisentraut wrote:
> > Probably right. I figured it would be useful to see what the outcome is
> > with primary_conninfo, so they can be treated similarly.
>
> The interactions with waiting
Noah Misch writes:
> On Thu, Feb 07, 2019 at 10:12:05AM -0500, Tom Lane wrote:
>> I have no particular opinion on whether pgindent should be part of the
>> mix for imath, but I do strongly recommend setting up and documenting a
>> reproducible import process, as I did for src/timezone.
> Good
Amit-san,
On Thu, Feb 7, 2019 at 10:22 AM, Amit Langote wrote:
> Rebased over bdd9a99aac.
I did code review of 0001 and I have some suggestions. Could you check them?
1.
0001: line 418
+* add_inherit_target_child_root() would've added only those
that are
On Thu, Feb 07, 2019 at 10:12:05AM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Feb 06, 2019 at 10:15:24AM -0500, Tom Lane wrote:
> >> I don't object to keeping imported code in a form that matches upstream
> >> as best we can. (Should we also exclude such files from pgindent'ing?)
>
(2019/02/08 10:09), Michael Paquier wrote:
On Thu, Feb 07, 2019 at 09:55:18PM +0900, Etsuro Fujita wrote:
I 100% agree with Tom, and actually, I tried to address his comments, but I
haven't come up with a clear solution for that yet. I really want to
address this, but I won't have much time to
From: Gavin Flower [mailto:gavinflo...@archidevsys.co.nz]
> Remember also that about 1 in 12 men are colour blind.
Thank you for referring to it. I'm one of them -- I'm visually impaired and
use screen reader software. I didn't notice any change in the 2019-03 CF page.
I thought "Ver" is the
On Thu, Feb 7, 2019 at 7:35 PM Tom Lane wrote:
> I have a working patch now, but I think I'm too tired to explain it,
> so I'm going to post it tomorrow instead. It's a big enough change
> that it might be advisable for someone to review it --- are you
> interested?
I'd be happy to review it.
Hi Amit,
From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp]
> Maybe I chose the the subject line of this thread poorly when I began
> working on it. It should perhaps have been something like "speeding up
> planning of point-lookup queries with many partitions" or something like
> that.
Peter Geoghegan writes:
> On Wed, Feb 6, 2019 at 9:15 PM Tom Lane wrote:
>> I have a mostly-working patch along these lines that I hope to
>> finish up and post tomorrow.
> Do you think that you'll end up pushing the HEAD-only fix shortly?
I have a working patch now, but I think I'm too tired
At Fri, 08 Feb 2019 12:03:31 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190208.120331.167280496.horiguchi.kyot...@lab.ntt.co.jp>
> By the way, I'm confused to see that attributes that don't want
> to go external are marked as 'x' in system catalogs. Currently
> (putting aside
Hi, I got redirected here by a kind suggestion by Tom.
At Fri, 28 Sep 2018 22:58:36 +0200, Peter Eisentraut
wrote in
<61666008-d1cd-7a66-33c8-215449f5d...@2ndquadrant.com>
> On 21/08/2018 17:24, Andres Freund wrote:
> >> Attached is a patch that instead moves those special cases into
> >>
On Wed, Feb 6, 2019 at 9:15 PM Tom Lane wrote:
> I have a mostly-working patch along these lines that I hope to
> finish up and post tomorrow.
Do you think that you'll end up pushing the HEAD-only fix shortly? It
would be nice to avoid immediate bitrot of an upcoming revision of the
nbtree patch
Tsunakawa-san,
On 2019/02/08 10:50, Tsunakawa, Takayuki wrote:
> From: David Rowley [mailto:david.row...@2ndquadrant.com]
>> It's good to see work being done to try and improve this, but I think
>> it's best to do it on another thread. I think there was some agreement
>> upthread about this not
On Fri, Feb 8, 2019 at 4:49 AM Thomas Munro
wrote:
> I don't have the answer yet but I have some progress: I finally
> reproduced the "could not find %d free pages" error by running lots of
> concurrent parallel queries. Will investigate.
Sometimes FreeManagerPutInternal() returns a
From: David Rowley [mailto:david.row...@2ndquadrant.com]
> It's good to see work being done to try and improve this, but I think
> it's best to do it on another thread. I think there was some agreement
> upthread about this not being Amit's patch's problem. Doing it here
> will make keeping track
On Fri, 8 Feb 2019 at 14:34, Imai, Yoshikazu
wrote:
>
> On Wed, Feb 6, 2019 at 2:04 AM, Tsunakawa, Takayuki wrote:
> > Can you compare the performance of auto and force_custom_plan again with
> > the attached patch? It uses PGPROC's LOCALLOCK list instead of the hash
> > table.
>
> Thanks for
Tsunakawa-san,
On Wed, Feb 6, 2019 at 2:04 AM, Tsunakawa, Takayuki wrote:
> Can you compare the performance of auto and force_custom_plan again with
> the attached patch? It uses PGPROC's LOCALLOCK list instead of the hash
> table.
Thanks for the patch, but it seems to have some problems.
When
On Thu, Feb 7, 2019 at 9:31 PM Haribabu Kommi
wrote:
> Hi Hackers,
>
> Does increase in Transaction commits per second means good query
> performance?
> Why I asked this question is, many monitoring tools display that number of
> transactions
> per second in the dashboard (including pgadmin).
>
On Thu, Feb 07, 2019 at 09:55:18PM +0900, Etsuro Fujita wrote:
> I 100% agree with Tom, and actually, I tried to address his comments, but I
> haven't come up with a clear solution for that yet. I really want to
> address this, but I won't have much time to work on that at least until
> after
On Fri, 8 Feb 2019 at 13:04, Michael Paquier wrote:
>
> On Thu, Feb 07, 2019 at 03:33:54PM +0100, Daniel Gustafsson wrote:
> > Correct. The idea was to maintain readability while making the regex a bit
> > better, without any claims to make it perfect.
>
> Agreed with your position. I see no
On Thu, Feb 07, 2019 at 12:07:01PM -0300, Alvaro Herrera wrote:
> On 2019-Feb-07, Peter Eisentraut wrote:
>> Another thing I was thinking of: We need some database-global tests.
>> For example, at some point during development, I had broken some variant
>> of REINDEX DATABASE. Where could we put
On Thu, Feb 07, 2019 at 04:16:22PM +0100, Oleksii Kliukin wrote:
> On 7. Feb 2019, at 07:51, Michael Paquier wrote:
> I’ve noticed you returned the 'see max_connections’ parameter there. As
> noticed
> previously in this thread by Kyotaro Horiguchi, it’s not clear what exactly we
> are supposed
On Thu, Feb 07, 2019 at 12:20:35AM -0500, Tom Lane wrote:
> No, that'd be additional effort on top, which I'm not sure I see
> a reason for. Nobody's given a plausible reason why we need
> a machine-readable way to identify the bug reporter's name from
> the commit log. And we get a fair number
On Thu, Feb 07, 2019 at 09:23:43PM +0100, Daniel Gustafsson wrote:
> On 7 Feb 2019, at 16:12, Tom Lane wrote:
>> .. I do strongly recommend setting up and documenting a
>> reproducible import process, as I did for src/timezone.
>
> Strong +1 on this.
+1.
--
Michael
signature.asc
Description:
On Thu, Feb 07, 2019 at 04:10:35PM -0500, Andrew Dunstan wrote:
> Also, SSLServer.pm contains a bunch of lines like this:
> copy_files("ssl/server-*.crt", $pgdata);
>
> I think if we're going to export it maybe we should have a method to set
> up the ssl directory with the required
On Thu, Feb 07, 2019 at 11:06:27PM +0100, Peter Eisentraut wrote:
> Probably right. I figured it would be useful to see what the outcome is
> with primary_conninfo, so they can be treated similarly.
The interactions with waiting for WAL to be available and the WAL
receiver stresses me a bit for
On Thu, Feb 07, 2019 at 10:03:30AM +0100, Daniel Gustafsson wrote:
> Doh, managed to completely overlook that. The attached updated patch also
> fixes the comment, thanks!
That looks fine to me. Could you just add it to the next CF as a bug
fix so as we don't forget? I am pretty sure that
On Thu, Feb 07, 2019 at 12:11:49PM -0300, Alvaro Herrera wrote:
> I looked at it briefly a few weeks ago and it seemed sound, though I
> haven't yet tried to write the constraint display query for psql using
> it, yet -- but that should be straightforward anyway. Let's get it
> committed so we
On Thu, Feb 07, 2019 at 03:33:54PM +0100, Daniel Gustafsson wrote:
> Correct. The idea was to maintain readability while making the regex a bit
> better, without any claims to make it perfect.
Agreed with your position. I see no point is making all the
expressions unreadable for little gain.
Andres Freund writes:
> There's plenty stuff that's chugging along in development but ought to
> be processed at less urgency / by different people, than the stuff
> targeted to be committed soon. It's already frustrating to contribute
> to postgresql for new people, but if they don't get
On 30/01/2019 07:16, Takashi Menjo wrote:
> Sorry but I found that the patchset v2 had a bug in managing WAL segment
> file offset. I fixed it and updated a patchset as v3 (attached).
I'm concerned with how this would affect the future maintenance of this
code. You are introducing a whole
On Thu, Feb 7, 2019 at 4:02 AM Andres Freund wrote:
> On 2019-02-07 12:53:39 +0100, Peter Eisentraut wrote:
> > What is the meaning of this? If something is meant for 13, shouldn't it
> > be moved to the next commit fest?
>
> Why? There's plenty stuff that's chugging along in development but
On 07/02/2019 09:14, Sergei Kornilov wrote:
> We have some possible trouble with restore_command? As far i know it also
> only looked at by the startup process.
Probably right. I figured it would be useful to see what the outcome is
with primary_conninfo, so they can be treated similarly.
--
Hi,
On 2019-02-07 09:03:06 +, Dave Page wrote:
> On Thu, Feb 7, 2019 at 8:26 AM Peter Eisentraut
> wrote:
> >
> > I'm wondering whether we should phase out the use of the ossp-uuid
> > library? (not the uuid-ossp extension) We have had preferred
> > alternatives for a while now, so it
On 07/02/2019 10:03, Dave Page wrote:
> Much as I'd like to get rid of it, we don't have an alternative for
> Windows do we?
Yes, that appears to be a significant problem, so we'll have to keep it
for the time being.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL
On 08/02/2019 00:53, Peter Eisentraut wrote:
On 06/02/2019 21:09, Magnus Hagander wrote:
This has now been pushed and is available. I've set it up with stable,
12 and 13 as possible versions for now, but I have not added any tags to
the existing patches (except for one, in order to test it).
On 2/7/19 4:01 PM, Andrew Dunstan wrote:
> On 2/6/19 8:44 PM, Michael Paquier wrote:
>> On Wed, Feb 06, 2019 at 08:34:11PM -0500, Andrew Dunstan wrote:
>>> The obvious solution is to perform the same surgery for the ssl and
>>> pg_rewind tests that we performed for genbki.pl and other scripts,
Hi,
On 2018-11-12 20:10:42 +0900, Kyotaro HORIGUCHI wrote:
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> index 7eed5866d2..e52ae54821 100644
> --- a/src/backend/access/transam/xlog.c
> +++ b/src/backend/access/transam/xlog.c
> @@ -8587,9 +8587,9 @@
On 2/6/19 8:44 PM, Michael Paquier wrote:
> On Wed, Feb 06, 2019 at 08:34:11PM -0500, Andrew Dunstan wrote:
>> The obvious solution is to perform the same surgery for the ssl and
>> pg_rewind tests that we performed for genbki.pl and other scripts, but
>> in these cases the used modules are not
While I've been staring at dependency.c, I've realized that this bit
in findDependentObjects is unsafe:
/*
* First, release caller's lock on this object and get
* deletion lock on the owning object. (We must release
* caller's
> On 7 Feb 2019, at 16:12, Tom Lane wrote:
> .. I do strongly recommend setting up and documenting a
> reproducible import process, as I did for src/timezone.
Strong +1 on this.
cheers ./daniel
> On Tue, Feb 5, 2019 at 12:54 AM Alvaro Herrera
> wrote:
>
> Actually, index-based replica identities failed in pg_dump: we first
> create the index ONLY on the partitioned table (marking it as invalid),
> so when we immediately do the ALTER TABLE/REPLICA IDENTITY, it rejects
> the invalid
> On 7 Feb 2019, at 18:20, David Fetter wrote:
>
> On Thu, Feb 07, 2019 at 10:10:32AM +0900, Michael Paquier wrote:
>> On Wed, Feb 06, 2019 at 03:41:20PM +0100, Daniel Gustafsson wrote:
>>> Correct. One could argue that the regex is still suboptimal since “COMMENT
>>> ON
>>> DATABASE postgres
Alvaro Herrera writes:
> So,
> "The error recovery code can either do PG_RE_THROW to propagate the
> error outwards, or do a (sub)transaction abort. Failure to do so may
> leave the system in an inconsistent state for further processing."
WFM.
regards, tom lane
> On 2019-02-06 13:09:59 -0300, Alvaro Herrera wrote:
> > This is obviously wrong; while we have a couple of codesites that omit
> > it, it's not a generally available coding pattern. I think we should
> > amend that comment. I propose: "The error recovery code must normally
> > do
Why is this script talking to me?
On 2019-Feb-07, David Fetter wrote:
> Similarly,
>
> die "-I, the header include path, must be specified.\n" unless $include_path;
But why must thee, oh mighty header include path, be specified?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
Nathan Wagner writes:
> On Wed, Feb 06, 2019 at 10:50:51PM -0500, Tom Lane wrote:
>> I do have a modest proposal for improving things going forward. How
>> about, if a commit purports to fix a particular bug, that we say
>> "Fixes: https://postgr.es/m/" in place of our current
>> habit of saying
While reviewing [1] it occurred to me that it might not be clean that
postgresGetForeignUpperPaths() adds ORDER BY to the remote query when it
receives stage=UPPERREL_GROUP_AGG. Shouldn't that only happen for
UPPERREL_ORDERED? Thus the processing of UPPERREL_ORDERED would have to be
able to handle
On Thu, Feb 07, 2019 at 10:09:08AM +0100, John Naylor wrote:
> This was suggested in
>
> https://www.postgresql.org/message-id/11766.1545942853%40sss.pgh.pa.us
>
> I also adjusted usage() to match. There might be other scripts that
> could use this treatment, but I figure this is a good start.
>
On Thu, Feb 7, 2019 at 9:10 PM Jakub Glapa wrote:
> > Do you have query logging enabled ? If not, could you consider it on at
> > least
> one of those servers ? I'm interested to know what ELSE is running at the
> time
> that query failed.
>
> Ok, I have configured that and will enable in the
čt 7. 2. 2019 v 16:03 odesílatel Alvaro Herrera
napsal:
> On 2019-Feb-07, Pavel Stehule wrote:
>
> > Your example
> >
> > postgres=# \dPtn+
> > List of partitioned tables
> > ┌┬┬───┬─┬┬─┐
> > │ Schema │ Name │ Owner │
On Thu, Feb 07, 2019 at 10:10:32AM +0900, Michael Paquier wrote:
> On Wed, Feb 06, 2019 at 03:41:20PM +0100, Daniel Gustafsson wrote:
> > Correct. One could argue that the regex is still suboptimal since “COMMENT
> > ON
> > DATABASE postgres IS ;” will be matched as well, but there I think the
Etsuro Fujita wrote:
> (2018/12/28 15:50), Etsuro Fujita wrote:
> > Attached is a new version of the
> > patch.
>
> Here is an updated version of the patch set. Changes are:
I've spent some time reviewing the patches.
First, I wonder if the information on LIMIT needs to be passed to the
FDW.
On Wed, Feb 06, 2019 at 10:50:51PM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Feb-06, Tom Lane wrote:
> >> That will have caught exactly none of my own commits.
>
> > Well, what text do you use? I see "Per bug #XYZ" in the free-form text
> > of your commit messages, though that
On Thu, May 17, 2018 at 3:49 AM Heikki Linnakangas wrote:
> On 14/05/18 02:15, Thomas Munro wrote:
> > Since commit cdf91edb (2012), nodeIndexonlyscan.c says:
> >
> > /*
> > * Predicate locks for index-only scans must be
> > acquired at the page
> >
> On 7. Feb 2019, at 07:51, Michael Paquier wrote:
>
> On Sat, Feb 02, 2019 at 10:35:20AM +0900, Michael Paquier wrote:
>> Oh, I have just noticed this patch when doing my vacuum homework. I
>> have just added my name as committer, just wait a bit until the CF is
>> closed before I begin
Noah Misch writes:
> On Wed, Feb 06, 2019 at 10:15:24AM -0500, Tom Lane wrote:
>> I don't object to keeping imported code in a form that matches upstream
>> as best we can. (Should we also exclude such files from pgindent'ing?)
> I think it depends on how much time one spends merging upstream
On 2019-Feb-07, Michael Paquier wrote:
> On Thu, Feb 07, 2019 at 01:34:15PM +0900, Amit Langote wrote:
> > Yeah, I agree. Should also check with Alvaro maybe?
>
> Good idea. Let's wait for his input.
I looked at it briefly a few weeks ago and it seemed sound, though I
haven't yet tried to
On 2019-Feb-07, Pavel Stehule wrote:
> Your example
>
> postgres=# \dPtn+
> List of partitioned tables
> ┌┬┬───┬─┬┬─┐
> │ Schema │ Name │ Owner │ Parent name │Size│ Description │
>
Peter Eisentraut writes:
> I'm wondering whether we should phase out the use of the ossp-uuid
> library?
It's not really costing us any maintenance effort that I've noticed,
so I vote no. Whether or not there are any people who can't use
another alternative, it would be more work to rip out
> On 7 Feb 2019, at 13:55, Tels wrote:
> On Wed, February 6, 2019 8:10 pm, Michael Paquier wrote:
>> On Wed, Feb 06, 2019 at 03:41:20PM +0100, Daniel Gustafsson wrote:
>>> Correct. One could argue that the regex is still suboptimal since
>>> “COMMENT ON
>>> DATABASE postgres IS ;” will be
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Hello
Sorry for late response. I review latest patch version.
I
Hi Thomas,
Thanks for your help,
Here are my experiments on the AIX 7.2 machine.
That sounds good !
About "huge", we have plans for AIX. But it is not urgent. Let's go with this
patch.
Regards,
Tony
Buffers for SharedMemory PSIZ has been extended by:
ldedit
(2019/02/02 10:21), Michael Paquier wrote:
On Fri, Nov 16, 2018 at 01:35:15PM -0500, Tom Lane wrote:
I wonder whether we'd be better off thinking of a way to let FDWs
invent additional system column IDs for their tables, so that
something like a remote table OID could be represented in the
Moin,
On Wed, February 6, 2019 8:10 pm, Michael Paquier wrote:
> On Wed, Feb 06, 2019 at 03:41:20PM +0100, Daniel Gustafsson wrote:
>> Correct. One could argue that the regex is still suboptimal since
>> “COMMENT ON
>> DATABASE postgres IS ;” will be matched as well, but there I think the
>>
At Thu, 07 Feb 2019 15:24:18 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190207.152418.139132570.horiguchi.kyot...@lab.ntt.co.jp>
> I'm going to retake numbers with search-only queries.
Yeah, I was stupid.
I made a rerun of benchmark using "-S -T 30" on the server build
with no
On Thu, Feb 07, 2019 at 12:49:43PM +0100, Peter Eisentraut wrote:
> Anyway, that's all cosmetics. Are there any more functional or
> correctness issues to be addressed?
Not that I can think of. At least this evening.
> Another thing I was thinking of: We need some database-global tests.
> For
Hi,
On 2019-02-07 12:53:39 +0100, Peter Eisentraut wrote:
> On 06/02/2019 21:09, Magnus Hagander wrote:
> > This has now been pushed and is available. I've set it up with stable,
> > 12 and 13 as possible versions for now, but I have not added any tags to
> > the existing patches (except for one,
On 30/01/2019 06:16, Michael Paquier wrote:
> On Tue, Jan 29, 2019 at 09:51:35PM +0100, Peter Eisentraut wrote:
>> On 16/01/2019 09:27, Michael Paquier wrote:
>>> index_create does not actually need its extra argument with the tuple
>>> descriptor. I think that we had better grab the column name
čt 7. 2. 2019 v 11:25 odesílatel Amit Langote
napsal:
> Hi,
>
> On 2019/02/07 18:08, Pavel Stehule wrote:
> > čt 7. 2. 2019 v 9:51 odesílatel Amit Langote <
> langote_amit...@lab.ntt.co.jp>
> >> \dPn seems to work fine, but I don't quite understand why \dPn+ should
> >> show the sizes only for
On 7/2/19 10:03, Dave Page wrote:
On Thu, Feb 7, 2019 at 8:26 AM Peter Eisentraut
wrote:
I'm wondering whether we should phase out the use of the ossp-uuid
library? (not the uuid-ossp extension)
Hmm... FWIW, just get it in core altogether? Seems small and useful
enough... if it carries the
Hi Hackers,
Does increase in Transaction commits per second means good query
performance?
Why I asked this question is, many monitoring tools display that number of
transactions
per second in the dashboard (including pgadmin).
During the testing of bunch of queries with different set of
Hi,
On 2019/02/07 18:08, Pavel Stehule wrote:
> čt 7. 2. 2019 v 9:51 odesílatel Amit Langote
>> \dPn seems to work fine, but I don't quite understand why \dPn+ should
>> show the sizes only for nested partitions of level. Consider the
(correcting words of my previous email: ... of level 1.)
>
> Do you have query logging enabled ? If not, could you consider it on at
least
one of those servers ? I'm interested to know what ELSE is running at the
time
that query failed.
Ok, I have configured that and will enable in the time window when the
errors usually occur. I'll report as soon as I
Hi, thanks for recent rapid work.
>From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
>At Tue, 5 Feb 2019 19:05:26 -0300, Alvaro Herrera
>wrote in <20190205220526.GA1442@alvherre.pgsql>
>> On 2019-Feb-05, Tomas Vondra wrote:
>>
>> > I don't think we need to remove the expired
Hello.
At Thu, 7 Feb 2019 15:51:46 +0900, Michael Paquier wrote
in <20190207065146.gn4...@paquier.xyz>
> On Sat, Feb 02, 2019 at 10:35:20AM +0900, Michael Paquier wrote:
> > Oh, I have just noticed this patch when doing my vacuum homework. I
> > have just added my name as committer, just wait
čt 7. 2. 2019 v 9:51 odesílatel Amit Langote
napsal:
> Hi Pavel,
>
> Thanks for sending the updated patch.
>
> On 2018/12/19 15:38, Pavel Stehule wrote:
> > út 18. 12. 2018 v 8:49 odesílatel Amit Langote <
> >> On 2018/12/17 17:48, Pavel Stehule wrote:
> >>> I can imagine new additional flag -
This was suggested in
https://www.postgresql.org/message-id/11766.1545942853%40sss.pgh.pa.us
I also adjusted usage() to match. There might be other scripts that
could use this treatment, but I figure this is a good start.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL
> On 7 Feb 2019, at 05:12, Michael Paquier wrote:
>
> On Wed, Feb 06, 2019 at 11:18:22PM +0100, Daniel Gustafsson wrote:
>> The errorhandling in be_tls_init(), and functions called from it, set the
>> appropriate elevel by the isServerStart. ssl_protocol_version_to_openssl()
>> is
>> however
On Thu, Feb 7, 2019 at 8:26 AM Peter Eisentraut
wrote:
>
> I'm wondering whether we should phase out the use of the ossp-uuid
> library? (not the uuid-ossp extension) We have had preferred
> alternatives for a while now, so it shouldn't be necessary to use this
> anymore, except perhaps in some
Hi Pavel,
Thanks for sending the updated patch.
On 2018/12/19 15:38, Pavel Stehule wrote:
> út 18. 12. 2018 v 8:49 odesílatel Amit Langote <
>> On 2018/12/17 17:48, Pavel Stehule wrote:
>>> I can imagine new additional flag - line "n" nested - and then we can
>>> display nested partitioned
Alvaro Herrera writes:
> On 2019-Feb-06, Arseny Sher wrote:
>
>>
>> Alvaro Herrera writes:
>>
>> > note the additional pg_temp_XYZ row in the middle. This is caused by
>> > the rewrite in ALTER TABLE. Peter E fixed that in Pg11 in commit
>> > 325f2ec55; I don't think there's much to do in
On 04/02/2019 23:02, Peter Eisentraut wrote:
> Some things from this thread were left for post-11; see attached patch.
>
> Specifically, this changes pg_dump and ruleutils.c to use the FUNCTION
> keyword instead of PROCEDURE in trigger and event trigger definitions,
> which was postponed because
As discussed in [0], should we restrict access to pg_stat_ssl to
superusers (and an appropriate pg_ role)?
If so, is there anything in that view that should be made available to
non-superusers? If not, then we could perhaps do this via a simple
permission change instead of going the route of
On Thu, Feb 7, 2019 at 9:27 AM Moon, Insung
wrote:
>
> Dear Ibrar Ahmed.
>
> From: Ibrar Ahmed [mailto:ibrar.ah...@gmail.com]
> Sent: Thursday, February 07, 2019 4:09 AM
> To: Moon, Insung
> Cc: Tom Lane; PostgreSQL-development
> Subject: Re: [Proposal] Table-level Transparent Data Encryption
I'm wondering whether we should phase out the use of the ossp-uuid
library? (not the uuid-ossp extension) We have had preferred
alternatives for a while now, so it shouldn't be necessary to use this
anymore, except perhaps in some marginal circumstances? As we know,
ossp-uuid isn't maintained
Hello
>> I think the recovery parameters
>>
>> archive_cleanup_command
>
> Only triggered by the checkpointer.
>
>> promote_trigger_file
>> recovery_end_command
>> recovery_min_apply_delay
>
> Only looked at by the startup process.
We have some possible trouble with
Here is a patch that makes more use of unconstify() by replacing casts
whose only purpose is to cast away const. Also a preliminary patch to
remove casts that were useless to begin with.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote
99 matches
Mail list logo
