On 17 October 2012 10:19, Markus Wanner wrote:
> On 10/17/2012 10:34 AM, Simon Riggs wrote:
>> IMHO an API is required for "give me the next allocation of numbers",
>> essentially a bulk equivalent of nextval().
>
> Agreed. That pretty exactly matches what I described (and what's
> implemented in
On 17 October 2012 11:21, Dimitri Fontaine wrote:
> Simon Riggs writes:
>> On 16 October 2012 15:15, Tom Lane wrote:
>>> What you really want is something vaguely like nextval but applied to
>>> a distinct type of object. That is, I think we first need a different
>>> kind of object called a "g
On 16 October 2012 16:56, Tom Lane wrote:
> Is anybody concerned about the compatibility implications of fixing this
> bug in the back branches? I'm worried about people complaining that we
> broke their application in a minor release. Maybe they were depending
> on incorrect behavior, but they
If OOM happens during expand_table() in hash_search_with_hash_value()
for RelationCacheInsert, the hash table entry is allocated and stored
in the hash table, but idhentry->reldesc remains NULL. Since OOM
causes AbortTransaction(), in AtEOXact_RelationCache() this NULL
pointer is referenced and we
On Oct 17, 2012, at 4:45 PM, Daniel Farina wrote:
> On Wed, Oct 17, 2012 at 1:12 PM, Josh Berkus wrote:
>> On 10/17/12 12:57 PM, Daniel Farina wrote:
>>> I'll have to register my disagreement then, in the special case where
>>> a feature becomes so obscure that many people don't have a wide-spre
Kevin Grittner wrote:
> Hmm. The comment is probably better now, but I've been re-checking
> the code, and I think my actual code change is completely wrong.
> Give me a bit to sort this out.
I'm having trouble seeing a way to make this work without rearranging
the code for concurrent drop to get
On Wednesday, October 17, 2012 9:38 PM Alvaro Herrera wrote:
> A week ago, I wrote:
>
> > Some numbers: we got 65 patches this time, of which we rejected 4 and
> > returned 3 with feedback. 14 patches have already been committed, and
> > 13 are waiting on their respective authors. 25 patches nee
Kevin Grittner wrote:
> It took me a while to spot it, but yeah -- I reversed the field
> names in the comment. :-( The email was right; I fixed the comment.
Hmm. The comment is probably better now, but I've been re-checking
the code, and I think my actual code change is completely wrong. Give
me
Tom Lane wrote:
> "Kevin Grittner" writes:
>> To put that another way, it should be done at a time when it is
>> sure that no query sees indisvalid = true and no query has yet
>> seen indisready = false. Patch attached. Will apply if nobody sees
>> a problem with it.
>
> The above statement of th
Hi Tomas,
On 2012/10/17, at 20:45, Tomas Vondra wrote:
>
> Dne 17.10.2012 12:34, Shigeru HANADA napsal:
>> Performance test
>>
>> I tested 1000 tables case (each is copy of pgbench_branches with 10
>> rows) on 1GB shared_buffers server. Please note that I tested on
>> MacBo
On Wed, Oct 17, 2012 at 5:43 PM, Alvaro Herrera
wrote:
> (I tested the new pg_dump with 8.2 and HEAD and also verified it passes
> pg_upgrade's "make check". I didn't test with other server versions.)
I also tested against 8.3 and 8.4 since 8.4 is the version that
introduced pg_get_function_iden
Ah. It's too late. I'll re-submit updated versions of my patches
left alone in the last CF.
> Hi, I've marked this patch as Returned with Feedback (thanks Tom).
> Please submit an updated version to the upcoming commitfest. Thanks.
I'm sorry and thank you.
--
Kyotaro Horiguchi
NTT Open Source
"Kevin Grittner" writes:
> To put that another way, it should be done at a time when it is sure
> that no query sees indisvalid = true and no query has yet seen
> indisready = false. Â Patch attached. Â Will apply if nobody sees a
> problem with it.
The above statement of the requirement doesn't
Josh Berkus writes:
> I would tend to say "well, they're not hurting anyone, why not keep
> them?" Except that we're gathering an increasing number of features
> (RETURNING, FDWs, CTEs, Command triggers) which don't work well together
> with RULEs.
Really? On what do you base that claim? The on
On Wed, Oct 17, 2012 at 3:24 PM, Josh Berkus wrote:
> Daniel,
>
>> Unfortunately I myself see little evidence of the vast, vast --
>> several nines of vast -- majority of folks using rules, and as I said:
>> as a thought experiment, merely one solved bug is worth more to me
>> than rules from what
I wrote:
> So this is essentially an oversight in the patch that added tracking of
> nullable_relids. I got confused about the difference between
> outerjoin_delayed (this clause, as a whole, is not outerjoin_delayed
> because its natural semantic level would be at the join anyway) and
> having no
On 17 October 2012 23:24, Josh Berkus wrote:
> I fact, I'll go further and say that I believe we will be deprecating
> RULEs eventually. It's merely a question of how long that will take and
> what we need to document, announce and implement before then.
>
> I would tend to say "well, they're no
Kevin Grittner wrote:
> Simon Riggs wrote:
>> On 6 October 2012 00:56, Tom Lane wrote:
>
>>> 2. DROP INDEX CONCURRENTLY doesn't bother to do
>>> TransferPredicateLocksToHeapRelation until long after it's
>>> invalidated the index. Surely that's no good? Is it even possible
>>> to do that correct
Daniel,
> Unfortunately I myself see little evidence of the vast, vast --
> several nines of vast -- majority of folks using rules, and as I said:
> as a thought experiment, merely one solved bug is worth more to me
> than rules from what I know at this time.
Again, the answer to this is to run
On Wed, Oct 17, 2012 at 5:45 PM, Daniel Farina wrote:
> retort -- which is true, Heroku's user base is not provably
> representative of all users. But what else is there to go on, besides
> experiences of others, such as yours and Andrew's, or others?
Well, Heroku doesn't support Slony + Londist
On Wed, Oct 17, 2012 at 1:12 PM, Josh Berkus wrote:
> On 10/17/12 12:57 PM, Daniel Farina wrote:
>> I'll have to register my disagreement then, in the special case where
>> a feature becomes so obscure that many people don't have a wide-spread
>> intuition at what it's good at or used for. Tom al
Joel Jacobson wrote:
> On Thu, Jul 5, 2012 at 10:33 PM, Tom Lane wrote:
>
> > You may in fact need a new field --- I'm just saying it should be in the
> > object-type-specific struct, eg FuncInfo, not DumpableObject.
>
>
> I suggest adding char *funcsig to FuncInfo, and moving the "funcsig =
>
On Wed, Oct 17, 2012 at 4:25 PM, Josh Berkus wrote:
>
>> It is not meant to be a full implementation of application level queuing
>> system though but just the capture, persisting and distribution parts
>>
>> Using this as an "application level queue" needs a set of interface
>> functions to extra
On Tue, Oct 16, 2012 at 11:56:52AM -0400, Tom Lane wrote:
> Is anybody concerned about the compatibility implications of fixing this
> bug in the back branches? I'm worried about people complaining that we
> broke their application in a minor release. Maybe they were depending
> on incorrect beha
Simon Riggs wrote:
> On 6 October 2012 00:56, Tom Lane wrote:
>> 2. DROP INDEX CONCURRENTLY doesn't bother to do
>> TransferPredicateLocksToHeapRelation until long after it's
>> invalidated the index. Surely that's no good? Is it even possible
>> to do that correctly, when we don't have a lock t
> It is not meant to be a full implementation of application level queuing
> system though but just the capture, persisting and distribution parts
>
> Using this as an "application level queue" needs a set of interface
> functions to extract the events and also to keep track of the processed
> ev
On 10/17/12 12:57 PM, Daniel Farina wrote:
> I'll have to register my disagreement then, in the special case where
> a feature becomes so obscure that many people don't have a wide-spread
> intuition at what it's good at or used for. Tom also said "build the
> replacement," and without itemization
Kohei KaiGai escribió:
> 2012/10/5 Alvaro Herrera :
> The attached patch fixes the messaging issue.
> I newly add func_signature_string_oid() that returns compatible function's
> signature, but takes its object-id.
>
> So, the error message is now constructed as:
> + case OBJECT_AGGREGATE:
> You and Josh seem to be strong proponents of rules for reasons other
> than "I just don't want to break applications". That's not too many
> to ask both of you: can you itemize your use cases and how important
> you feel they are?
Well, my main issue is actually that I don't want to break peop
On Wed, Oct 17, 2012 at 12:43 PM, Andrew Dunstan wrote:
>
> On 10/17/2012 03:06 PM, Daniel Farina wrote:
>>
>> On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan
>> wrote:
>
> Triggers necessarily operate on a row-at-a-time basis. In theory,
> for at least some bulk operations, a rule
On 10/17/2012 03:06 PM, Daniel Farina wrote:
On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan wrote:
Triggers necessarily operate on a row-at-a-time basis. In theory,
for at least some bulk operations, a rule could greatly outperform
a trigger. It's difficult to walk away from that - unless
On 10/17/2012 11:32 AM, Josh Berkus wrote:
I am not sure where to stick it but we should also include the fact that
rules are almost always slower that a trigger/function comparative.
That wouldn't be accurate, actually.
Let me add: when used with partitioning. I should have been more exp
On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan wrote:
>>> Triggers necessarily operate on a row-at-a-time basis. In theory,
>>> for at least some bulk operations, a rule could greatly outperform
>>> a trigger. It's difficult to walk away from that - unless somebody
>>> can prove that the advan
On 10/17/12 10:46 AM, Greg Stark wrote:
Warning: RULES are tricky to use correctly. They rewrite the original
query into a new query before it is run and it is very hard to
correctly anticipate and rewrite every possible input query into the
desired result. There are also unexpected interactions
Well, replication is arguably a relevant case.
For Slony, the origin/master node never cares about logged changes - that
data is only processed on replicas. Now, that's certainly a little
weaselly - the log data (sl_log_*) has got to get read to get to the
replica.
This suggests, nonetheless, a
On 17 October 2012 18:46, Greg Stark wrote:
> I would suggest something like
>
> Warning: RULES are tricky to use correctly. They rewrite the original
> query into a new query before it is run and it is very hard to
> correctly anticipate and rewrite every possible input query into the
> desired
On 10/17/12 2:31 AM, Dimitri Fontaine wrote:
Then if you insist on comparing to a macro facility, as we're talking
about dynamic code rewriting, maybe we need to compare RULEs to the lisp
style macro facility, which is nothing like a pre-processor facility (in
lisp, that's the reader, I think).
> I am not sure where to stick it but we should also include the fact that
> rules are almost always slower that a trigger/function comparative.
That wouldn't be accurate, actually.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hack
On 10/17/2012 10:46 AM, Greg Stark wrote:
I dislike both of the explanations above which don't actually explain
why people shouldn't use rules (Josh does say they're tricky which is
a start). Just telling people we hate parts of the system doesn't
really come off well and leaves them wondering
Greg Stark writes:
> I dislike both of the explanations above which don't actually explain
> why people shouldn't use rules (Josh does say they're tricky which is
> a start). Just telling people we hate parts of the system doesn't
> really come off well and leaves them wondering why.
Agreed. I t
Greg,
> Warning: RULES are tricky to use correctly. They rewrite the original
> query into a new query before it is run and it is very hard to
> correctly anticipate and rewrite every possible input query into the
> desired result. There are also unexpected interactions with other
> components whe
On 17 October 2012 18:46, Greg Stark wrote:
> I would suggest something like
>
> Warning: RULES are tricky to use correctly. They rewrite the original
> query into a new query before it is run and it is very hard to
> correctly anticipate and rewrite every possible input query into the
> desired r
On 17 October 2012 18:50, Andrew Dunstan wrote:
> I don't know how many times I have to say this: people are not listening.
> Tom has already given a case for it upthread:
>
>
>>> Triggers necessarily operate on a row-at-a-time basis. In theory,
>>> for at least some bulk operations, a rule could
On 10/12/12, Josh Berkus wrote:
> I realize you weren't around when we removed row OIDs, but I was *still*
> getting flack from that in 2008. And we lost entire OSS projects to
> other databases because of removing row OIDs. And those were marked
> deprecated for 3 years before we removed them.
On 10/17/2012 01:02 PM, Joshua D. Drake wrote:
On 10/17/2012 02:48 AM, Simon Riggs wrote:
Would you or someone else be able to come up with some words of
caution for us to put in the manual that would be helpful to
developers?
There isn't even a list of caveats for rules.
I think we need t
I dislike both of the explanations above which don't actually explain
why people shouldn't use rules (Josh does say they're tricky which is
a start). Just telling people we hate parts of the system doesn't
really come off well and leaves them wondering why.
I would suggest something like
Warning:
All,
For the record, I like RULEs and would prefer if someone fixed the
issues with them instead of deprecating them. However, I also
acknowledge that that is unlikely to happen.
> Would you or someone else be able to come up with some words of
> caution for us to put in the manual that would be
Kyotaro HORIGUCHI wrote:
> Hello, sorry for long absense,
>
> # I had unexpected and urgent time-consuming tasks... :-(
>
> I have had a bit more precise inspection by two aspects, and they
> seemd showing that the difference should be the execution time of
> ExecProject.
>
> I'll be able to ba
On 10/17/2012 11:31 AM, Dimitri Fontaine wrote:
Peter Geoghegan writes:
Clearly deprecating rules implies some loss of functionality - there
is no exact, drop-in equivalent to something that magically rewrites
SQL that isn't equally baroque and problematic.
Maybe we can upgrade STATEMENT trigg
At 2012-10-17 09:19:58 -0400, and...@dunslane.net wrote:
>
> This doesn't appear to correct any ambiguity, nor any grammatical
> error.
FWIW, it's quite standard and uncontroversial "good writing" advice to
push "only" as far right as it can go. It does correct an ambiguity,
but in this case the a
On Wed, Oct 17, 2012 at 11:26 AM, Hannu Krosing wrote:
> The simplest usage would be implementing "remote log tables" that is
> tables, where you do INSERT on the master side, but it "inserts" only
> a logical WAL record and nothing else.
>
> On subscriber side your replay process reads this WAL r
Kyotaro HORIGUCHI wrote:
> Hello, I will propose reduce palloc's in numeric operations.
>
> The numeric operations are slow by nature, but usually it is not
> a problem for on-disk operations. Altough the slowdown is
> enhanced on on-memory operations.
>
> I inspcted them and found some very shor
On Wed, Oct 17, 2012 at 9:29 AM, Peter Geoghegan wrote:
> On 17 October 2012 14:53, Merlin Moncure wrote:
>> Is that defined in the standard?
>
> RETURNING isn't even defined in the standard.
Right: Point being, assumptions based on implementation ordering are
generally to be avoided unless they
On 17 October 2012 18:02, Joshua D. Drake wrote:
> Note: Do not use, use Triggers with Functions instead
Agreed, something simple is required. I suggest expanding that just a little...
"Rules are a non-SQL Standard feature and where possible we recommend
that you write your applications using
On 10/17/2012 02:48 AM, Simon Riggs wrote:
Would you or someone else be able to come up with some words of
caution for us to put in the manual that would be helpful to
developers?
There isn't even a list of caveats for rules.
I think we need the inverse. Some documentation on why to use rule
On Wednesday 17 October 2012, you wrote:
> "P. Christeas" writes:
> > It has been a fact that the RETURNING clause on an INSERT will return
> > multiple rows with the same order as multiple VALUES have been fed.
>
> I don't believe this is a good idea in the slightest. Yeah, the current
> impleme
Alvaro Herrera escribió:
> Here's the final version. I think this is ready to go in.
Committed.
There are several uses of SHM_QUEUE in the backend code which AFAICS can
be replaced with dlist. If someone's looking for an easy project,
here's one.
--
Álvaro Herrerahttp://www.2n
A week ago, I wrote:
> Some numbers: we got 65 patches this time, of which we rejected 4 and
> returned 3 with feedback. 14 patches have already been committed, and
> 13 are waiting on their respective authors. 25 patches need review, and
> 6 are said to be ready for committers.
A week later, n
Hitoshi Harada escribió:
> Patch does not apply cleanly against latest master. outfuncs.c,
> allpath.c and cost.h have rejected parts. The make check failed in a
> lot of cases up to 26 out of 133. I didn't look into each issue but I
> suggest rebasing on the latest master and making sure the r
On 17 October 2012 14:53, Merlin Moncure wrote:
> Is that defined in the standard?
RETURNING isn't even defined in the standard.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hack
"P. Christeas" writes:
> It has been a fact that the RETURNING clause on an INSERT will return
> multiple rows with the same order as multiple VALUES have been fed.
> eg: INSERT INTO tbl1(code) VALUES ('abc'), ('def'), ('agh')
>RETURNING id, code;
> is expected to yield:
>id | co
On Wed, Oct 17, 2012 at 7:38 AM, P. Christeas wrote:
> It has been a fact that the RETURNING clause on an INSERT will return
> multiple rows with the same order as multiple VALUES have been fed.
Is that defined in the standard?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
Laurent Laborde writes:
> Friendly greetings !
> There is a change between 9.1 and 9.2 that doesn't seems to be in the
> changelog :
> http://www.postgresql.org/docs/9.2/static/runtime-config-client.html#GUC-TIMEZONE
> http://www.postgresql.org/docs/9.1/static/runtime-config-client.html#GUC-TIMEZO
On 10/16/2012 11:24 PM, Karl O. Pinc wrote:
Hi,
As long as I'm sending in trivial fixes
to the docs here's a bit of wording that's been bugging me.
In a number of places the docs read "only relevant",
this patch reverses this to read "relevant only".
I believe this reads better because it qui
On Wednesday, October 17, 2012 5:16 PM Amit Kapila wrote:
> > On Monday, October 15, 2012 3:43 PM Heikki Linnakangas wrote:
> > On 13.10.2012 19:35, Fujii Masao wrote:
> > > On Thu, Oct 11, 2012 at 11:52 PM, Heikki Linnakangas
> > > wrote:
> > >> Ok, thanks. Committed.
> > >
> > > I found one typ
It has been a fact that the RETURNING clause on an INSERT will return
multiple rows with the same order as multiple VALUES have been fed.
eg: INSERT INTO tbl1(code) VALUES ('abc'), ('def'), ('agh')
RETURNING id, code;
is expected to yield:
id | code
---
1 | abc
2 |
> On Monday, October 15, 2012 3:43 PM Heikki Linnakangas wrote:
> On 13.10.2012 19:35, Fujii Masao wrote:
> > On Thu, Oct 11, 2012 at 11:52 PM, Heikki Linnakangas
> > wrote:
> >> Ok, thanks. Committed.
> >
> > I found one typo. The attached patch fixes that typo.
>
> Thanks, fixed.
>
> > ISTM y
Hi,
thanks for the review. I'll look into that in ~2 weeks, once the
pgconf.eu
is over. A few comments in the text below.
Dne 17.10.2012 12:34, Shigeru HANADA napsal:
Performance test
I tested 1000 tables case (each is copy of pgbench_branches with
10
rows) on 1GB share
On Wednesday, October 17, 2012 3:09 PM chinnaobi wrote:
> Hey Amitkapila,
>
> Thank you for the quick reply.
>
> How can implement this patch in windows, because I am using windows
> 9.1.1
> postgreSQL application ??
>
If the patch serves the feature you require, then once it gets committed
(th
Hi Tomas,
Sorry to be late.
On Sat, Aug 25, 2012 at 7:36 AM, Tomas Vondra wrote:
> attached is a patch that improves performance when dropping multiple
> tables within a transaction. Instead of scanning the shared buffers for
> each table separately, the patch removes this and evicts all the tab
On 10/17/2012 12:03 AM, Josh Berkus wrote:
Hannu,
Can you explain in more detail how this would be used on the receiving
side? I'm unable to picture it from your description.
It would be used similar to how the event tables in pgQ (from skytools)
is used - as a source of "events" to be replied
Simon Riggs writes:
> On 16 October 2012 15:15, Tom Lane wrote:
>> What you really want is something vaguely like nextval but applied to
>> a distinct type of object. That is, I think we first need a different
>> kind of object called a "global sequence" with its own DDL operations.
>>
> hence a
On 12 October 2012 10:08, Daniel Farina wrote:
> On Thu, Oct 11, 2012 at 11:55 PM, Simon Riggs wrote:
>> As regards cost/benefit analysis, this is a low importance feature,
>> but then that is why I proposed a low effort fix that is flexible to
>> the needs of users affected.
>
> Is there any fea
Hey Amitkapila,
Thank you for the quick reply.
How can implement this patch in windows, because I am using windows 9.1.1
postgreSQL application ??
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/How-to-avoid-base-backup-in-automated-failover-tp5711147p5728562.html
Se
Peter Geoghegan writes:
> Clearly deprecating rules implies some loss of functionality - there
> is no exact, drop-in equivalent to something that magically rewrites
> SQL that isn't equally baroque and problematic. If that's the bar,
> then detractors of rules should stop wasting their breath, be
Simon,
On 10/17/2012 10:34 AM, Simon Riggs wrote:
> IMHO an API is required for "give me the next allocation of numbers",
> essentially a bulk equivalent of nextval().
Agreed. That pretty exactly matches what I described (and what's
implemented in Postgres-R). The API then only needs to be called
On 17 October 2012 09:10, Markus Wanner wrote:
> Simon,
>
> On 10/16/2012 02:36 PM, Simon Riggs wrote:
>> Where else would you put the hook? The hook's location as described
>> won't change whether you decide you want 1, 2 or 3.
>
> You assume we want an API that supports all three options. In tha
Tom,
On 10/16/2012 06:15 PM, Tom Lane wrote:
> I challenge you to find anything in the SQL standard that suggests that
> sequences have any nonlocal behavior. If anything, what you propose
> violates the standard, it doesn't make us follow it more closely.
If you look at a distributed database a
Simon,
On 10/16/2012 02:36 PM, Simon Riggs wrote:
> Where else would you put the hook? The hook's location as described
> won't change whether you decide you want 1, 2 or 3.
You assume we want an API that supports all three options. In that case,
yes, the hooks need to be very general.
Given tha
79 matches
Mail list logo
