2013-11-28 00:17 keltezéssel, Tom Lane írta:
Peter Eisentraut pete...@gmx.net writes:
On 11/27/13, 3:47 PM, Tom Lane wrote:
Given these considerations, I think it'd be better to allow explicit
application control over whether read-ahead happens for a particular
query. And I have no problem
On Thu, Nov 28, 2013 at 09:04:17AM +0100, Boszormenyi Zoltan wrote:
Well, technically, unspecified means NO SCROLL according to the SQL
standard. A lot of applications in ECPG are ported from other systems,
That means by automatically adding a literal NO SCROLL to the command we obey
standard,
On Wed, Nov 27, 2013 at 09:22:50PM -0500, Bruce Momjian wrote:
Well, I can understand that, but part of the argument was that
default_transaction_read_only is not part of the database, but rather
just the transaction default:
Karsten wrote:
Maybe I am splitting hairs but setting
2013-11-28 09:55 keltezéssel, Michael Meskes írta:
On Thu, Nov 28, 2013 at 09:04:17AM +0100, Boszormenyi Zoltan wrote:
Well, technically, unspecified means NO SCROLL according to the SQL
standard. A lot of applications in ECPG are ported from other systems,
That means by automatically adding
Hi,
On 2013-11-24 16:56:26 -0500, J Smith wrote:
coredumper worked like a charm. Useful tool, that is... although as a
bit of advice, I'd try not to run it on Postgres if your various
memory settings are tweaked towards production use -- the core dump
that was captured on my server weighed in
Tom Lane t...@sss.pgh.pa.us writes:
I'm not real sure what this'd buy us that wouldn't be done as well or
better by creating a view on the remote side. (IOW, there's nothing
that says that the remote object backing a foreign table can't be a
view.)
Agreed, for those remote sides that know
I wrote:
I wrote:
Kyotaro HORIGUCHI wrote:
* In get_relation_info(), the patch determines the branch
condition keyattno != ObjectIdAttributeNumber. I fail to
understand the meaning of this branch condition. Could you explain
about it?
Literally answering, it means oid cannot
On 27 November 2013 10:35 Fujii Masao wrote:
On Wed, Nov 27, 2013 at 1:27 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 26 November 2013 23:11 Fujii Masao wrote:
On Wed, Nov 20, 2013 at 7:43 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
I tried using of stat'ing in two
On Wed, Nov 27, 2013 at 11:22 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Nov 27, 2013 at 11:04 AM, Sawada Masahiko sawada.m...@gmail.com
wrote:
Thank you for feedback.
I attached the v4 patch which have modified. Just name changed to
'wal_log_hintbtis'.
Few typos in this
On Wed, Nov 27, 2013 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
We could still do this if we were willing to actually reject requests
for session level locks on fast-path-eligible lock types. At the moment
that costs us nothing really. If anyone ever did have a use case, we
Robert Haas escribió:
On Wed, Nov 6, 2013 at 9:40 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Noah Misch wrote:
Incomplete list:
- If smgrDoPendingDeletes() finds files to delete, mdunlink() and its
callee
relpathbackend() call palloc(); this is true in all supported
Hello,
Investigating corruption in a client's database we unfortunately found
another data corrupting bug that's relevant for 9.3+:
Since 9.3 heap_tuple_needs_freeze() and heap_freeze_tuple() don't
correctly handle the xids contained in a multixact. They separately do a
check for their
Robert Haas robertmh...@gmail.com writes:
In terms of making this more robust, one idea - along the lines you
mentioned in your original post - is to have a separate code path for
the case where we're releasing *all* locks.
Yeah, I thought seriously about that, but concluded that it was too
On 2013-11-28 10:31:21 -0500, Tom Lane wrote:
The only remaining risk is that, if pointer
fetch/store isn't atomic, we might fetch a half-updated pointer; which
will be non-null, but not something we can use to reach the list. Since
we do purport to support such architectures, we'd better
On Thu, Nov 28, 2013 at 10:20:53AM +0100, Karsten Hilbert wrote:
Is it that statement_timeout is less likely to lead to a restore failure?
That seems right -- default_read_only WILL fail the
restore while stmt_timeout CAN.
Or rather:
One of the *legitimate* settings of read_only WILL
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-28 10:31:21 -0500, Tom Lane wrote:
The only remaining risk is that, if pointer
fetch/store isn't atomic, we might fetch a half-updated pointer; which
will be non-null, but not something we can use to reach the list. Since
we do purport
In case it has gone unnoticed: The buidlfarm has gone red across the board.
http://buildfarm.postgresql.org/cgi-bin/show_status.pl
(and sure enough I can't build either...)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Erik Rijkers e...@xs4all.nl writes:
In case it has gone unnoticed: The buidlfarm has gone red across the board.
http://buildfarm.postgresql.org/cgi-bin/show_status.pl
It wasn't red when I looked an hour ago, so evidently one of Alvaro's
recent commits is at fault.
On 2013-11-28 16:28:53 +0100, Andres Freund wrote:
My current thoughts are that we need to check whether any member of a
multixact needs freezing. If we find one we do MultiXactIdIsRunning()
MultiXactIdWait() if!InRecovery. That's pretty unlikely to be necessary,
but afaics we cannot guarntee
Andres Freund wrote:
Instead of calculating the multixact cutoff xid by using the global
minimum of OldestMemberMXactId[] and OldestVisibleMXactId[] and then
subtracting vacuum_freeze_min_age compute it solely as the minimum of
OldestMemberMXactId[]. If we do that computation *after* doing
On 2013-11-28 14:10:43 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
Instead of calculating the multixact cutoff xid by using the global
minimum of OldestMemberMXactId[] and OldestVisibleMXactId[] and then
subtracting vacuum_freeze_min_age compute it solely as the minimum of
While debugging the recent fastpath lock unpleasantness, I noticed that
the code tends to use only the last few entries in the fpRelId[] arrays,
which seemed a bit surprising. The reason of course is the way that
FastPathGrantRelationLock() is written: it remembers the *last* unused
slot while
On Fri, Nov 29, 2013 at 12:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
While debugging the recent fastpath lock unpleasantness, I noticed that
the code tends to use only the last few entries in the fpRelId[] arrays,
which seemed a bit surprising. The reason of course is the way that
Atri Sharma atri.j...@gmail.com writes:
On Fri, Nov 29, 2013 at 12:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
We could add an extra test in FastPathGrantRelationLock's loop to make
it remember the first unused slot rather than the last one, but that
would add some cycles there, partially
On Thu, Nov 28, 2013 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
While debugging the recent fastpath lock unpleasantness, I noticed that
the code tends to use only the last few entries in the fpRelId[] arrays,
which seemed a bit surprising. The reason of course is the way that
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 28, 2013 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We could add an extra test in FastPathGrantRelationLock's loop to make
it remember the first unused slot rather than the last one, but that
would add some cycles there, partially
On Thu, Nov 28, 2013 at 2:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I did think about instituting a rule that all valid entries must be
consecutive at the front, but it's far from clear that the extra logic
needed to maintain that invariant would cost less than what's saved.
FWIW, I considered
On Thu, Nov 28, 2013 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 28, 2013 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We could add an extra test in FastPathGrantRelationLock's loop to make
it remember the first unused slot rather than
On Thu, Nov 28, 2013 at 10:10 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Robert Haas escribió:
On Wed, Nov 6, 2013 at 9:40 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Noah Misch wrote:
Incomplete list:
- If smgrDoPendingDeletes() finds files to delete, mdunlink() and its
I wrote:
Daniel Wood dw...@salesforce.com writes:
Does the original version of my stress test not repro the problem on 9.2?
[ tries it ... ] No, it doesn't, or at least the MTBF is a couple orders
of magnitude better than on 9.3.
Oh, of course: the reason the test doesn't fail as given on
Robert Haas robertmh...@gmail.com writes:
But I don't think it'll hurt anything. If you can prove that it
actually helps something, I'll buy you a glass of wine. :-)
FWIW, I did try benchmarking this using pgbench -S -c 10 -M prepared.
If there's any difference, it's below the noise floor.
On Thu, Nov 28, 2013 at 3:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
But I don't think it'll hurt anything. If you can prove that it
actually helps something, I'll buy you a glass of wine. :-)
FWIW, I did try benchmarking this using pgbench -S -c 10
On Tue, Nov 26, 2013 at 2:08 PM, Peter Eisentraut pete...@gmx.net wrote:
Now for the linestyles. I can see how some of them are attractive, but
several of them have poor aesthetics, I think. I don't see a reason to
accept 7 new styles just for fun. If I had to choose, I'd consider
-double1
On Wed, Nov 27, 2013 at 9:31 AM, Amit Kapila amit.kapil...@gmail.com wrote:
Sure, but to explore (a), the scope is bit bigger. We have below
options to explore (a):
1. try to optimize existing algorithm as used in patch, which we have
tried but ofcourse we can spend some more time to see if
Robert Haas escribió:
On Tue, Nov 26, 2013 at 2:08 PM, Peter Eisentraut pete...@gmx.net wrote:
Now for the linestyles. I can see how some of them are attractive, but
several of them have poor aesthetics, I think. I don't see a reason to
accept 7 new styles just for fun. If I had to
On Wed, Nov 27, 2013 at 4:44 PM, Bruce Momjian br...@momjian.us wrote:
Seems broadly reasonable, but I'd use no other effect throughout.
That sounds awkward, e.g.:
Issuing commandROLLBACK/ outside of a transaction
block emits a warning but has no other effect.
I could live with
On Thu, Nov 28, 2013 at 4:48 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Robert Haas escribió:
On Tue, Nov 26, 2013 at 2:08 PM, Peter Eisentraut pete...@gmx.net wrote:
Now for the linestyles. I can see how some of them are attractive, but
several of them have poor aesthetics, I
On Wed, Nov 27, 2013 at 4:33 PM, Bruce Momjian br...@momjian.us wrote:
On Sat, Jan 12, 2013 at 02:14:03PM -0500, Kevin Grittner wrote:
Amit Kapila wrote:
On Thursday, January 10, 2013 6:09 AM Josh Berkus wrote:
Surely VACUUM FULL should rebuild the visibility map, and make
tuples in the
On Thu, Nov 28, 2013 at 04:51:14PM -0500, Robert Haas wrote:
On Wed, Nov 27, 2013 at 4:44 PM, Bruce Momjian br...@momjian.us wrote:
Seems broadly reasonable, but I'd use no other effect throughout.
That sounds awkward, e.g.:
Issuing commandROLLBACK/ outside of a transaction
On Nov 28, 2013, at 5:18 PM, Bruce Momjian br...@momjian.us wrote:
On Thu, Nov 28, 2013 at 04:51:14PM -0500, Robert Haas wrote:
On Wed, Nov 27, 2013 at 4:44 PM, Bruce Momjian br...@momjian.us wrote:
Seems broadly reasonable, but I'd use no other effect throughout.
That sounds awkward, e.g.:
On Thu, Nov 28, 2013 at 05:17:07PM -0500, Robert Haas wrote:
I need to know this is the right approach, and need to know what things
are wrong or missing.
The fact that you've needed to modify SetHintBits() to make this work
is pretty nasty. I'm not exactly sure what to do about that, but
On Thu, Nov 28, 2013 at 10:39:18AM -0500, Bruce Momjian wrote:
Well, then we are actually using two different reasons for patching
pg_dumpall and not pg_dump. Your reason is based on the probability of
failure, while Tom/Kevin's reason is that default_transaction_read_only
might be used to
Hi,
I decided to look into how much work implementing the todo item about
supporting amgettuple in GIN would be, since exclusion constraints on
GIN would be neat. Robert Haas suggested a solution[1], but to fix it we
also need to look into why the commit message mentions that it did not
work
On Wed, Nov 27, 2013 at 5:42 PM, Andres Freund and...@2ndquadrant.com wrote:
So, I've done this for 9.3+ for now. Testing around that turned up that
our current way to schedule anti mxid wraparounds doesn't really work:
1) autovacuum.c knows about such vacuums, but vacuum.c doesn't. Leading
to
On 2013-11-28 19:23:29 -0500, Robert Haas wrote:
On Wed, Nov 27, 2013 at 5:42 PM, Andres Freund and...@2ndquadrant.com wrote:
So, I've done this for 9.3+ for now. Testing around that turned up that
our current way to schedule anti mxid wraparounds doesn't really work:
1) autovacuum.c knows
On Thu, 2013-11-28 at 16:23 -0500, Robert Haas wrote:
On Tue, Nov 26, 2013 at 2:08 PM, Peter Eisentraut pete...@gmx.net
wrote:
Now for the linestyles. I can see how some of them are attractive,
but
several of them have poor aesthetics, I think. I don't see a reason
to
accept 7 new
On Thu, 2013-11-28 at 18:48 -0300, Alvaro Herrera wrote:
An output style that emits
DocBook markup for tables, something which we could paste on the docs.
DocBook supports HTML tables from version 4.3 on. We currently use
version 4.2, but we could presumably raise that if needed.
--
Sent
On Thu, Nov 14, 2013 at 8:46 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-11-12 18:50:33 +0100, Andres Freund wrote:
You've actually changed the meaning of this section (and not in a good
way):
be set at server start. varnamewal_level/ must be set
-to
On Mon, 2013-11-25 at 16:32 +0100, Magnus Hagander wrote:
Thanks for the reminder - done (installed the DEB from sid, version
1.78.1).
This will somehow show up in the snapshot builds, correct? So we
(you? :P) can verify after the next snapshots that it's correct?
After in-depth inspection,
Robert Haas wrote
Issuing
command
ROLLBACK
/
outside of a transaction
block has the sole effect of emitting a warning.
Sure, that sounds OK.
...Robert
+1 for:
Issuing commandROLLBACK/ outside of a transaction
block has no effect except emitting a warning.
In all of
On Wed, 2013-11-27 at 18:17 -0500, Tom Lane wrote:
Hm. So you're suggesting that ECPG fix this problem by inserting an
explicit NO SCROLL clause into translated DECLARE CURSOR commands, if
there's not a SCROLL clause?
I wouldn't go that far yet.
Do I understand this right that the future
Andres Freund escribió:
Patch 02 has changed its shape slightly since the version I posted here,
because it's a prerequisite for the fix for the multixact bugs around
heap_freeze_tuple() and heap_tuple_needs_freeze() I've written about
nearby. I think Alvaro plans to work over my fixes to
David Johnston wrote:
In all of these cases we are assuming that the user understands that
emitting a warning means that something is being logged to disk and thus is
causing a resource drain.
I like explicitly saying that issuing these commands is pointless/has no
effect; being indirect
On Thu, Nov 28, 2013 at 12:11 PM, Rajeev rastogi
rajeev.rast...@huawei.com wrote:
On 28 November 2013, Amit Kapila Wrote:
Further Review of this patch:
b. why to display 'First log segment after reset' in 'Currrent
pg_control values' section as now the same information
is available in
On 29 November 2013, Amit Kapila Wrote:
Further Review of this patch:
b. why to display 'First log segment after reset' in 'Currrent
pg_control values' section as now the same information
is available in new section Values to be used after reset: ?
May not be always. Suppose
On Thu, Nov 28, 2013 at 11:04 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
David Johnston wrote:
In all of these cases we are assuming that the user understands that
emitting a warning means that something is being logged to disk and thus is
causing a resource drain.
I like explicitly
2013-11-29 04:56 keltezéssel, Peter Eisentraut írta:
On Wed, 2013-11-27 at 18:17 -0500, Tom Lane wrote:
Hm. So you're suggesting that ECPG fix this problem by inserting an
explicit NO SCROLL clause into translated DECLARE CURSOR commands, if
there's not a SCROLL clause?
I wouldn't go that far
On Tue, Nov 26, 2013 at 7:26 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 25 November 2013 10:43 Amit Kapila wrote:
On Fri, Nov 22, 2013 at 12:12 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 19 November 2013 10:33 Amit Kapila wrote:
If I understood correctly, then your
On Fri, Nov 29, 2013 at 10:00 AM, Rajeev rastogi
rajeev.rast...@huawei.com wrote:
On 29 November 2013, Amit Kapila Wrote:
Further Review of this patch:
I have done few more cosmetic changes in your patch, please find the
updated patch attached with this mail.
Kindly check once whether
On 29 November 2013, Amit Kapila Wrote:
Further Review of this patch:
I have done few more cosmetic changes in your patch, please find the
updated patch attached with this mail.
Kindly check once whether changes are okay.
Changes are fine. Thanks you.
I have uploaded the latest
2013/11/28 Robert Haas robertmh...@gmail.com
On Tue, Nov 26, 2013 at 2:08 PM, Peter Eisentraut pete...@gmx.net wrote:
Now for the linestyles. I can see how some of them are attractive, but
several of them have poor aesthetics, I think. I don't see a reason to
accept 7 new styles just for
2013/11/28 Alvaro Herrera alvhe...@2ndquadrant.com
Robert Haas escribió:
On Tue, Nov 26, 2013 at 2:08 PM, Peter Eisentraut pete...@gmx.net
wrote:
Now for the linestyles. I can see how some of them are attractive, but
several of them have poor aesthetics, I think. I don't see a reason
Hi Royes,
I'm sorry for my late review...
I feel potential of your patch in PG replication function, and it might be
something useful for all people. I check your patch and have some comment for
improvement. I haven't executed detail of unexpected sutuation yet. But I think
that under
63 matches
Mail list logo
