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 followi
2013/11/28 Alvaro Herrera
> Robert Haas escribió:
> > On Tue, Nov 26, 2013 at 2:08 PM, Peter Eisentraut
> 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 j
2013/11/28 Robert Haas
> On Tue, Nov 26, 2013 at 2:08 PM, Peter Eisentraut 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
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 h
On Fri, Nov 29, 2013 at 10:00 AM, Rajeev rastogi
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 changes are oka
On Tue, Nov 26, 2013 at 7:26 PM, Haribabu kommi
wrote:
> On 25 November 2013 10:43 Amit Kapila wrote:
>> On Fri, Nov 22, 2013 at 12:12 PM, Haribabu kommi
>> wrote:
>> > On 19 November 2013 10:33 Amit Kapila wrote:
>> >> If I understood correctly, then your patch's main intention is to
>> >> corre
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 Thu, Nov 28, 2013 at 11:04 PM, Alvaro Herrera
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 saying that
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:" ?
> >> >
> >>
On Thu, Nov 28, 2013 at 12:11 PM, Rajeev rastogi
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 new sect
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 ind
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
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 r
Robert Haas wrote
>>
>> Issuing
>
> ROLLBACK
>
> outside of a transaction
>> block has the sole effect of emitting a warning.
>
> Sure, that sounds OK.
>
> ...Robert
+1 for:
Issuing ROLLBACK outside of a transaction
block has no effect except emitting a warning.
In all of these
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 inspect
On Thu, Nov 14, 2013 at 8:46 AM, Andres Freund 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. wal_level must be set
>> > -to archive or hot_standb
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, 2013-11-28 at 16:23 -0500, Robert Haas wrote:
> On Tue, Nov 26, 2013 at 2:08 PM, Peter Eisentraut
> 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 jus
On 2013-11-28 19:23:29 -0500, Robert Haas wrote:
> On Wed, Nov 27, 2013 at 5:42 PM, Andres Freund 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 vacuu
On Wed, Nov 27, 2013 at 5:42 PM, Andres Freund 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 a long cycle of pa
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 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 t
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 tha
On Nov 28, 2013, at 5:18 PM, Bruce Momjian 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 wrote:
Seems broadly reasonable, but I'd use "no other effect" throughout.
>>>
>>> That sounds awkward, e.g.:
>>>
>>> Issui
On Thu, Nov 28, 2013 at 04:51:14PM -0500, Robert Haas wrote:
> On Wed, Nov 27, 2013 at 4:44 PM, Bruce Momjian wrote:
> >> Seems broadly reasonable, but I'd use "no other effect" throughout.
> >
> > That sounds awkward, e.g.:
> >
> > Issuing ROLLBACK outside of a transaction
> > block emi
On Wed, Nov 27, 2013 at 4:33 PM, Bruce Momjian 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 ne
On Thu, Nov 28, 2013 at 4:48 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Tue, Nov 26, 2013 at 2:08 PM, Peter Eisentraut 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
>> >
On Wed, Nov 27, 2013 at 4:44 PM, Bruce Momjian wrote:
>> Seems broadly reasonable, but I'd use "no other effect" throughout.
>
> That sounds awkward, e.g.:
>
> Issuing ROLLBACK outside of a transaction
> block emits a warning but has no other effect.
>
> I could live with this:
>
>
Robert Haas escribió:
> On Tue, Nov 26, 2013 at 2:08 PM, Peter Eisentraut 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 co
On Wed, Nov 27, 2013 at 9:31 AM, Amit Kapila 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 anything more
> ca
On Tue, Nov 26, 2013 at 2:08 PM, Peter Eisentraut 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 and -double4
On Thu, Nov 28, 2013 at 3:09 PM, Tom Lane wrote:
> Robert Haas 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 d
Robert Haas 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. (I see about
0.2% o
I wrote:
> Daniel Wood 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 9.2 is that
9.2 d
On Thu, Nov 28, 2013 at 10:10 AM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Wed, Nov 6, 2013 at 9:40 AM, Alvaro Herrera
>> wrote:
>> > Noah Misch wrote:
>> >> Incomplete list:
>> >>
>> >> - If smgrDoPendingDeletes() finds files to delete, mdunlink() and its
>> >> callee
>> >> relpat
On Thu, Nov 28, 2013 at 2:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Nov 28, 2013 at 1:46 PM, Tom Lane 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
On Thu, Nov 28, 2013 at 2:12 PM, Tom Lane 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 that approach w
Robert Haas writes:
> On Thu, Nov 28, 2013 at 1:46 PM, Tom Lane 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 negating any benefit. Instead
>> I pr
On Thu, Nov 28, 2013 at 1:46 PM, Tom Lane 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
> FastPathGrantRelationLock()
Atri Sharma writes:
> On Fri, Nov 29, 2013 at 12:16 AM, Tom Lane 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 negating any benefit. Instead
>> I p
On Fri, Nov 29, 2013 at 12:16 AM, Tom Lane 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
> FastPathGrantRelationLock(
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 sca
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
>
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 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 gua
"Erik Rijkers" 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.
regards, tom lan
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:
http://www.p
Andres Freund 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 to support suc
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_onl
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
Robert Haas 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
debatable for a back-
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 respective
Robert Haas escribió:
> On Wed, Nov 6, 2013 at 9:40 AM, Alvaro Herrera
> 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 branches.
On Wed, Nov 27, 2013 at 8:21 PM, Tom Lane 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
>> could conside
On Wed, Nov 27, 2013 at 11:22 AM, Michael Paquier
wrote:
> On Wed, Nov 27, 2013 at 11:04 AM, Sawada Masahiko
> wrote:
>> Thank you for feedback.
>> I attached the v4 patch which have modified. Just name changed to
>> 'wal_log_hintbtis'.
> Few typos in this patch found while I quickly went throug
On 27 November 2013 10:35 Fujii Masao wrote:
> On Wed, Nov 27, 2013 at 1:27 PM, Haribabu kommi
> wrote:
> > On 26 November 2013 23:11 Fujii Masao wrote:
> >> On Wed, Nov 20, 2013 at 7:43 PM, Haribabu kommi
> >> wrote:
> >> > I tried using of stat'ing in two directories, which is having a
> >> pro
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,
Tom Lane 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 what a view is.
-
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
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 a
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 t
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
stan
2013-11-28 00:17 keltezéssel, Tom Lane írta:
Peter Eisentraut 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 whatsoever with re
63 matches
Mail list logo
