On Apr 24, 2011, at 1:22 PM, Simon Riggs si...@2ndquadrant.com wrote:
Unlogged tables are a good new feature.
Thanks.
I noticed Bruce had mentioned they were the equivalent of NoSQL, which
I don't really accept.
Me neither. I thought that was poorly said.
Heap blocks would be zeroed if
The only data we can't rebuild it's the heap. So what about an option for
UNlogged indexes on a LOGged table? It would always preserve data, and it would
'only' cost a rebuilding of the indexes in case of an unclean shutdown. I think
it would give a boost in performance for all those cases
On Mon, Apr 25, 2011 at 8:36 AM, Leonardo Francalanci m_li...@yahoo.it wrote:
The only data we can't rebuild it's the heap. So what about an option for
UNlogged indexes on a LOGged table? It would always preserve data, and it
would 'only' cost a rebuilding of the indexes in case of an unclean
On Mon, Apr 25, 2011 at 8:14 AM, Robert Haas robertmh...@gmail.com wrote:
On Apr 24, 2011, at 1:22 PM, Simon Riggs si...@2ndquadrant.com wrote:
Unlogged tables are a good new feature.
Thanks.
I noticed Bruce had mentioned they were the equivalent of NoSQL, which
I don't really accept.
Me
I noticed that ALTER FOREIGN TABLE RENAME TO emits a wrong hint message
if the object was not a foreign table. ISTM that the hint message is
not necessary there. Attached patch removes the hint message.
Steps to reproduce the situation:
postgres=# CREATE FOREIGN TABLE foo () SERVER
On 25 April 2011 10:06, Shigeru Hanada han...@metrosystems.co.jp wrote:
I noticed that ALTER FOREIGN TABLE RENAME TO emits a wrong hint message if
the object was not a foreign table. ISTM that the hint message is not
necessary there. Attached patch removes the hint message.
Steps to
(2011/04/25 19:34), Thom Brown wrote:
Don't you mean that you created a regular table first, then tried to
rename it as a foreign table? Your example here will be successful
without the error.
Oops, you are right.
Right procedure to reproduce is:
postgres=# CREATE TABLE foo(c1 int);
CREATE
One is at src/interfaces/ecpg/ecpglib/sqlda.c:231, which is this line:
sqlda-sqlvar[i].sqlformat = (char *) (long) PQfformat(res, i);
I'm not clear about the purpose of this anyway. It doesn't seem to
After not hearing from the author I just commented out that line. I cannot find
any
On Mon, Apr 25, 2011 at 5:04 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Apr 25, 2011 at 8:14 AM, Robert Haas robertmh...@gmail.com wrote:
On Apr 24, 2011, at 1:22 PM, Simon Riggs si...@2ndquadrant.com wrote:
Unlogged tables are a good new feature.
Thanks.
I noticed Bruce had
On Mon, Apr 25, 2011 at 3:36 AM, Leonardo Francalanci m_li...@yahoo.it wrote:
The only data we can't rebuild it's the heap. So what about an option for
UNlogged indexes on a LOGged table? It would always preserve data, and it
would 'only' cost a rebuilding of the indexes in case of an unclean
On Sun, Apr 24, 2011 at 6:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
On Apr 24, 2011, at 2:55 PM, Tom Lane wrote:
Hmm ... it's sufficient, but I think people are going to be confused as
to proper usage if you call two different things the version.
On Sun, Apr 24, 2011 at 7:18 PM, Peter Eisentraut pete...@gmx.net wrote:
I noticed again that make check in contrib doesn't work, so here is a
patch to fix it. Perhaps someone wants to fill in the Windows support
for it. Naturally, this works only for contrib itself, not for external
On Thu, Apr 21, 2011 at 11:06 AM, Mike Pultz m...@mikepultz.com wrote:
And since serial4 and serial8 are simply pseudo-types- effectively there for
convenience, I’d argue that it should simply be there for completeness- just
because it may be less used, doesn’t mean it shouldn’t be convenient?
The recent and wide-ranging formatting curmudgeons thread included
suggestions by Tom and myself that we should consider branching the
tree immediately after beta1.
http://archives.postgresql.org/pgsql-hackers/2011-04/msg01157.php
http://archives.postgresql.org/pgsql-hackers/2011-04/msg01162.php
On 04/25/2011 08:53 AM, Robert Haas wrote:
The argument that no check
target at all is more useful than a check target that fails with a
reasonably informative error message seems week to me.
+1 (weak too)
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 04/25/2011 09:17 AM, Robert Haas wrote:
The recent and wide-ranging formatting curmudgeons thread included
suggestions by Tom and myself that we should consider branching the
tree immediately after beta1.
http://archives.postgresql.org/pgsql-hackers/2011-04/msg01157.php
On Sun, Apr 24, 2011 at 11:33 PM, Dan Ports d...@csail.mit.edu wrote:
On Sat, Apr 23, 2011 at 08:54:31AM -0500, Kevin Grittner wrote:
Even though this didn't show any difference in Dan's performance
tests, it seems like reasonable insurance against creating a new
bottleneck in very high
On Fri, Apr 22, 2011 at 11:46 PM, David Christensen da...@endpoint.com wrote:
On Apr 22, 2011, at 3:50 PM, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Fri, Apr 22, 2011 at 1:28 PM, Peter Eisentraut pete...@gmx.net wrote:
It would probably be more reasonable and feasible to
Shigeru Hanada han...@metrosystems.co.jp writes:
I noticed that ALTER FOREIGN TABLE RENAME TO emits a wrong hint message
if the object was not a foreign table. ISTM that the hint message is
not necessary there. Attached patch removes the hint message.
Surely it would be better to make the
Merlin Moncure mmonc...@gmail.com wrote:
Procedures unlike functions however can no longer rely that
catalogs remain static visibility wise through execution for
functions.
If you start from the perspective that stored procedures are in many
respects more like psql scripts than functions,
* Robert Haas (robertmh...@gmail.com) wrote:
On balance, I think I prefer the
current arrangement, though if we could make the CommitFests a bit
shorter I would certainly like that better. I don't know how to make
that happen without more reviewers, though.
Given our current method (where we
Robert Haas robertmh...@gmail.com writes:
On Sun, Apr 24, 2011 at 7:18 PM, Peter Eisentraut pete...@gmx.net wrote:
I noticed again that make check in contrib doesn't work, so here is a
patch to fix it.
I think it might be more useful to have a check target that actually
succeeds, even if it
The sort of failure shown below has happened a few times recently. See
recent failures on crake, mastodon and casteroides at
http://www.pgbuildfarm.org/cgi-bin/show_failures.pl. It seems harmless
enough. Do we need an alternative regression results file, or is there
some way to prevent this?
Robert Haas robertmh...@gmail.com wrote:
The recent and wide-ranging formatting curmudgeons thread
included suggestions by Tom and myself that we should consider
branching the tree immediately after beta1.
My take is that it should be branched as soon as a committer would
find it useful to
Robert Haas robertmh...@gmail.com writes:
The recent and wide-ranging formatting curmudgeons thread included
suggestions by Tom and myself that we should consider branching the
tree immediately after beta1.
http://archives.postgresql.org/pgsql-hackers/2011-04/msg01157.php
On Mon, Apr 25, 2011 at 9:18 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Merlin Moncure mmonc...@gmail.com wrote:
Procedures unlike functions however can no longer rely that
catalogs remain static visibility wise through execution for
functions.
If you start from the perspective
Andrew Dunstan and...@dunslane.net writes:
The sort of failure shown below has happened a few times recently. See
recent failures on crake, mastodon and casteroides at
http://www.pgbuildfarm.org/cgi-bin/show_failures.pl. It seems harmless
enough. Do we need an alternative regression results
On Mon, Apr 25, 2011 at 3:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
One small issue that would have to be resolved before branching is
whether and when to do a final pgindent run for 9.1. Seems like the
alternatives would be:
If the tools become easy to run is it possible we cold get to the
On Mon, Apr 25, 2011 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Apr 24, 2011 at 7:18 PM, Peter Eisentraut pete...@gmx.net wrote:
I noticed again that make check in contrib doesn't work, so here is a
patch to fix it.
I think it might be
Greg Stark gsst...@mit.edu writes:
If the tools become easy to run is it possible we cold get to the
point where we do an indent run on every commit? This wold require a
stable list of system symbols plus the tool would need to add any new
symbols added by the patch. As long as the tool
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 25, 2011 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Apr 24, 2011 at 7:18 PM, Peter Eisentraut pete...@gmx.net wrote:
I noticed again that make check in contrib doesn't work, so here is
On 04/24/2011 10:06 PM, Daniel Farina wrote:
On Thu, Apr 21, 2011 at 8:51 PM, Greg Smithg...@2ndquadrant.com wrote:
There's still the fsync'd a data block but not the directory entry yet
issue as fall-out from this too. Why doesn't PostgreSQL run into this
problem? Because the exact code
On Mon, Apr 25, 2011 at 11:03 AM, Greg Stark gsst...@mit.edu wrote:
If the tools become easy to run is it possible we cold get to the
point where we do an indent run on every commit? This wold require a
stable list of system symbols plus the tool would need to add any new
symbols added by the
On Mon, Apr 25, 2011 at 10:45 AM, Tom Lane t...@sss.pgh.pa.us wrote:
One small issue that would have to be resolved before branching is
whether and when to do a final pgindent run for 9.1. Seems like the
alternatives would be:
1. Don't do anything more, be happy with the one run done
On Mon, Apr 25, 2011 at 11:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 25, 2011 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Apr 24, 2011 at 7:18 PM, Peter Eisentraut pete...@gmx.net wrote:
On Mon, Apr 25, 2011 at 11:32 AM, Christopher Browne cbbro...@gmail.com wrote:
Methinks there'd need to be an experiment run where pgindent is run
each time on some sort of parallel tree for a little while, to let
people get some feel for what changes it introduces.
The point is that if the
On 04/23/2011 09:58 AM, Matthew Woodcraft wrote:
As far as I can make out, the current situation is that this fix (the
auto_da_alloc mount option) doesn't work as advertised, and the ext4
maintainers are not treating this as a bug.
See https://bugzilla.kernel.org/show_bug.cgi?id=15910
I
On Apr 25, 2011, at 5:49 AM, Robert Haas wrote:
I think it's a bit awkward that we have to do it this way, though.
The installed version of the extension at the SQL level won't match
what the user thinks they've installed. Granted, it'll be in the
ballpark (1.0 vs 1.0.3, for example) but
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 25, 2011 at 10:45 AM, Tom Lane t...@sss.pgh.pa.us wrote:
But a much more significant issue is that I don't see a lot of point in
branching until we are actually ready to start active 9.2 development.
So unless you see this as a vehicle
Bruce Momjian wrote:
Well, having seen no replies, I am going to apply the version of the
patch in a few days that keeps the old vacuum-disable behavior for older
releases, and uses the -b flag for newer ones by testing the catalog
version, e.g.:
snprintf(cmd, sizeof(cmd),
Aidan Van Dyk ai...@highrise.ca wrote:
2) Discipline of all new published commits being pgindent clean.
Heck, I think it would be reasonable to require that patch
submitters run it before creating their patches. If people merged
in changes from the main repository and then ran pgindent, I
On Mon, Apr 25, 2011 at 12:00 PM, David E. Wheeler da...@kineticode.com wrote:
These are really great points. I knew I wasn't thrilled about this suggest,
but wasn't sure why. Frankly, I think it will be really confusing to users
who think they have FooBar 1.2.2 installed but see only 1.2 in
Excerpts from Tomas Vondra's message of dom abr 24 13:49:31 -0300 2011:
Right now I do have a very simple tool that reads a given file and
performs a lot of checks at the block level (as described in bufpage.h),
and the next step should be validating basic structure of the tuples
(lengths).
On Apr 25, 2011, at 9:14 AM, Aidan Van Dyk wrote:
Really, that means you just a sql function to your extension,
somethign similary to uname -a, or rpm -qi, which includes something
that is *forced* to change the postgresql catalog view of your
extension every time you ship a new version
A recent complaint in pgsql-novice revealed that if you have say
hostsslall all 127.0.0.1/32md5
clientcert=1
in pg_hba.conf, but you forget to enable SSL in postgresql.conf,
you get something like this:
LOG: client certificates can only be checked if a
On Mon, Apr 25, 2011 at 12:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You're ignoring the extremely real costs involved in an early branch,
namely having to double-patch every bug fix we make during beta.
(And no, my experiences with git cherry-pick are not so pleasant as
to make me feel that
On Mon, Apr 25, 2011 at 12:17 PM, David E. Wheeler da...@kineticode.com wrote:
On Apr 25, 2011, at 9:14 AM, Aidan Van Dyk wrote:
Really, that means you just a sql function to your extension,
somethign similary to uname -a, or rpm -qi, which includes something
that is *forced* to change the
On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
A recent complaint in pgsql-novice revealed that if you have say
hostssl all all 127.0.0.1/32 md5
clientcert=1
in pg_hba.conf, but you forget to enable SSL in postgresql.conf,
you get
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Aidan Van Dyk ai...@highrise.ca wrote:
Of course, that all depends on:
1) pgindent being work everywhere, exactly the same
2) Discipline of all new published commits being pgindent clean.
The problem is that getting it set up isn't yet
On mån, 2011-04-25 at 11:22 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 25, 2011 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Apr 24, 2011 at 7:18 PM, Peter Eisentraut pete...@gmx.net wrote:
I noticed
On Mon, Apr 25, 2011 at 18:59, Robert Haas robertmh...@gmail.com wrote:
On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
A recent complaint in pgsql-novice revealed that if you have say
hostssl all all 127.0.0.1/32 md5
clientcert=1
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm inclined to think that the correct fix is to make parse_hba_line,
where it first realizes the line is hostssl, check not only that SSL
support is compiled but that it's turned on.
Peter Eisentraut pete...@gmx.net writes:
On mån, 2011-04-25 at 11:22 -0400, Tom Lane wrote:
The proposed patch is to fix it, not remove it. Surely that's more
useful than a no-op target.
The proposed patch will support make check for contrib modules, but not
for external users of pgxs.
So
On Mon, Apr 25, 2011 at 1:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Aidan Van Dyk ai...@highrise.ca wrote:
Of course, that all depends on:
1) pgindent being work everywhere, exactly the same
2) Discipline of all new published commits being
On Mon, Apr 25, 2011 at 19:11, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm inclined to think that the correct fix is to make parse_hba_line,
where it first realizes the line is hostssl,
On 04/25/2011 01:12 PM, David Blewett wrote:
On Mon, Apr 25, 2011 at 1:04 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Kevin Grittnerkevin.gritt...@wicourts.gov writes:
Aidan Van Dykai...@highrise.ca wrote:
Of course, that all depends on:
1) pgindent being work everywhere, exactly the same
2)
Magnus Hagander mag...@hagander.net writes:
On Mon, Apr 25, 2011 at 18:59, Robert Haas robertmh...@gmail.com wrote:
It's not clear to me what behavior you are proposing. Would we
disregard the hostssl line or treat it as an error?
It would absolutely have to be treat it as an error. another
On Mon, Apr 25, 2011 at 1:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm inclined to think that the correct fix is to make parse_hba_line,
where it first realizes the line is hostssl,
On Mon, Apr 25, 2011 at 19:18, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Apr 25, 2011 at 18:59, Robert Haas robertmh...@gmail.com wrote:
It's not clear to me what behavior you are proposing. Would we
disregard the hostssl line or treat it as an
On Wed, Apr 20, 2011 at 11:08 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Apr 20, 2011 at 9:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Shigeru Hanada han...@metrosystems.co.jp writes:
Attached patch implements along specifications below. It also includes
documents and regression
Magnus Hagander mag...@hagander.net writes:
Yeah, better make any misconfiguration very clear - let's throw an error.
OK, so we need something like (untested)
if (token[4] == 's')/* hostssl */
{
#ifdef USE_SSL
+if (!EnableSSL)
+{
+
On mån, 2011-04-25 at 13:12 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On mån, 2011-04-25 at 11:22 -0400, Tom Lane wrote:
The proposed patch is to fix it, not remove it. Surely that's more
useful than a no-op target.
The proposed patch will support make check for
Robert Haas robertmh...@gmail.com writes:
Hmm, it appears we had some pre-existing inconsistency here, because
ALL TABLES IN schema currently includes views. That's weird, but
it'll be even more weird if we adopt the approach suggested by this
patch, which creates ALL FOREIGN TABLES IN schema
Dne 25.4.2011 18:16, Alvaro Herrera napsal(a):
Excerpts from Tomas Vondra's message of dom abr 24 13:49:31 -0300 2011:
Right now I do have a very simple tool that reads a given file and
performs a lot of checks at the block level (as described in bufpage.h),
and the next step should be
Peter Eisentraut pete...@gmx.net writes:
Since some people didn't like removing the hint about installcheck,
I'd suggest just removing the exit 1, which should then be pretty
consistent overall.
Works for me.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Mon, Apr 25, 2011 at 19:38, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Yeah, better make any misconfiguration very clear - let's throw an error.
OK, so we need something like (untested)
if (token[4] == 's') /* hostssl */
{
#ifdef
I have two separate ideas, but they are kind of connected,
(1) Make the detailed error message available in SPs and not only the short
error message (SQLERRM)
When debugging errors in stored procedures, I often add an exception handler
and print the values of declared variables to the log.
On mån, 2011-04-25 at 09:17 -0400, Robert Haas wrote:
it'll be harder to organize reviewers (see esp. the note
by Greg Smith in that regard),
As far as I'm concerned, those who run the commit fests will have to
work out how to best configure the commit fests. I have no strong
feelings about my
Magnus Hagander mag...@hagander.net writes:
On Mon, Apr 25, 2011 at 19:38, Tom Lane t...@sss.pgh.pa.us wrote:
While I'm looking at this, I notice that here (and in some other places
in pg_hba.conf) we say not supported on this platform which seems
rather bogus to me. It implies that it's not
On Mon, Apr 25, 2011 at 1:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Hmm, it appears we had some pre-existing inconsistency here, because
ALL TABLES IN schema currently includes views. That's weird, but
it'll be even more weird if we adopt the approach
The amount of data loss on a big
table will be 1% of the data loss
caused by truncating the whole table.
If that 1% is random (not time/transaction related), usually you'd rather have
an empty table. In other words: is a table that is not consistant with anything
else in the db useful?
--
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 25, 2011 at 1:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not sure I quite understood what you were saying there, but I'm
coming around to the view that this is already 100% consistent with
the way views are handled:
rhaas=# create view
On mån, 2011-04-25 at 13:11 -0400, Tom Lane wrote:
Or we could go in the direction of making hostssl lines be a silent
no-op in both cases, but that doesn't seem like especially
user-friendly design to me. We don't treat any other cases in
pg_hba.conf comparably AFAIR.
We ignore local even
On 2011-04-25 20:00, Leonardo Francalanci wrote:
The amount of data loss on a big table will be 1% of the data
loss caused by truncating the whole table.
If that 1% is random (not time/transaction related), usually you'd
rather have an empty table. In other words: is a table that is not
On mån, 2011-04-25 at 19:12 +0200, Magnus Hagander wrote:
We need to be very careful about ignoring *anything* in pg_hba.conf,
since it's security configuration. Doing it silently is even worse.
You're not really ignoring anything. It's just not going to be a
match.
--
Sent via
On mån, 2011-04-25 at 13:35 -0400, Robert Haas wrote:
Hmm, it appears we had some pre-existing inconsistency here, because
ALL TABLES IN schema currently includes views.
Which makes sense because you use GRANT ... ON TABLE to grant privileges
to views.
That's weird, but
it'll be even more
Jesper Krogh jes...@krogh.cc wrote:
On 2011-04-25 20:00, Leonardo Francalanci wrote:
The amount of data loss on a big table will be 1% of the data
loss caused by truncating the whole table.
If that 1% is random (not time/transaction related), usually
you'd rather have an empty table. In
On Mon, Apr 25, 2011 at 2:03 PM, Jesper Krogh jes...@krogh.cc wrote:
On 2011-04-25 20:00, Leonardo Francalanci wrote:
The amount of data loss on a big table will be 1% of the data
loss caused by truncating the whole table.
If that 1% is random (not time/transaction related), usually you'd
On Mon, Apr 25, 2011 at 2:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 25, 2011 at 1:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not sure I quite understood what you were saying there, but I'm
coming around to the view that this is already
On Mon, Apr 25, 2011 at 7:00 PM, Leonardo Francalanci m_li...@yahoo.it wrote:
The amount of data loss on a big
table will be 1% of the data loss
caused by truncating the whole table.
If that 1% is random (not time/transaction related), usually you'd rather
have an empty table.
Why do you
Peter Eisentraut pete...@gmx.net writes:
On mån, 2011-04-25 at 13:11 -0400, Tom Lane wrote:
Or we could go in the direction of making hostssl lines be a silent
no-op in both cases, but that doesn't seem like especially
user-friendly design to me. We don't treat any other cases in
On tor, 2011-04-21 at 18:24 +0300, Peter Eisentraut wrote:
So the topic of real stored procedures came up again. Meaning a
function-like object that executes outside of a regular transaction,
with the ability to start and stop SQL transactions itself.
I would like to add a note about the SQL
On Mon, Apr 25, 2011 at 1:42 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Apr 25, 2011 at 5:04 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Apr 25, 2011 at 8:14 AM, Robert Haas robertmh...@gmail.com wrote:
On Apr 24, 2011, at 1:22 PM, Simon Riggs si...@2ndquadrant.com wrote:
All,
�I'm not aware that we've set
any dates for 9.2 CommitFests yet ...
I thought the idea of setting the initial CF for July 15th for 9.1 was
that we would consistently have the first CF in July every year? As
discussed at that time, there's value to our corporate-sponsored
developers in
On 04/25/2011 02:18 PM, Peter Eisentraut wrote:
On tor, 2011-04-21 at 18:24 +0300, Peter Eisentraut wrote:
So the topic of real stored procedures came up again. Meaning a
function-like object that executes outside of a regular transaction,
with the ability to start and stop SQL transactions
Robert Haas robertmh...@gmail.com writes:
... There's a similar stanza for sequences, but that one uses
ereport(WARNING...) rather than ereport(ERROR...). We could either
remove that stanza entirely (making foreign tables consistent with
views) or change ERROR to WARNING (making it consistent
On Mon, Apr 25, 2011 at 1:18 PM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-04-21 at 18:24 +0300, Peter Eisentraut wrote:
So the topic of real stored procedures came up again. Meaning a
function-like object that executes outside of a regular transaction,
with the ability to start
On Mon, Apr 25, 2011 at 2:21 PM, Simon Riggs si...@2ndquadrant.com wrote:
Right, but the trick is how you identify which blocks you need to
zero. You used the word damaged, which to me implied that the block
had been modified in some way but ended up with other than the
expected contents, so
Excerpts from Tomas Vondra's message of lun abr 25 14:50:18 -0300 2011:
Yes, I know the tuple length is in HeapTupleHeader (and I'm already
checking that), but that does not allow to check lengths of the
individual columns, especially those with varlena types.
That's a very annoying type of
On mån, 2011-04-25 at 14:18 -0400, Tom Lane wrote:
In the particular case at hand, if someone is trying to use the same
hostssl-containing pg_hba.conf across multiple systems, is it not
reasonable to suppose that he should have SSL turned on in
postgresql.conf on all those systems? If he
On Mon, Apr 25, 2011 at 4:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, not at all, because you're ignoring the common case of a series of
dependent patches that are submitted in advance of the first one having
been committed.
Uh, true.
To get to the point where we could do things that way,
Josh Berkus j...@agliodbs.com writes:
As much as I'd like to start development early officially, I'm with Tom
in being pessimistic about the bugs we're going to find in SSI,
Collations and Synch Rep. Frankly, if you and Tom weren't so focused on
fixing it, I'd be suggesting that we pull
On mån, 2011-04-25 at 13:34 -0500, Merlin Moncure wrote:
hm. does the sql standard prohibit the use of extra transactional
features?
It doesn't prohibit anything. It just kindly requests that standard
syntax has standard behavior.
are you sure it's not implied that any sql (including
START
Robert Haas robertmh...@gmail.com writes:
However, I think that the logged table, unlogged index idea is
probably the most promising thing to think about doing first.
+1 for that --- it's clean, has a clear use-case, and would allow us
to manage the current mess around hash indexes more
On tor, 2011-04-21 at 18:24 +0300, Peter Eisentraut wrote:
So the topic of real stored procedures came up again. Meaning a
function-like object that executes outside of a regular transaction,
with the ability to start and stop SQL transactions itself.
I would like to collect some specs on
Peter Eisentraut pete...@gmx.net writes:
On mån, 2011-04-25 at 14:18 -0400, Tom Lane wrote:
In the particular case at hand, if someone is trying to use the same
hostssl-containing pg_hba.conf across multiple systems, is it not
reasonable to suppose that he should have SSL turned on in
Greg Stark gsst...@mit.edu writes:
Fwiw I tried getting Gnu indent to work. I'm having a devil of a time
figuring out how to get even remotely similar output.
...
And it doesn't take a file for the list of typedefs. You have to
provide each one as an argment on the command-line.
*Ouch*.
Peter Eisentraut pete...@gmx.net wrote:
what would be the actual use cases of any of these features?
Let's collect some, so we can think of ways to make them work.
The two things which leap to mind for me are:
(1) All the \d commands in psql should be implemented in SPs so
that they are
On 04/25/2011 03:30 PM, Tom Lane wrote:
Greg Starkgsst...@mit.edu writes:
Fwiw I tried getting Gnu indent to work. I'm having a devil of a time
figuring out how to get even remotely similar output.
...
And it doesn't take a file for the list of typedefs. You have to
provide each one as an
On Mon, Apr 25, 2011 at 2:26 PM, Josh Berkus j...@agliodbs.com wrote:
I thought the idea of setting the initial CF for July 15th for 9.1 was
that we would consistently have the first CF in July every year? As
discussed at that time, there's value to our corporate-sponsored
developers in
1 - 100 of 152 matches
Mail list logo
