On Wed, Oct 19, 2011 at 11:33 PM, Robert Haas 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 again in the morning.
On Wed, Oct 19, 2011 at 3:30 PM, Kohei KaiGai 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 some changes.
> part
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 cou
On Wed, Oct 19, 2011 at 10:40 PM, Tom Lane wrote:
> Josh Kupershmidt 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 mean
Josh Kupershmidt 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 test wo
On Mon, Sep 26, 2011 at 5:03 PM, Andreas Karlsson 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 ... EXECUTE
> even when
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 also..
On Oct20, 2011, at 01:19 , Tom Lane wrote:
> Florian Pflug 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 a
Florian Pflug 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 validity checks w
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 ProcArra
On Oct20, 2011, at 00:09 , Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane 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
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 proc
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
Robert Haas 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 list (pgsql-hackers@
Robert Haas writes:
> On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane 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 get to keep both pieces after
>>
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Dan Ports 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
"Kevin Grittner" writes:
> Dan Ports 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. W
On Wed, Oct 19, 2011 at 6:35 AM, Kohei KaiGai wrote:
> 2011/10/19 Tom Lane :
>> Robert Haas writes:
>>> On Sun, Oct 16, 2011 at 4:46 AM, Kohei KaiGai wrote:
I tried to reproduce the scenario with enough small
from/join_collapse_limit
(typically 1), but it allows to push down qual
On Wed, Oct 19, 2011 at 5:13 PM, Tom Lane wrote:
> "David E. Wheeler" 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 'md5bdd7f8e73a214981b1519
Dan Ports 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
captured as par
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
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
"David E. Wheeler" 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';
> ALTER ROLE dud
Dan Ports 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 synchronized s
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 Seri
Florian Pflug 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 something and commi
"Kevin Grittner" writes:
> Tom Lane 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
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
On Oct19, 2011, at 19:49 , Kevin Grittner wrote:
> Robert Haas wrote:
>> Tom Lane wrote:
>>> Florian Pflug 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
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
"Kevin Grittner" 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 serializable
transactio
Robert Haas wrote:
> Tom Lane wrote:
>> Florian Pflug 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 connection has
>>> to import the snapshot without
Tom Lane 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 time before,
Robert Haas 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 mailing list (pgsql-hacke
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 de
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.
> >
> >
On Wed, Oct 19, 2011 at 1:02 PM, Tom Lane wrote:
> Florian Pflug 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
On Wed, Oct 19, 2011 at 7:35 AM, Marti Raudsepp 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);
> begin;
Florian Pflug 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
>> property?
>
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
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
On Oct19, 2011, at 18:17 , Tom Lane wrote:
> Joachim Wieland 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
On Thu, Oct 6, 2011 at 10:15 PM, gabrielle wrote:
> On Wed, Oct 5, 2011 at 5:14 PM, Marti Raudsepp 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 OK.
>
> No worries, and
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 i
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 po
"Kevin Grittner" writes:
> Tom Lane 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 s
On 19.10.2011 19:17, Tom Lane wrote:
Joachim Wieland 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 ta
Joachim Wieland 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, repeatedly, until yo
Tom Lane 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 on an assertio
On Wed, Oct 19, 2011 at 10:41 AM, Fujii Masao wrote:
> On Wed, Oct 19, 2011 at 9:44 PM, Robert Haas 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.
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 Clie
On Thu, Oct 13, 2011 at 12:46 PM, Kohei KaiGai 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. The regression t
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 d
On Tue, Oct 18, 2011 at 6:01 PM, Tom Lane 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 retry a failure, t
On Wed, Oct 19, 2011 at 3:29 PM, Fujii Masao wrote:
> On Wed, Oct 19, 2011 at 9:45 PM, Robert Haas 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 does
On Wed, Oct 19, 2011 at 9:44 PM, Robert Haas 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 back-patched to 9.1 to r
On Wed, Oct 19, 2011 at 6:18 AM, Kohei KaiGai wrote:
> 2011/10/18 Robert Haas :
>>> 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
>>
>
On Wed, Oct 19, 2011 at 9:45 PM, Robert Haas 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 description
of pg_stat
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 n
On Wed, Oct 19, 2011 at 8:43 AM, Dickson S. Guedes wrote:
> 2011/10/19 Fujii Masao :
>> On Tue, Oct 18, 2011 at 10:18 PM, Simon Riggs wrote:
>>> Any reason or objection to committing this patch?
>>
>> The checkpointer doesn't call pgstat_send_bgwriter(), but it should.
>> Otherwise, some entries
On Wed, Oct 19, 2011 at 2:31 AM, Fujii Masao 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 occur. I can
>
2011/10/19 Fujii Masao :
> On Tue, Oct 18, 2011 at 10:18 PM, Simon Riggs 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.
Yes, checkpoints_req,
On Wed, Oct 19, 2011 at 3:31 PM, Fujii Masao 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.
>
> I think th
2011/10/18 Simon Riggs :
> On Wed, Oct 5, 2011 at 8:02 AM, Simon Riggs wrote:
>> On Wed, Oct 5, 2011 at 5:10 AM, Dickson S. Guedes
>> wrote:
>>
>>> Ah ok! I started reviewing the v4 patch version, this is my comments:
>>
>> ...
>>
>>> Well, all the tests was running with the default postgresql.c
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: deferra
2011/10/19 Tom Lane :
> Robert Haas writes:
>> On Sun, Oct 16, 2011 at 4:46 AM, Kohei KaiGai 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 least scan
>>> plan.
>
>> Hmm, you're right. LIM
On Tue, Oct 18, 2011 at 10:18 PM, Simon Riggs 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 is performed by check
2011/10/18 Robert Haas :
>> 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 function has 10 arg
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
On ons, 2011-10-19 at 01:10 -0400, Tom Lane wrote:
> Jeff Davis 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
> > tr
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
On 19 October 2011 05:50, Peter Eisentraut 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 the sam
> 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
73 matches
Mail list logo
