On 03/02/2015 11:21 PM, Peter Geoghegan wrote:
On Mon, Mar 2, 2015 at 12:15 PM, Heikki Linnakangas wrote:
Hmm. I used a b-tree to estimate the effect that the locking would have in
the UPSERT case, for UPSERT into a table with a b-tree index. But you're
right that for the question of whether th
Thanks for reviewing my patch.
2015-03-02 22:50 GMT+09:00 Thom Brown :
> I seem to be getting a problem with whole-row references:
>
> # SELECT p.name, c.country, e.pet_name, p FROM pets e INNER JOIN people p on
> e.person_id = p.id inner join countries c on p.country_id = c.id;
> ERROR: table "r
On Tue, Mar 3, 2015 at 12:05 AM, Heikki Linnakangas wrote:
>> My experimental branch works just fine (with a variant jjanes_upsert
>> with subxact looping), until I need to restart an update after a
>> "failed" heap_update() that still returned HeapTupleMayBeUpdated
>> (having super deleted within
2015-03-02 23:07 GMT+09:00 Kouhei Kaigai :
>> I seem to be getting a problem with whole-row references:
>>
>> # SELECT p.name, c.country, e.pet_name, p FROM pets e INNER JOIN people p on
>> e.person_id = p.id inner join countries c on p.country_id = c.id;
>> ERROR: table "r" has 3 columns availabl
> 2 марта 2015 г., в 21:28, Bruce Momjian написал(а):
>
> On Tue, Feb 24, 2015 at 12:13:17PM +0300, Vladimir Borodin wrote:
>>
>>20 февр. 2015 г., в 18:21, Bruce Momjian написал(а):
>>
>>On Fri, Feb 20, 2015 at 09:45:08AM -0500, Bruce Momjian wrote:
>>
>>#3 bothered me as
Report the origin of syntax errors from pgbench.
Currently only the column number (for expressions) and command are
essentially reported:
sh> ./pgbench -f bad.sql
syntax error at column 14
set: parse error
The patch helps locate the origin of errors with the file name, line
number and
Hanada-san,
I checked the patch, below is the random comments from my side.
* Context variables
---
Sorry, I might give you a wrong suggestion.
The foreign_glob_cxt and deparse_expr_cxt were re-defined as follows:
typedef struct foreign_glob_cxt
{
PlannerInfo *root;
Greetings,
I got a problem when i used the 'security label on role ...' command to
make a label for a database role.
It show me an error like "ERROR: unsupported object type: 1260".So i read the
document about 'security label' command ,it show me like this:
SECURITY LABEL [ FOR provider ]
On 03/03/15 03:08, Arthur Silva wrote:
> Does it always perform mergesort instead of quicksort when enabled?
Yes; there seemed no advantage to any additional complexity.
The merge consistently performs fewer comparisons than the
quicksort, on random input - and many fewer if there are
any sorted (
Are you trying with sepgsql.so module?
From standpoint of SQL syntax, yep, SECURITY LABEL command support
the object types below, however, it fully depends on security label
provider; sepgsql.so in this case.
At this moment, it supports database, schema, function, tables and
column are supported b
Thanks for the detailed comments.
2015-03-03 18:01 GMT+09:00 Kouhei Kaigai :
> Hanada-san,
>
> I checked the patch, below is the random comments from my side.
>
> * Context variables
> ---
> Sorry, I might give you a wrong suggestion.
> The foreign_glob_cxt and deparse_expr_cxt wer
On Tue, Mar 3, 2015 at 8:51 AM, Josh Berkus wrote:
> On 03/02/2015 03:43 PM, Andres Freund wrote:
>> Hi,
>>
>> On 2015-03-02 15:40:27 -0800, Josh Berkus wrote:
>>> ! #max_wal_size = 1GB# in logfile segments
>>
>> Independent of the rest of the changes, the "in logfile segme
On Tue, Mar 3, 2015 at 4:25 PM, Heikki Linnakangas wrote:
> On 03/03/2015 01:43 AM, Andres Freund wrote:
>>
>> On 2015-03-02 15:40:27 -0800, Josh Berkus wrote:
>>>
>>> ! #max_wal_size = 1GB # in logfile segments
>>
>>
>> Independent of the rest of the changes, the "in logfile seg
On Tue, Mar 3, 2015 at 12:36 AM, Marco Nenciarini
wrote:
> Il 02/03/15 14:21, Fujii Masao ha scritto:
>> On Thu, Feb 12, 2015 at 10:50 PM, Marco Nenciarini
>> wrote:
>>> Hi,
>>>
>>> I've attached an updated version of the patch.
>>
>> basebackup.c:1565: warning: format '%lld' expects type 'long l
> > * Bug reported by Thom Brown
> > -
> > # EXPLAIN VERBOSE SELECT NULL FROM (SELECT people.id FROM people INNER JOIN
> countries ON people.country_id = countries.id LIMIT 3) x;
> > ERROR: could not open relation with OID 0
> >
> > Sorry, it was a problem caused by my
On 2015-02-25 14:04:55 -0800, Peter Geoghegan wrote:
> On Wed, Feb 25, 2015 at 3:26 AM, Andres Freund wrote:
> > I'm pretty sure this will entirely fail if you have a transaction that's
> > large enough to spill to disk. Calling ReorderBufferIterTXNNext() will
> > reuse the memory for the in memor
Sorry, I misoperated on patch creation.
Attached one is the correct version.
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
> Sent: Tuesda
Thank you Michael. I have looked the patch. Overall logic looks good to me,
I have checked it with MSVC{2013,2008}. It works for MSVC 2013 but fail for
MSVC 2008, I think the condition "if ($proj =~
qr{ResourceCompile\s*Include="([^"]+)”})” is not going to work for MSVC2008
and MSVC2005 i.e.
MSVC2
Kaigai-san,
The v6 patch was cleanly applied on master branch. I'll rebase my
patch onto it, but before that I have a comment about name of the new
FDW API handler GetForeignJoinPath.
Obviously FDW can add multiple paths at a time, like GetForeignPaths,
so IMO it should be renamed to GetForeignJ
On 2015-03-02 16:32:53 -0500, Tom Lane wrote:
> Andres Freund writes:
> > The easiest way to solve this would teach ruleutils.c to simply always
> > attach AS clauses for auto-generated columnnames. Won't look too pretty
> > though. Does somebody have a better idea?
>
> No, it would look awful :-
I rebased "join push-down" patch onto Kaigai-san's Custom/Foreign Join
v6 patch. I posted some comments to v6 patch in this post:
http://www.postgresql.org/message-id/CAEZqfEcNvjqq-P=jxnw1pb4t9wvpcporcn7g6cc46jgub7d...@mail.gmail.com
Before applying my v3 patch, please apply Kaigai-san's v6 patc
On 3 March 2015 at 12:34, Shigeru Hanada wrote:
> I rebased "join push-down" patch onto Kaigai-san's Custom/Foreign Join
> v6 patch. I posted some comments to v6 patch in this post:
>
> http://www.postgresql.org/message-id/CAEZqfEcNvjqq-P=jxnw1pb4t9wvpcporcn7g6cc46jgub7d...@mail.gmail.com
>
> Bef
On Tue, Mar 3, 2015 at 11:38:58AM +0300, Vladimir Borodin wrote:
> No, you would not need to take a full backup if you use these
> instructions.
>
>
> Although it would be applied to documentation for 9.5 only, are these
> instructions applicable for upgrading from 9.3.6 to 9.4.1?
Yes. Th
On Tue, Mar 3, 2015 at 08:38:50AM -0500, Bruce Momjian wrote:
> > < 2015-02-24 11:47:22.861 MSK >WARNING: WAL was generated with wal_level=
> > minimal, data may be missing
> > < 2015-02-24 11:47:22.861 MSK >HINT: This happens if you temporarily set
> > wal_level=minimal without taking a new bas
> 3 марта 2015 г., в 16:38, Bruce Momjian написал(а):
>
> On Tue, Mar 3, 2015 at 11:38:58AM +0300, Vladimir Borodin wrote:
>>No, you would not need to take a full backup if you use these
>> instructions.
>>
>>
>> Although it would be applied to documentation for 9.5 only, are these
>> in
David Kubečka wrote:
> I have read the optimizer README file and also looked briefly at
> the code, but this seems to be something not related to
> particular implementation of algorithm (e.g. nested loop).
> Perhaps it's the way how cost estimates are propagated down
It could be as simple as no
On March 2, 2015 12:56:23 AM Jan de Visser wrote:
>
> Here's my first crack at this. Notes:
> 1/ I haven't done the '-W' flag Tom mentions yet.
> 2/ Likewise haven't touched pg_reload_conf()
> 3/ Design details: I introduced a new struct in pg_ctl containing the
> parsed- out data from postmaster.
PL/Python uses str(v) to convert float data, but is lossy
by design. Only repr(v) is guaranteed to have enough
precision to make floats roundtrip properly:
https://docs.python.org/2/library/functions.html#func-repr
https://docs.python.org/2/library/functions.html#str
Example:
$ python
>
Andres Freund writes:
> Hm, so I looked into it, and I think the problem is actually restricted
> to columns where the typename that FigureColname() assigns is different
> from the one that will result after ger_rule_expr()/get_const_expr()'s
> implicit cast is added.
> For this case it seems eas
On Tue, Mar 3, 2015 at 04:55:56PM +0300, Vladimir Borodin wrote:
> OK, hmmm. Thanks for testing. It feels like you didn't have your new
> master set up for streaming replication when you ran pg_upgrade. Is
> that correct? Should I specify that specifically in the instructions?
>
>
On Mon, Jun 30, 2014 at 8:06 AM, Abhijit Menon-Sen wrote:
> After sleeping on it, I realised that the code would return '{all}' for
> 'all' in pg_hba.conf, but '{"all"}' for '"all"'. So it's not exactly
> ambiguous, but I don't think it's especially useful for callers.
Hm. Nope, it doesn't. It ju
On Fri, Feb 20, 2015 at 1:26 AM, Tom Lane wrote:
> 1. Extend the definition of the postmaster.pid file to add another
> line, which will contain the time of the last postmaster configuration
> load attempt (might as well be a numeric Unix-style timestamp) and
> a boolean indication of whether that
Hi all,
I have encountered a performance problem with relatively simple query,
which I think is caused by the overly pesimistic estimates in optimizer. I
have originally run into this issue on a table few GBs large, but it can be
reproduced with much smaller table as follows:
-- Setup main fact t
Hi,
Sorry for the delay, I missed this thread.
Here is a new version of this patch considering Andreas' comments.
On 30/12/2014 03:48, Andreas Karlsson wrote:
> - A test fails in create_view.out. I looked some into it and did not see
> how this could happen.
>
> ***
> /home/andreas/dev/po
Hi all,
I have encountered a performance problem with relatively simple query,
which I think is caused by the overly pesimistic estimates in optimizer. I
have originally run into this issue on a table few GBs large, but it can be
reproduced with much smaller table as follows:
-- Setup main fact t
On 2015-03-03 15:21:24 +, Greg Stark wrote:
> Fwiw this concerns me slightly. I'm sure a lot of people are doing
> things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
postmaster.pid already contains considerably more than just the pid. e.g.
4071
/srv/dev/pgdev-master
1425396089
Andres Freund writes:
> On 2015-03-03 15:21:24 +, Greg Stark wrote:
>> Fwiw this concerns me slightly. I'm sure a lot of people are doing
>> things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
> postmaster.pid already contains considerably more than just the pid. e.g.
Yeah, t
Hello,
>It would be good to get those problems fixed first. Could you send an updated
>patch?
Please find attached updated patch with WAL replay error fixed. The patch
follows chunk ID approach of xlog format.
Following are brief measurement numbers.
Hi,
I've regularly wished we had automated tests that setup HS and then
compare primary/standby at the end to verify replay worked
correctly.
Heikki's page comparison tools deals with some of that verification, but
it's really quite expensive and doesn't care about runtime only
differences. I.e.
On 2015-03-03 09:39:03 -0500, Tom Lane wrote:
> Andres Freund writes:
> > For this case it seems easiest if we'd make get_rule_expr() (and some of
> > its helpers) return whether an implicit cast has been added.
>
> Aside from being pretty ugly, that doesn't seem particularly
> bulletproof.
Right
Andres Freund writes:
> On 2015-03-03 09:39:03 -0500, Tom Lane wrote:
>> And on the third hand ... doing that would really only be robust as long
>> as you assume that the output will be read by a server using exactly the
>> same FigureColname() logic as what we are using. So maybe the whole idea
On Sun, Feb 22, 2015 at 03:12:12PM -0500, Magnus Hagander wrote:
> > # Attempt to identify the file using magic information
> > mtype = mag.buffer(contents)
> > if mtype.startswith('text/x-diff'):
> > a.ispatch
On Tue, Mar 3, 2015 at 10:58:28AM -0500, Bruce Momjian wrote:
> > Would you suggest removing the automated system completely, or keep it
> > around
> > and just make it possible to override it (either by removing the note that
> > something is a patch, or by making something that's not listed as
On Tue, Oct 14, 2014 at 01:21:53PM -0400, Bruce Momjian wrote:
> On Tue, Oct 14, 2014 at 09:20:22AM -0700, Jeff Janes wrote:
> > On Mon, Oct 13, 2014 at 12:11 PM, Bruce Momjian wrote:
> >
> >
> > I looked into this, and came up with more questions. Why is
> > checkpoint_completion_targe
On 2015-03-03 11:09:29 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-03-03 09:39:03 -0500, Tom Lane wrote:
> > I think this is the way to go though. There's different extremes we can
> > go to though - the easiest is to simply remove the attname = "?column?"
> > assignment from get_ta
On 3/3/15 9:26 AM, Andres Freund wrote:
On 2015-03-03 15:21:24 +, Greg Stark wrote:
Fwiw this concerns me slightly. I'm sure a lot of people are doing
things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
postmaster.pid already contains considerably more than just the pid. e.
On March 3, 2015 10:29:43 AM Tom Lane wrote:
> Andres Freund writes:
> > On 2015-03-03 15:21:24 +, Greg Stark wrote:
> >> Fwiw this concerns me slightly. I'm sure a lot of people are doing
> >> things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
> >
> > postmaster.pid already
On March 3, 2015 11:09:29 AM Jim Nasby wrote:
> On 3/3/15 9:26 AM, Andres Freund wrote:
> > On 2015-03-03 15:21:24 +, Greg Stark wrote:
> >> Fwiw this concerns me slightly. I'm sure a lot of people are doing
> >> things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
> >
> > postm
On Thu, Feb 26, 2015 at 01:55:44PM -0800, Josh Berkus wrote:
> On 02/26/2015 01:54 PM, Alvaro Herrera wrote:
> > This patch decouples these three things so that they
> > can changed freely -- but provides no user interface to do so. I think
> > that trying to only decouple the thing we currently h
On 3/3/15 11:23 AM, Bruce Momjian wrote:
On Thu, Feb 26, 2015 at 01:55:44PM -0800, Josh Berkus wrote:
On 02/26/2015 01:54 PM, Alvaro Herrera wrote:
This patch decouples these three things so that they
can changed freely -- but provides no user interface to do so. I think
that trying to only de
On 3/3/15 11:15 AM, Jan de Visser wrote:
On March 3, 2015 11:09:29 AM Jim Nasby wrote:
On 3/3/15 9:26 AM, Andres Freund wrote:
On 2015-03-03 15:21:24 +, Greg Stark wrote:
Fwiw this concerns me slightly. I'm sure a lot of people are doing
things like "kill -HUP `cat .../postmaster.pid`" or
On Tue, Mar 3, 2015 at 11:24:38AM -0600, Jim Nasby wrote:
> On 3/3/15 11:23 AM, Bruce Momjian wrote:
> >On Thu, Feb 26, 2015 at 01:55:44PM -0800, Josh Berkus wrote:
> >>On 02/26/2015 01:54 PM, Alvaro Herrera wrote:
> >>>This patch decouples these three things so that they
> >>>can changed freely -
On 2015-03-03 11:09:29 -0600, Jim Nasby wrote:
> On 3/3/15 9:26 AM, Andres Freund wrote:
> >On 2015-03-03 15:21:24 +, Greg Stark wrote:
> >>Fwiw this concerns me slightly. I'm sure a lot of people are doing
> >>things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
> >
> >postmaste
Stephen,
Thanks for the review. I have pushed these patches, squashed in one
commit, with the exception of the one that changed ALTER TABLE. You had
enough comments about that one that I decided to put it aside for now,
and get the other ones done. I will post a new series shortly.
I fixed (mo
On 3/3/15 11:26 AM, Bruce Momjian wrote:
On Tue, Mar 3, 2015 at 11:24:38AM -0600, Jim Nasby wrote:
On 3/3/15 11:23 AM, Bruce Momjian wrote:
On Thu, Feb 26, 2015 at 01:55:44PM -0800, Josh Berkus wrote:
On 02/26/2015 01:54 PM, Alvaro Herrera wrote:
This patch decouples these three things so th
On 3/3/15 11:33 AM, Andres Freund wrote:
On 2015-03-03 11:09:29 -0600, Jim Nasby wrote:
On 3/3/15 9:26 AM, Andres Freund wrote:
On 2015-03-03 15:21:24 +, Greg Stark wrote:
Fwiw this concerns me slightly. I'm sure a lot of people are doing
things like "kill -HUP `cat .../postmaster.pid`" or
On 2015-03-03 11:43:46 -0600, Jim Nasby wrote:
> It's certainly better than now, but why put DBAs through an extra step for
> no reason?
Because it makes it more complicated than it already is? It's nontrivial
to capture the output, escape it to somehow fit into a delimited field,
et al. I'd rath
On Fri, Feb 27, 2015 at 09:09:35AM +0900, Amit Langote wrote:
> On 27-02-2015 AM 03:24, Andres Freund wrote:
> > On 2015-02-26 12:15:17 +0900, Amit Langote wrote:
> >> On 26-02-2015 AM 05:15, Josh Berkus wrote:
> >>> I would love to have it for 9.5, but I guess the
> >>> patch isn't nearly baked en
On Tue, Mar 3, 2015 at 2:00 AM, Jeremy Harris wrote:
> Yes; there seemed no advantage to any additional complexity.
> The merge consistently performs fewer comparisons than the
> quicksort, on random input - and many fewer if there are
> any sorted (or reverse-sorted) sections. However, it also
>
On 3/3/15 9:08 AM, Greg Stark wrote:
On Mon, Jun 30, 2014 at 8:06 AM, Abhijit Menon-Sen wrote:
After sleeping on it, I realised that the code would return '{all}' for
'all' in pg_hba.conf, but '{"all"}' for '"all"'. So it's not exactly
ambiguous, but I don't think it's especially useful for cal
On 03/02/2015 11:25 PM, Heikki Linnakangas wrote:
> I propose that we remove the comment from max_wal_size, and also remove
> the "in milliseconds" from wal_receiver_timeout and
> autovacuum_vacuum_cost_delay.
+1
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-ha
On 03/03/2015 10:15 AM, Josh Berkus wrote:
> On 03/02/2015 11:25 PM, Heikki Linnakangas wrote:
>> I propose that we remove the comment from max_wal_size, and also remove
>> the "in milliseconds" from wal_receiver_timeout and
>> autovacuum_vacuum_cost_delay.
>
> +1
>
Actually, let's be consistent
On 03/03/2015 07:49 AM, Andres Freund wrote:
> I'd very much like to add a automated test like this to the tree, but I
> don't see wa way to do that sanely without a comparison tool...
We could use a comparison tool anyway. Baron Schwartz was pointing out
that Percona has a comparison tool for My
On 03/03/2015 08:21 PM, Josh Berkus wrote:
On 03/03/2015 10:15 AM, Josh Berkus wrote:
On 03/02/2015 11:25 PM, Heikki Linnakangas wrote:
I propose that we remove the comment from max_wal_size, and also remove
the "in milliseconds" from wal_receiver_timeout and
autovacuum_vacuum_cost_delay.
+1
On 03/03/2015 10:29 AM, Heikki Linnakangas wrote:
> On 03/03/2015 08:21 PM, Josh Berkus wrote:
>> On 03/03/2015 10:15 AM, Josh Berkus wrote:
>>> On 03/02/2015 11:25 PM, Heikki Linnakangas wrote:
I propose that we remove the comment from max_wal_size, and also remove
the "in milliseconds"
On 03/03/2015 08:31 PM, Josh Berkus wrote:
On 03/03/2015 10:29 AM, Heikki Linnakangas wrote:
On 03/03/2015 08:21 PM, Josh Berkus wrote:
On 03/03/2015 10:15 AM, Josh Berkus wrote:
On 03/02/2015 11:25 PM, Heikki Linnakangas wrote:
I propose that we remove the comment from max_wal_size, and also
On 03/03/2015 10:37 AM, Heikki Linnakangas wrote:
> On 03/03/2015 08:31 PM, Josh Berkus wrote:
>> On 03/03/2015 10:29 AM, Heikki Linnakangas wrote:
>>> On 03/03/2015 08:21 PM, Josh Berkus wrote:
On 03/03/2015 10:15 AM, Josh Berkus wrote:
> On 03/02/2015 11:25 PM, Heikki Linnakangas wrote:
On Tue, Mar 3, 2015 at 6:05 PM, Jim Nasby wrote:
> What about a separate column that's just the text from pg_hba? Or is that
> what you're opposed to?
I'm not sure what you mean by that. There's a rawline field we could
put somewhere but it contains the entire line.
> FWIW, I'd say that having
Naive question: would it be /possible/ to change configuration to accept
percentages, and have a percent mean "of existing RAM at startup time"?
I ask because most of the tuning guidelines I see suggest setting memory
parameters as a % of RAM available.
On Tue, Mar 3, 2015 at 1:29 PM, Heikki Linn
On 03/03/2015 02:12 AM, Fujii Masao wrote:
> On Tue, Mar 3, 2015 at 8:51 AM, Josh Berkus wrote:
>> On 03/02/2015 03:43 PM, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2015-03-02 15:40:27 -0800, Josh Berkus wrote:
! #max_wal_size = 1GB# in logfile segments
>>>
>>> Independe
I wrote:
> Robert Haas writes:
>> On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote:
>>> To some extent this is a workaround for the fact that plpgsql does type
>>> conversions the way it does (ie, by I/O rather than by using the parser's
>>> cast mechanisms). We've talked about changing that, but
On 03/03/2015 10:58 AM, Corey Huinker wrote:
> Naive question: would it be /possible/ to change configuration to accept
> percentages, and have a percent mean "of existing RAM at startup time"?
>
> I ask because most of the tuning guidelines I see suggest setting memory
> parameters as a % of RAM
2015-03-03 20:32 GMT+01:00 Tom Lane :
> I wrote:
> > Robert Haas writes:
> >> On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote:
> >>> To some extent this is a workaround for the fact that plpgsql does type
> >>> conversions the way it does (ie, by I/O rather than by using the
> parser's
> >>> cas
Josh Berkus writes:
> Do we want to remove unit comments from all settings which accept
> "MB,GB" or "ms,s,min"? There's more than a few. I'd be in favor of
> this, but seems like (a) it should be universal, and (b) its own patch.
Meh. Doing this strikes me as a serious documentation failure,
On 03/03/2015 11:57 AM, Tom Lane wrote:
> Josh Berkus writes:
>> Do we want to remove unit comments from all settings which accept
>> "MB,GB" or "ms,s,min"? There's more than a few. I'd be in favor of
>> this, but seems like (a) it should be universal, and (b) its own patch.
>
> Meh. Doing thi
On 04/03/15 08:57, Tom Lane wrote:
Josh Berkus writes:
Do we want to remove unit comments from all settings which accept
"MB,GB" or "ms,s,min"? There's more than a few. I'd be in favor of
this, but seems like (a) it should be universal, and (b) its own patch.
Meh. Doing this strikes me as a
No intention to hijack. Dropping issue for now.
On Tue, Mar 3, 2015 at 2:05 PM, Josh Berkus wrote:
> On 03/03/2015 10:58 AM, Corey Huinker wrote:
> > Naive question: would it be /possible/ to change configuration to accept
> > percentages, and have a percent mean "of existing RAM at startup time
>
> I think even something that just does that in pure SQL/plpgsql would be a
> big step forward, even if we wouldn't want it directly in the codebase.
Something like creating a trigger under the hood each time a MV is created,
that checks the changed rows on every statement against the query th
On 03/03/2015 02:59 PM, Josh Berkus wrote:
On 03/03/2015 11:57 AM, Tom Lane wrote:
Josh Berkus writes:
Do we want to remove unit comments from all settings which accept
"MB,GB" or "ms,s,min"? There's more than a few. I'd be in favor of
this, but seems like (a) it should be universal, and (b
On Mon, Mar 2, 2015 at 5:41 PM, Fabien COELHO wrote:
>> but I'd like to have a more robust discussion about what we want the error
>> reporting to look like rather than just sliding it into this patch.
>
> As an input, I suggest that the error reporting feature should provide a
> clue about where
Jim Nasby wrote:
> FWIW, what I would find most useful at this point is a way to get the
> equivalent of an AFTER STATEMENT trigger that provided all changed rows in a
> MV as the result of a statement.
Ah, like
https://www.postgresql.org/message-id/1402790204.65037.YahooMailNeo%40web122301.mail.
On 2/28/15 6:32 PM, Stephen Frost wrote:
> This isn't really /etc/shadow though, this is more like direct access to
> the filesystem through the device node- and you'll note that Linux
> certainly has got an independent set of permissions for that called the
> capabilities system. That's because m
On Tue, Mar 03, 2015 at 05:49:06PM -0300, Alvaro Herrera wrote:
> Jim Nasby wrote:
>
> > FWIW, what I would find most useful at this point is a way to get
> > the equivalent of an AFTER STATEMENT trigger that provided all
> > changed rows in a MV as the result of a statement.
>
> Ah, like
> https
On Wed, Feb 25, 2015 at 7:27 AM, Michael Paquier
wrote:
> Coverity is pointing out that addRangeTableEntry contains the
> following code path that does a NULL-pointer check on pstate:
> if (pstate != NULL)
> pstate->p_rtable = lappend(pstate->p_rtable, rte);
> But pstate is
On 3/1/15 2:17 PM, Stephen Frost wrote:
> Peter, if you have a minute, could you take a look at this thread and
> discussion of having TAP tests under src/test/modules which need to
> install an extension? I think it's something we certainly want to
> support but I'm not sure it's a good idea to j
On Wed, Feb 25, 2015 at 10:03 AM, Fabien COELHO wrote:
>> You can add tests in src/test/modules/dummy_seclabel.
>
> Patch attached to test sec label there, in addition to the other more
> standard checks in event_trigger.
These tests seem worthwhile to me.
--
Robert Haas
EnterpriseDB: http://ww
On Mon, Mar 2, 2015 at 6:22 PM, Fujii Masao wrote:
> On Tue, Mar 3, 2015 at 3:07 AM, Josh Berkus wrote:
>>> Per document,
>>>
>>> --
>>> In fast failover, the server is brought up immediately. Any WAL files
>>> in the archive that have not yet been applied will be ignored, and all
On 3/3/15 2:36 PM, Andrew Dunstan wrote:
On 03/03/2015 02:59 PM, Josh Berkus wrote:
On 03/03/2015 11:57 AM, Tom Lane wrote:
Josh Berkus writes:
Do we want to remove unit comments from all settings which accept
"MB,GB" or "ms,s,min"? There's more than a few. I'd be in favor of
this, but seem
On Tue, Mar 3, 2015 at 11:41:20AM -0600, Jim Nasby wrote:
> >>Wouldn't it need attno info too, so all 3 orderings?
> >
> >Uh, what is the third ordering? Physical, logical, and ? It already
> >gets information about dropped columns, if that is the third one.
>
> attnum; used in other catalogs t
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sat, Feb 28, 2015 at 12:27 AM, Stephen Frost wrote:
> > While this generally "works", the usual expectation is that functions
> > that should be superuser-only have a check in the function rather than
> > depending on the execute privilege. I'm ce
On 3/3/15 3:34 PM, David Fetter wrote:
On Tue, Mar 03, 2015 at 05:49:06PM -0300, Alvaro Herrera wrote:
Jim Nasby wrote:
FWIW, what I would find most useful at this point is a way to get
the equivalent of an AFTER STATEMENT trigger that provided all
changed rows in a MV as the result of a state
On Tue, Mar 3, 2015 at 10:29 PM, Stephen Frost wrote:
>> -1. If that policy exists at all, it's a BAD policy, because it
>> prevents users from changing the permissions using DDL. I think the
>> superuser check should be inside the function, when, for example, it
>> masks some of the output data
Stephen Frost writes:
> It's not a documented policy but it's certainly what a whole slew of
> functions *do*. Including pg_start_backup, pg_stop_backup,
> pg_switch_xlog, pg_rotate_logfile, pg_create_restore_point,
> pg_xlog_replay_pause, lo_import, lo_export, and pg_xlog_replay_resume,
> pg_rea
On 3/3/15 11:48 AM, Andres Freund wrote:
On 2015-03-03 11:43:46 -0600, Jim Nasby wrote:
>It's certainly better than now, but why put DBAs through an extra step for
>no reason?
Because it makes it more complicated than it already is? It's nontrivial
to capture the output, escape it to somehow fi
Jim Nasby writes:
> On 3/3/15 11:48 AM, Andres Freund wrote:
>> It'll be confusing to have different interfaces in one/multiple error cases.
> If we simply don't want the code complexity then fine, but I just don't
> buy this argument. How could it possibly be confusing?
What I'm concerned abou
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > The discussion I'm having with Peter on another thread is a very similar
> > case that should be looping in, which is if we should continue to have
> > any superuser check on updating catalog tables. He is advocating that
> > we r
On March 3, 2015 04:57:58 PM Jim Nasby wrote:
> On 3/3/15 11:48 AM, Andres Freund wrote:
> > I'm saying that you'll need a way to notice that a reload was processed
> > or not. And that can't really be the message itself, there has to be
> > some other field; like the timestamp Tom proposes.
>
On Fri, Feb 20, 2015 at 4:01 PM, Peter Geoghegan wrote:
> On Fri, Feb 20, 2015 at 11:58 AM, Tomas Vondra
> wrote:
>> This seems to happen because ordered_set_startup() calls
>> tuplesort_begin_datum() when (use_tuples == true), which only sets
>> 'onlyKey' and leaves (sortKeys == NULL). So 'merge
On Tue, Feb 24, 2015 at 2:20 PM, Peter Eisentraut wrote:
> On 2/20/15 3:09 PM, Tomas Vondra wrote:
>> The 'combine' function gets two such 'state' values, while transition
>> gets 'state' + next value.
>
> I think the combine function is not actually a property of the
> aggregate, but a property o
On Tue, Mar 3, 2015 at 3:53 PM, Robert Haas wrote:
> I find your statement that this is a pre-existing issue in
> tuplesort_begin_datum() to be pretty misleading, unless what you mean
> by it is "pre-existing since November, when an earlier patch by Peter
> Geoghegan changed the comments without c
1 - 100 of 139 matches
Mail list logo
