On Sat, Jul 21, 2018 at 09:38:38AM +0300, Sergei Kornilov wrote:
> Currently log_autovacuum_min_duration log message has no difference
> between regular autovacuum and to prevent wraparound autovacuum. There
> are important differences, for example, backend can automatically
> cancel regular autova
Hello
> Yes, a bit more verbosity would be nice for that. Using the term
> "anti-wraparound" directly in the logs makes the most sense?
I used "(to prevent wraparound)" to looks like reporting in pg_stat_activity.
As far i can see currently we not using "anti-wraparound" for user messages.
On the
Hi!
> 19 июля 2018 г., в 23:26, Andrey Borodin написал(а):
>
> I'm working on triggering left split during vacuum. Will get back when done.
> Thanks!
Here's patch including some messy hacks to trigger NSN and FollowRight jumps
during VACUUM.
To trigger FollowRight GiST sometimes forget to cl
Sorry Tom (and others), I didn't notice my change affected libpq. Though I
would really like the possibility to have an encrypted way of presenting
the pgpassfile. Would it be more secure if the script / command is passed
as a compile option to libpg and the variable only contains the filename of
t
"Tels" writes:
> + *) if [ `find ${PGDATA} -type f ! -perm 640 | wc -l` -ne 0 ]; then
> Shouldn't ${PGDATA} in the above as argument to find be quoted, otherwise
> the shell would get confused if it contains spaces or other special
> characters?
Hmm. Yeah, probably. I don't think this
The sentences in question currently read ...
Finally, SELECT FOR KEY SHARE obtains a shared lock which only
prevents tuple removal and modifications of key fields. This last mode
implements a mode just strong enough to implement RI checks, i.e. it ensures
that tuples do not go away from under a ch
Tom Lane writes:
> "Tels" writes:
>> +*) if [ `find ${PGDATA} -type f ! -perm 640 | wc -l` -ne 0 ]; then
>
>> Shouldn't ${PGDATA} in the above as argument to find be quoted, otherwise
>> the shell would get confused if it contains spaces or other special
>> characters?
>
> Hmm. Yeah, p
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Tom Lane writes:
>> Hmm. Yeah, probably. I don't think this script is meant to be run with
>> arbitrary values of PGDATA, but most of the other uses are quoted, so
>> for consistency's sake this should be too.
> Attached is
2018-07-20 2:18 GMT-07:00 Aleksander Alekseeev :
> Hello Charles,
>
> > Here is my current working status.
> > 1. Complete the thrift_binary_in and thrift_binary_out functions, so
> > that users can express their thrift struct using json. These two
> > functions support both simple data struct
On Sat, Jul 21, 2018 at 12:00:48PM -0700, Charles Cui wrote:
> 2018-07-20 2:18 GMT-07:00 Aleksander Alekseeev :
>
> > Hello Charles,
> >
> > > Here is my current working status.
> > > 1. Complete the thrift_binary_in and thrift_binary_out functions, so
> > > that users can express their thrift
yes, using home brew, will try that.
On Jul 21, 2018 12:33 PM, "David Fetter" wrote:
On Sat, Jul 21, 2018 at 12:00:48PM -0700, Charles Cui wrote:
> 2018-07-20 2:18 GMT-07:00 Aleksander Alekseeev :
>
> > Hello Charles,
> >
> > > Here is my current working status.
> > > 1. Complete the thrift_
Hi,
Today I spent some time closing PostGIS tickets in preparation to Monday's
release.
One of the blockers, https://trac.osgeo.org/postgis/ticket/4125, was filed
by Postgres APT repository maintainer Christoph Berg who noticed a test
suite failure on Debian Stretch with Postgres 11.
Upon invest
Andres Freund writes:
> On 2018-07-20 16:43:33 -0400, Tom Lane wrote:
>> On my RHEL6 machine, with unmodified HEAD and 8 sessions (since I've
>> only got 8 cores) but other parameters matching Mithun's example,
>> I just got
> It's *really* common to have more actual clients than cpus for oltp
>
Hello David,
[...]
Fixed.
[...]
I've changed it to something that makes more sense to me. Hope it
makes more sense to others.
Ok, all is fine for me.
I could not find a CF entry, so I created one:
https://commitfest.postgresql.org/19/1728/
--
Fabien.
Hi,
On 2018-07-21 23:14:47 +0300, Darafei "Komяpa" Praliaskouski wrote:
> Today I spent some time closing PostGIS tickets in preparation to Monday's
> release.
>
> One of the blockers, https://trac.osgeo.org/postgis/ticket/4125, was filed
> by Postgres APT repository maintainer Christoph Berg who
On Sat, Jul 21, 2018 at 04:23:14PM -0400, Fabien COELHO wrote:
>
> Hello David,
>
> >>[...]
> >
> >Fixed.
> >
> >>[...]
> >
> >I've changed it to something that makes more sense to me. Hope it
> >makes more sense to others.
>
> Ok, all is fine for me.
>
> I could not find a CF entry, so I creat
Re: Andres Freund 2018-07-21 <20180721202543.ri5jyfclj6kb6...@alap3.anarazel.de>
> Could you attempt to come up with a smaller reproducer?
The original instructions in
https://trac.osgeo.org/postgis/ticket/4125 are fairly easy to follow;
there's also a postgresql-11-postgis-2.5{,-scripts} package
Hi,
On 2018-07-21 22:36:44 +0200, Christoph Berg wrote:
> Re: Andres Freund 2018-07-21
> <20180721202543.ri5jyfclj6kb6...@alap3.anarazel.de>
> > Could you attempt to come up with a smaller reproducer?
>
> The original instructions in
> https://trac.osgeo.org/postgis/ticket/4125 are fairly easy t
Could you provide a link to the specification?
I cannot find something simple, and I was kind of hoping to avoid diving
into the source code of the java tool on github:-) In particular, I'm
looking for a description of the expected underlying schema and its size
(scale) parameters.
There are
Hi,
Here's somewhat minimized example.
https://gist.github.com/Komzpa/cc3762175328ff5d11de4b972352003d
You can put this file into regress/jitbug.sql in PostGIS code tree and run
after building postgis:
perl regress/run_test.pl regress/jitbug.sql --expect
perl regress/run_test.pl regress/jitbug.
On Sun, Jul 8, 2018 at 12:15 AM Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Sat, Jul 7, 2018 at 12:31 AM Tom Lane wrote:
> > Alexander Korotkov writes:
> > > I tool a look at this patch. It looks good for me. It applies
> > > cleanly on last master, builds without warnings, pas
Folks,
I'd like to $Subject for 12.
There are scripts it could break, but not ones that weren't already
broken in ways important to access control.
What say?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.pos
On 21/07/18 23:58, David Fetter wrote:
> Folks,
>
> I'd like to $Subject for 12.
>
> There are scripts it could break, but not ones that weren't already
> broken in ways important to access control.
>
> What say?
I say it should at least throw a sensible error for a few versions
before it's rem
Hello David,
I'd like to $Subject for 12.
There are scripts it could break, but not ones that weren't already
broken in ways important to access control.
What say?
What is the rational?
I'm unsure of the logic behind removing -W (--password) but keeping -w
(--no-password), especially as
Moin,
On Sat, July 21, 2018 12:47 pm, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane writes:
>
>> "Tels" writes:
>>> + *) if [ `find ${PGDATA} -type f ! -perm 640 | wc -l` -ne 0 ]; then
>>
>>> Shouldn't ${PGDATA} in the above as argument to find be quoted,
>>> otherwise
>>> the shell would ge
On 22/07/18 00:41, Fabien COELHO wrote:
>
> Hello David,
>
>> I'd like to $Subject for 12.
>>
>> There are scripts it could break, but not ones that weren't already
>> broken in ways important to access control.
>>
>> What say?
>
> What is the rational?
It's first on our list of things not to d
"Tels" writes:
> Looking at your new patch, I notice you used "" for quoting, not ''. (Not
> sure which variant Tom used when pushing a patch).
> I'm not a shell expert, but I think '' are safer, as "" still has some
> interpolation from the shell (at least on the systems I use regulary):
We can'
Vik Fearing writes:
> On 22/07/18 00:41, Fabien COELHO wrote:
>> What is the rational?
> It's first on our list of things not to do:
> https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_psql_-W_or_--password
As I recall, when this has been discussed in the past, people objected
because t
Hi,
There is a small catch in the parsing of --help and --version args by pgbench:
they are processed correctly only as the first argument. If it's not the case,
strange error message occurs:
$ pgbench -q --help
pgbench: unrecognized option '--help'
Try "pgbench --help" for more information.
The
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Hi Paul,
this is a review of the patch:
CABQrizc90sfkZgi4=+0bbp1
Having tried David's method to install 10.4 and 11 on my mac and turns out
worked for me. The compiling issue posted by Aleksander is because
some json helpers changed function name and is not backward compatible with
9.4 and 10. Using #if macro resolves the problem,
Here is the commit to solve thi
Andrei Korigodski writes:
> There is a small catch in the parsing of --help and --version args by pgbench:
> they are processed correctly only as the first argument.
This is, in fact, how it's done in all PG apps.
regards, tom lane
On July 21, 2018 11:15:51 PM PDT, Tom Lane wrote:
>Andrei Korigodski writes:
>> There is a small catch in the parsing of --help and --version args by
>pgbench:
>> they are processed correctly only as the first argument.
>
>This is, in fact, how it's done in all PG apps.
Think there's a fair a
Andres Freund writes:
> On July 21, 2018 11:15:51 PM PDT, Tom Lane wrote:
>> This is, in fact, how it's done in all PG apps.
> Think there's a fair argument that we should improve that at some point...
Perhaps. Peter E. might remember why it's like that. But I'm dubious
about changing it in o
34 matches
Mail list logo
