On Wed, Nov 19, 2014 at 11:46 PM, Robert Haas wrote:
> On Tue, Nov 18, 2014 at 9:19 AM, Alvaro Herrera
> wrote:
> >> Right, but they provide same functionality as symlinks and now we
> >> are even planing to provide this feature for both linux and windows as
> >> both Tom and Robert seems to feel
BTW, I published the 'ctidscan' module below as an example of custom-scan.
https://github.com/kaigai/ctidscan
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On B
Hello,
The attached obvious patch adds T_CustomScan on case-switch of
ExplainTargetRel() that was oversight.
It looked like working, but what it did was just printing referenced
name, instead of table name.
postgres=# explain select ctid, * from t0 hoge where ctid > '(50,0)'::tid;
On Wed, 2014-11-19 at 16:52 -0800, Peter Geoghegan wrote:
> Someone mentioned to me privately that they weren't sure that the
> question of whether or not RETURNING only projected actually inserted
> tuples was the right one. Also, I think someone else mentioned this a
> few months back. I'd like t
On Wed, Nov 19, 2014 at 8:56 PM, Robert Haas wrote:
>
> On Tue, Nov 18, 2014 at 8:53 AM, Amit Kapila
wrote:
> > Won't this be addressed because both updates issued from myfunc()
> > are considered as separate commands, so w.r.t lock it should behave
> > as 2 different updates in same transaction.
On Wed, Nov 19, 2014 at 9:33 PM, Robert Haas wrote:
>
> On Tue, Nov 18, 2014 at 4:40 AM, Jeff Davis wrote:
> >> To reiterate the basic problem here, if we do nothing at all about the
> >> lock manager, a parallel backend can stall trying to grab an
> >> AccessExclusiveLock that the user backend a
At 2014-11-19 19:12:22 +0200, hlinnakan...@vmware.com wrote:
>
> But pg_xlogdump's way of using the CRC isn't necessarily
> representative of how the backend uses it. It's probably pretty close
> to WAL replay in the server, but even there the server might be hurt
> more by the extra cache used by
On 1/31/14 9:28 PM, Bruce Momjian wrote:
> On Fri, Jan 31, 2014 at 09:28:06PM -0500, Andrew Dunstan wrote:
>>
>> On 01/31/2014 09:19 PM, Bruce Momjian wrote:
>>> On Thu, Oct 10, 2013 at 11:00:30PM -0400, Andrew Dunstan wrote:
On 10/10/2013 09:35 PM, Peter Eisentraut wrote:
> On Tue, 2013-1
On Wed, Nov 19, 2014 at 8:02 PM, Michael Paquier
wrote:
> Just a small thing I noticed while looking at pageinspect.sgml, the
> set of SQL examples related to BRIN indexes uses lower-case characters
> for reserved keywords. This has been introduced by 7516f52.
> Patch is attached.
My nitpicky obs
Hi all,
Just a small thing I noticed while looking at pageinspect.sgml, the
set of SQL examples related to BRIN indexes uses lower-case characters
for reserved keywords. This has been introduced by 7516f52.
Patch is attached.
Regards,
--
Michael
diff --git a/doc/src/sgml/pageinspect.sgml b/doc/sr
On Wed, Nov 19, 2014 at 7:01 AM, Peter Geoghegan wrote:
> On Tue, Nov 4, 2014 at 7:26 AM, Amit Kapila wrote:
>> I think these functions will be quite useful for debugging purpose
>> and we already have similar function's for other index (btree).
>
> This patch has bitrotted. I attach rebased revi
Robert,
>
> I thought putting the partition boundaries into pg_inherits was a
> strange choice. I'd put it in pg_class, or in pg_partition if we
> decide to create that.
Hmm, yeah I guess we are better off using pg_inherits for just saying that a
partition is an inheritance child. Other deta
On 6/18/13 9:52 AM, Cédric Villemain wrote:
> 0006-Fix-suggested-layout-for-extension.patch
I have committed this patch.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier wrote:
> 1) Couldn't this paragraph be reworked?
>
> +The table_rewrite event occurs just before a table is going
> to
> +get rewritten by the commands ALTER TABLE. While other
> +control statements are available to rewrite a table,
> +like CLUSTER and VACUUM,
On Wed, Nov 19, 2014 at 6:04 PM, Peter Geoghegan wrote:
> I think that 3 is out. It seems hard to justify not RETURNING anything
> in respect of a slot when there is a before row insert trigger that
> returns NULL on the one hand, but RETURNING something despite not
> inserting for ON CONFLICT UPD
On Wed, Nov 19, 2014 at 5:37 PM, Andreas Karlsson wrote:
> I think we have three options.
>
> 1. Return only inserted tuples
> 2. Return inserted and updated tuples
> 3. Return inserted, updated and skipped tuples
>
> To me option 1 is surprising and less useful since I imagine in most cases
> whe
On 11/20/2014 01:52 AM, Peter Geoghegan wrote:
On Mon, Nov 10, 2014 at 3:33 PM, Peter Geoghegan wrote:
Also, I think someone else mentioned this a few months back.
Yeah, that was me.
I think we have three options.
1. Return only inserted tuples
2. Return inserted and updated tuples
3. Return
On Thu, Nov 20, 2014 at 2:57 AM, Dimitri Fontaine
wrote:
> Fixed in the attached version of the patch.
Thanks! Things are moving nicely for this patch. Patch compiles and
passes check-world. Some minor comments about the latest version:
1) Couldn't this paragraph be reworked?
+The table_r
On Mon, Nov 10, 2014 at 3:33 PM, Peter Geoghegan wrote:
> Attached is V1.4.
Someone mentioned to me privately that they weren't sure that the
question of whether or not RETURNING only projected actually inserted
tuples was the right one. Also, I think someone else mentioned this a
few months back
On Sun, Oct 5, 2014 at 5:16 AM, Stephen Frost wrote:
>> next a message:
>>
>> ERROR: new row violates WITH CHECK OPTION for "data"
>> DETAIL: Failing row contains (2014-10-05 12:28:30.79652, petr, 1000).
>>
>> Doesn't inform about broken policy.
>
> I'm guessing this is referring to the above po
Pavel Stehule writes:
> 2014-11-19 23:54 GMT+01:00 Tom Lane :
>> The core of that complaint is that we'd have to make ASSERT a plpgsql
>> reserved word, which is true enough as things stand today. However,
>> why is it that plpgsql statement-introducing keywords need to be
>> reserved?
> Doesn't
Hi,
On 2014-11-19 15:09:10 -0800, Josh Berkus wrote:
> One patch that got deferred from 9.4 was the merger of recovery.conf and
> postgresql.conf, due to conflicts with ALTER SYSTEM SET. However, this
> is still a critical TODO, because recovery.conf is still an ongoing
> major management problem
Hackers,
One patch that got deferred from 9.4 was the merger of recovery.conf and
postgresql.conf, due to conflicts with ALTER SYSTEM SET. However, this
is still a critical TODO, because recovery.conf is still an ongoing
major management problem for PostgreSQL DBAs.
So, what happened to this? I
2014-11-19 23:54 GMT+01:00 Tom Lane :
> Marko Tiikkaja writes:
> > I also went back to the original thread, and I think Heikki's summary
> > dismissed e.g. Robert's criticism quite lightly:
> >
> http://www.postgresql.org/message-id/ca+tgmobwossrncv_ijk3xhsytxb7dv0awgvwkmeurntovez...@mail.gmail.c
2014-11-19 23:38 GMT+01:00 Marko Tiikkaja :
> On 2014-11-19 23:18, Pavel Stehule wrote:
>
>> 2014-11-19 18:01 GMT+01:00 Tom Lane :
>>
>> Robert Haas writes:
>>>
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane wrote:
> FWIW, I would vote against it also. I do not find this to be a natu
Marko Tiikkaja writes:
> I also went back to the original thread, and I think Heikki's summary
> dismissed e.g. Robert's criticism quite lightly:
> http://www.postgresql.org/message-id/ca+tgmobwossrncv_ijk3xhsytxb7dv0awgvwkmeurntovez...@mail.gmail.com
The core of that complaint is that we'd hav
On 19/11/14 19:51, Simon Riggs wrote:
On 19 November 2014 16:11, Petr Jelinek wrote:
We need to be able to tell the difference between a crashed Startup
process and this usage.
As long as we can tell, I don't mind how we do it.
Suggestions please.
Different exit code?
Try this one.
O
On 2014-11-19 23:18, Pavel Stehule wrote:
2014-11-19 18:01 GMT+01:00 Tom Lane :
Robert Haas writes:
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane wrote:
FWIW, I would vote against it also. I do not find this to be a natural
extension of RAISE; it adds all sorts of semantic issues. (In
parti
On Wed, Nov 19, 2014 at 2:09 PM, Peter Geoghegan wrote:
> Attached is a revision of what I previously called btreecheck, which
> is now renamed to amcheck.
Whoops. I left in modifications to pg_config_manual.h to build with
Valgrind support. Here is a version without that.
--
Peter Geoghegan
di
2014-11-19 18:01 GMT+01:00 Tom Lane :
> Robert Haas writes:
> > On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane wrote:
> >> FWIW, I would vote against it also. I do not find this to be a natural
> >> extension of RAISE; it adds all sorts of semantic issues. (In
> particular,
> >> what is the evalua
2014-11-19 17:43 GMT+01:00 Robert Haas :
> On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> On 11/19/2014 06:35 AM, Simon Riggs wrote:
> >>> I seem to share the same opinion with Andrew: its not going to hurt to
> >>> include this, but its not gonna cause dancing
2014-11-19 17:13 GMT+01:00 Tom Lane :
> Andrew Dunstan writes:
> > On 11/19/2014 06:35 AM, Simon Riggs wrote:
> >> I seem to share the same opinion with Andrew: its not going to hurt to
> >> include this, but its not gonna cause dancing in the streets either. I
> >> would characterize that as 2 v
Attached is a revision of what I previously called btreecheck, which
is now renamed to amcheck.
This is not 9.5 material - I already have 3 bigger patches in the
queue, 2 of which are large and complex and have major controversies,
and one of which has details that need to be worked out, which is
Andres Freund writes:
> On 2014-11-19 19:59:33 +0200, Heikki Linnakangas wrote:
>> This grew "pg_dumpall | wc -c" from 5505689 to 6926066 bytes. The size of
>> the regression database grew, according to psql's "\l+" command grew from 45
>> MB to 57 MB. The amount of WAL generated by "make installc
On 11/19/2014 01:03 PM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> On 11/12/2014 06:57 PM, Alvaro Herrera wrote:
How did template0 even get a MultiXact? That sounds like they're really
abusing the template databases. :( (Do keep in mind that MXID 1 is a
special value.)
>>> No, i
Josh Berkus wrote:
> On 11/12/2014 06:57 PM, Alvaro Herrera wrote:
> >> How did template0 even get a MultiXact? That sounds like they're really
> >> abusing the template databases. :( (Do keep in mind that MXID 1 is a
> >> special value.)
> > No, it's normal -- template0 does not have a multixact
On 11/12/2014 06:57 PM, Alvaro Herrera wrote:
>> How did template0 even get a MultiXact? That sounds like they're really
>> abusing the template databases. :( (Do keep in mind that MXID 1 is a special
>> value.)
> No, it's normal -- template0 does not have a multixact in any tuple's
> xmax, but d
All,
> If we're going to change the catalog representation for the existing
> capabilities, I'd recommend that the first patch change the catalog
> representation and add the new syntax without adding any more
> capabilities; and then the second and subsequent patches can add
> additional capabil
On 19 November 2014 16:41, Fujii Masao wrote:
> On Wed, Nov 19, 2014 at 10:49 PM, Robert Haas wrote:
>> On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs wrote:
>>> If we ask for PAUSE and we're not in HotStandby it just ignores it,
>>> which means it changes into PROMOTE. My feeling is that we shoul
Peter Geoghegan wrote:
> On Wed, Nov 19, 2014 at 11:54 AM, Alvaro Herrera
> wrote:
> > Peter Geoghegan wrote:
> >> On Wed, Nov 19, 2014 at 11:34 AM, Alvaro Herrera
> >> wrote:
> >> > 0 for a transposition, wow.
> >>
> >> Again, they're optimizing for short strings (git commands) only. There
> >>
On Wed, Nov 19, 2014 at 11:54 AM, Alvaro Herrera
wrote:
> Peter Geoghegan wrote:
>> On Wed, Nov 19, 2014 at 11:34 AM, Alvaro Herrera
>> wrote:
>> > 0 for a transposition, wow.
>>
>> Again, they're optimizing for short strings (git commands) only. There
>> just isn't that many transposition errors
Peter Geoghegan wrote:
> On Wed, Nov 19, 2014 at 11:34 AM, Alvaro Herrera
> wrote:
> > 0 for a transposition, wow.
>
> Again, they're optimizing for short strings (git commands) only. There
> just isn't that many transposition errors possible with a 4 character
> string.
If there's logic in your
On Wed, Nov 19, 2014 at 11:34 AM, Alvaro Herrera
wrote:
> 0 for a transposition, wow.
Again, they're optimizing for short strings (git commands) only. There
just isn't that many transposition errors possible with a 4 character
string.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list
Robert Haas wrote:
> And the underlying Levenshtein implementation is here:
>
> https://github.com/git/git/blob/398dd4bd039680ba98497fbedffa415a43583c16/levenshtein.c
>
> Apparently what they're doing is charging 0 for a transposition (which
> we don't have as a separate concept), 2 for a substi
On Wed, Nov 19, 2014 at 11:13 AM, Robert Haas wrote:
> That's precisely the time I think it's *most* important. In a very
> long string, the threshold should be LESS than 50%. My original
> proposal was "no more than 3 characters of difference, but in any
> event not more than half the length of
On Wed, Nov 19, 2014 at 11:13 AM, Robert Haas wrote:
> Apparently what they're doing is charging 0 for a transposition (which
> we don't have as a separate concept), 2 for a substitution, 1 for an
> insertion, and 3 for a deletion, with the constraint that anything
> with a total distance of more
On Wed, Nov 19, 2014 at 1:22 PM, Peter Geoghegan wrote:
> On Wed, Nov 19, 2014 at 9:52 AM, Robert Haas wrote:
>> If you agree, then I'm not being clear enough. I don't think think
>> that tinkering with the Levenshtein cost factors is a good idea, and I
>> think it's unhelpful to suggest somethi
On Wed, Nov 19, 2014 at 10:33 AM, Peter Geoghegan wrote:
> Maybe you'd prefer if there was a more gradual ramp-up to requiring a
> distance of no greater than 50% of the string size (normalized to take
> account of my non-default costings)
I made this modification:
diff --git a/src/backend/parse
On 19 November 2014 16:11, Petr Jelinek wrote:
>> We need to be able to tell the difference between a crashed Startup
>> process and this usage.
>>
>> As long as we can tell, I don't mind how we do it.
>>
>> Suggestions please.
>>
>
> Different exit code?
Try this one.
--
Simon Riggs
On Wed, Nov 19, 2014 at 10:33 AM, Peter Geoghegan wrote:
> there is no "absolute
> quality" requirement for strings of 6 or fewer requirements.
I meant 6 or fewer *characters*, obviously.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Wed, Nov 19, 2014 at 10:22 AM, Peter Geoghegan wrote:
> Those are all very terse strings. What you're overlooking is what is
> broken by using straight Levenshtein distance, which includes things
> in the regression test that are reasonable and helpful. As I mentioned
> before, requiring a grea
On 2014-11-19 19:59:33 +0200, Heikki Linnakangas wrote:
> On 11/19/2014 05:01 PM, Andres Freund wrote:
> >On 2014-11-19 11:54:47 -0300, Alvaro Herrera wrote:
> >>Heikki Linnakangas wrote:
> >>> Schema | Name | Type | Owner | Size | Description
> >>>+--+
On Wed, Nov 19, 2014 at 9:52 AM, Robert Haas wrote:
> If you agree, then I'm not being clear enough. I don't think think
> that tinkering with the Levenshtein cost factors is a good idea, and I
> think it's unhelpful to suggest something when the suggestion and the
> original word differ by more
On Tue, Nov 18, 2014 at 9:19 AM, Alvaro Herrera
wrote:
>> Right, but they provide same functionality as symlinks and now we
>> are even planing to provide this feature for both linux and windows as
>> both Tom and Robert seems to feel, it's better that way. Anyhow,
>> I think naming any entity ge
On Wed, Nov 19, 2014 at 1:01 PM, Robert Haas wrote:
> On Tue, Nov 18, 2014 at 5:14 PM, Dimitri Fontaine
> wrote:
>> Robert Haas writes:
>>> It seems pretty weird, also, that the event trigger will fire after
>>> we've taken AccessExclusiveLock when you cluster a particular
>>> relation, and befo
On 11/19/2014 05:01 PM, Andres Freund wrote:
On 2014-11-19 11:54:47 -0300, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Schema | Name | Type | Owner | Size | Description
+--+---++-+-
public | btree_tall_tbl | tabl
On Tue, Nov 18, 2014 at 5:34 PM, Alvaro Herrera
wrote:
> Almost the whole of that function is conditions to bail out clustering
> the relation if things have changed since the relation list was
> collected. It seems wrong to invoke the event trigger in all those
> cases; it's going to fire spurio
On Tue, Nov 18, 2014 at 5:14 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> It seems pretty weird, also, that the event trigger will fire after
>> we've taken AccessExclusiveLock when you cluster a particular
>> relation, and before we've taken AccessExclusiveLock when you cluster
>> databa
Alvaro Herrera writes:
> Almost the whole of that function is conditions to bail out clustering
> the relation if things have changed since the relation list was
> collected. It seems wrong to invoke the event trigger in all those
> cases; it's going to fire spuriously. I think you should move t
On Wed, Nov 19, 2014 at 12:33 PM, Peter Geoghegan wrote:
> On Wed, Nov 19, 2014 at 5:43 AM, Robert Haas wrote:
>> I think we would be well-advised not to start inventing our own
>> approximate matching algorithm. Peter's suggestion boils down to a
>> guess that the default cost parameters for Le
On Wed, Nov 19, 2014 at 12:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane wrote:
>>> FWIW, I would vote against it also. I do not find this to be a natural
>>> extension of RAISE; it adds all sorts of semantic issues. (In particular,
>>> what is the
On Wed, Nov 19, 2014 at 5:43 AM, Robert Haas wrote:
> I think we would be well-advised not to start inventing our own
> approximate matching algorithm. Peter's suggestion boils down to a
> guess that the default cost parameters for Levenshtein suck, and your
> suggestion boils down to a guess tha
On Tue, Nov 18, 2014 at 3:41 PM, Jeff Janes wrote:
> The open_datasync code opens the output file as a test to make sure the
> flags are accepted by the OS, and if it succeeds it then immediately opens
> the file again with the same flags, overwriting and so leaking the
> descriptor from the previ
On 2014-11-19 19:12:22 +0200, Heikki Linnakangas wrote:
> On 11/19/2014 06:49 PM, Robert Haas wrote:
> >On Wed, Nov 19, 2014 at 11:44 AM, Heikki Linnakangas
> > wrote:
> >>That's an interesting choice of workload. That sure is heavy on the CRC
> >>calculation, but the speed of pg_xlogdump hardly ma
Alvaro Herrera writes:
> Heikki Linnakangas wrote:
>> 2. These make the regression database larger. The following tables and
>> indexes are added:
> I think it's good to have these tests, though Tom was complaining
> earlier about the size of the regression test database. Would it work
> to have
"Aaron W. Swenson" writes:
> configure.in was deprecated some years ago. We have a bug at Gentoo [1] to
> move it to configure.ac.
I see no advantage to this. It'll mess up our git history to do so,
not to mention complicate back-patching. If we were planning to adopt
additional tools from the
On 11/19/2014 06:49 PM, Robert Haas wrote:
On Wed, Nov 19, 2014 at 11:44 AM, Heikki Linnakangas
wrote:
That's an interesting choice of workload. That sure is heavy on the CRC
calculation, but the speed of pg_xlogdump hardly matters in real life.
But isn't a workload that is heavy on CRC calcu
configure.in was deprecated some years ago. We have a bug at Gentoo [1] to
move it to configure.ac.
I've done so in my git-clone of the postgresql repo, and ran autoupdate
to move away from the deprecated functions as well.
I generated the configure script again, but that didn't change.
make &&
On 11/19/2014 04:54 PM, Alvaro Herrera wrote:
Also I'm surprised that BRIN did not turn up here. At least the "page
evacuation protocol" to obtain a new revmap page is not exercised by the
current tests. I suppose it's because all WAL records are covered by
other activity, and page evacuation d
Robert Haas writes:
> On Wed, Nov 19, 2014 at 11:44 AM, Heikki Linnakangas
> wrote:
>> That's an interesting choice of workload. That sure is heavy on the CRC
>> calculation, but the speed of pg_xlogdump hardly matters in real life.
> But isn't a workload that is heavy on CRC calculation exactly
Robert Haas writes:
> On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane wrote:
>> FWIW, I would vote against it also. I do not find this to be a natural
>> extension of RAISE; it adds all sorts of semantic issues. (In particular,
>> what is the evaluation order of the WHEN versus the other subexpressi
On Wed, Nov 19, 2014 at 11:44 AM, Heikki Linnakangas
wrote:
> That's an interesting choice of workload. That sure is heavy on the CRC
> calculation, but the speed of pg_xlogdump hardly matters in real life.
But isn't a workload that is heavy on CRC calculation exactly what we
want here? That way
On 11/19/2014 05:58 PM, Abhijit Menon-Sen wrote:
At 2014-11-11 16:56:00 +0530, a...@2ndquadrant.com wrote:
I'm working on this (first speeding up the default calculation using
slice-by-N, then adding support for the SSE4.2 CRC instruction on
top).
I've done the first part in the attached patc
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 11/19/2014 06:35 AM, Simon Riggs wrote:
>>> I seem to share the same opinion with Andrew: its not going to hurt to
>>> include this, but its not gonna cause dancing in the streets either. I
>>> would characterize tha
On Wed, Nov 19, 2014 at 10:49 PM, Robert Haas wrote:
> On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs wrote:
>> If we ask for PAUSE and we're not in HotStandby it just ignores it,
>> which means it changes into PROMOTE. My feeling is that we should
>> change that into a SHUTDOWN, not a PROMOTE.
>
>
On 11/19/2014 08:22 AM, Alvaro Herrera wrote:
I think we're overblowing the pg_upgrade issue. Surely we don't need to
preserve commit_ts data when upgrading across major versions; and
pg_upgrade is perfectly prepared to remove old data when upgrading
(actually it just doesn't copy it; consider
Antonin Houska writes:
> Albe Laurenz wrote:
>> Currently it is possible to change the behaviour of a function with
>> CREATE OR REPLACE FUNCTION even if the function is part of an index
>> definition.
>>
>> I think that should be forbidden, because it is very likely to corrupt
>> the index. I
On 19/11/14 16:47, Simon Riggs wrote:
On 19 November 2014 13:13, Simon Riggs wrote:
Also, for the Shutdown itself, why are we not using
kill(PostmasterPid, SIGINT)?
Done
Other plan is to throw a FATAL message.
That gives a clean, fast shutdown rather than what looks like a crash.
I'
Andrew Dunstan writes:
> On 11/19/2014 06:35 AM, Simon Riggs wrote:
>> I seem to share the same opinion with Andrew: its not going to hurt to
>> include this, but its not gonna cause dancing in the streets either. I
>> would characterize that as 2 very neutral and unimpressed people, plus
>> 3 in
On 2014-11-19 16:04:49 +, Simon Riggs wrote:
> On 19 November 2014 15:57, Andres Freund wrote:
> > On 2014-11-19 15:47:05 +, Simon Riggs wrote:
> >> > Also, for the Shutdown itself, why are we not using
> >> >kill(PostmasterPid, SIGINT)?
> >>
> >> Done
> >
> > I don't think that's ok.
On 19/11/14 17:04, Simon Riggs wrote:
On 19 November 2014 15:57, Andres Freund wrote:
On 2014-11-19 15:47:05 +, Simon Riggs wrote:
Also, for the Shutdown itself, why are we not using
kill(PostmasterPid, SIGINT)?
Done
I don't think that's ok. The postmaster is the one that should be
On 19 November 2014 15:57, Andres Freund wrote:
> On 2014-11-19 15:47:05 +, Simon Riggs wrote:
>> > Also, for the Shutdown itself, why are we not using
>> >kill(PostmasterPid, SIGINT)?
>>
>> Done
>
> I don't think that's ok. The postmaster is the one that should be in
> control, not some s
On 2014-11-19 15:47:05 +, Simon Riggs wrote:
> > Also, for the Shutdown itself, why are we not using
> >kill(PostmasterPid, SIGINT)?
>
> Done
I don't think that's ok. The postmaster is the one that should be in
control, not some subprocess.
I fail to see the win in simplicity over using
On Tue, Nov 18, 2014 at 4:40 AM, Jeff Davis wrote:
>> To reiterate the basic problem here, if we do nothing at all about the
>> lock manager, a parallel backend can stall trying to grab an
>> AccessExclusiveLock that the user backend alread holds, either because
>> the user backend holds an Access
At 2014-11-11 16:56:00 +0530, a...@2ndquadrant.com wrote:
>
> I'm working on this (first speeding up the default calculation using
> slice-by-N, then adding support for the SSE4.2 CRC instruction on
> top).
I've done the first part in the attached patch, and I'm working on the
second (especially t
On 19 November 2014 13:13, Simon Riggs wrote:
> I've reworded docs a little.
Done
> If we ask for PAUSE and we're not in HotStandby it just ignores it,
> which means it changes into PROMOTE. My feeling is that we should
> change that into a SHUTDOWN, not a PROMOTE.
Done
>
> Also, for the Shut
>
>
>> On 18 November 2014 21:19, Petr Jelinek wrote:
>>
>> Personally, I see this as natural extension of the conditional block
>>> control
>>> which we already have for loops with CONTINUE WHEN and EXIT WHEN. This
>>> basically extends it to any block and it seems quite natural to have it
>>> f
Dag-Erling Smørgrav writes:
>
> The attached patches add an ssl_protocols configuration option which
> control which versions of SSL or TLS the server will use. The syntax is
> similar to Apache's SSLProtocols directive, except that the list is
> colon-separated instead of whitespace-separated,
On Tue, Nov 18, 2014 at 8:53 AM, Amit Kapila wrote:
> Won't this be addressed because both updates issued from myfunc()
> are considered as separate commands, so w.r.t lock it should behave
> as 2 different updates in same transaction. I think there may be more
> things to make updates possible v
On 19/11/14 14:13, Simon Riggs wrote:
On 18 November 2014 22:05, Petr Jelinek wrote:
OK, promote works for me as well, I attached patch that changes continue to
promote so you don't have to find and replace everything yourself. The
changed doc wording probably needs to be checked.
I've rewor
Albe Laurenz wrote:
> Currently it is possible to change the behaviour of a function with
> CREATE OR REPLACE FUNCTION even if the function is part of an index
> definition.
>
> I think that should be forbidden, because it is very likely to corrupt
> the index. I expect the objection that this
On 2014-11-19 11:54:47 -0300, Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
> > Schema | Name | Type | Owner | Size | Description
> > +--+---++-+-
> > public | btree_tall_tbl | table | heikki | 24 kB |
> > public |
Heikki Linnakangas wrote:
> 2. These make the regression database larger. The following tables and
> indexes are added:
>
> postgres=# \d+
> List of relations
> Schema | Name | Type | Owner | Size | Description
> +--+---+-
On 11/19/14 3:38 PM, Albe Laurenz wrote:
I think that should be forbidden, because it is very likely to corrupt
the index. I expect the objection that this would break valid use cases
where people know exactly what they are doing, but I believe that this
is a footgun for inexperienced users that
Hi,
On 2014-11-19 16:27:56 +0200, Heikki Linnakangas wrote:
> To test WAL replay, I often set up a master-standby system with streaming
> replication and run "make installcheck" on the master. However, the
> regression suite doesn't generate all WAL record types. I spent some time
> looking at the
Currently it is possible to change the behaviour of a function with
CREATE OR REPLACE FUNCTION even if the function is part of an index definition.
I think that should be forbidden, because it is very likely to corrupt
the index. I expect the objection that this would break valid use cases
where
To test WAL replay, I often set up a master-standby system with
streaming replication and run "make installcheck" on the master.
However, the regression suite doesn't generate all WAL record types. I
spent some time looking at the lcov report (make coverage-html), and
crafted new tests to test
On Mon, Nov 17, 2014 at 4:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Nov 13, 2014 at 7:34 PM, Tom Lane wrote:
>>> One thing that occurs to me is that if the generic plan estimate comes
>>> out much cheaper than the custom one, maybe we should assume that the
>>> generic's cost estim
On 11/19/2014 06:35 AM, Simon Riggs wrote:
On 18 November 2014 21:19, Petr Jelinek wrote:
Personally, I see this as natural extension of the conditional block control
which we already have for loops with CONTINUE WHEN and EXIT WHEN. This
basically extends it to any block and it seems quite na
On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs wrote:
> If we ask for PAUSE and we're not in HotStandby it just ignores it,
> which means it changes into PROMOTE. My feeling is that we should
> change that into a SHUTDOWN, not a PROMOTE.
To me, that seems like a definite improvement.
--
Robert Ha
1 - 100 of 117 matches
Mail list logo
