On Wed, Aug 31, 2016 at 2:46 PM, Peter Eisentraut
wrote:
> Here is a patch I've been working on to allow the use of ICU for sorting
> and other locale things.
This is very interesting work, and it's great to see some development
in this area. I've been peripherally involved in more than one
coll
2016-09-23 7:22 GMT+02:00 Rushabh Lathia :
>
>
> On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane wrote:
>
>> Rushabh Lathia writes:
>> > I agree with the argument in this thread, having "Source code" as part
>> > of \df+ is bit annoying, specifically when output involve some really
>> > big PL langua
On Fri, Sep 23, 2016 at 1:21 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Sep 20, 2016 at 12:53 PM, Tom Lane wrote:
>>> I'd be the first to agree that this point is inadequately documented
>>> in the code, but PostmasterRandom should be reserved for its existing
>>> security-related uses
On 22 September 2016 at 20:02, Yury Zhuravlev
wrote:
> On четверг, 15 сентября 2016 г. 19:09:16 MSK, Tom Lane wrote:
>>
>> Robert Haas writes:
>>>
>>> On Thu, Sep 15, 2016 at 11:01 AM, Anastasia Lubennikova
>>> wrote:
What do you think about moving stuff from pg_upgrade/file.c to
On Fri, Sep 23, 2016 at 9:40 AM, Peter Eisentraut
wrote:
> On 9/21/16 9:30 AM, Jesper Pedersen wrote:
>> Attached is v5, which add basic page verification.
>
> There are still some things that I found that appear to follow the old
> style (btree) conventions instead the new style (brin, gin) conve
On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane wrote:
> Rushabh Lathia writes:
> > I agree with the argument in this thread, having "Source code" as part
> > of \df+ is bit annoying, specifically when output involve some really
> > big PL language functions. Having is separate does make \df+ output
On 09/22/2016 04:35 PM, Daniel Gustafsson wrote:
Ran into a typo in libpq-int.h while reading/hacking:
- char *gsslib; /* What GSS librart to use
("gssapi" or
+ char *gsslib; /* What GSS library to use
("gssapi” or
Patch attached
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> On Tue, Sep 20, 2016 at 2:20 AM, Tsunakawa, Takayuki
> wrote:
> > There's no apparent evidence to indicate the cause, but I could guess
> > a few reasons. What do you think these ar
On 19 September 2016 at 07:12, Vladimir Gordiychuk wrote:
> New patch in attach. 0001 and 0002 without changes.
> 0003 - patch contain improvements for pg_recvloginca, now pg_recvloginca
> after receive SIGINT will send CopyDone package to postgresql and wait from
> server CopyDone. For backward c
On Fri, Sep 23, 2016 at 12:16 AM, Masahiko Sawada wrote:
> On Thu, Sep 22, 2016 at 1:25 AM, Peter Eisentraut
> wrote:
>> On 8/11/16 9:28 AM, Michael Paquier wrote:
>> Committed with that adjustment.
Thanks...
> Commit e7010ce seems to forget to change help message of pg_ctl.
> Attached patch.
On Fri, Sep 23, 2016 at 7:02 AM, Robert Haas wrote:
> On Thu, Sep 22, 2016 at 7:10 PM, Thomas Munro
> wrote:
>
>> I was thinking about suggesting a category "Replication" to cover the
>> waits for client IO relating to replication, as opposed to client IO
>> waits relating to regular user connect
On Thu, Sep 22, 2016 at 7:19 PM, Robert Haas wrote:
> On Wed, Sep 21, 2016 at 5:49 PM, Thomas Munro
> wrote:
>
> So, I tried to classify these. Here's what I came up with.
>
> Activity: ArchiverMain, AutoVacuumMain, BgWriterMain,
> BgWriterHibernate, CheckpointerMain, PgStatMain, RecoveryWalAll,
On 9/21/16 9:30 AM, Jesper Pedersen wrote:
> Attached is v5, which add basic page verification.
There are still some things that I found that appear to follow the old
style (btree) conventions instead the new style (brin, gin) conventions.
- Rename hash_metap to hash_metapage_info.
- Don't use B
On Thu, Sep 22, 2016 at 7:32 PM, Robert Haas wrote:
> On Thu, Sep 22, 2016 at 8:36 AM, Amit Kapila wrote:
>> I think for certain cases like into clause, the rows passed will be
>> equal to actual number of rows, otherwise it will generate error. So
>> we can pass that information in executor lay
On Fri, Sep 23, 2016 at 5:14 AM, Tomas Vondra
wrote:
> On 09/21/2016 08:04 AM, Amit Kapila wrote:
>>
>
> (c) Although it's not visible in the results, 4.5.5 almost perfectly
> eliminated the fluctuations in the results. For example when 3.2.80 produced
> this results (10 runs with the same paramet
On Fri, Sep 23, 2016 at 7:17 AM, Tomas Vondra
wrote:
> On 09/23/2016 03:20 AM, Robert Haas wrote:
>>
>> On Thu, Sep 22, 2016 at 7:44 PM, Tomas Vondra
>> wrote:
>>>
>>> I don't dare to suggest rejecting the patch, but I don't see how
>>> we could commit any of the patches at this point. So perhaps
On 23 September 2016 at 00:32, Tom Lane wrote:
> Craig Ringer writes:
>> On 13 September 2016 at 22:02, Tom Lane wrote:
>>> Without taking a position on the merits of this patch per se, I'd like
>>> to say that I find the argument for back-patching into 9.6 and not
>>> further than that to be pr
This is looking pretty good. More comments on this patch set:
0001:
Keep the file order alphabetical in Mkvcbuild.pm.
Needs nls.mk updates for file move (in initdb and pg_basebackup
directories).
0002:
durable_rename needs close(fd) in non-error path (compare backend code).
Changing from fsy
On 09/23/2016 03:20 AM, Robert Haas wrote:
On Thu, Sep 22, 2016 at 7:44 PM, Tomas Vondra
wrote:
I don't dare to suggest rejecting the patch, but I don't see how
we could commit any of the patches at this point. So perhaps
"returned with feedback" and resubmitting in the next CF (along
with anal
On Thu, Sep 22, 2016 at 7:10 PM, Thomas Munro
wrote:
> Interesting. OK, I agree that it'd be useful to show that we're
> waiting because there's nothing happening, or waiting because the user
> asked us to sleep, or waiting on IO, or waiting for an IPC response
> because something is happening, a
On Thu, Sep 22, 2016 at 7:44 PM, Tomas Vondra
wrote:
> I don't dare to suggest rejecting the patch, but I don't see how we could
> commit any of the patches at this point. So perhaps "returned with feedback"
> and resubmitting in the next CF (along with analysis of improved workloads)
> would be a
On Fri, Sep 16, 2016 at 09:56:39PM +0530, Sachin Kotwal wrote:
> Hi Tom,
>
> What I understood from this https://www.postgresql.org/docs/9.5/static/
> explicit-locking.html#TABLE-LOCK-COMPATIBILITY
> is :
>
> The RowExclusiveLock conflicts with queries want SHARE, SHARE ROW EXCLUSIVE,
> EXCLUSIV
On 09/21/2016 08:04 AM, Amit Kapila wrote:
On Wed, Sep 21, 2016 at 3:48 AM, Tomas Vondra
wrote:
...
I'll repeat the test on the 4-socket machine with a newer kernel,
but that's probably the last benchmark I'll do for this patch for
now.
Attached are results from benchmarks running on kern
On 09/22/2016 07:33 PM, Tom Lane wrote:
Andrew Dunstan writes:
I have just encountered an apparent bug in pg_upgrade (or possibly pg_dump).
Hmm, it sort of looks like pg_dump believes it should dump the range's
constructor function in binary-upgrade mode, while the backend is creating
the co
Andrew Dunstan writes:
> I have just encountered an apparent bug in pg_upgrade (or possibly pg_dump).
Hmm, it sort of looks like pg_dump believes it should dump the range's
constructor function in binary-upgrade mode, while the backend is creating
the constructor function during CREATE TYPE anywa
On Fri, Sep 23, 2016 at 1:49 AM, Robert Haas wrote:
> On Wed, Sep 21, 2016 at 5:49 PM, Thomas Munro
> wrote:
>>> Moreover, it's pretty confusing that we have this general concept of
>>> wait events in pg_stat_activity, and then here the specific type of
>>> wait event we're waiting for is the ...
I have just encountered an apparent bug in pg_upgrade (or possibly pg_dump).
To recreate, install the cranges extension - which can be obtained via
"git clone https://bitbucket.org/adunstan/pg-closed-ranges.git"; - for
both 9.4 and 9.5. Create a fresh 9.4 instance, create a database and in
i
On Thu, Sep 22, 2016 at 3:51 PM, Heikki Linnakangas wrote:
> It'd be good if you could overlap the final merges in the workers with the
> merge in the leader. ISTM it would be quite straightforward to replace the
> final tape of each worker with a shared memory queue, so that the leader
> could st
On 08/02/2016 01:18 AM, Peter Geoghegan wrote:
No merging in parallel
--
Currently, merging worker *output* runs may only occur in the leader
process. In other words, we always keep n worker processes busy with
scanning-and-sorting (and maybe some merging), but then all proce
Robert Haas writes:
> On Tue, Sep 20, 2016 at 12:53 PM, Tom Lane wrote:
>> I'd be the first to agree that this point is inadequately documented
>> in the code, but PostmasterRandom should be reserved for its existing
>> security-related uses, not exposed to the world for (ahem) random other
>> us
Robert Haas writes:
> On Mon, Sep 19, 2016 at 7:07 AM, Amit Kapila wrote:
>> I think you have a valid point. It seems we don't need to write WAL
>> for reuse page (aka don't call _bt_log_reuse_page()), if the page is
>> new, as the only purpose of that log is to handle conflict based on
>> trans
Pavan Deolasee writes:
> On Tue, Sep 20, 2016 at 8:34 PM, Tom Lane wrote:
>> Realistically, because struct HeapTupleHeaderData contains a field of
>> type ItemPointerData, it's probably silly to imagine that we can save
>> anything if the compiler can't be persuaded to believe that
>> sizeof(Item
> On Sep 22, 2016, at 9:14 AM, Tom Lane wrote:
>
> I'd call this kind of a wash, I guess. I'd be more excited about it if
> the change allowed removal of an actual cast-away-of-constness somewhere.
>
> I suppose it's a bit of a chicken and egg situation, in that the lack
> of const markings on
Hi,
On Tue, Sep 20, 2016 at 08:59:37PM -0400, Peter Eisentraut wrote:
> On 9/19/16 3:23 PM, Michael Banck wrote:
> > Version 2 attached.
>
> Committed, thanks.
Thanks!
> I added the new option to the help output in pg_restore.
Oh, sorry I missed that.
Michael
--
Michael Banck
Projektleite
Tomas Vondra writes:
>> On 08/25/2016 01:45 AM, Tom Lane wrote:
>>> I'll put this in the commitfest queue. It could use review from
>>> someone with the time and motivation to do performance
>>> testing/tuning.
> I've been toying with this patch a bit today, particularly looking at
> (1) sizing
Amit Kapila writes:
> On Tue, Sep 20, 2016 at 10:33 PM, Tom Lane wrote:
>> ISTM both the previous coding and this version can fail for no good
>> reason, that is what if GetLastError() happens to return one of these
>> error codes as a result of some unrelated failure from before this
>> subrouti
On Wed, Sep 21, 2016 at 08:44:15PM +0100, Geoff Winkless wrote:
> On 21 September 2016 at 13:29, Robert Haas wrote:
> > I'd be curious what benefits people expect to get.
>
> An edge case I came across the other day was a unique index on a large
> string: postgresql popped up and told me that I c
Rushabh Lathia writes:
> I agree with the argument in this thread, having "Source code" as part
> of \df+ is bit annoying, specifically when output involve some really
> big PL language functions. Having is separate does make \df+ output more
> readable. So I would vote for \df++ rather then addin
Craig Ringer writes:
> On 13 September 2016 at 22:02, Tom Lane wrote:
>> Without taking a position on the merits of this patch per se, I'd like
>> to say that I find the argument for back-patching into 9.6 and not
>> further than that to be pretty dubious. $(prove_check) has been there
>> since
Mark Dilger writes:
>> On Sep 20, 2016, at 1:06 PM, Tom Lane wrote:
>> ... that seems to be discarding type information in order to add
>> "const"; does not seem like a net benefit from here.
> The following seems somewhere in between, with ItemPointer
> changing to const ItemPointerData *. I e
Alvaro Herrera writes:
> Petr Jelinek wrote:
>>> I'm not sure how well it will work to replace all the bits of LIKE and
>>> regular expressions with ICU API calls. One problem is that ICU likes
>>> to do case folding as a whole string, not by character. I need to do
>>> more research about that.
I haven't really thought about this as I had been asked to make this
work as an additional option to the connection parameters...
Now that I've looked at it - there is really only the benefit of saving
the step of setting the PGPASSFILE environment variable.
However, there might be cases in which
Petr Jelinek wrote:
> > I'm not sure how well it will work to replace all the bits of LIKE and
> > regular expressions with ICU API calls. One problem is that ICU likes
> > to do case folding as a whole string, not by character. I need to do
> > more research about that.
>
> Can't we use the
On 09/22/2016 10:44 AM, Julian Markwort wrote:
Hello psql-hackers!
We thought it would be advantageous to be able to specify a 'custom'
pgpassfile within the connection string along the lines of the
existing parameters sslkey and sslcert.
Which is exactly what this very compact patch does.
On Thu, Sep 22, 2016 at 1:25 AM, Peter Eisentraut
wrote:
> On 8/11/16 9:28 AM, Michael Paquier wrote:
>> I have looked at them and the changes are looking fine for me. So I
>> have switched the patch as ready for committer, aka you.
>>
>> Just a nit:
>> + if (wait_seconds > 0)
>> + {
>
Hello psql-hackers!
We thought it would be advantageous to be able to specify a 'custom'
pgpassfile within the connection string along the lines of the existing
parameters sslkey and sslcert.
Which is exactly what this very compact patch does.
The patch is minimally invasive - when no pgpassf
I wrote:
> The reason this happens is that EvalPlanQualBegin copies down all the
> es_param_exec_vals values from the outer query into the EPQ execution
> state. That's OK for most uses of es_param_exec_vals values, but not
> at all for cteParam Params, which are used as internal communication
> v
On Thu, Sep 22, 2016 at 8:36 AM, Amit Kapila wrote:
> I think for certain cases like into clause, the rows passed will be
> equal to actual number of rows, otherwise it will generate error. So
> we can pass that information in executor layer. Another kind of cases
> which are worth considering a
On Thu, Sep 22, 2016 at 1:52 AM, Michael Paquier
wrote:
> Then comes the interesting bits: I don't think that it is a good idea
> to associate only one event for a waiting point in the system views.
> Say that at a waiting point WaitLatch is called with
> WL_POSTMASTER_DEATH and WL_TIMEOUT, I'd ra
On Wed, Sep 21, 2016 at 5:49 PM, Thomas Munro
wrote:
>> Moreover, it's pretty confusing that we have this general concept of
>> wait events in pg_stat_activity, and then here the specific type of
>> wait event we're waiting for is the ... wait event kind. Uh, what?
>
> Yeah, that is confusing. I
Ran into a typo in libpq-int.h while reading/hacking:
- char *gsslib; /* What GSS librart to use
("gssapi" or
+ char *gsslib; /* What GSS library to use
("gssapi” or
Patch attached.
cheers ./daniel
typo-libpq-int.diff
Descripti
I looked into the misbehavior reported in bug #14328,
https://www.postgresql.org/message-id/20160919160136.1348.55...@wrigleys.postgresql.org
What is happening is that during the EvalPlanQual recheck to see whether
the updated row still satisfies the SELECT's quals, we run ExecInitCteScan
and then
Tom Lane wrote:
> If we take this patch, what's to stop someone from complaining that we
> broke *their* badly-designed system that abuses the HOME variable?
POSIX warns against doing that, listing HOME in the variables that
should be left to their intended usage:
http://pubs.opengroup.or
On Tue, Sep 20, 2016 at 8:31 PM, Robert Haas wrote:
> On Tue, Sep 20, 2016 at 9:24 AM, Amit Kapila wrote:
>> I think here point is that for any case where there is count of rows
>> to be selected, we disable parallelism. There are many genuine cases
>> like select count(*) into cnt ... which wil
On четверг, 15 сентября 2016 г. 19:09:16 MSK, Tom Lane wrote:
Robert Haas writes:
On Thu, Sep 15, 2016 at 11:01 AM, Anastasia Lubennikova
wrote:
What do you think about moving stuff from pg_upgrade/file.c
to storage/file/
to allow reuse of this code? I think it'll be really helpful
for devel
On Wed, Sep 21, 2016 at 6:53 PM, Fabien COELHO wrote:
> In front of the tps line. Well, the performance displayed could also be
> improved... On my dual core SSD laptop I just got:
>
> sh> ./pgbench -c 10 -t 1000
> starting vacuum...end.
> transaction type:
> scaling factor: 100
> query mode
On Fri, Sep 2, 2016 at 5:00 PM, Etsuro Fujita
wrote:
> Hi Robert,
>
> Thanks for the comments!
>
> On 2016/09/02 11:55, Robert Haas wrote:
>
>> On Mon, Aug 1, 2016 at 5:44 PM, Etsuro Fujita
>> wrote:
>>
>>> I noticed that the following note about direct modification via
>>> GetForeignUpperPaths
On Thu, Sep 22, 2016 at 1:02 PM, Ashutosh Bapat
wrote:
> For list partitions, the ListInfo stores the index maps for values
> i.e. the index of the partition to which the value belongs. Those
> indexes are same as the indexes in partition OIDs array and come from
> the catalogs. In case a user cre
On Tue, Sep 20, 2016 at 4:26 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> PFA patch which takes care of some of the TODOs mentioned in my
> previous mail. The patch is based on the set of patches supporting
> declarative partitioning by Amit Langoted posted on 26th August.
I ha
On Fri, Sep 16, 2016 at 9:56 PM, Jeff Janes wrote:
> On Fri, Sep 16, 2016 at 4:20 AM, Amit Kapila
> wrote:
>>
>> Currently README of hash module contain algorithms written in below form.
>>
>> The insertion algorithm is rather similar:
>>
>> pin meta page and take buffer content lock in shared mo
On Thu, Sep 22, 2016 at 4:17 AM, Heikki Linnakangas wrote:
> On 09/22/2016 03:40 AM, Claudio Freire wrote:
>>
>> On Tue, Sep 20, 2016 at 3:34 PM, Claudio Freire
>> wrote:
>>>
>>> The results seem all over the map. Some regressions seem significant
>>> (both in the amount of performance lost and t
For list partitions, the ListInfo stores the index maps for values
i.e. the index of the partition to which the value belongs. Those
indexes are same as the indexes in partition OIDs array and come from
the catalogs. In case a user creates two partitioned tables with
exactly same lists for partitio
Hi
2016-09-21 19:53 GMT+02:00 Dave Cramer :
>
> On 18 September 2016 at 09:27, Dave Cramer wrote:
>
>>
>> On 10 August 2016 at 01:53, Pavel Stehule
>> wrote:
>>
>>> Hi
>>>
>>> 2016-08-03 13:54 GMT+02:00 Alexey Grishchenko :
>>>
On Wed, Aug 3, 2016 at 12:49 PM, Alexey Grishchenko <
agr
On 09/22/2016 03:40 AM, Claudio Freire wrote:
On Tue, Sep 20, 2016 at 3:34 PM, Claudio Freire wrote:
The results seem all over the map. Some regressions seem significant
(both in the amount of performance lost and their significance, since
all 4 runs show a similar regression). The worst being
64 matches
Mail list logo
