Hi Horiguchi-san,
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 so implicitly
> invoking of such commands should be d
On Thu, Jan 2, 2014 at 4:38 PM, Christian Kruse
wrote:
> Hi,
>
> On 02/01/14 10:02, Andres Freund wrote:
>> > Christian's idea of a context line seems plausible to me. I don't
>> > care for this implementation too much --- a global variable? Ick.
>>
>> Yea, the data should be stored in ErrorCont
Hello,
At Tue, 18 Feb 2014 19:24:50 +0900, "Etsuro Fujita" wrote
> > From: Shigeru Hanada [mailto:shigeru.han...@gmail.com]
> > 2014-02-10 21:00 GMT+09:00 Etsuro Fujita :
> > > (2014/02/07 21:31), Etsuro Fujita wrote:
> > >> So, I've modified the patch so
> > >> that we continue to disallow SET ST
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 which I was able to confirm. The customer's complaint is that
>> ce
On Tue, Feb 18, 2014 at 5:56 PM, Peter Geoghegan wrote:
> That was my first suspicion, but then re-indexing didn't help, while
> VACUUM FREEZE had the immediate effect of making both plans give a
> consistent answer.
I should add that this is an unremarkable int4 primary key (which was
dropped an
On Tue, Feb 18, 2014 at 5:50 PM, Alvaro Herrera
wrote:
> The multixact bugs would cause tuples to be hidden at the heap level.
> If the tuples are visible in a seqscan, then these are more likely to be
> related to index problems, not multixact problem.
That was my first suspicion, but then re-in
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 which I was able to confirm. The customer's complaint is that
> certain rows are either visible or invisible, depending on wheth
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 which I was able to confirm. The customer's complaint is that
certain rows are either visible or invisible, depending on whether an
index scan is used or a s
(2014/02/12 15:31), Inoue, Hiroshi wrote:
> (2014/02/12 3:03), Tom Lane wrote:
>> Hiroshi Inoue writes:
>>> (2014/02/09 8:06), Andrew Dunstan wrote:
Yeah. Incidentally, we didn't quite get rid of dlltool for Cygwin. We
did get rid of dllwrap. But I agree this is worth trying for Mingw.
>
Hello,
At Tue, 18 Feb 2014 09:49:23 -0500, Tom Lane wrote
> Kyotaro HORIGUCHI writes:
> > 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 so implicitly
> > invokin
I wrote:
> I looked through all the callers of pg_do_encoding_conversion(), and
> AFAICS this change is a good idea. There are a whole bunch of places
> that use pg_do_encoding_conversion() to convert from the database encoding
> to encoding X (most usually UTF8), and right now if you do that in a
I wrote:
> dig...@126.com writes:
>> select t, t::bytea from convert_from('\xeec1', 'sql_ascii') as g(t);
>> [ fails to check that string is valid in database encoding ]
> Hm, yeah. Normal input to the database goes through pg_any_to_server(),
> which will apply a validation step if the source en
On Tue, Feb 18, 2014 at 9:12 AM, Heikki Linnakangas wrote:
> On 02/18/2014 06:27 PM, Jeff Janes wrote:
>
>> On Tue, Feb 18, 2014 at 3:49 AM, MauMau wrote:
>>
>> --- or in other words, greater variance in response times. With my
>>> simple
>>> understanding, that sounds like a problem for respo
On 2014-02-18 23:01:08 +0200, Heikki Linnakangas wrote:
> On 02/18/2014 10:51 PM, Andres Freund wrote:
> >On 2014-02-18 19:12:32 +0200, Heikki Linnakangas wrote:
> >>Yeah, I'm pretty sure that's because of the extra checkpoints. If you look
> >>at the individual test graphs, there are clear spikes
On 2014-02-17 10:44:41 +0100, Christian Kruse wrote:
> This is true for now. But one of the purposes of using
> LocalPgBackendStatus instead of PgBackendStatus was to be able to add
> more fields like this in future. And thus we might need to change this
> in future, so why not do it now?
I don't
On 02/18/2014 10:51 PM, Andres Freund wrote:
On 2014-02-18 19:12:32 +0200, Heikki Linnakangas wrote:
Yeah, I'm pretty sure that's because of the extra checkpoints. If you look
at the individual test graphs, there are clear spikes in latency, but the
latency is otherwise small. With a higher TPS,
On 2014-02-18 08:35:35 +0900, Michael Paquier wrote:
> On Tue, Feb 18, 2014 at 7:22 AM, Andres Freund wrote:
> > On 2014-02-17 23:07:45 +0900, Michael Paquier wrote:
> >> On Mon, Feb 17, 2014 at 6:28 PM, Andres Freund
> >> wrote:
> >> > I don't think this really has gone above Needs Review yet.
On 2014-02-18 19:12:32 +0200, Heikki Linnakangas wrote:
> You're missing MauMau's point. In essence, he's comparing two systems with
> the same number of clients, issuing queries as fast as they can, and one can
> do 2000 TPS while the other one can do 1 TPS. You would expect the
> lower-throug
On 2014-02-18 22:23:59 +0200, Heikki Linnakangas wrote:
> On 02/18/2014 09:39 PM, 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.
Thirded.
> I
On 02/18/2014 09:39 PM, 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.
I considered it a new feature, so not back-patching was the default. If
you want t
On Tue, Feb 18, 2014 at 11:39 AM, Alvaro Herrera
wrote:
> Is there are reason this wasn't back-patched to 9.3? I think it should
> be.
+1.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
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.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent
On 02/17/2014 10:36 PM, Andres Freund wrote:
On 2014-02-17 22:30:54 +0200, Heikki Linnakangas wrote:
This is what I came up with. I like it, I didn't have to contort lwlocks as
much as I feared. I added one field to LWLock structure, which is used to
store the position of how far a WAL inserter
On 02/18/2014 06:27 PM, Jeff Janes wrote:
On Tue, Feb 18, 2014 at 3:49 AM, MauMau wrote:
--- or in other words, greater variance in response times. With my simple
understanding, that sounds like a problem for response-sensitive users.
If you need the throughput provided by 9.4, then using 9
From: "Magnus Hagander"
Unfortunately we missed the releases that have just been wrapped.
It's really unfortunate... I hope the next minor release will be soon.
I've applied this and backpatched to 9.3 and 9.2, which is as far back as
it goes cleanly.
Thank you.
In 9.1 the build system
On Tue, Feb 18, 2014 at 3:49 AM, MauMau wrote:
> From: "Andres Freund"
>
>> On 2014-02-18 01:35:52 +0900, MauMau wrote:
>>
>>> For example, please see the max latencies of test set 2 (PG 9.3) and test
>>> set 4 (xlog scaling with padding). They are 207.359 and 1219.422
>>> respectively. The th
Robert Haas writes:
> On Sat, Feb 15, 2014 at 4:17 PM, Peter Eisentraut wrote:
>> We already know that the uuid-ossp extension doesn't build OS X unless a
>> small patch is applied.
>>
>> This has now gotten slightly worse after the Autoconf upgrade, because
>> it will now fail if a header is pr
From: "Magnus Hagander"
We already have two different versions of make_absolute_path() in the tree
- one in src/backend/utils/init/miscinit.c and one in
src/test/regress/pg_regress.c.
I don't think we need a third one.
If we put it in port/ like this patch done, then we should make the other
c
On Sat, Feb 15, 2014 at 4:17 PM, Peter Eisentraut wrote:
> We already know that the uuid-ossp extension doesn't build OS X unless a
> small patch is applied.
>
> This has now gotten slightly worse after the Autoconf upgrade, because
> it will now fail if a header is present but cannot be compiled.
On Tue, Feb 18, 2014 at 3:28 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > I've applied this and backpatched to 9.3 and 9.2, which is as far back as
> > it goes cleanly.
>
> > In 9.1 the build system looked significantly different, which makes it
> > strange since the original report in this
Kyotaro HORIGUCHI writes:
> 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 so implicitly
> invoking of such commands should be defaultly turned off. If the
> ALTER'ing
Magnus Hagander writes:
> I've applied this and backpatched to 9.3 and 9.2, which is as far back as
> it goes cleanly.
> In 9.1 the build system looked significantly different, which makes it
> strange since the original report in this thread was about 9.1 but the
> patch supplied clearly wasn't
On Mon, Feb 3, 2014 at 3:06 PM, MauMau wrote:
> From: "Rajeev rastogi"
>
> I will update commitFest with the latest patch immediately after sending
>> the mail.
>>
>
> OK, done setting the status to ready for committer.
>
>
We already have two different versions of make_absolute_path() in the t
On Tue, Feb 4, 2014 at 12:57 PM, Craig Ringer wrote:
> On 02/04/2014 07:28 PM, MauMau wrote:
> >>
> >
> > Please don't mind, I didn't misunderstand your intent. I think we
> > should apply this in the next minor release to avoid unnecessary
> > confusion -- more new users would use PostgreSQL on
Hello
2014-02-17 22:14 GMT+01:00 Pavel Stehule :
> Hello
>
>
> 2014-02-17 18:10 GMT+01:00 Alvaro Herrera :
>
> Jeevan Chalke escribió:
>>
>> I don't understand this code. (Well, it's pg_dump.) Or maybe I do
>> understand it, and it's not doing what you think it's doing. I mean, in
>> this par
On 2014-02-18 20:49:06 +0900, MauMau wrote:
> From: "Andres Freund"
> >On 2014-02-18 01:35:52 +0900, MauMau wrote:
> >>For example, please see the max latencies of test set 2 (PG 9.3) and test
> >>set 4 (xlog scaling with padding). They are 207.359 and 1219.422
> >>respectively. The throughput i
From: "Andres Freund"
On 2014-02-18 01:35:52 +0900, MauMau wrote:
For example, please see the max latencies of test set 2 (PG 9.3) and test
set 4 (xlog scaling with padding). They are 207.359 and 1219.422
respectively. The throughput is of course greatly improved, but I think
the
response ti
From: "Peter Geoghegan"
You mentioned a hang during a B-Tree insert operation - do you happen
to have a backtrace that relates to that?
Sorry, I may have misunderstood. The three stack traces I attached are not
related to btree. I recall that I saw one stack trace containing
bt_insert(), b
(2014/02/17 21:44), Rajeev rastogi wrote:
It got compiled successfully on Windows.
Thank you for checking on Windows! It is very helpful for me.
Can we allow to add three statistics? I think only adding stdev is difficult to
image for user. But if there are min and max, we can image each statem
This patch is in "Waiting for Author" for a couple of weeks and has
received a review at least from Andres during this commit fest. As the
situation is not much progressing, I am going to mark it as "Returned
with feedback".
If there are any problems with that please let me know.
Thanks,
--
Michae
Hello,
> 2014-02-10 21:00 GMT+09:00 Etsuro Fujita :
> > (2014/02/07 21:31), Etsuro Fujita wrote:
> >> So, I've modified the patch so
> >> that we continue to disallow SET STORAGE on a foreign table *in the same
> >> manner as before*, but, as your patch does, allow it on an inheritance
> >> hierar
> From: Shigeru Hanada [mailto:shigeru.han...@gmail.com]
> 2014-02-10 21:00 GMT+09:00 Etsuro Fujita :
> > (2014/02/07 21:31), Etsuro Fujita wrote:
> >> So, I've modified the patch so
> >> that we continue to disallow SET STORAGE on a foreign table *in the
> >> same manner as before*, but, as your
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, and shipping
> that. Then people who want something else can
On 2014-02-17 18:49:59 -0800, Peter Geoghegan wrote:
> On Mon, Feb 17, 2014 at 6:35 PM, Robert Haas wrote:
> > What I actually suspect is going to happen if we ship this as-is is
> > that people are going to start building logical replication solutions
> > on top of the test_decoding module even t
On 2014-02-17 21:10:26 -0500, Tom Lane wrote:
> Robert Haas writes:
> > 1. How safe is it to try to do decoding inside of a regular backend?
> > What we're doing here is entering a special mode where we forbid the
> > use of regular snapshots in favor of requiring the use of "decoding
> > snapshot
Hi Robert,
On 2014-02-17 20:31:34 -0500, Robert Haas wrote:
> 1. How safe is it to try to do decoding inside of a regular backend?
> What we're doing here is entering a special mode where we forbid the
> use of regular snapshots in favor of requiring the use of "decoding
> snapshots", and forbid a
On 02/16/2014 10:19 PM, Jim Nasby wrote:
On 1/24/14, 3:52 PM, Jaime Casanova wrote:
On Tue, Dec 3, 2013 at 11:25 AM, Bruce Momjian wrote:
Is everyone else OK with this approach? Updated patch attached.
Hi,
I started to look at this patch and i found that it fails an assertion
as soon as y
47 matches
Mail list logo
