On 12 October 2012 00:45, Peter Geoghegan wrote:
> On 11 October 2012 20:28, Simon Riggs wrote:
>> Not many RULE-lovers out there, once you've tried to use them.
>>
>> Allowing RULEs complicates various things and can make security more
>> difficult.
>
> What exactly do they make more difficult?
On 12 October 2012 01:52, Andrew Dunstan wrote:
> I'm with Tom and Josh and Daniel on this, and to be honest I'm somewhat
> surprised at the willingness of some people to spring surprises on users.
I've never caused nor argued in favour of hardcoded changes that catch users.
This would be a doc
On 11 October 2012 23:59, Josh Berkus wrote:
>
>> With the DDL trigger, we're able to do that faster. The idea is you
>> can still delete it if you need compatibility, so we get the message
>> across without an extra release and without an annoying GUC (etc).
>
> You're seeing these things as bugs
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Amit Kapila
> Sent: Wednesday, October 10, 2012 7:57 PM
> To: 'Heikki Linnakangas'
> Cc: 'PostgreSQL-development'
> Subject: Re: [HACKERS] Switching timeline over st
I'm making some changes to a program that, among other things, reports
tup_fetched/tup_returned as if it were a cache hit rate, analogous to
blks_hit/blks_fetched.
The documentation didn't help me to understand if that was appropriate,
so I looked at the source and asked on IRC. It seems I'm not t
Thanks for looking at this.
Attached is a rebased patch using new OIDs.
On 11 October 2012 02:39, Peter Eisentraut wrote:
> Compiler warning needs to be fixed:
>
> rewriteHandler.c: In function 'RewriteQuery':
> rewriteHandler.c:2153:29: error: 'view_rte' may be used uninitialized in this
> func
What's the deal with the line type?
It's installed in the catalogs and listed in the documentation,
varyingly as not implemented or not fully implemented, but all the
support functions throw an error. Is there any known list of things
that would need to be done to make it fully implemented? Or s
Josh Berkus wrote:
For 9.3, I suggest we create a DDL trigger by default which prevents
RULEs and throws an ERROR that explains they are now deprecated.
Well, even if we were considering this, the sequence would need to be:
1. Announce in 9.3 that RULES will be going away RSN.
2. In 9.4, send
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Andrew Dunstan
> Sent: Thursday, October 11, 2012 8:52 PM
> To: Daniel Farina
> Cc: Joshua D. Drake; Josh Berkus; Simon Riggs;
pgsql-hackers@postgresql.org
> Subject:
FWIW I thought the stuff in commit 092d7ded2 might be pretty useful
generally.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom and Simon wrote:
>> If you want to get rid of rules, build the
>> replacement; don't just try to be a pain in the ass to users.
> Supporting broken and non-standard features *is* a pain in the ass to
> users, since they are sometimes persua
On 10/11/2012 08:20 PM, Daniel Farina wrote:
On Thu, Oct 11, 2012 at 5:07 PM, Joshua D. Drake wrote:
On 10/11/2012 03:59 PM, Josh Berkus wrote:
I'm also not real keen on the idea that someone could dump a 9.2
database and be unable to load it into 9.3 because of the DDL trigger,
especially i
On Thu, Oct 11, 2012 at 5:07 PM, Joshua D. Drake wrote:
>
> On 10/11/2012 03:59 PM, Josh Berkus wrote:
>
>> I'm also not real keen on the idea that someone could dump a 9.2
>> database and be unable to load it into 9.3 because of the DDL trigger,
>> especially if they might not encounter it until
On 10/11/2012 03:59 PM, Josh Berkus wrote:
I'm also not real keen on the idea that someone could dump a 9.2
database and be unable to load it into 9.3 because of the DDL trigger,
especially if they might not encounter it until halfway through a
restore. That seems rather user-hostile to me.
A
On 11 October 2012 20:28, Simon Riggs wrote:
> Not many RULE-lovers out there, once you've tried to use them.
>
> Allowing RULEs complicates various things and can make security more
> difficult.
What exactly do they make more difficult? Are you particularly
concerned with the overhead that rule
On Thu, Oct 11, 2012 at 3:59 PM, Josh Berkus wrote:
>
>> With the DDL trigger, we're able to do that faster. The idea is you
>> can still delete it if you need compatibility, so we get the message
>> across without an extra release and without an annoying GUC (etc).
>
> You're seeing these things
On 10/11/2012 04:06 PM, Tom Lane wrote:
> Yeah, if we decide to stick with the limitation, some documentation
> would be called for. I remember having run into this and having removed
> functionality from an rm_desc function rather than question the premise.
> But maybe the extra functionality is
Markus Wanner writes:
> On 10/11/2012 03:11 PM, Tom Lane wrote:
>> The original design intention was that rm_desc should not attempt to
>> print any such data, but obviously some folks didn't get the word.
> FWIW: in case the source code contains comments explaining that
> intention, I certainly
> With the DDL trigger, we're able to do that faster. The idea is you
> can still delete it if you need compatibility, so we get the message
> across without an extra release and without an annoying GUC (etc).
You're seeing these things as bugs. I see them as features. And we
don't need a GUC i
On 12-10-11 06:27 PM, Josh Berkus wrote:
On 10/10/12 7:26 PM, Bruce Momjian wrote:
How does Slony write its changes without causing serialization replay
conflicts?
Since nobody from the Slony team answered this:
a) Slony replicates *rows*, not *statements*
True, but the proposed logical repl
>> For 9.3, I suggest we create a DDL trigger by default which prevents
>> RULEs and throws an ERROR that explains they are now deprecated.
Well, even if we were considering this, the sequence would need to be:
1. Announce in 9.3 that RULES will be going away RSN.
2. In 9.4, send a warning every
On Thu, Oct 11, 2012 at 3:39 PM, Simon Riggs wrote:
> On 11 October 2012 23:28, Josh Berkus wrote:
>>
For 9.3, I suggest we create a DDL trigger by default which prevents
RULEs and throws an ERROR that explains they are now deprecated.
>>
>> Well, even if we were considering this, the s
On 11 October 2012 03:16, Greg Stark wrote:
> On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane wrote:
>>> I think I've mentioned it before, but in the interest of not being
>>> seen to critique the bikeshed only after it's been painted: this
>>> design gives up something very important that exists in ou
On Wed, Oct 10, 2012 at 10:26 PM, Bruce Momjian wrote:
> How does Slony write its changes without causing serialization replay
> conflicts?
It uses a sequence to break any ordering conflicts at the time that
data is inserted into its log tables.
If there are two transactions, A and B, that were
Tom,
On 10/11/2012 03:11 PM, Tom Lane wrote:
> The original design intention was that rm_desc should not attempt to
> print any such data, but obviously some folks didn't get the word.
FWIW: in case the source code contains comments explaining that
intention, I certainly missed them so far.
Rega
On 11 October 2012 23:28, Josh Berkus wrote:
>
>>> For 9.3, I suggest we create a DDL trigger by default which prevents
>>> RULEs and throws an ERROR that explains they are now deprecated.
>
> Well, even if we were considering this, the sequence would need to be:
>
> 1. Announce in 9.3 that RULES
On Thu, Oct 11, 2012 at 6:25 PM, Simon Riggs wrote:
> Anyway, lets start with a discussion of what rules give us that SQL
> standard features do not?
The somewhat broader question that this elicits is "How would we go
about deprecating a feature that seems to be troublesome?" I think
Josh Berkus
On 10/10/12 7:26 PM, Bruce Momjian wrote:
> How does Slony write its changes without causing serialization replay
> conflicts?
Since nobody from the Slony team answered this:
a) Slony replicates *rows*, not *statements*
b) Slony uses serializable mode internally for row replication
c) it's possib
On 11 October 2012 20:50, Tom Lane wrote:
> Simon Riggs writes:
>> Not many RULE-lovers out there, once you've tried to use them.
>> Allowing RULEs complicates various things and can make security more
>> difficult.
>
>> For 9.3, I suggest we create a DDL trigger by default which prevents
>> RUL
On 10/10/12 9:37 PM, Aaron Sheldon wrote:
> I have begun sketching these ideas in off the shelf pgSQL using composite
> types and constructor functions; but am far from tackling anything like
> building external C extensions to handle the data types. I can set-up a
> GitHub repository if anyone is
Markus Wanner writes:
> I stumbled across a minor issue in xlog.c:1030: the WAL_DEBUG code block
> there passes rdata->data to the rm_desc() methode. However, that's only
> the first XLogRecData struct, not the entire XLog record. So the
> rm_desc() method effectively reports spurious data for any
I wrote:
> What I'm thinking about is modifying eval_const_expressions so that
> one of its responsibilities is to force CoercionForm fields to
> COERCE_DONTCARE in the output;
I fooled around with that approach for awhile and didn't like the
results, mainly because it caused EXPLAIN output to cha
Tom Lane writes:
> This is utter nonsense. We can't deprecate them until we have a
> substitute that is better. If you want to get rid of rules, build the
> replacement; don't just try to be a pain in the ass to users.
My understanding is that the main reason why RULEs are bad™ is that they
wil
Hi,
I stumbled across a minor issue in xlog.c:1030: the WAL_DEBUG code block
there passes rdata->data to the rm_desc() methode. However, that's only
the first XLogRecData struct, not the entire XLog record. So the
rm_desc() method effectively reports spurious data for any subsequent part.
Take a
Simon Riggs writes:
> Not many RULE-lovers out there, once you've tried to use them.
> Allowing RULEs complicates various things and can make security more
> difficult.
> For 9.3, I suggest we create a DDL trigger by default which prevents
> RULEs and throws an ERROR that explains they are now d
On 11 October 2012 20:43, Tom Lane wrote:
> Robert Haas writes:
>> So we have to take the snapshot before you begin execution, but it
>> seems that to avoid surprising behavior we also have to take it after
>> acquiring locks. And it looks like locking is intertwined with a
>> bunch of other par
Robert Haas writes:
> So we have to take the snapshot before you begin execution, but it
> seems that to avoid surprising behavior we also have to take it after
> acquiring locks. And it looks like locking is intertwined with a
> bunch of other parse analysis tasks that might require a snapshot t
On 11 October 2012 20:30, Robert Haas wrote:
> On Thu, Oct 11, 2012 at 2:42 PM, Andrew Dunstan wrote:
>> I have a quietish few days starting on Saturday, will be looking at this
>> then. Is it only the Windows aspect that needs reviewing? Are we more or
>> less happy with the rest?
>
> I think th
On 11 October 2012 20:25, Robert Haas wrote:
> On Thu, Oct 11, 2012 at 2:48 PM, Simon Riggs wrote:
>> Hmm, so now the patch author thinks his patch is not just broken with
>> respect to lock waits, but in all cases? Surely the above race
>> condition is obvious, now and before. Why is it suddenly
On Thu, Oct 11, 2012 at 2:42 PM, Andrew Dunstan wrote:
> I have a quietish few days starting on Saturday, will be looking at this
> then. Is it only the Windows aspect that needs reviewing? Are we more or
> less happy with the rest?
I think the Windows issues were the biggest thing, but I suspect
Not many RULE-lovers out there, once you've tried to use them.
Allowing RULEs complicates various things and can make security more difficult.
For 9.3, I suggest we create a DDL trigger by default which prevents
RULEs and throws an ERROR that explains they are now deprecated.
Anybody that really
On Thu, Oct 11, 2012 at 2:48 PM, Simon Riggs wrote:
> Hmm, so now the patch author thinks his patch is not just broken with
> respect to lock waits, but in all cases? Surely the above race
> condition is obvious, now and before. Why is it suddenly unacceptable?
> (If you believe that, why on earth
On 11 October 2012 19:59, Robert Haas wrote:
> On Wed, Oct 10, 2012 at 3:32 AM, Simon Riggs wrote:
>> 2) Clearly, rollout scripts benefit from not throwing errors.
>> Personally I would prefer setting SET ddl_abort_on_missing_object =
>> false; at the top of a script than having to go through eve
I looked into the complaint in bug #7598,
http://archives.postgresql.org/pgsql-bugs/2012-10/msg00090.php
The core of the problem is in an inner sub-select that's written
like
outercol IN (SELECT varcharcol FROM ... WHERE varcharcol = anothercol ...
The "=" operator is actually texteq, since varch
On Wed, Oct 10, 2012 at 3:32 AM, Simon Riggs wrote:
> 2) Clearly, rollout scripts benefit from not throwing errors.
> Personally I would prefer setting SET ddl_abort_on_missing_object =
> false; at the top of a script than having to go through every SQL
> statement and add extra syntax. That might
On 11 October 2012 19:41, Tom Lane wrote:
> Simon Riggs writes:
>> On 11 October 2012 18:22, Tom Lane wrote:
>>> If it worked, I might be amenable to that, but it doesn't. You can't
>>> trigger taking a new snapshot off whether we waited for a lock; that
>>> still has race conditions, just ones
On 11 October 2012 19:36, Robert Haas wrote:
> On Thu, Oct 11, 2012 at 2:23 PM, Simon Riggs wrote:
>> So where's the race?
>>
>> AFAICS it either waits or it doesn't - the code isn't vague on that
>> point. If we wait we set the flag.
>>
>> The point is that lock waits are pretty rare since most
On 10/11/2012 02:22 PM, Magnus Hagander wrote:
On Wed, Oct 10, 2012 at 6:17 PM, Alvaro Herrera
wrote:
Tom Lane wrote:
Alvaro Herrera writes:
IIRC, the parallel pg_dump one is said to need review by a Windows
expert, which is not me, so I've not looked at it.
Andrew? Magnus?
There's, unfor
Simon Riggs writes:
> On 11 October 2012 18:22, Tom Lane wrote:
>> If it worked, I might be amenable to that, but it doesn't. You can't
>> trigger taking a new snapshot off whether we waited for a lock; that
>> still has race conditions, just ones that are not so trivial to
>> demonstrate manual
On Thu, Oct 11, 2012 at 2:23 PM, Simon Riggs wrote:
> So where's the race?
>
> AFAICS it either waits or it doesn't - the code isn't vague on that
> point. If we wait we set the flag.
>
> The point is that lock waits are pretty rare since most locks are
> compatible, so triggering a second snap if
On 11 October 2012 18:22, Tom Lane wrote:
>> I suggested a way to automatically trigger a second snapshot. I think
>> that would be acceptable to backpatch.
>
> If it worked, I might be amenable to that, but it doesn't. You can't
> trigger taking a new snapshot off whether we waited for a lock;
On Wed, Oct 10, 2012 at 6:17 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Alvaro Herrera writes:
>> IIRC, the parallel pg_dump one is said to need review by a Windows
>> expert, which is not me, so I've not looked at it.
>
> Andrew? Magnus?
There's, unfortunately, not a chance I'll have a tim
> For starters, the use-case hasn't been explained to my satisfaction.
> In what situation is it actually helpful to TRUNCATE a table that's
> not there yet? Aren't you going to have to do a CREATE IF NOT EXISTS
> to keep from failing later in the script? If so, why not just do that
> first?
The
Simon Riggs writes:
> On 11 October 2012 17:53, Tom Lane wrote:
>> Maybe what we really need is to find a way to make taking a snapshot a
>> lot cheaper, such that the whole need for this patch goes away. We're
>> not going to get far with the idea of making SnapshotNow MVCC-safe
>> unless it be
On 11 October 2012 17:53, Tom Lane wrote:
> Simon Riggs writes:
>> On 11 October 2012 01:43, Tom Lane wrote:
>>> I think we have to revert and go back to the drawing board on this.
>
>> Given that change was also sold on the basis of higher performance, I
>> suggest we retest performance to chec
On 10 October 2012 14:56, Pavel Stehule wrote:
> (eelog3.diff)
This looks better.
You need a better comment here:
+ * relerror.c
+ * relation error loging functions
+ *
I'm still not satisfied with the lack of firm guarantees about what
errcodes one can assume these fields will be avai
Simon Riggs writes:
> On 11 October 2012 01:43, Tom Lane wrote:
>> I think we have to revert and go back to the drawing board on this.
> Given that change was also sold on the basis of higher performance, I
> suggest we retest performance to check there is a gain. If there is
> still a gain, I s
On 10/11/2012 09:05 AM, Peter Eisentraut wrote:
The flex and bison make rules refactoring I just did broke the Windows
build. I think the fixes should look like the patch below. Could
someone please verify and/or commit that?
Close, but not quite. I have made it work and committed it.
chee
On Thursday, October 11, 2012 03:27:17 PM Andres Freund wrote:
> On Thursday, October 11, 2012 03:23:12 PM Alvaro Herrera wrote:
> > Alvaro Herrera escribió:
> > > I also included two new functions in that patch, dlisti_push_head and
> > > dlisti_push_tail. These functions are identical to dlist_p
Andres Freund wrote:
> On Friday, August 31, 2012 06:59:51 AM Alvaro Herrera wrote:
> > v21 is merged to latest master.
> Ok, I am starting to look at this.
>
> (working with a git merge of alvherre/fklocks into todays master)
>
> In a very first pass as somebody who hasn't followed the discussio
On Thursday, October 11, 2012 8:22 PM Heikki Linnakangas wrote:
On 11.10.2012 13:17, Amit Kapila wrote:
>>> How does this look now?
>
>> The Patch is fine and test results are also fine.
>Ok, thanks. Committed.
Thank you very much.
With Regards,
Amit Kapila.
--
Sent via pgsql-hackers maili
On Friday, August 31, 2012 06:59:51 AM Alvaro Herrera wrote:
> v21 is merged to latest master.
Ok, I am starting to look at this.
(working with a git merge of alvherre/fklocks into todays master)
In a very first pass as somebody who hasn't followed the discussions in the
past I took notice of th
On 11.10.2012 13:17, Amit Kapila wrote:
How does this look now?
The Patch is fine and test results are also fine.
Ok, thanks. Committed.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/p
On Thursday, October 11, 2012 03:23:12 PM Alvaro Herrera wrote:
> Alvaro Herrera escribió:
> > I also included two new functions in that patch, dlisti_push_head and
> > dlisti_push_tail. These functions are identical to dlist_push_head and
> > dlist_push_tail, except that they do not accept non-ci
Alvaro Herrera escribió:
> I also included two new functions in that patch, dlisti_push_head and
> dlisti_push_tail. These functions are identical to dlist_push_head and
> dlist_push_tail, except that they do not accept non-circular lists.
> What this means is that callers that find the non-circu
The flex and bison make rules refactoring I just did broke the Windows
build. I think the fixes should look like the patch below. Could
someone please verify and/or commit that?
diff --git a/src/tools/msvc/pgbison.pl b/src/tools/msvc/pgbison.pl
index d6f2444..15db921 100644
--- a/src/tools/msvc/
On Thursday, October 11, 2012 09:15:47 AM Heikki Linnakangas wrote:
> On 22.09.2012 20:00, Andres Freund wrote:
> > [[basic-schema]]
> > .Architecture Schema
> > ["ditaa"]
> > -
> > -
> >
> > Traditional Stuff
> >
On Wed, Oct 10, 2012 at 12:19:17PM -0300, Alvaro Herrera wrote:
> Many of those patches waiting on authors have been in such state for a
> rather long time. I feel inclined to mark them "returned with
> feedback", and have them posted again for the next commitfest.
+1
--
Sent via pgsql-hackers
2012/10/11 Dimitri Fontaine :
> Heikki Linnakangas writes:
>> I've wanted to allow writing i/o functions in non-C languages for a long
>> time as well, but never got around to do anything about it. Custom datatypes
>> are really powerful, but as soon as you have to write C code, that raises
>> the
On Tue, Oct 02, 2012 at 01:58:40PM -0400, Noah Misch wrote:
> > > On Mon, Aug 27, 2012 at 7:43 PM, Tom Lane wrote:
> > >> There's also the big-picture question of whether we should just get rid
> > >> of fuzzy comparisons in the geometric types instead of trying to hack
> > >> indexes to work arou
Do you intend to follow through with this, Jeff?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
Heikki Linnakangas writes:
> I've wanted to allow writing i/o functions in non-C languages for a long
> time as well, but never got around to do anything about it. Custom datatypes
> are really powerful, but as soon as you have to write C code, that raises
> the bar significantly. I/O functions wr
On Wednesday, October 10, 2012 9:15 PM Heikki Linnakangas wrote:
> On 04.10.2012 13:12, Amit kapila wrote:
> > Following changes are done to support replication timeout in sender as
> well as receiver:
> >
> > 1. One new configuration parameter wal_receiver_timeout is added to
> detect timeout at
On 10/09/2012 04:06 PM, Tom Lane wrote:
> Second, to my mind the point of a multi-table TRUNCATE is to ensure that
> all the referenced tables get reset to empty *together*. With something
> like this, you'd have no such guarantee. Consider a timeline like this:
>
> Session 1
On 10/09/2012 10:04 PM, Robert Haas wrote:
>> - if a table is not yet or no more visible, because of search_path
>> modification
>
> I don't think I understand the case you are describing here.
Here's a sample :
begin;
set search_path = foo, public;
create table c ( … ) ;
commit;
begin;
set
Heikki Linnakangas writes:
> Now that we support include-directories in postgresql.conf, you could put a
> "mylib.conf" file in the include directory that contains the above line, if
> you want to enable/disable a module just by moving things around in the
> filesystem (after configuring an includ
Hi Hanada-san,
> Please examine attached v2 patch (note that is should be applied onto
> latest dblink_fdw_validator patch).
I've reviewed your patch quickly. I noticed that the patch has been created in
a slightly different way from the guidelines:
http://www.postgresql.org/docs/devel/static/fd
On 11 October 2012 01:43, Tom Lane wrote:
> I think we have to revert and go back to the drawing board on this.
Given that change was also sold on the basis of higher performance, I
suggest we retest performance to check there is a gain. If there is
still a gain, I suggest we add this as a SIGHU
On 10/11/2012 03:10 AM, Robert Haas wrote:
On Wed, Oct 10, 2012 at 7:02 PM, Peter Geoghegan wrote:
The purpose of ApplyCache/transaction reassembly is to reassemble
interlaced records, and organise them by XID, so that the consumer
client code sees only streams (well, lists) of records split by
On 10/11/2012 04:31 AM, Tom Lane wrote:
Greg Stark writes:
On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane wrote:
Isn't there an even more serious problem, namely that this assumes
*all* transactions are serializable? What happens when they aren't?
Or even just that the effective commit order is n
On 22.09.2012 20:00, Andres Freund wrote:
[[basic-schema]]
.Architecture Schema
["ditaa"]
--
Traditional Stuff
+-+-+-+-++
| Backend | Backend | Backend | Autovac | ...|
81 matches
Mail list logo
