On Thu, Mar 9, 2017 at 3:11 AM, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 6:41 PM, Robert Haas wrote:
Great, thanks. 0001 looks good to me now, so committed.
>>>
>>> Committed 0002.
>>
>> Here are some initial review thoughts on 0003 based on
On Wed, Mar 8, 2017 at 3:52 PM, Tsunakawa, Takayuki
wrote:
> Hello,
>
> dblink fails to close the unnamed connection as follows when a new unnamed
> connection is requested. The attached patch fixes this.
This issue was reported about ten years ago and added as
Hi, Andres
Thanks a lot for the review!
> Why are we keeping that list / the "batch" allocation pattern? It
> doesn't actually seem useful to me after these changes. Given that we
> don't shrink hash-tables, we could just use the hash-table memory for
> this, no?
I don't think we can do that.
On Thu, Mar 9, 2017 at 8:21 AM, Rushabh Lathia wrote:
> Thanks Robert for committing this.
>
> My colleague Neha Sharma found one regression with the patch. I was about
> to send this mail and noticed that you committed the patch.
Oops. Bad timing.
> postgres=#
On Wed, Mar 8, 2017 at 1:43 AM, Peter Geoghegan wrote:
> On Sat, Mar 4, 2017 at 1:30 AM, Amit Kapila wrote:
>>> While I can't see this explained anywhere, I'm
>>> pretty sure that that's supposed to be impossible, which this patch
>>> changes.
>>>
>>
>>
On Thu, Mar 9, 2017 at 10:02 PM, Dilip Kumar wrote:
> I slightly modified your query to reproduce this issue.
>
> explain analyze select * from r1 where value<555;
>
> Patch is attached to fix the problem.
I forgot to mention the cause of the problem.
if
On Thu, Mar 9, 2017 at 12:25 AM, Robert Haas wrote:
> On Wed, Mar 8, 2017 at 7:45 AM, Amit Kapila wrote:
>> Okay, I can try, but note that currently there is no test related to
>> "snapshot too old" for any other indexes.
>
> Wow, that's
On Thu, Mar 9, 2017 at 9:17 PM, David Rowley
wrote:
> patch with [1]
>
> =# create table r1(value int);
> CREATE TABLE
> =# insert into r1 select (random()*1000)::int from
> generate_Series(1,100);
> INSERT 0 100
> =# create index on r1 using brin(value);
>
Hi Amit,
> Sorry, I didn't mean to dissuade you from trying those
> micro-optimizations. If general inheritance cases can benefit from it
> (which, until we have a different method, will be used by partitioned
> tables as well), I think we should try it.
OK, I'll see what could be done here as
> On Mar 9, 2017, at 7:59 AM, Peter Eisentraut
> wrote:
>
> On 2/28/17 22:15, Peter Eisentraut wrote:
>> The SQL standard defines a separate error code for nextval exhausting
>> the sequence space. I haven't found any discussion of this in the
>> archives, so
On Thu, Mar 9, 2017 at 11:50 AM, Dilip Kumar wrote:
> On Thu, Mar 9, 2017 at 10:02 PM, Dilip Kumar wrote:
>> I slightly modified your query to reproduce this issue.
>>
>> explain analyze select * from r1 where value<555;
>>
>> Patch is attached to
Stephen Frost writes:
> We have already figured out that the user's predicate results in a
> subset of the index's or we wouldn't be able to use that index though,
> right? Do we really need to spend cycles re-discovering that? Are
> there cases where we actually need the
I was just doing some testing on [1] when I noticed that there's a problem
with parallel bitmap index scans scans.
Test case:
patch with [1]
=# create table r1(value int);
CREATE TABLE
=# insert into r1 select (random()*1000)::int from
generate_Series(1,100);
INSERT 0 100
=# create
On Thu, Mar 9, 2017 at 9:42 PM, Robert Haas wrote:
> On Thu, Mar 9, 2017 at 8:21 AM, Rushabh Lathia
> wrote:
> > Thanks Robert for committing this.
> >
> > My colleague Neha Sharma found one regression with the patch. I was about
> > to send this
On Thu, Mar 9, 2017 at 9:37 PM, Dilip Kumar wrote:
>> =# create table r1(value int);
>> CREATE TABLE
>> =# insert into r1 select (random()*1000)::int from
>> generate_Series(1,100);
>> INSERT 0 100
>> =# create index on r1 using brin(value);
>> CREATE INDEX
>> =#
On 03/09/2017 07:54 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Wed, Mar 8, 2017 at 3:52 PM, Tsunakawa, Takayuki
>> wrote:
>>> dblink fails to close the unnamed connection as follows when a new unnamed
>>> connection is requested. The
On Thu, Mar 9, 2017 at 7:47 AM, Naytro Naytro wrote:
> We are having some performance issues after we upgraded to newest
> version of PostgreSQL, before it everything was fast and smooth.
>
> Upgrade was done by pg_upgrade from 9.4 directly do 9.6.1. Now we
> upgraded to
On 2/28/17 22:15, Peter Eisentraut wrote:
> The SQL standard defines a separate error code for nextval exhausting
> the sequence space. I haven't found any discussion of this in the
> archives, so it seems this was just not considered or not yet in
> existence when the error codes were
On Thu, Mar 9, 2017 at 11:25 AM, Rushabh Lathia
wrote:
> I don't see this failure with the patch. Even I forced the gather merge
> in the above query and that just working fine.
>
> Attaching patch, with the discussed changes.
Committed.
--
Robert Haas
EnterpriseDB:
2017-03-09 13:18 GMT+01:00 Surafel Temesgen :
> Hi ,
>
> Here is a patch corrected as your feedback except missed tests case
> because corresponding by clause is implemented on the top of set operation
> and you can’t do that to set operation without corresponding by clause
Stephen Frost writes:
> Perhaps I'm missing something obvious, but isn't it a bit redundant to
> have both a Recheck condition (which is the predicate of the index) and
> a Filter condition (which is the user's predicate) when we've already
> decided that the user's predicate
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Perhaps I'm missing something obvious, but isn't it a bit redundant to
> > have both a Recheck condition (which is the predicate of the index) and
> > a Filter condition (which is the user's predicate)
Fujii Masao writes:
> On Wed, Mar 8, 2017 at 3:52 PM, Tsunakawa, Takayuki
> wrote:
>> dblink fails to close the unnamed connection as follows when a new unnamed
>> connection is requested. The attached patch fixes this.
> This issue was
Greetings,
Consider this:
create table t10 (c1 int, c2 int);
create index on t10 (c1) where c2 > 5;
\d t10
Table "sfrost.t10"
Column | Type | Modifiers
+-+---
c1 | integer |
c2 | integer |
Indexes:
"t10_c1_idx" btree (c1) WHERE c2 > 5
insert
On 3/8/17 9:34 AM, Andreas Karlsson wrote:
Also, if by any chance you think (or use any
software that thinks) that OIDs for system objects are a stable
identifier, this will be the first case where that ceases to be true.
If the system is shut down or crashes or the session is killed, you'll
be
On Thu, Mar 9, 2017 at 8:17 PM, Bruce Momjian wrote:
>> In my opinion, we expose query id (and dbid, and userid) as the
>> canonical identifier for each pg_stat_statements entry, and have done
>> so for some time. That's the stable API -- not query text. I'm aware
>> of cases
>>
>> The new name merge_fdw_options() is shorter than the one I chose, but
>> we are not exactly merging options for an upper relation since there
>> isn't the other fpinfo to merge from. But I think we can live with
>> merge_fdw_options().
>
> Perhaps "combine" is a better word? I didn't really
On Thu, Mar 9, 2017 at 6:28 PM, Robert Haas wrote:
> On Thu, Mar 9, 2017 at 7:42 AM, Ashutosh Bapat
> wrote:
>>>
>>> +if (rel->partial_pathlist != NIL &&
>>> +(Path *) linitial(rel->partial_pathlist) == subpath)
>>> +
Robert Haas writes:
> On Thu, Mar 9, 2017 at 4:01 PM, Joe Conway wrote:
>> On 03/09/2017 12:27 PM, Tom Lane wrote:
>>> For good measure I also added a DEBUG1 log message reporting successful
>>> binding to a port. I'm not sure if there's an argument
On 09/03/17 18:46, Peter Eisentraut wrote:
> On 3/6/17 05:27, Petr Jelinek wrote:
>> updated and rebased version of the patch attached.
>
> Some comments on this patch:
>
> Can we have a better explanation of different snapshot options in
> CREATE_REPLICATION_SLOT. We use all these variants in
On 09/03/17 18:48, Peter Eisentraut wrote:
> On 3/6/17 05:27, Petr Jelinek wrote:
>> And lastly I changed the automagic around exporting, not exporting and
>> using the snapshot produced by CREATE_REPLICATION_SLOT into explicit
>> parameter for the CREATE_REPLICATION_SLOT command (and added simple
On 3/7/17 00:32, Michael Paquier wrote:
>> OK. After a lookup, I am just seeing opfamily, opclass missing, so
>> this patch is doing it as you describe.
I'm not sure what you mean here.
>> @@ -7198,6 +7198,33 @@ function_with_argtypes:
>> n->objargs = extractArgTypes($2);
>>
On Fri, Mar 10, 2017 at 3:11 AM, Andres Freund wrote:
> On 2017-03-09 16:37:29 -0500, Tom Lane wrote:
>> Robert Haas writes:
>> > On Thu, Mar 9, 2017 at 2:30 PM, Peter Eisentraut
>> > wrote:
>> >> In practice, I think
On Sat, Mar 4, 2017 at 10:52:44AM -0800, Peter Geoghegan wrote:
> On Sat, Mar 4, 2017 at 8:02 AM, Tom Lane wrote:
> > Meh ... we've generally regretted it when we "solved" a backwards
> > compatibility problem by introducing a GUC that changes query semantics.
> > I'm
Hi,
while discussing with Craig issues around restarting logical replication
stream related to the patch he posted [1], I realized that we track
wrong origin LSN in the logical replication apply.
We currently track commit_lsn which is *start* of commit record, what we
need to track is end_lsn
Andres Freund writes:
> FWIW, Unless somebody seriously protests, I'm going to commit this soon-ish.
Sure, if you want to take responsibility for it, push away.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 2/28/17 13:02, Dmitry Dolgov wrote:
> +
> +-- Extract value by key
> +SELECT ('{"a": 1}'::jsonb)['a'];
> +
> +-- Extract nested value by key path
> +SELECT ('{"a": {"b": {"c": 1}}}'::jsonb)['a']['b']['c'];
> +
> +-- Extract element by index
> +SELECT ('[1, "2", null]'::jsonb)['1'];
> +
> +--
Robert Haas writes:
> On Thu, Mar 9, 2017 at 9:17 PM, Tom Lane wrote:
>> Buildfarm thinks eight wasn't enough.
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=clam=2017-03-10%2002%3A00%3A01
> At first I was confused how you knew that this
On 10 March 2017 at 10:13, Ashutosh Bapat
wrote:
> On Thu, Mar 9, 2017 at 6:28 PM, Robert Haas wrote:
>> On Thu, Mar 9, 2017 at 7:42 AM, Ashutosh Bapat
>> wrote:
+if (rel->partial_pathlist
On 2/28/17 20:58, David Steele wrote:
> This patch introduces a new initdb param, -u/-file-mode-mask, and a new
> GUC, file_mode_mask, to allow the default mode of files and directories
> in the $PGDATA directory to be modified.
The postmaster.pid file appears not to observe the configured mask.
On Mon, Feb 27, 2017 at 11:15 PM, Jim Nasby wrote:
>> * You're considering any WAL file with a power of 2 as valid. Suppose,
>> the correct WAL seg size is 64mb. For some reason, the server
>> generated a 16mb invalid WAL file(maybe it crashed while creating the
>> WAL
On Thu, Mar 9, 2017 at 7:59 AM, Michael Paquier
wrote:
> Yes, I agree with that for MD5, and after looking around I can see
> (like here http://prosody.im/doc/plain_or_hashed) as well that
> SCRAM-hashed is used. Now, there are as well references to the salt,
> like in
Greetings,
While going over the contrib modules, I noticed that sepgsql was not
updated for partitioned tables. What that appears to mean is that it's
not possible to define labels on partitioned tables. As I recall,
accessing the parent of a table will, similar to the GRANT system, not
perform
Hi, Kirill!
2017-03-06 12:41 GMT+05:00 Кирилл Бороздин :
> My name is Kirill Borozdin. I am a student of Ural Federal University from
> Yekaterinburg, Russia.
That's fine. I'm the associate professor at Ural Federal University.
But not in your institution, though.
> I
On Thu, Mar 9, 2017 at 9:47 AM, Stephen Frost wrote:
> Greetings,
>
> While going over the contrib modules, I noticed that sepgsql was not
> updated for partitioned tables. What that appears to mean is that it's
> not possible to define labels on partitioned tables. As I
On 03/09/2017 06:34 AM, Robert Haas wrote:
> On Thu, Mar 9, 2017 at 7:59 AM, Michael Paquier
> wrote:
>> Yes, I agree with that for MD5, and after looking around I can see
>> (like here http://prosody.im/doc/plain_or_hashed) as well that
>> SCRAM-hashed is used. Now,
On 3/6/17 05:27, Petr Jelinek wrote:
> And lastly I changed the automagic around exporting, not exporting and
> using the snapshot produced by CREATE_REPLICATION_SLOT into explicit
> parameter for the CREATE_REPLICATION_SLOT command (and added simple
> framework for adding more of those if needed
On 09.03.2017 18:58, Robert Haas wrote:
Also, even if the superset thing were true on a theoretical plane, I'm
not sure it would do us much good in practice. If we start using
YAML-specific constructs, we won't have valid JSON any more. If we
use only things that are legal in JSON, YAML's
I think you might have the titles for 0002 and 0003 backwards.
On Fri, Mar 3, 2017 at 2:51 AM, Amit Langote
wrote:
> 0002: some cosmetic fixes to create_table.sgml
I think this sentence may be unclear to some readers:
+ One might however want to set it for only
On 3/8/17 04:11, Ashutosh Bapat wrote:
> The header for this table is "list of relations", so type gets
> associated with relations indicated type of relation. btree: gin as a
> type of relation doesn't sound really great. Instead we might want to
> add another column "access method" and specify
On Sun, Feb 19, 2017 at 12:02 PM, David Christensen wrote:
> Hi Robert, this is part of a larger patch which *does* enable the checksums
> online; I’ve been extracting the necessary pieces out with the understanding
> that some people thought the disable code might be useful
On Thu, Mar 9, 2017 at 10:23 AM, Amit Kapila wrote:
>> +mode anyway). It would seem natural to complete the split in VACUUM, but
>> since
>> +splitting a bucket might require allocating a new page, it might fail if you
>> +run out of disk space. That would be bad
On 08.03.2017 20:48, Peter van Hardenberg wrote:
Small point of order: YAML is not strictly a super-set of JSON.
I haven't read the whole standard, but from what I can see the standard
considers JSON an official subset of itself:
http://www.yaml.org/spec/1.2/spec.html
Regards,
Sven
--
I typically build with --with-system-tzdata, which means that any time
Red Hat sees fit to push out a new copy of the tzdata package, that's
what I'm testing against. This morning they updated to tzdata2017a,
and I'm seeing the attached test failures.
The reason for this is that the IANA crew
Perhaps I'm confused by the title of this thread/CF entry, but
background workers already do show up in pg_stat_activity. (You can
verify that by testing the background sessions patch.) So which
additional things are we aiming to see with this?
In practice, I think it's common to do a quick
Robert Haas writes:
> This is about list-ifying a note, but I think we should try to
> de-note-ify it. It's a giant block of text that is not obviously more
> noteworthy than the surrounding text; I think should be saved
> for things that particularly need to be called
On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane wrote:
> Andres Freund writes:
>> Wonder if we there's an argument to be made for implementing this
>> roughly similarly to split_pathtarget_at_srf - instead of injecting a
>> ProjectSet node we'd add a
On 3/8/17 08:30, Stephen Frost wrote:
> Right, I don't think having an extra column which is going to be NULL a
> large amount of the time is good.
Note that \di already has a column "Table" that is null for something
that is not an index. So I don't think this argument is very strong.
--
Anecdotally, we just stored dates as strings and used a convention (key
ends in "_at", I believe) to interpret them. The lack of support for dates
in JSON is well-known, universally decried... and not a problem the
PostgreSQL community can fix.
On Thu, Mar 9, 2017 at 10:24 AM, Sven R. Kunze
Hello Amit,
On Tue, Mar 7, 2017 at 4:24 PM, Amit Langote
wrote:
> Hi Kuntal,
>
> Patches apply and compile fine. Works as advertised.
>
> Some minor comments on the patches themselves.
>
Thanks for the review.
> In 0001:
>
> - * pgstat_bestart() -
> + *
This is looking pretty neat. I played around with it a bit. There are
a couple of edge cases that you need to address, I think.
- Does not support \x
- When \pset format is rst, then \pset linestyle also shows up as
"rst". That is wrong. Same for markdown.
- Broken output in tuples_only
On 3/9/17 12:27, Mark Dilger wrote:
> Perhaps you should add something to the release notes. Somebody could be
> testing for the old error code.
The release notes will be written when the release is prepared.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development,
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > We have already figured out that the user's predicate results in a
> > subset of the index's or we wouldn't be able to use that index though,
> > right? Do we really need to spend cycles re-discovering
On 3/6/17 05:27, Petr Jelinek wrote:
> updated and rebased version of the patch attached.
Some comments on this patch:
Can we have a better explanation of different snapshot options in
CREATE_REPLICATION_SLOT. We use all these variants in different
places, but it's not fully documented why.
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I do notice that createplan.c makes some effort to get rid of filter
>> conditions that are provably true when the index conditions are.
>> Doesn't look like it considers the reverse direction. Not sure if
>>
On 08.03.2017 20:52, Magnus Hagander wrote:
On Wed, Mar 8, 2017 at 11:48 AM, Peter van Hardenberg > wrote:
Small point of order: YAML is not strictly a super-set of JSON.
Editorializing slightly, I have not seen much interest in the
world for YAML
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 3/8/17 04:11, Ashutosh Bapat wrote:
> > The header for this table is "list of relations", so type gets
> > associated with relations indicated type of relation. btree: gin as a
> > type of relation doesn't sound really
Mark Dilger writes:
>> On Mar 9, 2017, at 7:59 AM, Peter Eisentraut
>> wrote:
>> On 2/28/17 22:15, Peter Eisentraut wrote:
>>> The SQL standard defines a separate error code for nextval exhausting
>>> the sequence space. I haven't
On Thu, Mar 9, 2017 at 1:19 AM, Ashutosh Bapat
wrote:
>>> At least we need to update the documentation.
>>
>> Got a proposal?
>
> How about something like attached?
Committed with some revisions.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
On Wed, Jan 11, 2017 at 11:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 10, 2017 at 5:38 PM, Andrew Gierth
>> wrote:
>>> But the problem that actually came up is this: if you do the PQprepare
>>> before the
On Thu, Mar 9, 2017 at 12:48 PM, Sven R. Kunze wrote:
> On 08.03.2017 20:48, Peter van Hardenberg wrote:
>>
>> Small point of order: YAML is not strictly a super-set of JSON.
>
> I haven't read the whole standard, but from what I can see the standard
> considers JSON an official
On Wed, Mar 8, 2017 at 12:46 PM, Robert Haas wrote:
> Here's a patch which updates parallel.sgml for the new parallel scan
> types which have recently been committed, and also expands the
> explanation of parallel joins slightly. I hope everyone will find
> this useful in
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 3/8/17 08:30, Stephen Frost wrote:
> > Right, I don't think having an extra column which is going to be NULL a
> > large amount of the time is good.
>
> Note that \di already has a column "Table" that is null for something
> that
On Wed, Jan 25, 2017 at 12:44 AM, Craig Ringer wrote:
>> The way that SetTransactionIdLimit() now works looks a bit dangerous.
>> xidWrapLimit, xidStopLimit, and xidWarnLimit are computed based on the
>> passed-in oldestXid value and written straight into shared memory.
>>
Hi,
On 2017-03-09 13:47:35 +0100, Naytro Naytro wrote:
> We are having some performance issues after we upgraded to newest
> version of PostgreSQL, before it everything was fast and smooth.
>
> Upgrade was done by pg_upgrade from 9.4 directly do 9.6.1. Now we
> upgraded to 9.6.2 with no
Tom, all,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane wrote:
> >> If you don't want to make ExecInitExpr responsible, then the planner would
> >> have to do something like
On 09.03.2017 19:50, Peter van Hardenberg wrote:
Anecdotally, we just stored dates as strings and used a convention
(key ends in "_at", I believe) to interpret them. The lack of support
for dates in JSON is well-known, universally decried... and not a
problem the PostgreSQL community can fix.
On 2/14/17 16:50, Jeff Janes wrote:
> make installcheck currently fails against a server running
> with bytea_output = escape.
>
> Making it succeed is fairly easy, and I think it is worth doing.
>
> Attached are two options for doing that. One overrides bytea_output
> locally where-ever
On Wed, Mar 8, 2017 at 10:18 PM, Roman Shaposhnik wrote:
> I'd like to offer a forward port from a change I'm contributing
> the Greenplum code base over here:
> https://github.com/greenplum-db/gpdb/pull/1983
Thanks. Please add this to https://commitfest.postgresql.org/14/
hi
2017-03-09 17:19 GMT+01:00 Pavel Stehule :
>
>
> 2017-03-09 13:18 GMT+01:00 Surafel Temesgen :
>
>> Hi ,
>>
>> Here is a patch corrected as your feedback except missed tests case
>> because corresponding by clause is implemented on the top of
On Wed, Mar 8, 2017 at 5:23 PM, Robert Haas wrote:
> I think something like 0007-hj-shared-buf-file-v6.patch from
> https://www.postgresql.org/message-id/CAEepm=3g=dMG+84083fkFzLvgMJ7HdhbGB=aezabnukbzm3...@mail.gmail.com
> is probably a good approach to this problem. In
Robert Haas writes:
> On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane wrote:
>> If you don't want to make ExecInitExpr responsible, then the planner would
>> have to do something like split_pathtarget_at_srf anyway to decompose the
>> expressions, no matter
On 3/7/17 18:27, Mark Dilger wrote:
> You appear to be using a #define macro to wrap a function of the same name
> with the code:
>
> #define copyObject(obj) ((typeof(obj)) copyObject(obj))
Yeah, that's a bit silly. Here is an updated version that changes that.
--
Peter Eisentraut
On Wed, Mar 8, 2017 at 5:55 PM, Robert Haas wrote:
> I like to err on the side of the approach that requires fewer changes.
> That is, if the question is "does pg_restore need to treat this issue
> specially?" and the answer is unclear, I like to assume it probably
>
Robert Haas writes:
> On Thu, Mar 9, 2017 at 2:30 PM, Peter Eisentraut
> wrote:
>> In practice, I think it's common to do a quick select * from
>> pg_stat_activity to determine whether a database instance is in use.
> I thought of the
Vaishnavi Prabakaran wrote:
>if (PQbatchStatus(st->con) != PQBATCH_MODE_ON)
>
>But, it is better to use if (PQbatchStatus(st->con) ==
> PQBATCH_MODE_OFF) for this verification. Reason is there is one more state
> in batch mode - PQBATCH_MODE_ABORTED. So, if the batch mode is in
On Thu, Mar 9, 2017 at 11:19 AM, Peter Geoghegan wrote:
> That patch seems to be solving the problem by completely taking over
> management of temp files from fd.c. That is, these temp files are not
> marked as temp files in the way ordinary temp BufFiles are, with
> explicit buy-in
On Fri, Mar 10, 2017 at 12:00 AM, Joe Conway wrote:
> On 03/09/2017 06:34 AM, Robert Haas wrote:
>> On Thu, Mar 9, 2017 at 7:59 AM, Michael Paquier
>> wrote:
>>> Yes, I agree with that for MD5, and after looking around I can see
>>> (like here
On Thu, Mar 9, 2017 at 10:43 PM, Peter Eisentraut
wrote:
> On 3/8/17 02:34, Michael Paquier wrote:
>> This patch looks good to me.
>
> committed
Thanks.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Thu, Mar 9, 2017 at 2:30 PM, Peter Eisentraut
wrote:
> Perhaps I'm confused by the title of this thread/CF entry, but
> background workers already do show up in pg_stat_activity. (You can
> verify that by testing the background sessions patch.) So which
>
I tried a non-cassert compile on a machine that has a pickier compiler
than my laptop, and got:
costsize.c: In function ‘set_tablefunc_size_estimates’:
costsize.c:4574:17: error: variable ‘rte’ set but not used
[-Werror=unused-but-set-variable]
That appears to be a legitimate gripe. Perhaps:
It's just been brought to my attention that the following which worked
in current releases is broken in master:
BEGIN;
CREATE TYPE test_enum AS ENUM ('v1','v2');
ALTER TYPE test_enum OWNER TO postgres;
CREATE TABLE test_table (test_col test_enum DEFAULT 'v1'::test_enum);
COMMIT;
The
Thanks!
On 08.03.2017 17:37, Andreas Karlsson wrote:
The current code for to_char will on the first call to to_char build
arrays with the localized names of the week days and the months. I
suspect that you may need to build something similar but a set of
arrays per locale.
Not sure what the
On 08.03.2017 03:37, Robert Haas wrote:
The commit message for 64353640e87b54250f1b8a1d2a708d270dff4bfd has
some interesting perspective on this.
"""
Also, mark to_date() and to_char(interval) as stable; although these appear
not to depend on any GUC variables as of CVS HEAD, that seems a
Robert Haas writes:
> I tried a non-cassert compile on a machine that has a pickier compiler
> than my laptop, and got:
> costsize.c: In function ‘set_tablefunc_size_estimates’:
> costsize.c:4574:17: error: variable ‘rte’ set but not used
>
Amit, Michael,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> On 2017/03/09 11:51, Michael Paquier wrote:
> > OK, I am marking that as ready for committer.
>
> Thanks.
Thanks for this, I've pushed this now. I do have a few notes about
changes that I made from your patch;
- Generally
On Thu, Mar 9, 2017 at 10:54 PM, Peter Eisentraut
wrote:
> On 3/7/17 11:16, Robert Haas wrote:
>> Well, if the problem you're trying to solve is "retain WAL for as long
>> as possible without running out of disk space and having everything go
>> kablooey", then
On Thu, Mar 9, 2017 at 4:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> I tried a non-cassert compile on a machine that has a pickier compiler
>> than my laptop, and got:
>
>> costsize.c: In function ‘set_tablefunc_size_estimates’:
>>
2017-03-09 18:28 GMT+01:00 Robert Haas :
> On Thu, Mar 9, 2017 at 7:47 AM, Naytro Naytro
> wrote:
> > We are having some performance issues after we upgraded to newest
> > version of PostgreSQL, before it everything was fast and smooth.
> >
> >
On 10 March 2017 at 06:17, Robert Haas wrote:
> On Thu, Mar 9, 2017 at 11:50 AM, Dilip Kumar
> wrote:
> > On Thu, Mar 9, 2017 at 10:02 PM, Dilip Kumar
> wrote:
> >> I slightly modified your query to reproduce this issue.
> >>
1 - 100 of 211 matches
Mail list logo