On Wed, Nov 19, 2014 at 6:16 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Nov 17, 2014 at 12:30 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Mon, Nov 17, 2014 at 10:02 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Nov 15, 2014 at 9:10 PM, Michael Paquier
When we specify a value which exceeds valid range in Customized
Options , its behavior is different from Parameter Interaction via
Configuration File behavior.
In case of Parameter Interaction via Configuration File, it finish
with FATAL error when it get threshold error.
But in
Ok. I added that comment to the commitfest and changed the status to ready
for commiter.
On Wed, Nov 19, 2014 at 1:10 PM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
wrote:
(2014/11/19 15:56), Ashutosh Bapat wrote:
On Wed, Nov 19, 2014 at 12:14 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp
On Wed, Nov 19, 2014 at 5:15 PM, Magnus Hagander mag...@hagander.net wrote:
On Wed, Nov 19, 2014 at 6:16 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Nov 17, 2014 at 12:30 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Mon, Nov 17, 2014 at 10:02 AM, Fujii Masao
On Sun, Nov 16, 2014 at 12:19 PM, David Rowley dgrowle...@gmail.com wrote:
On Sun, Nov 16, 2014 at 10:09 AM, Simon Riggs si...@2ndquadrant.com
wrote:
I propose that we keep track of whether there are any potentially
skippable joins at the top of the plan. When we begin execution we do
a
(2014/11/19 18:21), Ashutosh Bapat wrote:
Ok. I added that comment to the commitfest and changed the status to
ready for commiter.
Many thanks!
PS: the link to the review emails that discuss the issue doesn't work
properly, so I re-added the link.
Best regards,
Etsuro Fujita
--
Sent via
On 19 November 2014 02:12, Petr Jelinek p...@2ndquadrant.com wrote:
Maybe we need better explanation of the LSN use-case(s) to understand why it
should be stored here and why the other solutions are significantly worse.
We should apply the same standard that has been applied elsewhere. If
I observed an interesting (and I think buggy) behaviour today after one of
our clusters crashed due to an out of space condition in the data directory.
Five databases in that cluster have each one unlogged table.
The log reads as follows:
PANIC could not write to file pg_xlog/xlogtemp.1820: No
On 18 November 2014 21:19, Petr Jelinek p...@2ndquadrant.com 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 for
On 19/11/14 12:20, Simon Riggs wrote:
On 19 November 2014 02:12, Petr Jelinek p...@2ndquadrant.com wrote:
Maybe we need better explanation of the LSN use-case(s) to understand why it
should be stored here and why the other solutions are significantly worse.
We should apply the same standard
Hi,
On 2014-11-19 11:26:56 +, Albe Laurenz wrote:
I observed an interesting (and I think buggy) behaviour today after one of
our clusters crashed due to an out of space condition in the data directory.
Hah, just a couple days I pushed a fix for that ;)
Andres Freund wrote:
On 2014-11-19 11:26:56 +, Albe Laurenz wrote:
I observed an interesting (and I think buggy) behaviour today after one of
our clusters crashed due to an out of space condition in the data
directory.
Hah, just a couple days I pushed a fix for that ;)
On Tue, Nov 11, 2014 at 1:04 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Tue, Nov 11, 2014 at 1:43 AM, Magnus Hagander mag...@hagander.net
wrote:
Right now it just truncates the dn at NAMEDATALEN - so treating it the
same as we do with hostnames. My guess is this is not a big
On 18 November 2014 22:05, Petr Jelinek p...@2ndquadrant.com 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 reworded docs a little.
Petr Jelinek wrote:
This is good point, we are not too late in the cycle that LSN couldn't be
added later if we find that it is indeed needed (and we don't have to care
about pg_upgrade until beta).
I think we're overblowing the pg_upgrade issue. Surely we don't need to
preserve commit_ts
On Tue, Nov 18, 2014 at 8:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan p...@heroku.com writes:
On Tue, Nov 18, 2014 at 3:29 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Nov 17, 2014 at 3:04 PM, Peter Geoghegan p...@heroku.com wrote:
postgres=# select qty from orderlines ;
On Wed, Nov 19, 2014 at 8:22 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Petr Jelinek wrote:
This is good point, we are not too late in the cycle that LSN couldn't be
added later if we find that it is indeed needed (and we don't have to care
about pg_upgrade until beta).
I think we're
On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs si...@2ndquadrant.com 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
On 11/19/2014 06:35 AM, Simon Riggs wrote:
On 18 November 2014 21:19, Petr Jelinek p...@2ndquadrant.com 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
On Mon, Nov 17, 2014 at 4:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 13, 2014 at 7:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
One thing that occurs to me is that if the generic plan estimate comes
out much cheaper than the custom one, maybe
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
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
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 lcov
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
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 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 |
Albe Laurenz laurenz.a...@wien.gv.at 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
On 19/11/14 14:13, Simon Riggs wrote:
On 18 November 2014 22:05, Petr Jelinek p...@2ndquadrant.com 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
On Tue, Nov 18, 2014 at 8:53 AM, Amit Kapila amit.kapil...@gmail.com 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
Dag-Erling Smørgrav d...@des.no 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
On 18 November 2014 21:19, Petr Jelinek p...@2ndquadrant.com 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
On 19 November 2014 13:13, Simon Riggs si...@2ndquadrant.com 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
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 the
On Tue, Nov 18, 2014 at 4:40 AM, Jeff Davis pg...@j-davis.com 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
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 exit
On 19 November 2014 15:57, Andres Freund and...@2ndquadrant.com 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,
On 19/11/14 17:04, Simon Riggs wrote:
On 19 November 2014 15:57, Andres Freund and...@2ndquadrant.com 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
On 2014-11-19 16:04:49 +, Simon Riggs wrote:
On 19 November 2014 15:57, Andres Freund and...@2ndquadrant.com 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
Andrew Dunstan and...@dunslane.net 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,
On 19/11/14 16:47, Simon Riggs wrote:
On 19 November 2014 13:13, Simon Riggs si...@2ndquadrant.com 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
Antonin Houska a...@cybertec.at writes:
Albe Laurenz laurenz.a...@wien.gv.at 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
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
On Wed, Nov 19, 2014 at 10:49 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs si...@2ndquadrant.com 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
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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.
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
Robert Haas robertmh...@gmail.com writes:
On Wed, Nov 19, 2014 at 11:44 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
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
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 06:49 PM, Robert Haas wrote:
On Wed, Nov 19, 2014 at 11:44 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
Aaron W. Swenson titanof...@gentoo.org 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
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
hlinnakan...@vmware.com wrote:
That's an interesting choice of workload. That sure is heavy on the CRC
calculation, but the speed of
On Tue, Nov 18, 2014 at 3:41 PM, Jeff Janes jeff.ja...@gmail.com 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
On Wed, Nov 19, 2014 at 5:43 AM, Robert Haas robertmh...@gmail.com 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
On Wed, Nov 19, 2014 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Nov 19, 2014 at 12:33 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Nov 19, 2014 at 5:43 AM, Robert Haas robertmh...@gmail.com 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
Alvaro Herrera alvhe...@2ndquadrant.com 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
On Tue, Nov 18, 2014 at 5:14 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Nov 18, 2014 at 5:34 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
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 |
On Wed, Nov 19, 2014 at 1:01 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 18, 2014 at 5:14 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
It seems pretty weird, also, that the event trigger will fire after
we've taken
On Tue, Nov 18, 2014 at 9:19 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On Wed, Nov 19, 2014 at 9:52 AM, Robert Haas robertmh...@gmail.com 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
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 10:22 AM, Peter Geoghegan p...@heroku.com 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,
On Wed, Nov 19, 2014 at 10:33 AM, Peter Geoghegan p...@heroku.com 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
On 19 November 2014 16:11, Petr Jelinek p...@2ndquadrant.com 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 p...@heroku.com 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
On Wed, Nov 19, 2014 at 1:22 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Nov 19, 2014 at 9:52 AM, Robert Haas robertmh...@gmail.com 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
On Wed, Nov 19, 2014 at 11:13 AM, Robert Haas robertmh...@gmail.com 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
On Wed, Nov 19, 2014 at 11:13 AM, Robert Haas robertmh...@gmail.com 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
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
On Wed, Nov 19, 2014 at 11:34 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
Peter Geoghegan wrote:
On Wed, Nov 19, 2014 at 11:34 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On Wed, Nov 19, 2014 at 11:54 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Peter Geoghegan wrote:
On Wed, Nov 19, 2014 at 11:34 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
0 for a transposition, wow.
Again, they're optimizing for short strings (git commands) only. There
just
Peter Geoghegan wrote:
On Wed, Nov 19, 2014 at 11:54 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Peter Geoghegan wrote:
On Wed, Nov 19, 2014 at 11:34 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
0 for a transposition, wow.
Again, they're optimizing for short strings
On 19 November 2014 16:41, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Nov 19, 2014 at 10:49 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs si...@2ndquadrant.com wrote:
If we ask for PAUSE and we're not in HotStandby it just ignores it,
which
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
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
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 in any
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, it's normal --
Andres Freund and...@2ndquadrant.com 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
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
2014-11-19 17:13 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Andrew Dunstan and...@dunslane.net 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
2014-11-19 17:43 GMT+01:00 Robert Haas robertmh...@gmail.com:
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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
2014-11-19 18:01 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Nov 19, 2014 at 2:09 PM, Peter Geoghegan p...@heroku.com 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.
--
On 2014-11-19 23:18, Pavel Stehule wrote:
2014-11-19 18:01 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, I would vote against it also. I do not find this to be a natural
extension
On 19/11/14 19:51, Simon Riggs wrote:
On 19 November 2014 16:11, Petr Jelinek p...@2ndquadrant.com 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?
Marko Tiikkaja ma...@joh.to 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
2014-11-19 23:38 GMT+01:00 Marko Tiikkaja ma...@joh.to:
On 2014-11-19 23:18, Pavel Stehule wrote:
2014-11-19 18:01 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, I would vote
2014-11-19 23:54 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Marko Tiikkaja ma...@joh.to writes:
I also went back to the original thread, and I think Heikki's summary
dismissed e.g. Robert's criticism quite lightly:
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?
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
Pavel Stehule pavel.steh...@gmail.com writes:
2014-11-19 23:54 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
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
On Sun, Oct 5, 2014 at 5:16 AM, Stephen Frost sfr...@snowman.net 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
On Mon, Nov 10, 2014 at 3:33 PM, Peter Geoghegan p...@heroku.com 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
On Thu, Nov 20, 2014 at 2:57 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr 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?
On 11/20/2014 01:52 AM, Peter Geoghegan wrote:
On Mon, Nov 10, 2014 at 3:33 PM, Peter Geoghegan p...@heroku.com 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
On Wed, Nov 19, 2014 at 5:37 PM, Andreas Karlsson andr...@proxel.se 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
On Wed, Nov 19, 2014 at 6:04 PM, Peter Geoghegan p...@heroku.com 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
1 - 100 of 114 matches
Mail list logo
