On Wed, Oct 19, 2011 at 11:28 AM, Robert Haas robertmh...@gmail.com wrote:
Convince me. :-)
Yeah, I try.
My reading of the situation is that you're talking about a problem
that will only occur if, while the master is in the process of
shutting down, a network error occurs.
No. This happens
As I suggested in the reply to Simon, I think that the change of FPW
should be WAL-logged separately from that of HS parameters. ISTM
packing them in one WAL record makes XLogReportParameters()
quite confusing. Thought?
I updated a patch for what you have suggested (that the change of FPW
On 19 October 2011 05:50, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-10-18 at 18:38 -0400, Tom Lane wrote:
The problem with this is you cannot get into the database as it acts
as if it did find the hba file but found it empty.
Well, an actually empty pg_hba.conf file would have
On tis, 2011-10-18 at 21:47 -0700, Jeff Davis wrote:
On Tue, 2011-10-18 at 22:25 +0300, Peter Eisentraut wrote:
Presumably because Jeff doesn't have that particular locale installed.
locale -a would clarify that.
$ locale -a |grep -i tr
tr_CY.utf8
tr_TR.utf8
So, yes, I only have the
On ons, 2011-10-19 at 01:10 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
On Tue, 2011-10-18 at 22:25 +0300, Peter Eisentraut wrote:
Presumably because Jeff doesn't have that particular locale installed.
locale -a would clarify that.
$ locale -a |grep -i tr
tr_CY.utf8
Hi,
(2011/10/18 16:32), Leonardo Francalanci wrote:
New API AnalyzeForeignTable
I didn't look at the patch, but I'm using CSV foreign tables with named pipes
to get near-realtime KPI calculated by postgresql. Of course, pipes can be
read just once, so I wouldn't want an automatic analyze of
2011/10/18 Robert Haas robertmh...@gmail.com:
In the example table creation, heap_create_with_catalog() is invoked
by 5 routines, however, 3 of them are just internal usages, so it is not
preferable to apply permission checks on table creation
Some wit once made the remark that if a
On Tue, Oct 18, 2011 at 10:18 PM, Simon Riggs si...@2ndquadrant.com wrote:
Any reason or objection to committing this patch?
The checkpointer doesn't call pgstat_send_bgwriter(), but it should.
Otherwise, some entries in pg_stat_bgwriter will never be updated.
If we adopt the patch, checkpoint
2011/10/19 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Sun, Oct 16, 2011 at 4:46 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I tried to reproduce the scenario with enough small from/join_collapse_limit
(typically 1), but it allows to push down qualifiers into the
Hi list,
PostgreSQL 9.0 introduced the join removal feature for cases where
an left join can't return more than one output row. This feature
relies on checking whether a UNIQUE constraint exists on the joined
column in the referenced table.
However, there was another new feature in 9.0:
2011/10/18 Simon Riggs si...@2ndquadrant.com:
On Wed, Oct 5, 2011 at 8:02 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Oct 5, 2011 at 5:10 AM, Dickson S. Guedes lis...@guedesoft.net
wrote:
Ah ok! I started reviewing the v4 patch version, this is my comments:
...
Well, all the
On Wed, Oct 19, 2011 at 3:31 PM, Fujii Masao masao.fu...@gmail.com wrote:
(2) for this marginal improvement, you're giving up including
PQerrorMessage(streamConn) in the error message that ultimately gets
omitted, which seems like a substantial regression as far as
debuggability is concerned.
2011/10/19 Fujii Masao masao.fu...@gmail.com:
On Tue, Oct 18, 2011 at 10:18 PM, Simon Riggs si...@2ndquadrant.com wrote:
Any reason or objection to committing this patch?
The checkpointer doesn't call pgstat_send_bgwriter(), but it should.
Otherwise, some entries in pg_stat_bgwriter will
On Wed, Oct 19, 2011 at 2:31 AM, Fujii Masao masao.fu...@gmail.com wrote:
My reading of the situation is that you're talking about a problem
that will only occur if, while the master is in the process of
shutting down, a network error occurs.
No. This happens even if a network error doesn't
On Wed, Oct 19, 2011 at 8:43 AM, Dickson S. Guedes lis...@guedesoft.net wrote:
2011/10/19 Fujii Masao masao.fu...@gmail.com:
On Tue, Oct 18, 2011 at 10:18 PM, Simon Riggs si...@2ndquadrant.com wrote:
Any reason or objection to committing this patch?
The checkpointer doesn't call
Adding CORRESPONDING to Set Operations
Initial patch, filename: corresponding_clause_v2.patch
This patch adds CORRESPONDING clause to set operations according to
SQL20nn standard draft as Feature F301, CORRESPONDING in query
expressions
Corresponding clause either contains a BY(...) clause or
On Wed, Oct 19, 2011 at 9:45 PM, Robert Haas robertmh...@gmail.com wrote:
I don't really see any reason to break the monitoring view just
because we did some internal refactoring. I'd rather have backward
compatibility.
Fair enough.
The patch doesn't change any document, but at least the
On Wed, Oct 19, 2011 at 6:18 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/10/18 Robert Haas robertmh...@gmail.com:
In the example table creation, heap_create_with_catalog() is invoked
by 5 routines, however, 3 of them are just internal usages, so it is not
preferable to apply permission
On Wed, Oct 19, 2011 at 9:44 PM, Robert Haas robertmh...@gmail.com wrote:
The original behavior, in 9.0, is that all outstanding WAL are
replicated to the standby when the master shuts down normally.
But ISTM the behavior was changed unexpectedly in 9.1. So
I think that it should be
On Wed, Oct 19, 2011 at 3:29 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Oct 19, 2011 at 9:45 PM, Robert Haas robertmh...@gmail.com wrote:
I don't really see any reason to break the monitoring view just
because we did some internal refactoring. I'd rather have backward
compatibility.
On Tue, Oct 18, 2011 at 6:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The chunks are sent indivisibly, because they are less than the pipe
buffer size. Read the pipe man page. It's guaranteed that the write
will either succeed or fail as a whole, not write a partial message.
If we cared to
On Oct19, 2011, at 17:47 , Greg Jaskiewicz wrote:
On 15 Oct 2011, at 11:31, Florian Pflug wrote:
Ok, here's a first cut.
So I looked at the patch, and first thing that pops out,
is lack of the volatile keyword before the ClientConnectionLostPending
variable is defined. Is that done on
On Thu, Oct 13, 2011 at 12:46 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
And, also I added regression test cases to detect these code paths,
because some of object types does not cover the case when it was
dropped.
These regression tests seem busted to me. First, I applied the part 2
patch.
On 19 Oct 2011, at 17:54, Florian Pflug wrote:
On Oct19, 2011, at 17:47 , Greg Jaskiewicz wrote:
On 15 Oct 2011, at 11:31, Florian Pflug wrote:
Ok, here's a first cut.
So I looked at the patch, and first thing that pops out,
is lack of the volatile keyword before the
On Wed, Oct 19, 2011 at 10:41 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Oct 19, 2011 at 9:44 PM, Robert Haas robertmh...@gmail.com wrote:
The original behavior, in 9.0, is that all outstanding WAL are
replicated to the standby when the master shuts down normally.
But ISTM the
Tom Lane t...@sss.pgh.pa.us wrote:
Unfortunately, the problem we're dealing with here is exactly that
we can't write to stderr. So it's a bit hard to see what we can
usefully do to report that we have a problem (short of crashing,
which isn't a net improvement).
Are you sure that crashing
Joachim Wieland j...@mcknight.de writes:
[ synchronized-snapshots patch ]
Looking through this code, it strikes me that SET TRANSACTION SNAPSHOT
is fundamentally incompatible with SERIALIZABLE READ ONLY DEFERRABLE
mode. That mode assumes that you should be able to just take a new
snapshot,
On 19.10.2011 19:17, Tom Lane wrote:
Joachim Wielandj...@mcknight.de writes:
[ synchronized-snapshots patch ]
Looking through this code, it strikes me that SET TRANSACTION SNAPSHOT
is fundamentally incompatible with SERIALIZABLE READ ONLY DEFERRABLE
mode. That mode assumes that you should
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Unfortunately, the problem we're dealing with here is exactly that
we can't write to stderr. So it's a bit hard to see what we can
usefully do to report that we have a problem (short of crashing,
which
On Oct19, 2011, at 18:05 , Greg Jaskiewicz wrote:
On 19 Oct 2011, at 17:54, Florian Pflug wrote:
On Oct19, 2011, at 17:47 , Greg Jaskiewicz wrote:
On 15 Oct 2011, at 11:31, Florian Pflug wrote:
Ok, here's a first cut.
So I looked at the patch, and first thing that pops out,
is lack of
On 15 Oct 2011, at 11:31, Florian Pflug wrote:
Ok, here's a first cut.
So I looked at the patch, and first thing that pops out,
is lack of the volatile keyword before the ClientConnectionLostPending variable
is defined. Is that done on purpose ? Is that on purpose ?
Otherwise the patch
On Thu, Oct 6, 2011 at 10:15 PM, gabrielle gor...@gmail.com wrote:
On Wed, Oct 5, 2011 at 5:14 PM, Marti Raudsepp ma...@juffo.org wrote:
I think you intended to use the Waiting on Author status -- that
leaves the commitfest entry open. I will re-open the commitfest entry
myself, I hope that's
On Oct19, 2011, at 18:17 , Tom Lane wrote:
Joachim Wieland j...@mcknight.de writes:
[ synchronized-snapshots patch ]
Looking through this code, it strikes me that SET TRANSACTION SNAPSHOT
is fundamentally incompatible with SERIALIZABLE READ ONLY DEFERRABLE
mode. That mode assumes that you
On 19 Oct 2011, at 18:28, Florian Pflug wrote:
All the other flags which indicate cancellation reasons are set from signal
handers, I believe. We could of course mark as ClientConnectionLostPending as
volatile just to be consistent. Not sure whether that's a good idea, or not.
It might
Is it really necessary for GetSerializableTransactionSnapshotInt to
acquire an empty SERIALIZABLEXACT before it acquires a snapshot?
If so, why? The proposed synchronized-snapshots feature will mean
that the allegedly-new snapshot actually was taken some time before,
so it seems to me that either
Florian Pflug f...@phlo.org writes:
On Oct19, 2011, at 18:17 , Tom Lane wrote:
AFAICS we should just throw an error if SET TRANSACTION SNAPSHOT is done
in a transaction with those properties. Has anyone got another
interpretation? Would it be better to silently ignore the DEFERRABLE
On Wed, Oct 19, 2011 at 7:35 AM, Marti Raudsepp ma...@juffo.org wrote:
This probably doesn't affect many real-world applications, but it
seems wrong that a performance feature can affect results returned by
a query.
Test case:
create table uniq (i int unique deferrable initially deferred);
On Wed, Oct 19, 2011 at 1:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
On Oct19, 2011, at 18:17 , Tom Lane wrote:
AFAICS we should just throw an error if SET TRANSACTION SNAPSHOT is done
in a transaction with those properties. Has anyone got another
On Wed, 2011-10-19 at 11:44 +0300, Peter Eisentraut wrote:
On tis, 2011-10-18 at 21:47 -0700, Jeff Davis wrote:
On Tue, 2011-10-18 at 22:25 +0300, Peter Eisentraut wrote:
Presumably because Jeff doesn't have that particular locale installed.
locale -a would clarify that.
$ locale -a
On Wed, 2011-10-19 at 10:10 -0700, Jeff Davis wrote:
dpkg-reconfigure locales
I had to manually do
# locale-gen tr_TR
to make it generate tr_TR.ISO-8859-9, and now it works.
I'm not sure what we should do, exactly, but I expect that others who
attempt to run the test on ubuntu (and maybe
Robert Haas robertmh...@gmail.com writes:
Yuck. Well, that's certainly a bug. What's weird is that I thought
we had put logic into the join removal code to ignore deferrable
constraints.
Yeah, I thought we had too.
regards, tom lane
--
Sent via pgsql-hackers
Tom Lane t...@sss.pgh.pa.us wrote:
Is it really necessary for GetSerializableTransactionSnapshotInt
to acquire an empty SERIALIZABLEXACT before it acquires a
snapshot? If so, why? The proposed synchronized-snapshots
feature will mean that the allegedly-new snapshot actually was
taken some
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
This allows a deferrable snapshot to be used on a second
connection (by e.g. pg_dump), and still be marked as DEFERRABLE.
If we throw an error unconditionally, the second
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
If the intent is that each serializable transaction sharing
the snapshot is a separate logical transaction, it *might* hold --
I think the rules have to be that the snapshot provided to a
serializable transaction must be provided by an active
Excerpts from David Fetter's message of lun oct 17 03:00:19 -0300 2011:
On Fri, Oct 14, 2011 at 07:36:32PM +0100, Peter Geoghegan wrote:
This evening, David Fetter described a problem to me that he was
having building the Twitter FDW. It transpired that it was down to its
dependence on an
On Oct19, 2011, at 19:49 , Kevin Grittner wrote:
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
This allows a deferrable snapshot to be used on a second
connection (by e.g. pg_dump), and still be marked as DEFERRABLE.
If we
Hackers,
We've just found an issue with pg_dumpall in 9.1.1 where a dump starts with
lines like these:
ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN
PASSWORD 'md5bdd7f8e73a214981b1519212b02a5530' VALID UNTIL 'infinity';
ALTER ROLE dude SET default_tablespace TO
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Is it really necessary for GetSerializableTransactionSnapshotInt
to acquire an empty SERIALIZABLEXACT before it acquires a
snapshot? If so, why? The proposed synchronized-snapshots
feature will mean that
Florian Pflug f...@phlo.org wrote:
Oh, cool. I thought the opt-out only works for explicitly
DEFERRABLE transactions.
Basically, if there is no serializable read-write transaction active
which overlaps the read-only transaction and also overlaps a
serializable transaction which wrote
On Wed, Oct 19, 2011 at 12:56:58PM -0400, Tom Lane wrote:
Is it really necessary for GetSerializableTransactionSnapshotInt to
acquire an empty SERIALIZABLEXACT before it acquires a snapshot?
If so, why?
*That* isn't necessary, no. It is necessary, however, to acquire the
snapshot while
Dan Ports d...@csail.mit.edu writes:
On Wed, Oct 19, 2011 at 12:56:58PM -0400, Tom Lane wrote:
The proposed synchronized-snapshots feature will mean
that the allegedly-new snapshot actually was taken some time before,
so it seems to me that either this is not necessary or we cannot use
a
David E. Wheeler da...@kineticode.com writes:
We've just found an issue with pg_dumpall in 9.1.1 where a dump starts with
lines like these:
ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN
PASSWORD 'md5bdd7f8e73a214981b1519212b02a5530' VALID UNTIL 'infinity';
On Oct 19, 2011, at 2:13 PM, Tom Lane wrote:
ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN
PASSWORD 'md5bdd7f8e73a214981b1519212b02a5530' VALID UNTIL 'infinity';
ALTER ROLE dude SET default_tablespace TO 'users';
I'm beginning to think that the correct
On Wed, Oct 19, 2011 at 04:36:41PM -0400, Tom Lane wrote:
No, the intention of the synchronized-snapshots feature is just to be
able to start multiple transactions using exactly the same snapshot.
They're independent after that. The aspect of it that is worrying me
is that if xact A starts,
Dan Ports d...@csail.mit.edu wrote:
the sxact's lastCommitBeforeSnapshot needs to match the snapshot,
SxactGlobalXmin needs to be set to the correct value, etc. That's
why the call to GetSnapshotData happens from where it does
Oh, right. I knew I was forgetting something. What if that was
On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
We've just found an issue with pg_dumpall in 9.1.1 where a dump starts with
lines like these:
ALTER ROLE dude WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN
On Wed, Oct 19, 2011 at 6:35 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/10/19 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Sun, Oct 16, 2011 at 4:46 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I tried to reproduce the scenario with enough small
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Dan Ports d...@csail.mit.edu wrote:
the sxact's lastCommitBeforeSnapshot needs to match the snapshot,
SxactGlobalXmin needs to be set to the correct value, etc. That's
why the call to GetSnapshotData happens from where it does
Oh, right. I
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Dan Ports d...@csail.mit.edu wrote:
the sxact's lastCommitBeforeSnapshot needs to match the
snapshot, SxactGlobalXmin needs to be set to the correct value,
etc. That's why the call to GetSnapshotData happens
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm beginning to think that the correct solution to these problems is to
greatly restrict what you can set in ALTER ROLE/DATABASE SET. Or at
least to document that if you use it, you
Robert Haas robertmh...@gmail.com writes:
Well, there's clearly some way to prevent pushdown from happening,
because sticking a LIMIT in there does the trick...
I already pointed you at subquery_is_pushdown_safe ...
regards, tom lane
--
Sent via pgsql-hackers mailing
On Wed, Oct 19, 2011 at 05:04:52PM -0400, Tom Lane wrote:
I wonder whether it would be prudent to set the synchronized-snapshots
patch aside until you've finished that work (assuming you're actively
working on it). It's evidently going to require some nontrivial changes
in predicate.c, and I
ProcessStandbyHSFeedbackMessage has a race condition: it thinks it can
call GetOldestXmin and then the result will politely hold still while
it considers what to do next. But in fact, whoever has the oldest xmin
could exit their transaction, allowing the global minimum to advance.
If a VACUUM
On Oct20, 2011, at 00:09 , Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm beginning to think that the correct solution to these problems is to
greatly restrict what you can set in ALTER ROLE/DATABASE SET. Or at
I think it would be fairly sensible to push some of this into
ProcArray, actually. The commit sequence numbers just involve assigning/
incrementing a global counter when taking a snapshot and finishing a
transaction -- that's not too much work, doesn't require any additional
locking beyond
Florian Pflug f...@phlo.org writes:
Taking this even further, why do we bother with non-immutable (i.e.,
depending on the database's contents) checks during ALTER ROLE/DATABASET SET
at all?
Yeah, I was wondering about that one too. It would not solve all the
problems here, but skipping
On Oct20, 2011, at 01:19 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
Taking this even further, why do we bother with non-immutable (i.e.,
depending on the database's contents) checks during ALTER ROLE/DATABASET SET
at all?
Yeah, I was wondering about that one too. It would not
I've recently gotten annoyed again by the sorry state of docbook
SGML support in macports, and finally decided to do something
about it (OK, the fact that I recently deleted my Ubuntu VM,
forgetting that one of the reasons I had it was to be able to
build our docs has something to do with it
On Mon, Sep 26, 2011 at 5:03 PM, Andreas Karlsson andr...@proxel.se wrote:
Magnus's patch for adding tab completion of views to the TABLE statement
reminded me of a minor annoyance of mine -- that EXECUTE always completes
with PROCEDURE as if it would have been part of CREATE TRIGGER ...
Josh Kupershmidt schmi...@gmail.com writes:
Incidentally, I was wondering what the heck was up with a clause like this:
else if (pg_strcasecmp(prev_wd, EXECUTE) == 0
pg_strcasecmp(prev2_wd, EXECUTE) == 0)
Hmm, maybe || was meant not ? It seems pretty unlikely that the
above
On Wed, Oct 19, 2011 at 10:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Kupershmidt schmi...@gmail.com writes:
Incidentally, I was wondering what the heck was up with a clause like this:
else if (pg_strcasecmp(prev_wd, EXECUTE) == 0
pg_strcasecmp(prev2_wd, EXECUTE) == 0)
On Thu, Oct 20, 2011 at 02:02:09AM +0200, Florian Pflug wrote:
I've patched the ports for openjade, iso8879 and docbook-dsssl,
and added a new port for docbook-sgml-4.2. These patches are sitting
in the macports trac now, waiting to be applied.
I'll try to take a look at them in the next
On Wed, Oct 19, 2011 at 3:30 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
part-1: only regression test of DROP [IF EXISTS] on unmodified master
Committed. Which I just noticed broke the build farm. Will go fix that now...
part-2: drop statement reworks that uses T_DropStmt
Committed with
On Wed, Oct 19, 2011 at 11:33 PM, Robert Haas robertmh...@gmail.com wrote:
Committed. Which I just noticed broke the build farm. Will go fix that
now...
Wow, that was a lot of pretty colors. Or not so pretty colors.
Seems to be turning green again now, so I'm going to bed. Will check
it
74 matches
Mail list logo
