On 16 October 2012 23:03, Josh Berkus j...@agliodbs.com wrote:
Can you explain in more detail how this would be used on the receiving
side? I'm unable to picture it from your description.
This will allow implementation of pgq in core, as discussed many times
at cluster hackers meetings.
I'm
On Wednesday, October 17, 2012 11:22 AM chinnaobi wrote:
Hey Haas,
What does the standby server have to wait for replication to catch up
before
promoting ?? Is there any parameter to configure this ??
Few more questions on this part
1. How could we ensure the standby has received all
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 that
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 as
On 17 October 2012 09:10, Markus Wanner mar...@bluegap.ch 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
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
Peter Geoghegan pe...@2ndquadrant.com 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
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
On 12 October 2012 10:08, Daniel Farina dan...@heroku.com wrote:
On Thu, Oct 11, 2012 at 11:55 PM, Simon Riggs si...@2ndquadrant.com 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
Simon Riggs si...@2ndquadrant.com writes:
On 16 October 2012 15:15, Tom Lane t...@sss.pgh.pa.us 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
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
Hi Tomas,
Sorry to be late.
On Sat, Aug 25, 2012 at 7:36 AM, Tomas Vondra t...@fuzzy.cz 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
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
(there are
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
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
hlinnakan...@vmware.com wrote:
Ok, thanks. Committed.
I found one typo. The attached patch fixes that typo.
Thanks, fixed.
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
hlinnakan...@vmware.com wrote:
Ok, thanks. Committed.
I found one
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
Laurent Laborde kerdez...@gmail.com 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
On Wed, Oct 17, 2012 at 7:38 AM, P. Christeas x...@linux.gr 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
P. Christeas x...@linux.gr 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:
On 17 October 2012 14:53, Merlin Moncure mmonc...@gmail.com 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
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
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,
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 Herrera
On Wednesday 17 October 2012, you wrote:
P. Christeas x...@linux.gr 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
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
On 17 October 2012 18:02, Joshua D. Drake j...@commandprompt.com wrote:
Note: Do not use, use Triggers with Functions instead link
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
On Wed, Oct 17, 2012 at 9:29 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 17 October 2012 14:53, Merlin Moncure mmonc...@gmail.com wrote:
Is that defined in the standard?
RETURNING isn't even defined in the standard.
Right: Point being, assumptions based on implementation ordering are
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 short term
On Wed, Oct 17, 2012 at 11:26 AM, Hannu Krosing ha...@2ndquadrant.com 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
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
On 10/17/2012 11:31 AM, Dimitri Fontaine wrote:
Peter Geoghegan pe...@2ndquadrant.com 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
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 back fully
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
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
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
On 10/12/12, Josh Berkus j...@agliodbs.com 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
On 17 October 2012 18:50, Andrew Dunstan and...@dunslane.net 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
On 17 October 2012 18:46, Greg Stark st...@mit.edu 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
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 when
Greg Stark st...@mit.edu 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.
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
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
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).
On 17 October 2012 18:46, Greg Stark st...@mit.edu 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
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 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
On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan and...@dunslane.net 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
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
On 10/17/2012 03:06 PM, Daniel Farina wrote:
On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan and...@dunslane.net 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
On Wed, Oct 17, 2012 at 12:43 PM, Andrew Dunstan and...@dunslane.net wrote:
On 10/17/2012 03:06 PM, Daniel Farina wrote:
On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan and...@dunslane.net
wrote:
Triggers necessarily operate on a row-at-a-time basis. In theory,
for at least some bulk
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 people's
Kohei KaiGai escribió:
2012/10/5 Alvaro Herrera alvhe...@2ndquadrant.com:
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
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 of
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
events.
Simon Riggs wrote:
On 6 October 2012 00:56, Tom Lane t...@sss.pgh.pa.us 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
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
On Wed, Oct 17, 2012 at 4:25 PM, Josh Berkus j...@agliodbs.com 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
Joel Jacobson wrote:
On Thu, Jul 5, 2012 at 10:33 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Oct 17, 2012 at 1:12 PM, Josh Berkus j...@agliodbs.com 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
On Wed, Oct 17, 2012 at 5:45 PM, Daniel Farina dan...@heroku.com 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
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 an
Kevin Grittner wrote:
Simon Riggs wrote:
On 6 October 2012 00:56, Tom Lane t...@sss.pgh.pa.us 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
On 17 October 2012 23:24, Josh Berkus j...@agliodbs.com 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
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
On Wed, Oct 17, 2012 at 3:24 PM, Josh Berkus j...@agliodbs.com 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
Josh Berkus j...@agliodbs.com 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
Kevin Grittner kgri...@mail.com 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
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
On Wed, Oct 17, 2012 at 5:43 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
Hi Tomas,
On 2012/10/17, at 20:45, Tomas Vondra t...@fuzzy.cz 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
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
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 need
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 to
On Oct 17, 2012, at 4:45 PM, Daniel Farina wrote:
On Wed, Oct 17, 2012 at 1:12 PM, Josh Berkus j...@agliodbs.com 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
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
76 matches
Mail list logo
