On Thu, Aug 1, 2013 at 10:14:43AM +0200, Antonin Houska wrote:
> While checking something, I noticed that opfamilies 3626, 3683, 3901
> (all btree AM), 3903 (hash) and 3919 (gist) are all defined in the
> section marked as "gin".
>
> (I'm not sure if it helps to deliver a patch - it may be easier
Greg Stark writes:
> One thing I keep coming back to is a bad ran chip setting a bit in the
> block number. But I just can't seem to get it to add up. The difference is
> not a power of two, it had happened on two different machines, and we don't
> see other weirdness on the machine. It seems like
On Fri, Aug 2, 2013 at 04:00:03PM +0800, Craig Ringer wrote:
> FOR SHARE|UPDATE NOWAIT will still block if they have to follow a ctid
> chain because the call to EvalPlanQualFetch doesn't take a param for
> noWait, so it doesn't know not to block if the updated row can't be locked.
>
> The attach
On Mon, Aug 5, 2013 at 04:20:40PM +0900, Michael Paquier wrote:
> Hi all,
>
> By having a look at the documentation of SELECT, it is not specified that FOR
> SHARE/UPDATE and friends are incompatible with the clauses in $subject
> http://www.postgresql.org/docs/9.2/static/sql-select.html
> This r
On Mon, Oct 7, 2013 at 03:02:36PM -0400, Robert Haas wrote:
> On Fri, Oct 4, 2013 at 3:20 PM, Andres Freund wrote:
> > On 2013-10-04 15:15:36 -0400, Robert Haas wrote:
> >> Andres, are you (or is anyone) going to try to fix this assertion failure?
> >
> > I think short term replacing it by IsTran
Bruce Momjian writes:
> On Fri, Jan 31, 2014 at 06:34:27PM +0100, Vik Fearing wrote:
>> Unfortunately, I gave up on it as being over my head when I noticed I
>> was changing the protocol itself. I should have notified the list so
>> someone else could have taken over.
> OK, so that brings up a g
On Fri, Jan 31, 2014 at 04:38:21PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Jan 31, 2014 at 06:34:27PM +0100, Vik Fearing wrote:
> >> Unfortunately, I gave up on it as being over my head when I noticed I
> >> was changing the protocol itself. I should have notified the list so
>
On Tue, Aug 13, 2013 at 05:34:12PM -0400, Tom Lane wrote:
> Further poking at this issue shows that there are related behaviors that
> aren't fixed by my proposed patch. The original complaint can be
> replicated in the regression database like this:
>
> select row_to_json(i8) from (select q1 as
On Thu, Aug 15, 2013 at 07:25:17PM +0900, Etsuro Fujita wrote:
> I wrote:
> > I've reworked on the patch.
>
> Attached is an updated version of the patch. In that version the code for the
> newly added function build_function_pathkeys() has been made more simple by
> using the macro INTEGER_BTREE
On Sat, Feb 1, 2014 at 12:42 AM, Robert Haas wrote:
> On Fri, Jan 31, 2014 at 2:28 AM, Michael Paquier
> wrote:
>>> I took a look at this with a view to committing it but on examination
>>> I'm not sure this is the best way to proceed. The proposed text
>>> documents that the tests should be run
On Sat, Feb 1, 2014 at 6:37 AM, Bruce Momjian wrote:
> On Mon, Aug 5, 2013 at 04:20:40PM +0900, Michael Paquier wrote:
>> Hi all,
>>
>> By having a look at the documentation of SELECT, it is not specified that FOR
>> SHARE/UPDATE and friends are incompatible with the clauses in $subject
>> http:/
Bruce Momjian writes:
> On Tue, Aug 13, 2013 at 05:34:12PM -0400, Tom Lane wrote:
>> Further poking at this issue shows that there are related behaviors that
>> aren't fixed by my proposed patch.
> Where are we on this?
Still have no idea how to fix the whole-row-Var case. We could fix some
of
Bruce Momjian writes:
> On Thu, Aug 15, 2013 at 07:25:17PM +0900, Etsuro Fujita wrote:
>> Attached is an updated version of the patch. In that version the code for
>> the
>> newly added function build_function_pathkeys() has been made more simple by
>> using the macro INTEGER_BTREE_FAM_OID.
> I
Robert Haas writes:
> On Sat, Jan 25, 2014 at 5:04 PM, Tom Lane wrote:
>> Yeah. If Robert's diagnosis is correct, and it sounds pretty plausible,
>> then this is really just one instance of a bug that's probably pretty
>> widespread in our signal handlers. Somebody needs to go through 'em
>> al
On Mon, Oct 21, 2013 at 01:31:26PM +, Albe Laurenz wrote:
> Bind attempts to an LDAP server should time out after two seconds,
> allowing additional lines in the service control file to be parsed
> (which provide a fall back to a secondary LDAP server or default options).
> The existing code fa
On 01/31/2014 01:11 PM, Tom Lane wrote:
> Greg Stark writes:
>> One thing I keep coming back to is a bad ran chip setting a bit in the
>> block number. But I just can't seem to get it to add up. The difference is
>> not a power of two, it had happened on two different machines, and we don't
>> see
On Sat, Aug 24, 2013 at 12:08:30AM +0300, Heikki Linnakangas wrote:
> You can also set min_recycle_wal_size = checkpoint_wal_size, which
> gets you the same behavior as without the patch, except that it's
> more intuitive to set it in terms of "MB of WAL space required",
> instead of "# of segments
Hi Rajeev san,
I reviewed the patch content. I find this fix useful.
I'd like to suggest some code improvements. I'll apply and test the patch
when I receive your reply.
(1)
I think it is appropriate to place find_my_abs_path() in path.c rather than
exec.c. Please look at the comments at
On Fri, Oct 11, 2013 at 12:30:41PM +0900, Fujii Masao wrote:
> > Sure. To be honest, when I received the same request from Andres,
> > I did that benchmark. But unfortunately because of machine trouble,
> > I could not report it, yet. Will do that again.
>
> Here is the benchmark result:
>
> * Re
On 01/31/2014 10:56 PM, Bruce Momjian wrote:
> On Fri, Jan 31, 2014 at 04:38:21PM -0500, Tom Lane wrote:
>> Bruce Momjian writes:
>>> On Fri, Jan 31, 2014 at 06:34:27PM +0100, Vik Fearing wrote:
Unfortunately, I gave up on it as being over my head when I noticed I
was changing the protoc
On Sat, Feb 1, 2014 at 02:25:16AM +0100, Vik Fearing wrote:
> > OK, thanks for the feedback. I understand now. The contents of the
> > string will potentially have a larger integer, but the byte length of
> > the string in the wire protocol doesn't change.
> >
> > Let's wait for Vik to reply and
On Fri, Jan 31, 2014 at 1:54 AM, Andres Freund wrote:
> I plan to split the atomics patch into smaller chunks before
> reposting. Imo the "Convert the PGPROC->lwWaitLink list into a dlist
> instead of open coding it." is worth being applied independently from
> the rest of the series, it simplies
On Thu, Oct 10, 2013 at 11:00:30PM -0400, Andrew Dunstan wrote:
>
> On 10/10/2013 09:35 PM, Peter Eisentraut wrote:
> >On Tue, 2013-10-08 at 10:04 -0400, Andrew Dunstan wrote:
> >>On 10/07/2013 08:47 PM, Peter Eisentraut wrote:
> >>>I suspect this line
> >>>
> >>>submake-libpq: $(libdir)/libpq.so
Applied.
---
On Wed, Sep 4, 2013 at 04:11:09AM +, Tsunakawa, Takayuki wrote:
> Hi,
>
> In the following page, statistics are kept across server restarts:
>
> http://www.postgresql.org/docs/current/static/monitoring-st
On 01/31/2014 09:19 PM, Bruce Momjian wrote:
On Thu, Oct 10, 2013 at 11:00:30PM -0400, Andrew Dunstan wrote:
On 10/10/2013 09:35 PM, Peter Eisentraut wrote:
On Tue, 2013-10-08 at 10:04 -0400, Andrew Dunstan wrote:
On 10/07/2013 08:47 PM, Peter Eisentraut wrote:
I suspect this line
submake-l
On Fri, Jan 31, 2014 at 09:28:06PM -0500, Andrew Dunstan wrote:
>
> On 01/31/2014 09:19 PM, Bruce Momjian wrote:
> >On Thu, Oct 10, 2013 at 11:00:30PM -0400, Andrew Dunstan wrote:
> >>On 10/10/2013 09:35 PM, Peter Eisentraut wrote:
> >>>On Tue, 2013-10-08 at 10:04 -0400, Andrew Dunstan wrote:
> >>
On Thu, Sep 5, 2013 at 09:13:23PM +0200, Andres Freund wrote:
> Hi,
>
> Heikki's catcache rehashing stuff reminded me that I'd posted an
> optimization to catcache (20121220153555.gh4...@awork2.anarazel.de) some
> time back which I didn't have energy to pursue at that point.
>
> I've brushed the
On Fri, Jan 31, 2014 at 10:11 PM, Tom Lane wrote:
> Yeah, I'd been wondering if the WAL record somehow got corrupted while
> in memory (presumably after being CRC-checked). It's a bit hard to see
> how though.
One thing I mentioned early on but bears repeating is that this
instance is 9.1.11.
A
On Sat, Feb 1, 2014 at 10:22 AM, Bruce Momjian wrote:
> On Fri, Oct 11, 2013 at 12:30:41PM +0900, Fujii Masao wrote:
>> > Sure. To be honest, when I received the same request from Andres,
>> > I did that benchmark. But unfortunately because of machine trouble,
>> > I could not report it, yet. Will
On Thu, Sep 19, 2013 at 02:39:43PM -0400, Robert Haas wrote:
> Right now, whether or not to autovacuum is the rest of a two-pronged
> test. The first prong is based on number of updates and deletes
> relative to table size; that triggers a regular autovacuum. The
> second prong is based on age(re
On Fri, Jan 31, 2014 at 6:15 PM, Tom Lane wrote:
> This looks good to me in principle. A couple minor beefs:
>
> * The addition to CleanupProcSignalState could use a comment,
> similar to the one you added in ProcKill.
OK.
> * I think the code in ProcKill and AuxiliaryProcKill might be more
> r
On Thu, Sep 5, 2013 at 09:15:09PM -0400, Josh Kupershmidt wrote:
> On Tue, Aug 27, 2013 at 1:14 PM, Heikki Linnakangas
> wrote:
> > Assuming no objections, I'll apply the attached patch to 9.3 and master
> > later tonight.
>
> Just a little stylistic nitpick: could we pluralize the --help output
Where are we on this?
---
On Fri, Nov 8, 2013 at 01:38:28PM -0500, Tom Lane wrote:
> Alexander Korotkov writes:
> > I wrote attached patch by following principles:
> > 1) NaN coordinates shouldn't crash or hang GiST.
> > 2
On 01/31/2014 02:48 PM, Merlin Moncure wrote:
Actually, there is a workaround to the limitations of hstore(record):
yeah I'm ok with hstore() function as it is. That also eliminates
backwards compatibility concerns so things worked out. The only 'must
fix' 9.4 facing issue I see on the ta
On 01/31/2014 11:35 PM, Andrew Dunstan wrote:
Yes, or anyone else who wants to join in. I'd very much welcome a
substantial code review - I have been staring at this far too long on
my own.
I should mention that in fact by far the largest piece of this is not my
work, but Oleg and Teodor's
On Fri, Jan 31, 2014 at 1:35 PM, Kyotaro HORIGUCHI
wrote:
> Hello, I've managed to reconstruct windows build environment and
> tried to run the previous patch.
Thanks.
>
>
> I will apologize in advance for probably silly questions but I
> have two problems.
I think both the problems are related a
Josh Berkus writes:
> FWIW, we've periodically seen reports from our clients of replica
> databases being slightly larger than the master. Nothing reproducable
> or as severe as Greg's issue, or we'd have reported it. But this could
> be a more widespread issue, just that it affects most users i
On Fri, Jan 31, 2014 at 8:20 PM, MauMau wrote:
> Hi, Amit san,
>
> I'm replying to your previous email. I wanted to reply to your latest mail
> below, but I removed it from my mailer by mistake.
>
> http://www.postgresql.org/message-id/CAA4eK1LAg6ndZdWLb5e=Ep5DzcE8KZU=JbmO+tFwySYHm2ja=q...@mail.g
101 - 138 of 138 matches
Mail list logo
