On Fri, Oct 16, 2015 at 9:51 AM, Robert Haas wrote:
>
> On Mon, Oct 5, 2015 at 8:20 AM, Amit Kapila
wrote:
> > [ new patch for heapam.c changes ]
>
> There's a second patch attached here as well, parallel-relaunch.patch,
> which makes it possible to relaunch workers with the same parallel
> conte
On Fri, Oct 16, 2015 at 11:29 PM, Michael Paquier wrote:
> Well, I have played a bit with this patch and rebased it as attached.
> One major change is the use of the variables PG_INT* that have been
> added in 62e2a8d. Some places were not updated with those new checks,
> in majority a couple of ro
On Mon, Oct 19, 2015 at 4:06 AM, Andres Freund wrote:
>
>
> I wonder if mmap() && msync(MS_ASYNC) isn't a better replacement for
> sync_file_range(SYNC_FILE_RANGE_WRITE) than posix_fadvise(DONTNEED). It
> might even be possible to later approximate that on windows using
> FlushViewOfFile().
>
I t
On Tue, Oct 20, 2015 at 1:05 AM, Alvaro Herrera
wrote:
>
> Fabien COELHO wrote:
>
> > >4) It's a bit dubious to only pgstat_send_bgwriter() when on schedule.
> >
> > No opinion!
>
> My guess here, without looking, is that this was based on the idea of
> "oops, we're late here for the checkpoint, l
Hello,
>I think that you should add the flag or something which indicates whether this
>backend is running VACUUM or not, into PgBackendStatus.
>pg_stat_vacuum_progress should display the entries of only backends with that
>flag set true. This design means that you need to set the flag to true w
You can create a Security Definer Funtion which can then be executed by
then non-superuser monitoring role:
(Assuming you have a role monitoring and pg_stat_statements is installed in
schema public)
-- connected as a superuser
CREATE FUNCTION pg_stat_statements()
RETURNS SETOF pg_stat
On 13 October 2015 at 20:57, Haribabu Kommi
wrote:
> On Tue, Oct 13, 2015 at 5:53 PM, David Rowley
> wrote:
> > On 13 October 2015 at 17:09, Haribabu Kommi
> > wrote:
> >>
> >> On Tue, Oct 13, 2015 at 12:14 PM, Robert Haas
> >> wrote:
> >> > Also, I think the path for parallel aggregation shou
On Mon, Oct 19, 2015 at 3:45 AM, Etsuro Fujita
wrote:
As Tom mentioned, just recomputing the original join tuple is not good
enough. We would need to rejoin the test tuples for the baserels even if
ROW_MARK_COPY is in use. Consider:
A=# BEGIN;
A=# UPDATE t SET a = a + 1 WHERE b = 1;
B=# SELEC
On Mon, Oct 19, 2015 at 8:47 PM, Masahiko Sawada
wrote:
>
> Hi,
>
> Attached patch is a rough patch which supports multi sync replication
> by another approach I sent before.
>
> The new GUC parameters are:
> * synchronous_standby_num, which specifies the number of standby
> servers using sync re
On 19 October 2015 at 20:16, Tomas Vondra
wrote:
> Hello Kyotaro-san,
>
> On 09/11/2015 06:58 PM, Tomas Vondra wrote:
> >
>
>> Maybe the best solution is to abandon the ALTER TABLE approach
>> entirely, and instead invent a new set of commands
>>
>>CREATE STATISTICS
>>DROP STATISTICS
>>
>
On Fri, Oct 16, 2015 at 7:11 PM, Alexander Korotkov
wrote:
> On Sun, Jun 7, 2015 at 11:01 PM, Peter Geoghegan wrote:
>
>> On Sun, Jun 7, 2015 at 8:10 AM, Andreas Karlsson
>> wrote:
>> > Are you planning to work on this patch for 9.6?
>>
>> FWIW I hope so. It's a nice patch.
>>
>
> I'm trying to
walsender.c, CreateReplicationSlot() currently has this:
slot_name = NameStr(MyReplicationSlot->data.name);
if (cmd->kind == REPLICATION_KIND_LOGICAL)
{
[...]
}
else if (cmd->kind == REPLICATION_KIND_PHYSICAL && cmd->reserve_wal)
{
[
Hi,
I found typos in plannodes.h: s/scan.plan.quals/scan.plan.qual/g Please
find attached a patch.
Best regards,
Etsuro Fujita
diff --git a/src/include/nodes/plannodes.h b/src/include/nodes/plannodes.h
index 92fd8e4..6b28c8e 100644
--- a/src/include/nodes/plannodes.h
+++ b/src/include/nodes/plan
On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek wrote:
> I agree with that sentiment.
>
> Attached patch adds variable to the shmem which is used for module
> activation tracking - set to true in ActiveCommitTs() and false in
> DeactivateCommitTs(). All the checks inside the commit_ts code were chan
On Sun, Oct 18, 2015 at 2:52 PM, Peter Geoghegan wrote:
> On Thu, Oct 15, 2015 at 9:07 AM, Robert Haas wrote:
>> Would you be willing to try coding it up that way so we can see how it looks?
>
> I attach a patch that does it that way.
That looks good to me. I've committed this, and the other pa
Hi.
Introduction
PostgreSQL full-text search extension uses dictionaries from the various
open source spell checker software to perform word normalization.
Currently, Ispell, MySpell and Hunspell dictionaries are supported.
Dictionaries requires two files: a dictionary file and
On Sun, Oct 18, 2015 at 4:56 PM, Shay Rojansky wrote:
> Here's a patch that adds back the GUC, with default/min/max 0 and
> GUC_NO_SHOW_ALL | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE.
>
> This is my first pg patch, please be gentle with any screwups :)
Why, you dummy.
No, actually, this looks fi
On Sun, Oct 18, 2015 at 5:23 PM, Jeff Janes wrote:
> I'm planning on adding a todo item to have COPY FREEZE set PD_ALL_VISIBLE.
> Or is there some reason this can't be done?
>
> Since the whole point of COPY FREEZE is to avoid needing to rewrite the
> entire table, it seems rather perverse that th
Hey Lukas,
Thanks. Able to see the queries from all users. Can you explain the
monitoring.get_stat_statements()?
--
View this message in context:
http://postgresql.nabble.com/SuperUser-check-in-pg-stat-statements-tp5870589p5870733.html
Sent from the PostgreSQL - hackers mailing list archive at
On 2015-10-19 21:14:55 +0200, Fabien COELHO wrote:
> >In my performance testing it showed that calling PerformFileFlush() only
> >at segment boundaries and in CheckpointWriteDelay() can lead to rather
> >spikey IO - not that surprisingly. The sync in CheckpointWriteDelay() is
> >problematic because
On Sun, Oct 18, 2015 at 6:59 PM, Jeff Janes wrote:
> This patch adds "VERSION" to the list of words completed after "create
> extension foo", and adds the list of available versions of foo after "create
> extension foo version".
>
> There is no point in filtering out the already installed version,
On Mon, Oct 19, 2015 at 12:25 AM, Amit Langote
wrote:
> Attached fixes the following in comment above ExecCheckIndexConstraints:
>
> s/no no conflict/no conflict/g
Thanks, committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-
Wouldn't it be better to have these two parameters documented next to each
other,
as in the attached patch?
Yours,
Laurenz Albe
0001-Move-documentation-for-min_wal_size-before-max_wal_s.patch
Description: 0001-Move-documentation-for-min_wal_size-before-max_wal_s.patch
--
Sent via pgsql-hacker
On Sat, Oct 17, 2015 at 6:17 PM, Robert Haas wrote:
> It's good to have your perspective on how this can be improved, and
> I'm definitely willing to write more documentation. Any lack in that
> area is probably due to being too close to the subject area, having
> spent several years on paralleli
On Mon, Oct 19, 2015 at 7:59 PM, Jim Nasby wrote:
> I fail to see how doing
>
> HINT: NULL
>
> is much better than just not raising a HINT at all...
I'm not a huge fan of this patch, as previously noted, but I certainly
agree that if we're going to do it, we should ignore a null argument,
not pri
On Mon, Oct 19, 2015 at 8:02 PM, Jim Nasby wrote:
> On 10/19/15 1:07 PM, David Fetter wrote:
>>
>> What I'd like to do is lift the restriction on ROWS FROM(), which
>> currently requires that the stuff inside the parentheses set-returning
>> functions, so constructs something like the following wo
Hi,
On 10/20/2015 01:14 PM, Simon Riggs wrote:
On 19 October 2015 at 20:16, Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote:
Hello Kyotaro-san,
On 09/11/2015 06:58 PM, Tomas Vondra wrote:
>
Maybe the best solution is to abandon the ALTER TABLE approach
ent
On Tue, Oct 20, 2015 at 12:48 AM, Rajeev rastogi
wrote:
> On 19 October 2015 21:37, Robert Haas [mailto:robertmh...@gmail.com] Wrote:
>
>>On Sat, Oct 17, 2015 at 4:52 PM, Alvaro Herrera
>> wrote:
>>> Andres Freund wrote:
On 2015-10-14 17:33:01 +0900, Kyotaro HORIGUCHI wrote:
> If I reca
On Tue, Oct 20, 2015 at 10:52:05AM -0400, Robert Haas wrote:
> On Mon, Oct 19, 2015 at 8:02 PM, Jim Nasby wrote:
> > On 10/19/15 1:07 PM, David Fetter wrote:
> >>
> >> What I'd like to do is lift the restriction on ROWS FROM(), which
> >> currently requires that the stuff inside the parentheses se
2015-10-20 16:50 GMT+02:00 Robert Haas :
> On Mon, Oct 19, 2015 at 7:59 PM, Jim Nasby
> wrote:
> > I fail to see how doing
> >
> > HINT: NULL
> >
> > is much better than just not raising a HINT at all...
>
> I'm not a huge fan of this patch, as previously noted, but I certainly
> agree that if we
On Tue, Oct 20, 2015 at 7:45 AM, Etsuro Fujita
wrote:
> I found typos in plannodes.h: s/scan.plan.quals/scan.plan.qual/g Please
> find attached a patch.
Oops. Good catch. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsq
On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule wrote:
> Probably it was my request. I don't like to using NULL as value, that should
> be ignored. The "hint" is clean, there NULL can be ignored, but what about
> DETAIL or MESSAGE?
If the field is required - as MESSAGE is - then its absence is an
On Tue, Oct 20, 2015 at 11:03 AM, David Fetter wrote:
> On Tue, Oct 20, 2015 at 10:52:05AM -0400, Robert Haas wrote:
>> On Mon, Oct 19, 2015 at 8:02 PM, Jim Nasby wrote:
>> > On 10/19/15 1:07 PM, David Fetter wrote:
>> >>
>> >> What I'd like to do is lift the restriction on ROWS FROM(), which
>>
On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra
wrote:
>> Koyotaro's changes to force COLUMN to be required won't get through.
>>
>> ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, and
>> use REMOVE STATISTICS instead of DROP STATISTICS. That way we can use
>> ALTER TABLE rathe
On Tue, Oct 20, 2015 at 11:16:13AM -0400, Robert Haas wrote:
> On Tue, Oct 20, 2015 at 11:03 AM, David Fetter wrote:
> > On Tue, Oct 20, 2015 at 10:52:05AM -0400, Robert Haas wrote:
> >> On Mon, Oct 19, 2015 at 8:02 PM, Jim Nasby
> >> wrote:
> >> > On 10/19/15 1:07 PM, David Fetter wrote:
> >> >
2015-10-20 17:15 GMT+02:00 Robert Haas :
> On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule
> wrote:
> > Probably it was my request. I don't like to using NULL as value, that
> should
> > be ignored. The "hint" is clean, there NULL can be ignored, but what
> about
> > DETAIL or MESSAGE?
>
> If the
Robert Haas writes:
> On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra
> wrote:
ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, and
use REMOVE STATISTICS instead of DROP STATISTICS. That way we can use
ALTER TABLE rather than inventing a new command. 5 minute cha
I fixed some typos in posgres.
They are all in comments. :)
Thanks
PATCH.typos
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
> I don't think that proc_exit(1) is the right way to exit here. It's
> not very friendly to exit without at least attempting to give the
> client a clue about what has gone wrong. I suggest something like
> this:
>
> ereport(FATAL,
> (errcode(
On 20 October 2015 at 11:59, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra
> > wrote:
> ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS,
> and
> use REMOVE STATISTICS instead of DROP STATISTICS. That way we can use
>
On Tue, Oct 20, 2015 at 02:28:15PM +, Robert Haas wrote:
> Tab complete CREATE EXTENSION .. VERSION.
>
> Jeff Janes
Would this be worth back-patching to 9.5? It seems like a pretty
isolated change with a pretty helpful utility.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 4
On 18 August 2015 at 12:23, Amit Langote wrote:
> Hi Thom,
>
> On Tue, Aug 18, 2015 at 8:02 PM, Thom Brown wrote:
>>
>>
>> Wow, didn't expect to see that email this morning.
>>
>> A very quick test:
>>
>> CREATE TABLE purchases (purchase_id serial, purchase_time timestamp, item
>> text) partition
On Wednesday, 21 October 2015, Thom Brown wrote:
> On 18 August 2015 at 12:23, Amit Langote > wrote:
> > Hi Thom,
> >
> > On Tue, Aug 18, 2015 at 8:02 PM, Thom Brown > wrote:
> >>
> >>
> >> Wow, didn't expect to see that email this morning.
> >>
> >> A very quick test:
> >>
> >> CREATE TABLE pu
On 20 October 2015 at 18:34, Amit Langote wrote:
>
>
> On Wednesday, 21 October 2015, Thom Brown wrote:
>>
>> On 18 August 2015 at 12:23, Amit Langote wrote:
>> > Hi Thom,
>> >
>> > On Tue, Aug 18, 2015 at 8:02 PM, Thom Brown wrote:
>> >>
>> >>
>> >> Wow, didn't expect to see that email this mo
On 10/13/2015 11:41 AM, Bruce Momjian wrote:
FYI, I think we already have two limits for the first line summary of
commit messages. The limits are 64 for commit message subjects and 50
characters for gitweb summary pages --- anything longer is truncated.
My commit template shows me the limits
On 10/20/15 10:27 AM, Albe Laurenz wrote:
> Wouldn't it be better to have these two parameters documented next to each
> other,
> as in the attached patch?
I was also about to fix that. I did it slightly differently, to restore
the original alphabetical ordering.
--
Sent via pgsql-hackers ma
On Tue, Oct 20, 2015 at 12:11 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> I don't think that proc_exit(1) is the right way to exit here. It's
>> not very friendly to exit without at least attempting to give the
>> client a clue about what has gone wrong. I suggest something like
>> this:
>
On Tue, Oct 20, 2015 at 11:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra
>> wrote:
> ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, and
> use REMOVE STATISTICS instead of DROP STATISTICS. That way we can use
> ALT
On Tue, Oct 20, 2015 at 11:29 AM, Pavel Stehule wrote:
> 2015-10-20 17:15 GMT+02:00 Robert Haas :
>> On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule
>> wrote:
>> > Probably it was my request. I don't like to using NULL as value, that
>> > should
>> > be ignored. The "hint" is clean, there NULL ca
Robert Haas wrote:
> On Tue, Oct 20, 2015 at 12:11 PM, Alvaro Herrera
> wrote:
> > Agreed, but I don't think "shutdown" is the right word to use here --
> > that makes it sound like it was orderly. Perhaps "crash"?
>
> Well, that's a little speculative. "due to unexpected postmaster exit"?
WF
On 10/17/15 10:25 AM, Michael Paquier wrote:
> I think that we should just suggest a reverse formula of the maximum
> soft limit of checkpoint_segments for max_wal_size in the release notes
> of 9.5, basically:
> (3 * your_old_checkpoint_segments + 1) * 16MB = max_wal_size
How about this patch?
(
On 10/20/2015 05:59 PM, Tom Lane wrote:
Robert Haas writes:
On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra
wrote:
ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, and
use REMOVE STATISTICS instead of DROP STATISTICS. That way we can use
ALTER TABLE rather than inventing
Tomas Vondra writes:
> On 10/20/2015 05:59 PM, Tom Lane wrote:
>> Why is this an improvement over using already-existing keywords?
> The problem is that the actual syntax is ADD [COLUMN], so we can't
> simply use ADD STATISTICS as that would mean a conflict in the grammar.
> Resolving it means
On 2014-08-14 15:01:53 +0200, Fabien COELHO wrote:
>
> Add --limit to limit latency under throttling
>
> Under throttling, transactions are scheduled for execution at certain times.
> Transactions may be far behind schedule and the system may catch up with the
> load later. This option allows to
Robert Haas wrote:
> On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek wrote:
> > I agree with that sentiment.
> >
> > Attached patch adds variable to the shmem which is used for module
> > activation tracking - set to true in ActiveCommitTs() and false in
> > DeactivateCommitTs(). All the checks insi
I wrote:
> Tomas Vondra writes:
>> The problem is that the actual syntax is ADD [COLUMN], so we can't
>> simply use ADD STATISTICS as that would mean a conflict in the grammar.
>> Resolving it means either making COLUMN non-optional, or adding
>> STATISTICS to reserved keywords - both options b
On 2015-10-20 20:55:46 +0200, Andres Freund wrote:
> On 2014-08-14 15:01:53 +0200, Fabien COELHO wrote:
> >
> > Add --limit to limit latency under throttling
> >
> > Under throttling, transactions are scheduled for execution at certain times.
> > Transactions may be far behind schedule and the sy
* Joshua D. Drake (j...@commandprompt.com) wrote:
> On 10/13/2015 11:41 AM, Bruce Momjian wrote:
>
> >FYI, I think we already have two limits for the first line summary of
> >commit messages. The limits are 64 for commit message subjects and 50
> >characters for gitweb summary pages --- anything
2015-10-20 20:05 GMT+02:00 Robert Haas :
> On Tue, Oct 20, 2015 at 11:29 AM, Pavel Stehule
> wrote:
> > 2015-10-20 17:15 GMT+02:00 Robert Haas :
> >> On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule <
> pavel.steh...@gmail.com>
> >> wrote:
> >> > Probably it was my request. I don't like to using N
Hi,
On 10/20/2015 09:11 PM, Tom Lane wrote:
I wrote:
Tomas Vondra writes:
The problem is that the actual syntax is ADD [COLUMN], so we
can't simply use ADD STATISTICS as that would mean a conflict in
the grammar. Resolving it means either making COLUMN
non-optional, or adding STATISTICS to re
On 20 October 2015 at 16:48, Tomas Vondra
wrote:
> and I can get this to work too
>>
>> | DROP STATISTICS ON '(' name_list ')'
>>
>> if I expand out the "DROP opt_column" productions to be two separate
>> productions with and without COLUMN, as was done long ago for ADD
>
Rajan,
I'll reply off-list since this isn't the right discussion for -hackers.
Best,
Lukas
On Tue, Oct 20, 2015 at 7:02 AM, rajan wrote:
> Hey Lukas,
>
> Thanks. Able to see the queries from all users. Can you explain the
> monitoring.get_stat_statements()?
>
>
>
> --
> View this message in co
On 17 October 2015 at 18:17, Robert Haas wrote:
> It's good to have your perspective on how this can be improved, and
> I'm definitely willing to write more documentation. Any lack in that
> area is probably due to being too close to the subject area, having
> spent several years on parallelism
On 10/4/15 6:10 PM, Tom Lane wrote:
Andrew Dunstan writes:
>Sorry, I'm a bit late to this party. Does what you have committed mean
>people are less likely to see "Out of Memory" coming from
>pg_stat_statements? If not, what can be done about them short of a
>restart? And what bad effects follow
On 10/20/15 11:08 AM, CharSyam wrote:
I fixed some typos in posgres.
They are all in comments. :)
These all look good to me. RFC.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://Blue
On 10/20/15 9:00 AM, Artur Zakirov wrote:
Internal representation of the dictionary in the PostgreSQL doesn't
impose too strict limits on the number of affix rules. There are a
flagval array, which size must be increased from 256 to 65000.
Is that per dictionary entry, fixed at 64k? That seems
On 10/19/15 7:12 PM, Tom Lane wrote:
Jim Nasby writes:
What did seem odd is that while processing the DECLARE section there
were plpgsql datums for tt.a and tt.b. I would have expected the
assignment to produce a row datum of type tt.
Yeah, that's the thing that's weird about plpgsql's ROW da
Jim Nasby writes:
> On 10/19/15 7:12 PM, Tom Lane wrote:
>> IMO, we ought to get rid of the use of that representation for
>> composite-type variables and use the RECORD code paths for them,
> That also means there would only need to be changes to RECORD to allow
> CONSTANT, default, etc.
> Do
On Sat, Oct 10, 2015 at 4:20 AM, Robert Haas wrote:
> On Thu, Oct 8, 2015 at 1:52 PM, Andres Freund wrote:
>> I don't see the problem? I mean catversion will reliably tell you which
>> format the vm is in?
>
> Totally agreed.
>
>> We could additionally use the opportunity to as a metapage, but t
On 9 October 2015 at 15:20, Robert Haas wrote:
> On Thu, Oct 8, 2015 at 1:52 PM, Andres Freund wrote:
> > I don't see the problem? I mean catversion will reliably tell you which
> format the vm is in?
>
> Totally agreed.
>
This isn't an agreement competition, its a cool look at what might cause
On 10/20/2015 11:28 PM, Simon Riggs wrote:
On 20 October 2015 at 16:48, Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote:
>> On 10/20/2015 09:11 PM, Tom Lane wrote:
Can't we just insist that there be only one statistics declaration
for a given column list? >>
I would rather not, be
Tomas Vondra writes:
> On 10/20/2015 11:28 PM, Simon Riggs wrote:
>> Since this command doesn't actually ADD the statistics, it just creates
>> a specification used by the next ANALYZE, it would seem better to use a
>> different keyword than ADD, perhaps DECLARE STATISTICS ON... and DROP
>> STATIS
On 20 October 2015 at 21:06, Tom Lane wrote:
> I am getting more attracted to your suggestion of making these things
> stand-alone commands "CREATE STATISTICS" and "DROP STATISTICS". Not only
> does that fix the syntactic problems of shoehorning them into ALTER TABLE,
> but it would be possible
On Wed, Oct 21, 2015 at 3:11 AM, Peter Eisentraut wrote:
> On 10/17/15 10:25 AM, Michael Paquier wrote:
> > I think that we should just suggest a reverse formula of the maximum
> > soft limit of checkpoint_segments for max_wal_size in the release notes
> > of 9.5, basically:
> > (3 * your_old_che
On Sat, Jul 25, 2015 at 10:59:27AM -0400, Tom Lane wrote:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=axolotl&dt=2015-07-24%2020%3A29%3A18
>
> What evidently happened there is that "pg_ctl start" gave up waiting for
> the postmaster to start too soon. The postmaster log appears to co
On 2015/10/21 0:13, Robert Haas wrote:
On Tue, Oct 20, 2015 at 7:45 AM, Etsuro Fujita
wrote:
I found typos in plannodes.h: s/scan.plan.quals/scan.plan.qual/g Please
find attached a patch.
Oops. Good catch. Committed.
Thanks for picking this up!
Best regards,
Etsuro Fujita
--
Sent vi
On 2015/10/20 13:11, Etsuro Fujita wrote:
On 2015/10/20 5:34, Robert Haas wrote:
On Mon, Oct 19, 2015 at 3:45 AM, Etsuro Fujita
wrote:
As Tom mentioned, just recomputing the original join tuple is not good
enough. We would need to rejoin the test tuples for the baserels
even if
ROW_MARK_COPY
On Sat, Oct 10, 2015 at 1:54 AM, Stephen Frost wrote:
> * Haribabu Kommi (kommi.harib...@gmail.com) wrote:
>> On Fri, Oct 9, 2015 at 2:04 PM, Stephen Frost wrote:
>> > * Robert Haas (robertmh...@gmail.com) wrote:
>> >> We've got one reloption for views already - security_barrier. Maybe
>> >> we
On 20 October 2015 23:34, Robert Haas [mailto:robertmh...@gmail.com] Wrote:
>On Tue, Oct 20, 2015 at 12:11 PM, Alvaro Herrera
> wrote:
>> Robert Haas wrote:
>>> I don't think that proc_exit(1) is the right way to exit here. It's
>>> not very friendly to exit without at least attempting to give th
> -Original Message-
> From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp]
> Sent: Wednesday, October 21, 2015 12:31 PM
> To: Robert Haas
> Cc: Tom Lane; Kaigai Kouhei(海外 浩平); Kyotaro HORIGUCHI;
> pgsql-hackers@postgresql.org; Shigeru Hanada
> Subject: Re: [HACKERS] Foreign join pushdo
Hello Andres,
In my performance testing it showed that calling PerformFileFlush() only
at segment boundaries and in CheckpointWriteDelay() can lead to rather
spikey IO - not that surprisingly. The sync in CheckpointWriteDelay() is
problematic because it only is triggered while on schedule, and
Hi,
This may just be nitpicking but I noticed that ATWrongRelkindError() could
emit a better message in case of such errors during ALTER COLUMN DEFAULT
and ALTER COLUMN SET STORAGE than "%s is of the wrong type" which is what
it would emit now. Just need to add a couple of cases to the switch the
On Tue, Oct 20, 2015 at 3:01 AM, Robbie Harwood wrote:
> Stephen Frost writes:
>> psql: lost synchronization with server: got message type "S", length 22
>
> which unfortunately could be a great many things. I've said this a
> couple times now, but I really do need more information - a traffic
>
83 matches
Mail list logo