On Fri, Mar 15, 2019 at 02:24:29PM +0900, Kyotaro HORIGUCHI wrote:
> Yeah, surely it is typo, but not for tsvector but
> to_tsvector. See the block just below.
Yes, I agree with Horiguchi-san here that this refers to the function
call, and not the data type. Everybody agrees?
--
Michael
At Friday, March 15, 2019 2:24 PM, Kyotaro HORIGUCHI wrote
> Yeah, surely it is typo, but not for tsvector but to_tsvector. See the
> block just below.
>
> > -- json_to_tsvector corner cases
> > select json_to_tsvector('""'::json, '"all"');
Oops, thank you for your advice.
I fixed it.
Regards,
On Thu, 14 Mar 2019 at 23:37, Edmund Horner wrote:
> On Thu, 14 Mar 2019 at 23:06, David Rowley
> wrote:
> > Just looking again, I think the block of code starting:
> >
> > + if (density > 0.0)
> >
> > needs a comment to mention what it's doing. Perhaps:
> >
> > + /*
> > + * Using the average
Amit-san,
I have another little comments about v31-patches.
* We don't need is_first_child in inheritance_planner().
On Fri, Mar 8, 2019 at 9:18 AM, Amit Langote wrote:
> On 2019/03/08 16:16, Imai, Yoshikazu wrote:
> > I attached the diff of modification for v26-0003 patch which also
> contains
Hi Horiguchi-san, Kuroda-san
Horiguchi-san, thank you for your comment.
I have a question.
A bug of StatementCache is occurred in previous versions.
Should a patch be separated?
> Horiguchi-san wrote:
> It seems like a local cache of server-side data, which is similar
> to catcache on server
Hello.
At Fri, 15 Mar 2019 04:37:03 +, "Kato, Sho" wrote
in <25C1C6B2E7BE044889E4FE8643A58BA963E1D03D@G01JPEXMBKW03>
> Hi,
>
> I think ts_vector is a typo for tsvector.
> --- ts_vector corner cases
> +-- tsvector corner cases
> select to_tsvector('""'::json);
Yeah, surely it is typo,
Hi all,
Facing issue in using special characters. We are trying to insert records to a
remote Postgres Server and our application not able to perform this because of
errors.
It seems that issue is because of the special characters that has been used in
one of the field of a row.
Regards
Hello hackers,
What exactly is a savepointLevel?
They seem to have been there for 15 years[1], diligently copied from
parent transactions to children, fastidiously checked to avoid crossing
a level on rollback or release, but does anything ever change the level
from its initial value? I'm
Hello.
At Thu, 14 Mar 2019 17:26:11 -0700, Shawn Debnath wrote in
<20190315002611.ga1...@f01898859afd.ant.amazon.com>
> Thank you reviewing. Comments inline.
>
> On Wed, Mar 13, 2019 at 05:24:15PM +0900, Kyotaro HORIGUCHI wrote:
> > > Agree. In my testing WaitEventSetWait did the work for
On Mon, Mar 4, 2019 at 10:17 AM Thomas Munro wrote:
> On Thu, Oct 11, 2018 at 10:15 AM Kevin Grittner wrote:
> > It applies and builds clean, it passed make world with cassert and TAP
> > tests, and I can't see any remaining flaws. This is true both of just
> > the 0001 v16 patch and that with
Hi,
I think ts_vector is a typo for tsvector.
regards,
Sho Kato
fix-typo-for-tsvector.patch
Description: fix-typo-for-tsvector.patch
Hi
I propose mentioned functions without specified separator. In this case the
string is transformed to array of chars, in second case, the array of chars
is transformed back to string.
Comments, notes?
Regards
Pavel
Looks good.
On Thu, Mar 14, 2019 at 12:06:45PM +0100, Peter Eisentraut wrote:
> + # Temporarily unset PGAPPNAME so that the server doesn't inherit
> + # it. Otherwise this could affect libpqwalreceiver connections in
> + # confusing ways.
> + my $save_pgappname = $ENV{PGAPPNAME};
Hello.
At Thu, 14 Mar 2019 14:32:49 +0100, Dmitry Dolgov <9erthali...@gmail.com> wrote
in
> > On Tue, Mar 5, 2019 at 4:05 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> >
> > Although there are still some rough edges, e.g. going forth, back and forth
> > again leads to a sutiation, when
Hi,all
On website: https://wiki.postgresql.org/wiki/Todo#libpq
I found that in libpq module,there is a todo case:
---
Prevent PQfnumber() from lowercasing unquoted column names
PQfnumber() should never have been doing
On Fri, Mar 15, 2019 at 11:50:27AM +0900, Michael Paquier wrote:
> - Rename the control file when beginning the enabling operation, with
> a callback to rename the file back if the operation is interrupted.
>
> Does this make sense?
Just before I forget... Please note that this handles
On Thu, Mar 14, 2019 at 04:26:20PM +0100, Michael Banck wrote:
> Am Donnerstag, den 14.03.2019, 15:26 +0100 schrieb Magnus Hagander:
>> One big-hammer method could be similar to what pg_upgrade does --
>> temporarily rename away the controlfile so postgresql can't start, and
>> when done, put it
From: mikalaike...@ibagroup.eu [mailto:mikalaike...@ibagroup.eu]
> Do you mind me asking you whether you have thought that solving your problem
> can lead to the problem in the other user applications?
> Let's imagine a possible problem:
> 1. end-user sets 'socket_timeout' only for current session
From: Robert Haas [mailto:robertmh...@gmail.com]
> Now you might say - what if the server is stopped not because of
> SIGSTOP but because of some other reason, like it's waiting for a
> lock? Well, in that case, the database server is still functioning,
> and you will not want the connection to
Hi, David
On Thu, Mar 14, 2019 at 9:04 AM, David Rowley wrote:
> On Thu, 14 Mar 2019 at 21:35, Imai, Yoshikazu
> wrote:
> > 0007:
> > * This changes some processes using "for loop" to using
> "while(bms_next_member())" which speeds up processing when we scan few
> partitions in one statement,
At Thu, 14 Mar 2019 14:32:49 +0100, Dmitry Dolgov <9erthali...@gmail.com> wrote
in
> > On Tue, Mar 5, 2019 at 4:05 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> >
> > Although there are still some rough edges, e.g. going forth, back and forth
> > again leads to a sutiation, when `_bt_first`
On Thu, Mar 14, 2019 at 03:23:59PM +0100, Magnus Hagander wrote:
> Are you suggesting we should support running with a master with checksums
> on and a standby with checksums off in the same cluster? That seems.. Very
> fragile.
Well, saying that it is supported is a too big term for that. What
Amit-san,
On Thu, Mar 14, 2019 at 9:04 AM, Amit Langote wrote:
> > 0002:
> > * I don't really know that delaying adding resjunk output columns to
> the plan doesn't affect any process in the planner. From the comments
> of PlanRowMark, those columns are used in only the executor so I think
>
From: Robert Haas [mailto:robertmh...@gmail.com]
> One other thing -- I looked a bit into the pgsql-jdbc implementation
> of a similarly-named option, and it does seem to match what you are
> proposing here. I wonder what user experiences with that option have
> been like.
One case I faintly
On 3/14/19 12:56 PM, Kyotaro HORIGUCHI wrote:
> At Wed, 13 Mar 2019 19:37:45 +1300, David Rowley
> wrote in
>
>> On Wed, 13 Mar 2019 at 17:20, Kyotaro HORIGUCHI
>> wrote:
>>> bms_member_index seems working differently than maybe expected.
>>>
>>> bms_member_index((2, 4), 0) => 0, (I think)
On 2019-02-28 23:41, Alvaro Herrera wrote:
> Maybe ADD GENERATED AS IDENTITY / DROP IDENTITY should recurse; not
> really sure about this one. Peter?
No, the intention is that only the partition root has the identity
property. If you wanted to make it recurse, then you'd need to arrange
it so
On 2019-03-09 02:19, Haribabu Kommi wrote:
> Yes, I agree that it may be a problem if the existing data directory
> permissions
> are 0700 to changing it to 0750. But it may not be a problem for the
> scenarios,
> where the existing data permissions >=0750, to the upstream permissions.
> Because
Hi!
On Thu, Mar 14, 2019 at 7:56 AM Andreas Karlsson wrote:
> Yeah, your patch is sadly stuck behind the refactoring, and the
> refactoring proved to be harder to do than I initially thought. The
> different code paths for executing CREATE MATERIALIZED VIEW are so
> different that it is hard to
Attached 10th versions of the patches.
Fixed two bugs in patches 3 and 10 (see below).
Patch 3 was extracted from the main patch 5 (patch 4 in v9).
On 11.03.2019 20:42, Alexander Korotkov wrote:
Hi!
I've some questions regarding this patchset.
1) This comment needs to be revised. Now,
Robert Haas writes:
> On Thu, Mar 14, 2019 at 12:36 PM Tom Lane wrote:
>> Hmm, I wonder why not. I suppose the answer is that
>> the leak is worse in HEAD than before, but how come?
> I'd like to know that, too, but right now I don't.
I poked at this some more, by dint of adding some memory
Hi,
There seems to be a bug in pgbench when used with '-R' option, resulting
in stuck pgbench process. Reproducing it is pretty easy:
echo 'select 1' > select.sql
while /bin/true; do
pgbench -n -f select.sql -R 1000 -j 8 -c 8 -T 1 > /dev/null 2>&1;
date;
done;
I do get a stuck pgbench
On 3/14/19 3:08 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/14/19 12:41 AM, Tom Lane wrote:
>>> So far, no other failures ...
>> I have replicated this on my Msys2 test system.
>> I assume it's a bug in the mingw math library. I think jacana is the
>> only currently reporting mingw
On 2019-Mar-14, Pavel Stehule wrote:
> I looking to code
>
> void(*nodefree) (xmlNodePtr) = NULL;
> volatile xmlBufferPtr buf = NULL;
>
> should not be "nodefree" volatile too?
Ah, good question. I remember I had it volatile and removed it for some
reason, though I
Hi
pá 8. 3. 2019 v 19:44 odesílatel Alvaro Herrera
napsal:
> On 2019-Mar-08, Alvaro Herrera wrote:
>
> > > Maybe we can call explicitly xmlFreeDoc instead xmlFreeNode
> > >
> > > some like
> > >
> > > if (cur_copy->type == XML_DOCUMENT_NODE)
> > > xmlFreeDoc((xmlDocPtr) cur_copy);
> > > else
On Thu, Mar 14, 2019 at 3:36 PM Alvaro Herrera wrote:
> Well, I suppose that can be implemented as an optimization on top of
> what we have, but I think that we should first get this feature right,
> and later we can see about improving it.
Sure, not arguing with that.
> In any case, since the
On 2019-Mar-14, Robert Haas wrote:
> On Thu, Mar 14, 2019 at 1:40 PM Alvaro Herrera
> wrote:
> > When you say "fk (a) references pk1" you're saying that all the values
> > in fk(a) must appear in pk1. OTOH when you say "fk references pk" you
> > mean that the values might appear anywhere in
Andrew Dunstan writes:
> On 3/14/19 12:41 AM, Tom Lane wrote:
>> So far, no other failures ...
> I have replicated this on my Msys2 test system.
> I assume it's a bug in the mingw math library. I think jacana is the
> only currently reporting mingw member :-( The MSVC members appear to be
>
On Thu, Mar 14, 2019 at 4:00 AM Heikki Linnakangas wrote:
> Oh yeah, that makes perfect sense. I wonder why we haven't done it like
> that before? The new page split logic makes it more likely to help, but
> even without that, I don't see any downside.
The only downside is that we spend a few
On Thu, Mar 14, 2019 at 1:40 PM Alvaro Herrera wrote:
> Once I was finished, fixed bugs and tested it, I realized that that was
> a stupid thing to have done -- because THOSE ARE DIFFERENT CONSTRAINTS.
This made me laugh.
> When you say "fk (a) references pk1" you're saying that all the values
On Thu, Mar 14, 2019 at 1:40 PM Tom Lane wrote:
> So here's my problem with that argument: you're effectively saying that
> you needn't write any API spec for the PartitionDirectory functions
> because you intend that every person calling them will read their code,
> carefully and fully, before
On Thu, Mar 14, 2019 at 1:16 PM Tom Lane wrote:
> Actually, now that I've absorbed a bit more about 898e5e329,
> I don't like very much about it at all. I think having it
> try to hang onto pointers into the relcache is a completely
> wrongheaded design decision, and the right way for it to work
Robert Haas writes:
> On Thu, Mar 14, 2019 at 12:56 PM Tom Lane wrote:
>> It's completely not acceptable that every reader of this code should
>> have to reverse-engineer these design assumptions, especially given
>> how shaky they are.
> Well, one reason is that everything you just said is
On 2019-Feb-28, Amit Langote wrote:
Hello
> In the following case:
>
> create table pk (a int primary key) partition by list (a);
> create table pk1 (a int primary key);
> create table fk (a int references pk1);
>
> -- adds FK referencing pk1 via ATAddForeignKeyConstraint recursion
> alter
On Thu, Mar 14, 2019 at 12:56 PM Tom Lane wrote:
> Agreed, but the comments in this area are crap. Why doesn't
> CreatePartitionDirectory say something like
>
> * The object lives inside the given memory context and will be
> * freed when that context is destroyed. Nonetheless, the caller
>
On Thu, Mar 14, 2019 at 12:36 PM Tom Lane wrote:
> Hmm, I wonder why not. I suppose the answer is that
> the leak is worse in HEAD than before, but how come?
I'd like to know that, too, but right now I don't.
> I followed your reference to 898e5e329, and I've got to say that
> the hunk it adds
I wrote:
> Agreed, but the comments in this area are crap.
Actually, now that I've absorbed a bit more about 898e5e329,
I don't like very much about it at all. I think having it
try to hang onto pointers into the relcache is a completely
wrongheaded design decision, and the right way for it to
Robert Haas writes:
> On Thu, Mar 14, 2019 at 3:13 AM Amit Langote
> wrote:
>> I'm curious why DestroyPartitionDirectory doesn't do
>> hash_destroy(pdir->pdir_hash)?
> What would be the point? It's more efficient to let context teardown
> take care of it.
Agreed, but the comments in this area
Robert Haas writes:
> I did not back-patch, because the code is in a different file in v11,
> none of the hunks of the patch apply on v11, and v11 is not failing on
> hyrax.
Hmm, I wonder why not. I suppose the answer is that
the leak is worse in HEAD than before, but how come?
I followed your
On Wed, Mar 13, 2019 at 2:59 PM Robert Haas wrote:
> Yeah, that probably makes sense, though it might be polite to wait
> another hour or two to see if anyone wants to argue with that approach
> further.
Hearing nobody, done. If someone wants to argue more we can always
change it later.
I did
tushar writes:
> While running sqlsmith against 12devel, got the the following
> assertion- (issue is reproducible on v10/v11 as well)
> TRAP: FailedAssertion("!(bms_is_subset(appendrel->lateral_relids,
> required_outer))", File: "relnode.c", Line: 1521)
Doesn't crash for me, but that's
On Thu, Mar 14, 2019 at 3:13 AM Amit Langote
wrote:
> I'm curious why DestroyPartitionDirectory doesn't do
> hash_destroy(pdir->pdir_hash)?
What would be the point? It's more efficient to let context teardown
take care of it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
On Thu, Mar 14, 2019 at 6:12 AM David Rowley
wrote:
> On Wed, 6 Mar 2019 at 10:13, Robert Haas wrote:
> > Would anyone like to argue that there is any other reason not to
> > commit these patches?
>
> Hi Robert,
>
> Thanks for working on this. I'm sorry I didn't get a chance to
> dedicate some
Hi,
Am Donnerstag, den 14.03.2019, 15:32 +0100 schrieb Magnus Hagander:
> On Thu, Mar 14, 2019 at 3:28 PM Christoph Berg wrote:
> > Re: Magnus Hagander 2019-03-14
> >
> > > Are you suggesting we should support running with a master with checksums
> > > on and a standby with checksums off in
On Wed, Mar 13, 2019 at 8:18 PM Heikki Linnakangas wrote:
>
> I started to consider rewriting the data structure into something more
> like B-tree. Then I remembered that I wrote a data structure pretty much
> like that last year already! We discussed that on the "Vacuum: allow
> usage of more
Hi,
Am Donnerstag, den 14.03.2019, 15:26 +0100 schrieb Magnus Hagander:
> Given that the failure is data corruption, I don't think big fat
> warning is enough. We should really make it impossible to start up the
> postmaster by mistake during the checksum generation. People don't
> read the
On 3/13/19 5:38 PM, Tom Lane wrote:
regression=# select amopopr::regoperator from pg_amop where amopfamily = 2745;
amopopr
---
&&(anyarray,anyarray)
@>(anyarray,anyarray)
<@(anyarray,anyarray)
=(anyarray,anyarray)
(4 rows)
and none of those are obviously
On Thu, Mar 14, 2019 at 11:53 PM tushar wrote:
>
> Hi,
>
> While running sqlsmith against 12devel, got the the following
> assertion- (issue is reproducible on v10/v11 as well)
>
> TRAP: FailedAssertion("!(bms_is_subset(appendrel->lateral_relids,
> required_outer))", File: "relnode.c", Line:
On 3/14/19 9:13 AM, Mitar wrote:> I just want to make sure if I
understand correctly. But my initial
proposal/patch is currently waiting first for all patches for the
refactoring to happen, which are done by amazing Andreas? This sounds
good to me and I see a lot of progress/work has been done
Hi,
While running sqlsmith against 12devel, got the the following
assertion- (issue is reproducible on v10/v11 as well)
TRAP: FailedAssertion("!(bms_is_subset(appendrel->lateral_relids,
required_outer))", File: "relnode.c", Line: 1521)
stack trace -
#0 0x7f2a2f349277 in raise ()
On Thu, Mar 14, 2019 at 3:28 PM Christoph Berg wrote:
> Re: Magnus Hagander 2019-03-14 zmb8qck7ndmchey5...@mail.gmail.com>
> > Are you suggesting we should support running with a master with checksums
> > on and a standby with checksums off in the same cluster? That seems..
> Very
> > fragile.
Re: Magnus Hagander 2019-03-14
> Are you suggesting we should support running with a master with checksums
> on and a standby with checksums off in the same cluster? That seems.. Very
> fragile.
The case "shut down master and standby, run pg_checksums on both, and
start them again" should be
On Thu, Mar 14, 2019 at 5:39 AM Michael Paquier wrote:
> On Wed, Mar 13, 2019 at 08:56:33PM +0900, Michael Paquier wrote:
> > On Wed, Mar 13, 2019 at 12:09:24PM +0100, Michael Banck wrote:
> > > The attached patch should do the above, on top of Michael's last
> > > patchset.
> >
> > What you are
On Thu, Mar 14, 2019 at 1:23 AM Michael Paquier wrote:
> On Wed, Mar 13, 2019 at 12:24:21PM +0100, Magnus Hagander wrote:
> > Enabling or disabling the checksums offline on the master quite clearly
> > requires a rebuild of the standby, there is no other way (this is one of
> > the reasons for
On Thu, Mar 14, 2019 at 12:37 PM John Naylor
wrote:
>
> On Thu, Mar 14, 2019 at 2:17 PM Amit Kapila wrote:
> >
> > 1. Added an Assert in new_cluster_needs_fsm() that old cluster version
> > should be >= 804 as that is where fsm support has been added.
>
> There is already an explicit check for
Le 28/02/2019 à 09:26, Imai, Yoshikazu a écrit :
> Hosoya-san
>
> On Wed, Feb 27, 2019 at 6:51 AM, Yuzuko Hosoya wrote:
>>> From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp]
>>> Sent: Wednesday, February 27, 2019 11:22 AM
>>>
>>> Hosoya-san,
>>>
>>> On 2019/02/22 17:14, Yuzuko Hosoya
One other thing -- I looked a bit into the pgsql-jdbc implementation
of a similarly-named option, and it does seem to match what you are
proposing here. I wonder what user experiences with that option have
been like.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
Hi,
Am Mittwoch, den 13.03.2019, 17:54 +0100 schrieb Magnus Hagander:
> On Wed, Mar 13, 2019 at 4:51 PM Michael Banck
> wrote:
> > Am Mittwoch, den 13.03.2019, 12:43 +0100 schrieb Magnus Hagander:
> > > I think this is dangerous enough that it needs to be enforced and not
> > > documented.
> >
David Rowley writes:
> We should have maybe thought a bit harder when we put that strlcpy
> code into the codebase and considered if we might have been better off
> inventing our own function that just returns what it did copy instead
> of what it would have.
Well, strlcpy is (somewhat)
Robert Haas wrote:
> On Tue, Mar 12, 2019 at 4:34 AM Antonin Houska wrote:
> > Andy Fan wrote:
> > > I just don't know why shm_mq is designed to single-reader & single-writer.
> >
> > shm_mq was implemented as a part of infrastructure for parallel query
> > processing. The leader backend
> On Tue, Mar 5, 2019 at 4:05 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Although there are still some rough edges, e.g. going forth, back and forth
> again leads to a sutiation, when `_bt_first` is not applied anymore and the
> first element is wrongly skipped. I'll try to fix it with
Thanks for feedback!
Robert Haas wrote:
> However, this is also quite invasive. It changes a lot of code and it
> doesn't do so in a very predictable way. It's not like you went
> through and replaced every call to write() with a call to
> SpecialEncyptionMagicWrite(). Rather, there are new
On 3/14/19 12:41 AM, Tom Lane wrote:
> Dean Rasheed writes:
>> I'm amazed that jacana's asinh() returned -0 for an input of +0.
> Even more amusingly, it returns NaN for acosh('infinity'), cf
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana=2019-03-14%2003%3A00%3A34
>
>
On 2019-02-15 15:02, Alexey Bashtanov wrote:
> Hello Anders and Peter,
>
> Thanks for your messages.
> Please see the new patch version attached.
In my testing, I couldn't get this patch to do anything. Could you
please share your testing steps?
I did
postgres -D data
On Sat, Mar 9, 2019 at 3:08 AM Tomas Vondra
wrote:
>
> On 3/8/19 5:38 PM, Antonin Houska wrote:
> > Antonin Houska wrote:
> >
> >> Masahiko Sawada wrote:
> >>
> >>> Agreed.
> >>>
> >>> For the WAL encryption, I wonder if we can have a encryption key
> >>> dedicated for WAL. Regardless of keys
Hello Moodle Team,
I am a student who is currently take computer science classes at Glendale
Community College, AZ who wants to take this new knowledge to the next. Since
I’m so new to programming and software development I need some hands on
experience beyond academic curriculum. So please
At Wed, 13 Mar 2019 19:37:45 +1300, David Rowley
wrote in
> On Wed, 13 Mar 2019 at 17:20, Kyotaro HORIGUCHI
> wrote:
> > bms_member_index seems working differently than maybe expected.
> >
> > bms_member_index((2, 4), 0) => 0, (I think) should be -1
> > bms_member_index((2, 4), 1) => 0,
At Wed, 13 Mar 2019 12:39:30 -0400, Robert Haas wrote
in
> On Wed, Mar 13, 2019 at 12:20 AM Kyotaro HORIGUCHI
> wrote:
> > +Multivariate MCV (most-common values) lists are a straightforward
> > extension of
> >
> > "lists are *a*" is wrong?
>
> No, that's correct. Not sure exactly what
On Fri, 15 Mar 2019 at 00:11, Dagfinn Ilmari Mannsåker
wrote:
> Tom Lane writes:
> > Mmm ... if there's a way to do it that's not messy and typo-prone,
> > maybe. But I'm dubious that the potential gain is worth complicating
> > the code. The strings involved aren't usually all that long.
>
>
On Fri, 1 Mar 2019 at 03:09, Alexander Kuzmenkov
wrote:
> New version is attached.
I started looking over v11 and I'm wondering why you really need to
know which unique index proved the join unique?
I removed that check and I see it causes the following to remove the self-join:
create unique
Tom Lane writes:
> Ashwin Agrawal writes:
>> On Wed, Mar 13, 2019 at 9:51 AM Tom Lane wrote:
>>> I don't think that's a safe transformation: what strlcpy returns is
>>> strlen(src), which might be different from what it was actually
>>> able to fit into the destination.
Yeah, Andrew Gierth
On 2019-03-03 09:06, Noah Misch wrote:
> +1 for clearing PGAPPNAME before starting a test postmaster.
> I think this qualifies:
> env -i LANG=C "$(type -p pg_ctl)" -w restart -D "$PGDATA"
OK, let's make this simpler then. Here is an updated patch that just
unsets PGAPPNAME around pg_ctl
Hello, Takayuki.
> > > For example, OS issues such as abnormally (buggy) slow process
scheduling
> > or paging/swapping that prevent control from being passed to postgres.
Or,
> > abnormally long waits on lwlocks in postgres. statement_timeout
doesn't
> > take effect while waiting on a
On 13/03/2019 03:28, Peter Geoghegan wrote:
It would be great if you could take a look at the 'Add high key
"continuescan" optimization' patch, which is the only one you haven't
commented on so far (excluding the amcheck "relocate" patch, which is
less important). I can put that one off for a
At Thu, 14 Mar 2019 09:49:11 +, "Matsumura, Ryo"
wrote in
<03040DFF97E6E54E88D3BFEE5F5480F737AC3AD8@G01JPEXMBYT04>
> Horiguchi-san
>
> Thank you for your comment.
>
> > A connection cannot be concurrently used by multiple threads so
> > the programmer must guard connections using mutex
On Thu, 14 Mar 2019 at 23:06, David Rowley wrote:
> On Thu, 14 Mar 2019 at 21:12, Edmund Horner wrote:
> > I'm not sure how an unreasonable underestimation would occur here. If
> > you have a table bloated to say 10x its minimal size, the estimator
> > still assumes an even distribution of
Hello.
At Thu, 14 Mar 2019 09:42:44 +, "Tsunakawa, Takayuki"
wrote in
<0A3221C70F24FB45833433255569204D1FBC7626@G01JPEXMBYT05>
> From: mikalaike...@ibagroup.eu [mailto:mikalaike...@ibagroup.eu]
> > > For example, OS issues such as abnormally (buggy) slow process scheduling
> > or
Hello.
At Thu, 14 Mar 2019 12:33:38 +0300, mikalaike...@ibagroup.eu wrote in
> Hello, all.
>
> The main subject of discussion in this thread relates to the
> 'socket_timeout'. As I understand there is no any hesitation about
> applying TCP_USER_TIMEOUT into the PostgreSQL.
> We have been
On Thu, 14 Mar 2019 at 21:12, Edmund Horner wrote:
> I'm not sure how an unreasonable underestimation would occur here. If
> you have a table bloated to say 10x its minimal size, the estimator
> still assumes an even distribution of tuples (I don't think we can do
> much better than that). So
Horiguchi-san
Thank you for your comment.
> A connection cannot be concurrently used by multiple threads so
> the programmer must guard connections using mutex [1] or
> friends. If it is done by a single mutex (I suppose it is
> common.), there's no race condition also on the prepared
>
On Thu, 14 Mar 2019 at 21:52, Amit Langote
wrote:
> If the correct lock is taken in both cases by the current code, then maybe
> there's no need to change anything? What does idxlockmode improve about
> the existing situation? One thing I can imagine it improves is that we
> don't need the
From: mikalaike...@ibagroup.eu [mailto:mikalaike...@ibagroup.eu]
> > For example, OS issues such as abnormally (buggy) slow process scheduling
> or paging/swapping that prevent control from being passed to postgres. Or,
> abnormally long waits on lwlocks in postgres. statement_timeout doesn't
>
Hello, all.
The main subject of discussion in this thread relates to the
'socket_timeout'. As I understand there is no any hesitation about
applying TCP_USER_TIMEOUT into the PostgreSQL.
We have been waiting for applying TCP_USER_TIMEOUT in PostgreSQL for about
6 moths.
Fabien, I was wondering
On Fri, 8 Mar 2019 at 20:59, Amit Khandekar wrote:
>
> On Mon, 4 Mar 2019 at 14:09, Amit Khandekar wrote:
> >
> > On Fri, 14 Dec 2018 at 06:25, Andres Freund wrote:
> > > I've a prototype attached, but let's discuss the details in a separate
> > > thread. This also needs to be changed for
On 13/03/2019 03:28, Peter Geoghegan wrote:
On Wed, Mar 6, 2019 at 10:15 PM Heikki Linnakangas wrote:
I made a copy of the _bt_binsrch, _bt_binsrch_insert. It does the binary
search like _bt_binsrch does, but the bounds caching is only done in
_bt_binsrch_insert. Seems more clear to have
> 14 марта 2019 г., в 12:56, Evgeniy Efimkin
> написал(а):
>
> Hi!
>> I view that as the first step towards building a more granular privilege
>> system for subscription creation, and that was the second half of what I
>> was trying to say before- I do think there's value in having something
From: Fabien COELHO [mailto:coe...@cri.ensmp.fr]
> I think that the typical use-case of \c is to connect to another database
> on the same host, at least that what I do pretty often. The natural
> expectation is that the same "other" connection parameters are used,
> otherwise it does not make
On Sun, Mar 10, 2019 at 1:51 PM Alexander Korotkov
wrote:
> On Wed, Mar 6, 2019 at 12:40 AM Nikita Glukhov
> wrote:
> > Attached 36th version of the patches.
>
> Thank yo for the revision!
>
> In the attached revision following changes are made:
>
> > "unknown" refers here to ordinary
On Thu, 14 Mar 2019 at 21:35, Imai, Yoshikazu
wrote:
> 0007:
> * This changes some processes using "for loop" to using
> "while(bms_next_member())" which speeds up processing when we scan few
> partitions in one statement, but when we scan a lot of partitions in one
> statement, its
Imai-san,
On 2019/03/13 19:34, Imai, Yoshikazu wrote:
> I have done code review of v31 patches from 0001 to 0004.
> I described below what I confirmed or thoughts.
Thanks for checking.
> 0001: This seems ok.
>
> 0002:
> * I don't really know that delaying adding resjunk output columns to the
At Thu, 14 Mar 2019 17:18:29 +0900, Amit Langote
wrote in
> On 2019/03/14 16:46, Amit Langote wrote:
> > On 2019/03/14 16:32, Kyotaro HORIGUCHI wrote:
> >> At Thu, 14 Mar 2019 16:13:23 +0900, Amit Langote
> >> wrote in
> >> <3ad792cd-0805-858e-595c-c09e9d1ce...@lab.ntt.co.jp>
> >>> Hi,
>
1 - 100 of 128 matches
Mail list logo
