On 2014-02-18 18:10:02 -0800, Peter Geoghegan wrote:
> On Tue, Feb 18, 2014 at 5:50 PM, Alvaro Herrera
> wrote:
> > Peter Geoghegan wrote:
> >> I've had multiple complaints of apparent data loss on 9.3.2 customer
> >> databases. There are 2 total, both complaints from the past week, one
> >> of wh
On Wed, Feb 19, 2014 at 12:40 AM, Andres Freund wrote:
> Was there an index only scan or just a index scan? Any chance of a
> corrupted index?
Just an index scan. I think it's unlikely to be a corrupt index,
because the customer said that he dropped and restored the index, and
it's difficult to i
On 2014-02-19 00:55:03 -0800, Peter Geoghegan wrote:
> On Wed, Feb 19, 2014 at 12:40 AM, Andres Freund
> wrote:
> > Was there an index only scan or just a index scan? Any chance of a
> > corrupted index?
>
> Just an index scan. I think it's unlikely to be a corrupt index,
> because the customer
(2014/02/19 12:12), Kyotaro HORIGUCHI wrote:
At Tue, 18 Feb 2014 19:24:50 +0900, "Etsuro Fujita" wrote
From: Shigeru Hanada [mailto:shigeru.han...@gmail.com]
I'm not sure that allowing ALTER TABLE against parent table affects
descendants even some of them are foreign table. I think the rule
On Mon, Feb 17, 2014 at 3:56 PM, Tom Lane wrote:
> Emre Hasegeli writes:
>> How about only removing the inet and the cidr operator classes
>> from btree_gist. btree-gist-drop-inet-v2.patch does that.
>
> I'm not sure which part of "no" you didn't understand, but to be
> clear: you don't get to br
On Mon, Jan 20, 2014 at 5:37 PM, Simon Riggs wrote:
> Agreed; that was the original plan, but implementation delays
> prevented the whole vision/discussion/implementation. Requirements
> from various areas include WAL rate limiting for replication, I/O rate
> limiting, hard CPU and I/O limits for
On Fri, Feb 14, 2014 at 9:32 PM, Michael Paquier
wrote:
> On Thu, Feb 6, 2014 at 11:26 AM, Michael Paquier
> wrote:
>> Here are updated patches to use pg_lsn instead of pglsn...
> Should I register this patch somewhere to avoid having it lost in the void?
> Regards,
Well, I committed this, but t
On 2014-02-19 09:24:03 -0500, Robert Haas wrote:
> On Fri, Feb 14, 2014 at 9:32 PM, Michael Paquier
> wrote:
> > On Thu, Feb 6, 2014 at 11:26 AM, Michael Paquier
> > wrote:
> >> Here are updated patches to use pg_lsn instead of pglsn...
> > Should I register this patch somewhere to avoid having i
On Wed, Feb 19, 2014 at 9:30 AM, Andres Freund wrote:
> On 2014-02-19 09:24:03 -0500, Robert Haas wrote:
>> On Fri, Feb 14, 2014 at 9:32 PM, Michael Paquier
>> wrote:
>> > On Thu, Feb 6, 2014 at 11:26 AM, Michael Paquier
>> > wrote:
>> >> Here are updated patches to use pg_lsn instead of pglsn..
From: "Jeff Janes"
I thought that this was the point I was making, not the point I was
missing. You have the same hard drives you had before, but now due to a
software improvement you are cramming 5 times more stuff through them.
Yeah, you will get bigger latency spikes. Why wouldn't you? You
Robert Haas writes:
> On Mon, Feb 17, 2014 at 3:56 PM, Tom Lane wrote:
>> We should probably expend some thought on a general approach to
>> replacing the default opclass for a datatype, because I'm sure this
>> will come up again. Right now I don't see a feasible way.
> It seems odd for "defau
Robert Haas writes:
> On Wed, Feb 19, 2014 at 9:30 AM, Andres Freund wrote:
>> GET_8_BYTES only exists for 64bit systems.
> Right, I got that far. So it looks like float8, int8, timestamp,
> timestamptz, and money all have behavior contingent on
> USE_FLOAT8_BYVAL, making that symbol a misnomer
On Wed, Feb 19, 2014 at 10:03 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 19, 2014 at 9:30 AM, Andres Freund
>> wrote:
>>> GET_8_BYTES only exists for 64bit systems.
>
>> Right, I got that far. So it looks like float8, int8, timestamp,
>> timestamptz, and money all have behavior c
--On 18. Februar 2014 22:23:59 +0200 Heikki Linnakangas
wrote:
I considered it a new feature, so not back-patching was the default. If
you want to back-patch it, I won't object.
That was my original feeling, too, but +1 for backpatching.
--
Thanks
Bernd
--
Sent via pgsql-hacke
On Tue, Feb 18, 2014 at 04:39:27PM -0300, Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
> > Add a GUC to report whether data page checksums are enabled.
>
> Is there are reason this wasn't back-patched to 9.3? I think it should
> be.
+1 for back-patching.
Cheers,
David.
--
David Fetter ht
On Wed, Feb 19, 2014 at 8:28 AM, Greg Stark wrote:
> On Mon, Jan 20, 2014 at 5:37 PM, Simon Riggs wrote:
>
>> Agreed; that was the original plan, but implementation delays
>> prevented the whole vision/discussion/implementation. Requirements
>> from various areas include WAL rate limiting for rep
On Wed, Feb 19, 2014 at 3:11 PM, Robert Haas wrote:
> Hopefully the commit I just pushed will fix it. It now works on my
> machine with and without --disable-float8-byval.
It builds and passes here on 32bits
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
On Wed, Feb 19, 2014 at 11:03 AM, Greg Stark wrote:
> On Wed, Feb 19, 2014 at 3:11 PM, Robert Haas wrote:
>> Hopefully the commit I just pushed will fix it. It now works on my
>> machine with and without --disable-float8-byval.
>
> It builds and passes here on 32bits
The buildfarm seems happy s
On Mon, Feb 17, 2014 at 10:50 PM, Michael Paquier
wrote:
> On Tue, Feb 18, 2014 at 12:43 PM, Amit Kapila wrote:
>> Description for contents of PGDATA is mentioned at
>> following page in docs:
>> http://www.postgresql.org/docs/devel/static/storage-file-layout.html
>>
>> Isn't it better to have de
On Mon, Feb 17, 2014 at 11:29 AM, Alvaro Herrera
wrote:
> The pg_regress part is ugly. However, pg_regress is doing something
> unusual when starting postmaster itself, so the ugly coding to stop it
> seems to match. If we wanted to avoid the ugliness here, the right fix
> would be to use pg_ctl
On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
wrote:
> On Thu, Feb 6, 2014 at 3:48 AM, Peter Eisentraut wrote:
>> On 2/5/14, 1:31 PM, Robert Haas wrote:
>>> On Tue, Feb 4, 2014 at 3:26 PM, Peter Eisentraut wrote:
Perhaps this type should be called pglsn, since it's an
implementation-
On Sat, Feb 15, 2014 at 6:59 PM, Andres Freund wrote:
> On 2014-02-15 17:29:04 -0500, Robert Haas wrote:
>> On Fri, Feb 14, 2014 at 4:55 AM, Andres Freund
>> wrote:
>> > [ new patches ]
>>
>> 0001 already needs minor
>
> Hm?
>
> If there are conflicts, I'll push/send a rebased tomorrow or monday
On Sun, Feb 16, 2014 at 12:12 PM, Andres Freund wrote:
> On 2014-02-15 17:29:04 -0500, Robert Haas wrote:
>> On Fri, Feb 14, 2014 at 4:55 AM, Andres Freund
>> wrote:
>> > [ new patches ]
>>
>> 0001 already needs minor
>>
>> + * copied stuff from tuptoaster.c. Perhaps there should be toast_intern
Pavel Stehule escribió:
> > 7) Why do the functions accept only the timezone abbreviation, not the
> >full name? I find it rather confusing, because the 'timezone' option
> >uses the full name, and we're using this as the default. But doing
> >'show timestamp' and using the returned va
On Tue, Feb 18, 2014 at 4:07 AM, Andres Freund wrote:
>> 2. I think the snapshot-export code is fundamentally misdesigned. As
>> I said before, the idea that we're going to export one single snapshot
>> at one particular point in time strikes me as extremely short-sighted.
>
> I don't think so. I
On Sun, Feb 16, 2014 at 10:41 PM, Tom Lane wrote:
> Any comments before I start transposing them into the back branches?
Sorry I'm late.
> Shore up GRANT ... WITH ADMIN OPTION restrictions (Noah Misch)
I'm not familiar with the phrase "Shore up", I think it should use
more precise language: are
On Tue, Feb 18, 2014 at 4:33 AM, Andres Freund wrote:
> On 2014-02-17 21:35:23 -0500, Robert Haas wrote:
>> What
>> I don't understand is why we're not taking the test_decoding module,
>> polishing it up a little to produce some nice, easily
>> machine-parseable output, calling it basic_decoding,
On Wed, Feb 12, 2014 at 11:54 PM, Marti Raudsepp wrote:
> With partial-sort-basic-1 and this fix on the same test suite, the
> planner overhead is now a more manageable 0.5% to 1.3%; one test is
> faster by 0.5%.
Ping, Robert or anyone, does this overhead seem bearable or is that
still too much?
2014-02-19 19:01 GMT+01:00 Alvaro Herrera :
> Pavel Stehule escribió:
>
> > > 7) Why do the functions accept only the timezone abbreviation, not the
> > >full name? I find it rather confusing, because the 'timezone' option
> > >uses the full name, and we're using this as the default. But d
On 18-02-2014 06:33, Andres Freund wrote:
> I really hope there will be nicer ones by the time 9.4 is
> released. Euler did send in a json plugin
> http://archives.postgresql.org/message-id/52A5BFAE.1040209%2540timbira.com.br
> , but there hasn't too much feedback yet. It's hard to start discussing
2014-02-19 19:01 GMT+01:00 Alvaro Herrera :
> Pavel Stehule escribió:
>
> > > 7) Why do the functions accept only the timezone abbreviation, not the
> > >full name? I find it rather confusing, because the 'timezone' option
> > >uses the full name, and we're using this as the default. But d
Pavel Stehule escribió:
> I though about it, and now I am thinking so timezone in format
> 'Europe/Prague' is together with time ambiguous
>
> We can do it, but we have to expect so calculation will be related to
> current date - and I am not sure if it is correct, because someone can
> write som
Dne 19. 2. 2014 21:20 "Alvaro Herrera" napsal(a):
>
> Pavel Stehule escribió:
>
> > I though about it, and now I am thinking so timezone in format
> > 'Europe/Prague' is together with time ambiguous
> >
> > We can do it, but we have to expect so calculation will be related to
> > current date - an
Alvaro Herrera writes:
> My conclusion here is that the "time with time zone" datatype is broken
> in itself, because of this kind of ambiguity.
That's the conclusion that's been arrived at by pretty much everybody
who's looked at it with any care.
> Maybe we should just
> avoid offering more fu
I was trying to understand (and then perhaps mimic) how pg_standby does a
fast failover.
My current understanding is that when a secondary db is in standby mode, it
will exhaust all the archive log to be replayed from the primary and then
start streaming. It is at this point that xlog.c checks fo
2014-02-19 16:52, Tom Lane :
> Not at all, AFAICS. If it were okay to decide that some formerly-default
> opclass is no longer default, then having such a command would be better
> than manually manipulating pg_opclass.opcdefault --- but extension upgrade
> scripts could certainly do the latter if
On 02/19/2014 11:15 PM, Neil Thombre wrote:
And that is where I have a question. I noticed that in pg_standby.c when we
detect the word "fast" in the trigger file we truncate the file.
https://github.com/postgres/postgres/blob/REL9_1_11/contrib/pg_standby/pg_standby.c#L456
There is also a comme
Emre Hasegeli writes:
> [ cites bug #5705 ]
Hm. I had forgotten how thoroughly broken btree_gist's inet and cidr
opclasses are. There was discussion at the time of just ripping them
out despite the compatibility hit. We didn't do it, but if we had
then life would be simpler now.
Perhaps it wo
On 2014-02-19 12:47:40 -0500, Robert Haas wrote:
> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
> wrote:
> >> Yes, that's a good precedent in multiple ways.
> > Here are updated patches to use pg_lsn instead of pglsn...
>
> OK, so I think this stuff is all committed now, with assorted changes.
Hi,
I want to propose a new feature called "priority table" or "cache table".
This is same as regular table except the pages of these tables are having
high priority than normal tables. These tables are very useful, where a
faster query processing on some particular tables is expected.
The same f
Hiroshi Inoue writes:
>> (2014/02/12 3:03), Tom Lane wrote:
>>> Also, the only remaining usage of dllwrap is in src/bin/pgevent/Makefile.
>>> Do we need that either?
> Sorry for the late reply.
> Attached is a patch to remove dllwarp from pgevent/Makefile.
Pushed, thanks.
Haribabu Kommi writes:
> I want to propose a new feature called "priority table" or "cache table".
> This is same as regular table except the pages of these tables are having
> high priority than normal tables. These tables are very useful, where a
> faster query processing on some particular tabl
On Thu, Feb 20, 2014 at 2:47 AM, Robert Haas wrote:
> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
> wrote:
>> On Thu, Feb 6, 2014 at 3:48 AM, Peter Eisentraut wrote:
>>> On 2/5/14, 1:31 PM, Robert Haas wrote:
On Tue, Feb 4, 2014 at 3:26 PM, Peter Eisentraut wrote:
> Perhaps this ty
On Thu, Feb 20, 2014 at 1:01 AM, David Fetter wrote:
> On Tue, Feb 18, 2014 at 04:39:27PM -0300, Alvaro Herrera wrote:
>> Heikki Linnakangas wrote:
>> > Add a GUC to report whether data page checksums are enabled.
>>
>> Is there are reason this wasn't back-patched to 9.3? I think it should
>> be.
On Thu, Feb 20, 2014 at 11:38 AM, Tom Lane wrote:
> Haribabu Kommi writes:
> > I want to propose a new feature called "priority table" or "cache table".
> > This is same as regular table except the pages of these tables are having
> > high priority than normal tables. These tables are very usefu
On Thu, Feb 20, 2014 at 9:43 AM, Michael Paquier
wrote:
> On Thu, Feb 20, 2014 at 2:47 AM, Robert Haas wrote:
>> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
>> wrote:
>>> On Thu, Feb 6, 2014 at 3:48 AM, Peter Eisentraut wrote:
On 2/5/14, 1:31 PM, Robert Haas wrote:
> On Tue, Feb 4,
I wrote:
>> The minimum-refactoring solution to this would be to tweak
>> pg_do_encoding_conversion() so that if the src_encoding is SQL_ASCII but
>> the dest_encoding isn't, it does pg_verify_mbstr() rather than nothing.
>> I'm not sure if this would break anything we need to have work,
>> though
On Thu, Feb 20, 2014 at 8:55 AM, Andres Freund wrote:
> On 2014-02-19 12:47:40 -0500, Robert Haas wrote:
>> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
>> wrote:
>> >> Yes, that's a good precedent in multiple ways.
>> > Here are updated patches to use pg_lsn instead of pglsn...
>>
>> OK, so I
Hiroshi Inoue writes:
> Attached is a patch to remove dllwarp from pgevent/Makefile.
Actually, it looks like this patch doesn't work at all:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2014-02-20%2001%3A00%3A53
Did I fat-finger the commit somehow? I made a couple of cosmet
Tom Lane escribió:
> Hiroshi Inoue writes:
> > Attached is a patch to remove dllwarp from pgevent/Makefile.
>
> Actually, it looks like this patch doesn't work at all:
>
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2014-02-20%2001%3A00%3A53
>
> Did I fat-finger the commit
(2014/02/20 10:32), Tom Lane wrote:
> Hiroshi Inoue writes:
>> Attached is a patch to remove dllwarp from pgevent/Makefile.
>
> Actually, it looks like this patch doesn't work at all:
Strangely enough it works here though I see double EXPORTS lines
in libpgeventdll.def.
> http://buildfarm.postg
Hiroshi Inoue writes:
> Seems EXPORTS line in exports.txt should be removed.
Done.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Feb 19, 2014 at 4:49 PM, Michael Paquier
wrote:
>> +1 for back-patching.
> Back-patching would be interesting for existing applications, but -1
> as it is a new feature :)
I think that it rises to the level of an omission in 9.3 that now
requires correction. Many of our users couldn't run
On Thu, Feb 20, 2014 at 6:24 AM, Haribabu Kommi
wrote:
> On Thu, Feb 20, 2014 at 11:38 AM, Tom Lane wrote:
>> > I want to propose a new feature called "priority table" or "cache
>> > table".
>> > This is same as regular table except the pages of these tables are
>> > having
>> > high priority tha
On Wed, Feb 19, 2014 at 08:22:13PM -0500, Tom Lane wrote:
> The more I looked into mbutils.c, the less happy I got. The attached
> proposed patch takes care of the missing-verification hole in
> pg_do_encoding_conversion() and pg_server_to_any(), and also gets rid
> of what I believe to be obsolet
On Thu, Feb 20, 2014 at 2:26 PM, Amit Kapila wrote:
> On Thu, Feb 20, 2014 at 6:24 AM, Haribabu Kommi
> wrote:
> > On Thu, Feb 20, 2014 at 11:38 AM, Tom Lane wrote:
> >> > I want to propose a new feature called "priority table" or "cache
> >> > table".
> >> > This is same as regular table except
Hello,
> It is just my personal opinion, but I think it would be convenient for
> users to alter inheritance trees that contain foreign tables the same
> way as inheritance trees that don't contain any foreign tables,
> without making user conscious of the inheritance trees contains
> foreign tab
Hi,
At Wed, 19 Feb 2014 16:17:05 +0900, Shigeru Hanada wrote
> 2014-02-18 19:29 GMT+09:00 Kyotaro HORIGUCHI
> :
> > Could you guess any use cases in which we are happy with ALTER
> > TABLE's inheritance tree walking? IMHO, ALTER FOREIGN TABLE
> > always comes with some changes of the data source
Hi All,
Here is a strange behaviour with master branch with head at
commit d3c4c471553265e7517be24bae64b81967f6df40
Author: Peter Eisentraut
Date: Mon Feb 10 21:47:19 2014 -0500
The OS is
[ashutosh@ubuntu repro]uname -a
Linux ubuntu 3.2.0-59-generic #90-Ubuntu SMP Tue Jan 7 22:43:51 UTC 2014
x
On Thu, Feb 13, 2014 at 1:54 AM, Marti Raudsepp wrote:
> I think the 1st patch now has a bug in initial_cost_mergejoin; you
> still pass the "presorted_keys" argument to cost_sort, making it
> calculate a partial sort cost, but generated plans never use partial
> sort. I think 0 should be passed
60 matches
Mail list logo
