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
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 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
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 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
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 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
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 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 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 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 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 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 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
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 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
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 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 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 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
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 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
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 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
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
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
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
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:/
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 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 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 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
>
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 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
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 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
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 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
Marko Kreen writes:
> On Sat, Jan 25, 2014 at 12:25:30PM -0500, Tom Lane wrote:
>> Alternatively, given that TLS has been around for a dozen years and
>> openssl versions that old have not gotten security updates for a long
>> time, why don't we just reject SSLv3 on the backend side too?
> Attach
Peter Geoghegan writes:
> On Fri, Jan 31, 2014 at 5:07 AM, Mitsumasa KONDO
> wrote:
>> It accelerate to affect
>> update(delete and insert) cost in pg_stat_statements table. So you proposed
>> new setting
>> 10k in default max value. But it is not essential solution, because it is
>> also good pe
Thank you for your replies. I will get started.
Cheers,
Anirudh
On Fri, Jan 31, 2014 at 1:17 PM, Josh Berkus wrote:
> On 01/30/2014 07:23 PM, Anirudh wrote:
> > Hello everyone,
> >
> > My name is Anirudh Subramanian and I am a graduate student in Computer
> > Science. I would like to particip
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 a strange coincidence it
wo
On Fri, Jan 31, 2014 at 9:26 AM, Andrew Dunstan wrote:
>
> On 01/31/2014 09:53 AM, Merlin Moncure wrote:
>>
>> On Fri, Jan 31, 2014 at 8:45 AM, Andrew Dunstan
>> wrote:
>>>
>>> On 01/31/2014 08:57 AM, Merlin Moncure wrote:
On Fri, Jan 31, 2014 at 4:03 AM, Oleg Bartunov
wrote:
On Fri, Jul 26, 2013 at 06:28:05PM -0400, Tom Lane wrote:
> Our documentation appears not to disclose this fine point, but a look
> at the SQL-MED standard says it's operating per spec. The standard also
> says that ADD is an error if the option is already defined, which is a
> bit more defensible
Greg Stark writes:
> So just to summarize, this xlog record:
> [cur:EA1/637140, xid:1418089147, rmid:11(Btree), len/tot_len:18/6194,
> info:8, prev:EA1/635290] insert_leaf: s/d/r:1663/16385/1261982 tid
> 3634978/282
> [cur:EA1/637140, xid:1418089147, rmid:11(Btree), len/tot_len:18/6194,
> info:8,
On Fri, Jan 31, 2014 at 5:07 AM, Mitsumasa KONDO
wrote:
> And past result shows that your patch's most weak point is that deleting
> most old statement
> and inserting new old statement cost is very high, as you know.
No, there is no reason to imagine that entry_dealloc() is any slower,
really. T
On Fri, Jan 31, 2014 at 06:34:27PM +0100, Vik Fearing wrote:
> >> Application code that relies on the values already has problems though
> >> since the returned values are pretty bogus now. Including the fact that
> >> it can return 0 as the number of modified rows which is checked for more
> >> fr
On Fri, Jan 31, 2014 at 3:51 AM, Peter Geoghegan wrote:
>> Now, I haven't checked if it's already done. Sorry if it is. I did
>> mock around btree code a lot and don't remember any of this, but I do
>> remember stuff that could be used to achieve it (specifically, all the
>> index-only-scan machin
On Fri, Jan 31, 2014 at 07:15:05PM +0100, Andres Freund wrote:
> On 2014-01-31 12:29:52 -0500, Andrew Dunstan wrote:
> > While Bruce is working on pgindent
>
> If it's christmas, let me wish for a not completly broken formatting of
> function typedefs. E.g.
> typedef ForeignScan *(*GetForeignPlan_
On Fri, Jan 31, 2014 at 12:44:22PM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > While Bruce is working on pgindent, let me register a small wishlist
> > item. It would be quite useful to be able to supply extra typedefs on
> > the command line to supplement a typedefs file downloaded from
On 2014-01-31 15:10, Stephen Frost wrote:
* Craig Ringer (cr...@2ndquadrant.com) wrote:
On 01/31/2014 09:01 AM, Stephen Frost wrote:
The only case prevented is one where access to the child via the parent
shows rows that the parent's row-security qual would hide, because the
child's qual doesn't
On Sat, Jan 25, 2014 at 12:25:30PM -0500, Tom Lane wrote:
> Alternatively, given that TLS has been around for a dozen years and
> openssl versions that old have not gotten security updates for a long
> time, why don't we just reject SSLv3 on the backend side too?
> I guess it's barely possible that
On 01/30/2014 07:23 PM, Anirudh wrote:
> Hello everyone,
>
> My name is Anirudh Subramanian and I am a graduate student in Computer
> Science. I would like to participate in Google Summer of Code and would
> like to contribute to postgresql. I am not familiar with the postgresql
> codebase yet but
On 2014-01-31 12:29:52 -0500, Andrew Dunstan wrote:
> While Bruce is working on pgindent
If it's christmas, let me wish for a not completly broken formatting of
function typedefs. E.g.
typedef ForeignScan *(*GetForeignPlan_function) (PlannerInfo *root,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I agree that using the FDW-specific options is the right approach and
> > disallowing those to be set on foreign tables makes sense. I don't
> > particularly like the idea of applying changes during inheiritance
> > which we would
On Tue, Jan 28, 2014 at 6:39 PM, Rajeev rastogi
wrote:
> On 28/01/14, Christian Kruse wrote:
>> > I have checked the revised patch. It looks fine to me except one
>> minor code formatting issue.
>> > In elog.c, two tabs are missing in the definition of function
>> "errdetail_log_plural".
>> > Plea
In 9.3 I noticed that postmaster considers bgworker crashed (and
therefore tries to restart it) even if it has exited with zero status code.
I first thought about a patch like the one below, but then noticed that
postmaster.c:bgworker_quickdie() signal handler exits with 0 too (when
there's no suc
* Fujii Masao (masao.fu...@gmail.com) wrote:
> > We should add the tab-completion for ALTER TABLESPACE MOVE?
> > Attached does that.
>
> Committed.
Thanks! I had planned to get to it, but appreciate your handling of it.
Stephen
signature.asc
Description: Digital signature
On 01/31/2014 12:25 PM, Bruce Momjian wrote:
On Thu, Jul 25, 2013 at 04:53:45PM -0400, Andrew Dunstan wrote:
Jeff Janes asked me about this, and Bruce just tripped up on it.
Usually on Windows it's necessary to have libpq.dll/cygpq.dll either
in the PATH or in the same directory as client .exe f
Andrew Dunstan writes:
> While Bruce is working on pgindent, let me register a small wishlist
> item. It would be quite useful to be able to supply extra typedefs on
> the command line to supplement a typedefs file downloaded from the
> buildfarm or constructed however. A concrete example: in t
* Yeb Havinga (yebhavi...@gmail.com) wrote:
> This reasoning could go either way. GRANT is on a complete set of
> rows. This is a restriction on the level of individual rows, and in
> that sense, it is more like a row-level CHECK constraint.
Well, we certainly don't force CHECK constraints on chil
On 01/31/2014 06:19 PM, Bruce Momjian wrote:
> On Wed, Jul 24, 2013 at 08:08:32PM +0200, Andres Freund wrote:
>> On 2013-07-24 13:48:23 -0400, Tom Lane wrote:
>>> Vik Fearing writes:
Also worth mentioning is bug #7766.
http://www.postgresql.org/message-id/e1tlli5-0007tr...@wrigleys.postg
While Bruce is working on pgindent, let me register a small wishlist
item. It would be quite useful to be able to supply extra typedefs on
the command line to supplement a typedefs file downloaded from the
buildfarm or constructed however. A concrete example: in the code I have
been recently
On Thu, Jul 25, 2013 at 04:53:45PM -0400, Andrew Dunstan wrote:
> Jeff Janes asked me about this, and Bruce just tripped up on it.
> Usually on Windows it's necessary to have libpq.dll/cygpq.dll either
> in the PATH or in the same directory as client .exe files. The
> buildfarm client has for many
On Fri, Jan 31, 2014 at 11:57:28AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > OK. I have updated entab.c to support this new ability as -m. When
> > should it be run this against HEAD and supported back branches? Probably
> > when we run pgindent for 9.4.
>
> Yeah. The whole point is t
On Wed, Jul 24, 2013 at 08:08:32PM +0200, Andres Freund wrote:
> On 2013-07-24 13:48:23 -0400, Tom Lane wrote:
> > Vik Fearing writes:
> > > Also worth mentioning is bug #7766.
> > > http://www.postgresql.org/message-id/e1tlli5-0007tr...@wrigleys.postgresql.org
> >
> > Yeah, did you read that who
On 01/25/2014 06:25 AM, David Fetter wrote:
>> I like this patch, but I don't like its implementation at all.
>> >
>> > First of all, the documentation doesn't compile:
>> >
>> > openjade:ref/create_foreign_table.sgml:124:17:E: end tag for "LISTITEM"
>> > omitted, but OMITTAG NO was specified
>>
On 01/30/2014 12:46 AM, Peter Geoghegan wrote:
On Mon, Jan 27, 2014 at 10:54 AM, Peter Geoghegan wrote:
On Mon, Jan 27, 2014 at 10:27 AM, Heikki Linnakangas
wrote:
I think I see some bugs in _bt_moveright(). If you examine
_bt_finish_split() in detail, you'll see that it doesn't just drop the
On Fri, Jan 31, 2014 at 8:40 AM, Fujii Masao wrote:
> Yeah, I was thinking that, too. I'm not sure whether including log files
> in backup really increases the security risk, though. There are already
> very important data, i.e., database, in backups. Anyway, since
> the amount of log files can be
Bruce Momjian writes:
> OK. I have updated entab.c to support this new ability as -m. When
> should it be run this against HEAD and supported back branches? Probably
> when we run pgindent for 9.4.
Yeah. The whole point is to keep the branches in sync for patching,
so we need to do them all at
On Wed, Jul 24, 2013 at 10:57:14AM -0400, Tom Lane wrote:
> I wrote:
> > The only thing here that really bothers me is that a crash during DROP
> > DATABASE/TABLESPACE could leave us with a partially populated db/ts
> > that's still accessible through the system catalogs. ...
> > I guess one thing
Hello Robert,
>but the scripts are intended to be thin wrappers around
>the underlying database functionality, and I think this is straying
>too far from that core mission.
I think, you have a good point here.
Regards
On Friday, January 31, 2014 4:47 PM, Robert Haas wrote:
On Fri, Jan 31,
On Thu, Jan 30, 2014 at 8:47 PM, Fujii Masao wrote:
> On Tue, Jan 21, 2014 at 1:33 AM, Simon Riggs wrote:
>> On 20 January 2014 17:00, Stephen Frost wrote:
>>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
What if you're a superuser and you want to move everybody's objects
(perhaps in prepara
On Mon, Jul 22, 2013 at 07:32:20PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-22 15:55:46 -0400, Robert Haas wrote:
> >> And why is that?
>
> > The comment above tells: "while the lower half is the XOR of tv_sec and
> > tv_usec."
>
> Yeah, the code doesn't match the comment; t
On Fri, Jan 31, 2014 at 8:02 AM, Christian Kruse
wrote:
> what do you think about the approach the attached patch implements?
> I'm not really sure if this is what you had in mind, especially if
> this is the right lock.
The attached patch seems not to be attached, but the right lock to use
would
On Fri, Jan 31, 2014 at 4:40 AM, Andres Freund wrote:
> On 2014-01-30 12:27:43 -0500, Robert Haas wrote:
>> Nope, but I think this patch is broken. It looks to me like it's
>> conflating the process offset in the BackendStatus array with its
>> backendId, which does not seem like a good idea even
On Fri, Jan 31, 2014 at 11:18:17AM -0500, Bruce Momjian wrote:
> Yes, it is a shame pgindent has removed many proper empty lines in the
> past and there is no way to re-add them without causing backpatching
> problems.
FYI, the original BSD indent code that added the blank lines kind of
made sense
On Fri, Jan 31, 2014 at 6:31 AM, Yugo Nagata wrote:
> Hi Amit,
>
> Thanks for your reviewing. I updated the patch.
> I fixed the oids and removed the witespace.
This patch contains several whitespace-only hunks. Please revert them.
I don't like the changes to typenameTypeIdAndMod(). The code f
On Thu, Jan 30, 2014 at 11:44:31PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > OK, seven hours later, I have fixed pg_bsd_indent to no longer insert
> > blank lines above #elif/#else/#endif, and therefore removed the special
> > case code from pgindent.
>
> > You will need to download vers
On Fri, Jan 31, 2014 at 08:58:21AM -0500, Robert Haas wrote:
> > OK, eight hours later, I have the results for only removing tabs after
> > periods in comments:
> >
> > http://momjian.us/expire/entab_comment.v2.cdiff
> > http://momjian.us/expire/entab_comment.v2.pdiff
> > ht
So just to summarize, this xlog record:
[cur:EA1/637140, xid:1418089147, rmid:11(Btree), len/tot_len:18/6194,
info:8, prev:EA1/635290] insert_leaf: s/d/r:1663/16385/1261982 tid
3634978/282
[cur:EA1/637140, xid:1418089147, rmid:11(Btree), len/tot_len:18/6194,
info:8, prev:EA1/635290] bkpblock[1]: s
On Fri, Jan 31, 2014 at 3:41 PM, Tom Lane wrote:
>> 400 * 400 * 400 / 2000 * 54 + 1F0C / 2000
>> 11073632
Ooops, it's reading 54 in hex there.
> # select ((2^30) * 54.0 + 'x1F0C'::bit(32)::int) / 8192;
> ?column?
> --
> 7141472
ibase=16
400 * 400 * 400 / 2000 * 36 + 1F0C /
On 2014-01-31 10:33:16 -0500, Tom Lane wrote:
> Andres Freund writes:
> > It's interesting that the smgr gets this wrong then (as also evidenced
> > by the fact that relation_size does as well). Could you please do a ls
> > -l path/to/relfilenode*?
>
> IIRC, smgrnblocks will stop as soon as it fi
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 in a database called
>> regression, but the larger document
On Fri, Jan 31, 2014 at 9:09 AM, salah jubeh wrote:
>>$ createdb -U postgres hoge
>>$ psql -d hoge -U postgres
>>hoge=# create table test (col text);
>>hoge=# insert into test select repeat(chr(code),1) from
>>generate_series(1,10) code;
>
>>
>>$ dropdb -k hoge
>>2014-01-29 23:10:49 JST FA
Greg Stark writes:
> Sorry guys. I transposed two numbers when looking up the relation.
> "data_pk" wasn't the right index.
> =# select (page_header(get_raw_page('index_data_id', 'main', 3020854))).* ;
> lsn | tli | flags | lower | upper | special | pagesize |
> version | prune_xid
> --
Sorry guys. I transposed two numbers when looking up the relation.
"data_pk" wasn't the right index.
=# select (page_header(get_raw_page('index_data_id', 'main', 3020854))).* ;
lsn | tli | flags | lower | upper | special | pagesize |
version | prune_xid
--+-+---+-
Greg Stark writes:
> On Fri, Jan 31, 2014 at 3:19 PM, Andres Freund wrote:
>> Isn't the page 3634978?
> The page in the record is.
> But the page on disk is in the 54th segment at offset 1F0C
> So unless my arithmetic is wrong:
> bc -l
> ibase=16
> 400 * 400 * 400 / 2000 * 54 + 1F0C /
On 2014-01-31 10:33:16 -0500, Tom Lane wrote:
> Andres Freund writes:
> > It's interesting that the smgr gets this wrong then (as also evidenced
> > by the fact that relation_size does as well). Could you please do a ls
> > -l path/to/relfilenode*?
>
> IIRC, smgrnblocks will stop as soon as it fi
Andres Freund writes:
> It's interesting that the smgr gets this wrong then (as also evidenced
> by the fact that relation_size does as well). Could you please do a ls
> -l path/to/relfilenode*?
IIRC, smgrnblocks will stop as soon as it finds a segment that is not
1GB in size. Could you check th
Stephen Frost writes:
> I agree that using the FDW-specific options is the right approach and
> disallowing those to be set on foreign tables makes sense. I don't
> particularly like the idea of applying changes during inheiritance
> which we wouldn't allow the user to do directly. While it migh
On 2014-01-31 16:05, Stephen Frost wrote:
* Yeb Havinga (y.t.havi...@mgrid.net) wrote:
IMHO, there is another way to implement this, other than the
procedure to override the child-rel-quals with the ones from the
parent. At DDL time, synchronize quals on the parent with rls quals
of the childs.
On 01/31/2014 09:53 AM, Merlin Moncure wrote:
On Fri, Jan 31, 2014 at 8:45 AM, Andrew Dunstan wrote:
On 01/31/2014 08:57 AM, Merlin Moncure wrote:
On Fri, Jan 31, 2014 at 4:03 AM, Oleg Bartunov
wrote:
Hmm,
neither me, nor Teodor have experience and knowledge with
populate_record() and moreo
On 2014-01-31 15:21:35 +, Greg Stark wrote:
> On Fri, Jan 31, 2014 at 3:19 PM, Andres Freund wrote:
> >> =# select get_raw_page('data_pkey', 'main', 11073632) ;
> >> ERROR: block number 11073632 is out of range for relation "data_pkey"
> >
> > Isn't the page 3634978?
>
> The page in the reco
On Fri, Jan 31, 2014 at 3:19 PM, Andres Freund wrote:
>> =# select get_raw_page('data_pkey', 'main', 11073632) ;
>> ERROR: block number 11073632 is out of range for relation "data_pkey"
>
> Isn't the page 3634978?
The page in the record is.
But the page on disk is in the 54th segment at offset
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jan 30, 2014 at 5:05 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Thu, Jan 30, 2014 at 11:04 AM, Tom Lane wrote:
> >>> I think this is totally misguided. Who's to say that some weird FDW
> >>> might not pay attention to attstorage?
On 2014-01-31 15:15:24 +, Greg Stark wrote:
> On Fri, Jan 31, 2014 at 3:08 PM, Andres Freund wrote:
>
> > It points to the end of the record (i.e. the beginning of the next). It
> > needs to, because otherwise XLogFlush()es on the pd_lsn wouldn't flush
> > enough.
>
> Ah, in which case the r
On Fri, Jan 31, 2014 at 3:08 PM, Andres Freund wrote:
> It points to the end of the record (i.e. the beginning of the next). It
> needs to, because otherwise XLogFlush()es on the pd_lsn wouldn't flush
> enough.
Ah, in which case the relevant record is:
[cur:EA1/637140, xid:1418089147, rmid:11(Bt
From: "Dilip kumar"
Is there any direct scenario by which it can be reproduce ?
Thank you for reviewing and testing the patch. There is no other direct
scenario.
I reproduced the failure exactly like you suggested, because it was very
difficult to reproduce the problem without using the debug
On 2014-01-31 14:59:21 +, Greg Stark wrote:
> On Fri, Jan 31, 2014 at 2:39 PM, Greg Stark wrote:
> > [cur:EA1/637140, xid:1418089147, rmid:11(Btree), len/tot_len:18/6194,
> > info:8, prev:EA1/635290] bkpblock[1]: s/d/r:1663/16385/1261982
> > blk:3634978 hole_off/len:1240/2072
> > [cur:EA1/6389
1 - 100 of 138 matches
Mail list logo
