"Sergey E. Koposov" writes:
> I'm seeing something weird which looks like a bug in 9.1rc1 after the
> upgrade 8.4->9.0->9.1 done using pg_upgrade.
Hm, I wonder what pg_upgrade left relpages/reltuples set to ...
> INFO: "lassource": found 0 removable, 0 nonremovable row versions in 0
> out of
Ants Aasma writes:
> On Mon, Aug 29, 2011 at 10:12 PM, Tom Lane wrote:
>> Also, if the PPC machine really is hyperthreaded (the internal webpage
>> for it says "Hyper? True" but /proc/cpuinfo doesn't provide any clear
>> indications), that might mean it's not going to scale too well past 16x
>> t
On Mon, Aug 29, 2011 at 8:44 PM, YAMAMOTO Takashi
wrote:
>> On Sun, Aug 28, 2011 at 8:28 PM, YAMAMOTO Takashi
>> wrote:
On men, 2011-08-22 at 04:09 +, YAMAMOTO Takashi wrote:
> i know that postgresql uses ts=4 for C source code.
> but how about documatation?
I'd say ide
On Sun, Aug 28, 2011 at 8:28 PM, YAMAMOTO Takashi
wrote:
>> On men, 2011-08-22 at 04:09 +, YAMAMOTO Takashi wrote:
>>> i know that postgresql uses ts=4 for C source code.
>>> but how about documatation?
>>
>> I'd say ideally don't use any tabs at all.
>
> i agree.
>
>> It appears to be geared
Andrew Dunstan writes:
> On 08/28/2011 04:15 PM, Tom Lane wrote:
>> The bottom line seems to be that autoconf 2.59 is seriously broken on
>> recent toolchains. Should we try to do something about that, like
>> migrate the 8.2 and 8.3 releases to a newer autoconf? 8.2 is close
>> enough to EOL th
On Fri, Aug 26, 2011 at 10:42 PM, Robert Haas wrote:
> +1 for --if-exists, but -X isn't doing a lot for me, especially since
> we've used -X for other purposes in other commands. I'd just skip
> having a short form for this one.
Fine by me. Updated patch attached.
Josh
diff --git a/doc/src/sgml
On Mon, Aug 29, 2011 at 07:49:24PM +0200, hubert depesz lubaczewski wrote:
> On Mon, Aug 29, 2011 at 06:54:41PM +0200, hubert depesz lubaczewski wrote:
> vacuumdb: vacuuming of database "etsy_v2" failed: ERROR: could not access
> status of transaction 3429738606
> DETAIL: Could not open file "pg
Sorry, forgot to cc the list.
On Mon, Aug 29, 2011 at 10:12 PM, Tom Lane wrote:
> Also, if the PPC machine really is hyperthreaded (the internal webpage
> for it says "Hyper? True" but /proc/cpuinfo doesn't provide any clear
> indications), that might mean it's not going to scale too well past 16
On 29 August 2011 20:43, Andrew Dunstan wrote:
>
>
> On 08/29/2011 03:35 PM, David E. Wheeler wrote:
>>
>> On Aug 29, 2011, at 12:30 PM, Tom Lane wrote:
>>
When it gets to the timezone "America/Chicago" at the end, this is
handled in the DTK_DATE case, because of the "/". But because pty
Andrew Dunstan writes:
> On 08/29/2011 03:35 PM, David E. Wheeler wrote:
>> On Aug 29, 2011, at 12:30 PM, Tom Lane wrote:
>>> Do we actually *want* to support this? The "T" is supposed to mean that
>>> the string is strictly ISO-conformant, no?
> In that case we shouldn't be accepting an abbrevi
On 08/29/2011 03:35 PM, David E. Wheeler wrote:
On Aug 29, 2011, at 12:30 PM, Tom Lane wrote:
When it gets to the timezone "America/Chicago" at the end, this is
handled in the DTK_DATE case, because of the "/". But because ptype is
still set, it is expecting this to be an ISO time, so it erro
On Aug 29, 2011, at 12:30 PM, Tom Lane wrote:
>> When it gets to the timezone "America/Chicago" at the end, this is
>> handled in the DTK_DATE case, because of the "/". But because ptype is
>> still set, it is expecting this to be an ISO time, so it errors out.
>
> Do we actually *want* to suppor
Dean Rasheed writes:
> On 29 August 2011 15:40, Andrew Dunstan wrote:
>> Why do we parse this as a correct timestamptz literal:
>>2011-08-29T09:11:14.123 CDT
>> but not this:
>>2011-08-29T09:11:14.123 America/Chicago
> For this input string the "T" is recognised as the start of an ISO
>
On 08/29/2011 11:03 AM, Robert Haas wrote:
Instead of doing this only when vacuum costing is active, could we
drive it off of the pgBufferUsage stuff (maybe with a few tweaks...)
and do it unconditionally?
Sure. I've wondered about an ever larger refactoring, to reorient
vacuum costing ar
"Kevin Grittner" writes:
> Robert Haas wrote:
>> Stepping beyond the immediate issue of whether we want an unlocked
>> test in there or not (and I agree that based on these numbers we
>> don't), there's a clear and puzzling difference between those sets
>> of numbers. The Opteron test is showing
Robert Haas wrote:
> Stepping beyond the immediate issue of whether we want an unlocked
> test in there or not (and I agree that based on these numbers we
> don't), there's a clear and puzzling difference between those sets
> of numbers. The Opteron test is showing 32 clients getting about
> 23
Excerpts from hubert depesz lubaczewski's message of lun ago 29 14:49:24 -0300
2011:
> On Mon, Aug 29, 2011 at 06:54:41PM +0200, hubert depesz lubaczewski wrote:
> > On Fri, Aug 26, 2011 at 05:28:35PM +0200, hubert depesz lubaczewski wrote:
> > > On Fri, Aug 26, 2011 at 12:18:55AM -0400, Bruce Mom
Greg Stark writes:
> I was going to say the same thing as Tom that sequence points and
> volatile pointers have nothing at all to do with each other. However
> my brief searching online actually seemed to indicate that in fact the
> compiler isn't supposed to reorder volatile memory accesses acros
On Mon, Aug 29, 2011 at 2:15 PM, Tom Lane wrote:
> These tests were run on a 32-CPU Opteron machine (Sun Fire X4600 M2,
> 8 quad-core sockets). Test conditions the same as my IA64 set, except
> for the OS and the -j switches:
>
> Stock git head:
>
> pgbench -c 1 -j 1 -S -T 300 bench tps = 9
Robert Haas writes:
> I'm actually not convinced that we're entirely consistent here about
> what we require the semantics of acquiring and releasing a spinlock to
> be. For example, on x86 and x86_64, we acquire the lock using xchgb,
> which acts a full memory barrier. But when we release the l
I wrote:
> I am also currently running tests on x86_64 and PPC using Red Hat test
> machines --- expect results later today.
OK, I ran some more tests. These are not directly comparable to my
previous results with IA64, because (a) I used RHEL6.2 and gcc 4.4.6;
(b) I used half as many pgbench thr
On Mon, Aug 29, 2011 at 1:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> This discussion seems to miss the fact that there are two levels of
>> reordering that can happen. First, the compiler can move things
>> around. Second, the CPU can move things around.
>
> Right, I think that's exactly t
On Mon, Aug 29, 2011 at 06:54:41PM +0200, hubert depesz lubaczewski wrote:
> On Fri, Aug 26, 2011 at 05:28:35PM +0200, hubert depesz lubaczewski wrote:
> > On Fri, Aug 26, 2011 at 12:18:55AM -0400, Bruce Momjian wrote:
> > >
> > > OK, this was very helpful. I found out that there is a bug in curr
On 29 August 2011 15:40, Andrew Dunstan wrote:
>
> Why do we parse this as a correct timestamptz literal:
>
> 2011-08-29T09:11:14.123 CDT
>
> but not this:
>
> 2011-08-29T09:11:14.123 America/Chicago
>
> Replace the ISO-8601 style T between the date and time parts of the latter
> with a spac
On Mon, Aug 29, 2011 at 5:53 PM, Robert Haas wrote:
> Even though the compiler may emit those instructions in exactly that
> order, an x86 CPU can, IIUC, decide to load B before it finishes
> storing A, so that the actual apparent execution order as seen by
> other CPUs will be either the above,
Robert Haas writes:
> This discussion seems to miss the fact that there are two levels of
> reordering that can happen. First, the compiler can move things
> around. Second, the CPU can move things around.
Right, I think that's exactly the problem with the previous wording of
that comment; it d
On Sat, Aug 27, 2011 at 1:32 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> EXPLAIN SELECT * FROM test1 WHERE sha1 in (SELECT sha1 FROM test2);
>> QUERY PLAN
>> --
>> Hash Semi Join (cost=30.52
On Fri, Aug 26, 2011 at 05:28:35PM +0200, hubert depesz lubaczewski wrote:
> On Fri, Aug 26, 2011 at 12:18:55AM -0400, Bruce Momjian wrote:
> >
> > OK, this was very helpful. I found out that there is a bug in current
> > 9.0.X, 9.1.X, and HEAD that I introduced recently when I excluded temp
> >
On Mon, Aug 29, 2011 at 12:00 PM, Tom Lane wrote:
> Greg Stark writes:
>> The confusion for me is that it's talking about sequence points and
>> volatile pointers in the same breath as if one implies the other.
>> Making something a volatile pointer dose not create a sequence point.
>> It require
Shigeru Hanada writes:
> I'd like to develop pushing down JOIN between foreign tables which are
> on one foreign server, to enhance performance of joining foreign tables
> by reducing data transfer.
This sketch sounds pretty reasonable, with one minor point that's not
going to work:
> Costs of F
Greg Stark writes:
> The confusion for me is that it's talking about sequence points and
> volatile pointers in the same breath as if one implies the other.
> Making something a volatile pointer dose not create a sequence point.
> It requires that the compiler not move the access or store across a
On Mon, Aug 29, 2011 at 4:07 PM, Tom Lane wrote:
>> * ANOTHER CAUTION: be sure that TAS(), TAS_SPIN(), and
>> S_UNLOCK() represent
>> * sequence points, ie, loads and stores of other values must not be
>> moved
>> * across a lock or unlock. In most cases it suffices to make
>>
On Mon, Aug 29, 2011 at 11:42 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Aug 29, 2011 at 11:07 AM, Tom Lane wrote:
>>> Robert Haas writes:
IIUC, this is basically total nonsense.
>
>>> It could maybe be rewritten for more clarity, but it's far from being
>>> nonsense. The respon
Robert Haas writes:
> On Mon, Aug 29, 2011 at 11:07 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> IIUC, this is basically total nonsense.
>> It could maybe be rewritten for more clarity, but it's far from being
>> nonsense. The responsibility for having an actual hardware memory fence
>> inst
On Mon, Aug 29, 2011 at 11:03 AM, Valentine Gogichashvili
wrote:
>> Has anyone else ever found this error message confusing:
>> ERROR: 22021: invalid byte sequence for encoding "UTF8": 0xdb24
>> I think what is really meant is better expressed like this:
>> ERROR: 22021: invalid byte sequence fo
On Mon, Aug 29, 2011 at 11:07 AM, Tom Lane wrote:
> Robert Haas writes:
>> OK, done. I think while we're tidying up here we ought to do
>> something about this comment:
>
>> * ANOTHER CAUTION: be sure that TAS(), TAS_SPIN(), and
>> S_UNLOCK() represent
>> * sequence points, ie, loads
Robert Haas writes:
> OK, done. I think while we're tidying up here we ought to do
> something about this comment:
> * ANOTHER CAUTION: be sure that TAS(), TAS_SPIN(), and
> S_UNLOCK() represent
> * sequence points, ie, loads and stores of other values must not be
> moved
> *
>
> Has anyone else ever found this error message confusing:
> ERROR: 22021: invalid byte sequence for encoding "UTF8": 0xdb24
> I think what is really meant is better expressed like this:
> ERROR: 22021: invalid byte sequence for encoding "UTF8": 0xdb 0x24
> Otherwise it looks like a codepoint o
On Sun, Aug 28, 2011 at 5:54 AM, Greg Smith wrote:
> Updated patch cleans up two diff mistakes made when backing out the progress
> report feature. The tip-off I screwed up should have been the absurdly high
> write rate shown. The usleep was accidentally deleted, so it was running
> without cos
Hi all,
I'd like to develop pushing down JOIN between foreign tables which are
on one foreign server, to enhance performance of joining foreign tables
by reducing data transfer. This would need many changes in several part
of PG such as planner, executor and FDW API, so please let me describe
my
Why do we parse this as a correct timestamptz literal:
2011-08-29T09:11:14.123 CDT
but not this:
2011-08-29T09:11:14.123 America/Chicago
Replace the ISO-8601 style T between the date and time parts of the
latter with a space and the parser is happy again.
cheers
andrew
--
Sent v
On Sun, Aug 28, 2011 at 8:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Aug 28, 2011 at 7:19 PM, Tom Lane wrote:
>>> (IOW, +1 for inventing a second macro to use in the delay loop only.)
>
>> Beautiful. Got a naming preference for that second macro? I
>> suggested TAS_SPIN() because
On 29 Srpen 2011, 7:47, Noah Misch wrote:
> On Sat, Aug 27, 2011 at 03:57:16PM +0200, Tomas Vondra wrote:
>> On 27 Srpen 2011, 6:01, Noah Misch wrote:
>> > Could you remove this hazard by adding a step "2a. psql -c
>> CHECKPOINT"?
>>
>> I already do that, but it really does not solve the issue. It
On 29/08/11 08:21, Pavel Stehule wrote:
> Hello
Hi Pavel,
> is there some some result, report from PL summit?
The notes taken during the summit are here:
http://wiki.postgresql.org/wiki/PgCon_2011_PL_Summit
I think Selena also sent a "summary and next steps" mail to the
participants, perhaps i
On 26.08.2011 17:18, Alexander Korotkov wrote:
On Thu, Aug 25, 2011 at 11:08 PM, Heikki Linnakangas<
heikki.linnakan...@enterprisedb.com> wrote:
Could you share the test scripts, patches and data sets etc. needed to
reproduce the tests you've been running? I'd like to try them out on a test
se
45 matches
Mail list logo
