On 09.01.2013 21:29, Karl O. Pinc wrote:
On 01/09/2013 01:08:39 PM, Jan Urbański wrote:
I actually still prefer to keep the signatures of
PLy_get_spi_sqlerrcode
and PLy_get_spi_error_data similar, so I'd opt for keeping the patch
as-is :)
I will send it on to a committer.
Looks good to me. C
On 28 January 2013 03:34, Noah Misch wrote:
> Would you commit to the same git repository the pgbench-tools data for the
> graphs appearing in that blog post? I couldn't readily tell what was
> happening below 16 clients due to the graphed data points blending together.
I'm afraid that I no long
>> On Thu, Jan 17, 2013 at 7:43 PM, Tatsuo Ishii wrote:
>>> So if my understating is correct, 1)Tomas Vondra commits to work on
>>> Windows support for 9.4, 2)on the assumption that one of Andrew
>>> Dunstan, Dave Page or Magnus Hagander will help him in Windows
>>> development.
>>>
>>> Ok? If so,
On 28 January 2013 03:34, Noah Misch wrote:
> On the EBS configuration with volatile fsync timings, the variability didn't
> go away with 15s runs. On systems with stable fsync times, 15s was no better
> than 2s. Absent some particular reason to believe 5s is better than 2s, I
> would leave it a
On 01/28/2013 02:15 AM, Robert Haas wrote:
>
> I am not sure whether it's really true that a capability mechanism
> could "never really satisfy" anyone. It worked for Linux.
I have no concern about using a capabilities approach for this, but I
don't think Linux is a great example here. Linux's cap
On 13-01-24 11:15 AM, Steve Singer wrote:
On 13-01-24 06:40 AM, Andres Freund wrote:
Fair enough. I am also working on a user of this infrastructure but that
doesn't help you very much. Steve Singer seemed to make some stabs at
writing an output plugin as well. Steve, how far did you get there?
On Mon, Jan 28, 2013 at 12:16:24AM +, Peter Geoghegan wrote:
> On 27 January 2013 02:31, Noah Misch wrote:
> > I did a few more benchmarks along the spectrum.
>
> > So that's a nice 27-53% improvement, fairly similar to the pattern for your
> > laptop pgbench numbers.
>
> I presume that this
Hi Noah,
On 27 January 2013 02:31, Noah Misch wrote:
> I did a few more benchmarks along the spectrum.
> So that's a nice 27-53% improvement, fairly similar to the pattern for your
> laptop pgbench numbers.
I presume that this applies to a tpc-b benchmark (the pgbench
default). Note that the re
On 01/27/2013 06:51 PM, james wrote:
On the contrary, only a few months ago there was a far from
groundless fear that Microsoft would do just that. Following
considerable outcry they changed their mind. But this is definitely
not just paranoia. As for w64 support, the mingw-64 project exists
On the contrary, only a few months ago there was a far from groundless fear
that Microsoft would do just that. Following considerable outcry they changed
their mind. But this is definitely not just paranoia. As for w64 support, the
mingw-64 project exists more or less explicitly to produce 64 b
Hi,
Please find attached a new version of the patch, answering to most of
your reviewing points. I'll post another version shortly with support
for pg_dump and alter owner/rename.
The main priority was to confirm that the implementation is conforming
to the rought specs and design we agreed befor
On Sat, 2013-01-26 at 23:23 -0500, Robert Haas wrote:
> > If we were to try to defer writing the WAL until the page was being
> > written, the most it would possibly save is the small XLOG_HINT WAL
> > record; it would not save any FPIs.
>
> How is the XLOG_HINT_WAL record kept small and why does
Jeff Janes writes:
> I thought that template0 did not need vacuuming because everything in
> it was frozen. But it looks like it does need vacuuming, and no one
> but autovac can connect in order to do that vacuum.
Everything in it *should* be frozen, typically. My recollection is that
we used
On 27 January 2013 17:11, Robert Haas wrote:
> On Sun, Jan 27, 2013 at 4:17 AM, Simon Riggs wrote:
>> On 25 January 2013 17:19, Robert Haas wrote:
>>> We
>>> could easily run across a system where pg_class order happens to be
>>> better than anything else we come up with.
>>
>> I think you shoul
On 01/27/2013 02:48 PM, james wrote:
Anyway, this is getting way off track. The point is that the MS SDKs and
compilers are a bit of a mess and that MinGW support is useful because
we can't rely on them continuing to offer free SDKs and compilers in
future.
Well, more compilers are always use
I have a stress test of the of the WAL replay which panics the
database over and over again to make sure it recovers correctly.
This is in 9.3dev.
The test was eventually freezing up because of wraparound. The
problem was that, on fast enough hardware, the intentional crashes
were always happeni
Peter Geoghegan writes:
> On 27 January 2013 18:57, Tom Lane wrote:
>> However, this patch is not that, and mere documentation isn't going to buy a
>> thing here IMO. Especially not user-facing documentation, as opposed
>> to something that might be in a developers' face when he's
>> copying-and
Robert Haas writes:
>> Well I would think that "we don't support droping several objects at
>> once yet in 9.3" is an acceptable answer.
>
> On that point, I disagree.
Ok, will provide a patch for that soon, then. I did give higher priority
to exposing more information, ok to switch. Read some mo
On Thu, Jan 24, 2013 at 1:57 PM, Alvaro Herrera
wrote:
> Hi,
>
> I have a bug pending that autovacuum fails to give priority to
> for-wraparound tables. When xid consumption rate is high and dead tuple
> creation is also high, it is possible that some tables are waiting for
> for-wraparound vacuu
Peter Geoghegan writes:
> On 26 January 2013 22:36, Tom Lane wrote:
>> BTW, one thing that struck me in a quick look-through is that the
>> ERRCODE_FOREIGN_KEY_VIOLATION patches seem to inconsistently send
>> either the PK or FK rel as the "errtable". Is this really per spec?
>> I'd have sort of
On 27 January 2013 18:57, Tom Lane wrote:
> Peter Geoghegan writes:
>> I think we may be talking at cross purposes here. Guarantee may have
>> been too strong a word, or the wrong word entirely. All that I really
>> want here is for there to be a coding standard instituted, so that in
>> future c
On Sun, Jan 27, 2013 at 2:38 PM, Phil Sorber wrote:
> On Fri, Jan 25, 2013 at 11:20 AM, Fujii Masao wrote:
>> On Fri, Jan 25, 2013 at 4:10 AM, Phil Sorber wrote:
>>> On Thu, Jan 24, 2013 at 1:12 PM, Fujii Masao wrote:
set_pglocale_pgservice() should be called?
I think that the co
Anyway, this is getting way off track. The point is that the MS SDKs and
compilers are a bit of a mess and that MinGW support is useful because
we can't rely on them continuing to offer free SDKs and compilers in future.
Well, more compilers are always useful, but complaining that Microsoft
mig
On Fri, Jan 25, 2013 at 11:20 AM, Fujii Masao wrote:
> On Fri, Jan 25, 2013 at 4:10 AM, Phil Sorber wrote:
>> On Thu, Jan 24, 2013 at 1:12 PM, Fujii Masao wrote:
>>> set_pglocale_pgservice() should be called?
>>>
>>> I think that the command name (i.e., pg_isready) should be given to
>>> PQpingP
On Fri, Jan 25, 2013 at 10:02 AM, Robert Haas wrote:
>
> I'm worried about the case of a very, very frequently updated table
> getting put ahead of a table that needs a wraparound vacuum, but only
> just. It doesn't sit well with me to think that the priority of that
> goes from 0 (we don't even
On Fri, Jan 25, 2013 at 9:19 AM, Robert Haas wrote:
>
> I think that to do this right, we need to consider not only the status
> quo but the trajectory. For example, suppose we have two tables to
> process, one of which needs a wraparound vacuum and the other one of
> which needs dead tuples remo
On Sun, Jan 27, 2013 at 12:57 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> The current patch implementation is to fill in the object id, name and
>>> schema with NULL when we have something else than a single object as the
>>> target. I did that when I realized we have a precedent with s
Peter Geoghegan writes:
> On 26 January 2013 22:36, Tom Lane wrote:
>> I'm inclined to remove the "requirements" business altogether and just
>> document that these fields may be supplied, or words to that effect.
> I think we may be talking at cross purposes here. Guarantee may have
> been too
On Fri, Jan 25, 2013 at 11:47 AM, Erik Rijkers wrote:
> On Wed, January 23, 2013 08:36, Alexander Korotkov wrote:
> > Hi!
> >
> > Some quick answers to the part of notes/issues. I will provide rest of
> > answers soon.
> >
> [...]
> > trgm-regexp-0.10.patch.gz27 k
>
> Trying to build this I g
On Sun, Jan 27, 2013 at 1:09 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 25, 2013 at 2:59 PM, Kohei KaiGai wrote:
>>> 2013/1/20 Tom Lane :
The traditional answer to that, which not only can be done already in
all existing releases but is infinitely more flexible than any
>
On Sun, Jan 27, 2013 at 6:30 AM, Josh Berkus wrote:
> So while testing some replication stuff on 9.2.2 I discovered that it's
> completely possible to connect a replica to itself. Seems like we ought
> to at least be able to detect and log *that*.
We could certainly alter the protocol so that it
Robert Haas writes:
> On Fri, Jan 25, 2013 at 2:59 PM, Kohei KaiGai wrote:
>> 2013/1/20 Tom Lane :
>>> The traditional answer to that, which not only can be done already in
>>> all existing releases but is infinitely more flexible than any
>>> hard-wired scheme we could implement, is that you cre
Robert Haas writes:
>> The current patch implementation is to fill in the object id, name and
>> schema with NULL when we have something else than a single object as the
>> target. I did that when I realized we have a precedent with statement
>> triggers and that we would maybe share the implement
2013/1/27 Tom Lane :
> Craig Ringer writes:
>> That's what it sounds like - confirming that PostgreSQL is really fully
>> shut down.
>
>> I'm not sure how you could do that over a protocol connection, myself.
>> I'd just read the postmaster pid from the pidfile on disk and then `kill
>> -0` it in
Craig Ringer writes:
> That's what it sounds like - confirming that PostgreSQL is really fully
> shut down.
> I'm not sure how you could do that over a protocol connection, myself.
> I'd just read the postmaster pid from the pidfile on disk and then `kill
> -0` it in a delay loop until the `kill`
On 13-01-22 11:30 AM, Andres Freund wrote:
Hi,
I pushed a new rebased version (the xlogreader commit made it annoying
to merge).
The main improvements are
* way much coherent code internally for intializing logical rep
* explicit control over slots
* options for logical replication
Exactly w
On Sun, Jan 27, 2013 at 12:08 PM, Steve Singer wrote:
> On 13-01-26 11:11 PM, Robert Haas wrote:
>> On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
>> wrote:
>>>
>>> My understanding is that if the command string we give to event triggers
>>> is ambiguous (sub-object names, schema qualificatio
On Sun, Jan 27, 2013 at 4:17 AM, Simon Riggs wrote:
> On 25 January 2013 17:19, Robert Haas wrote:
>> We
>> could easily run across a system where pg_class order happens to be
>> better than anything else we come up with.
>
> I think you should read that back to yourself and see if you still
> fe
On 13-01-26 11:11 PM, Robert Haas wrote:
On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
wrote:
My understanding is that if the command string we give to event triggers
is ambiguous (sub-object names, schema qualifications, etc), it comes
useless for logical replication use. I'll leave it to
On Sun, Jan 27, 2013 at 3:50 AM, Simon Riggs wrote:
> If we attempted to defer the FPI last thing before write, we'd need to
> cope with the case that writes at checkpoint occur after the logical
> start of the checkpoint, and also with the overhead of additional
> writes at checkpoint time.
Oh,
On Sun, Jan 27, 2013 at 1:01 AM, Michael Paquier
wrote:
>> So... what happens when recovery ends? Do the settings loaded from
>> recovery.conf get reverted, or what?
>
> With current patch the settings are kept if set in postgresql.conf and
> discarded if they are loaded as GUC after a server res
On 27 January 2013 11:30, Josh Berkus wrote:
> So while testing some replication stuff on 9.2.2 I discovered that it's
> completely possible to connect a replica to itself. Seems like we ought
> to at least be able to detect and log *that*.
How do we do that?
--
Simon Riggs
From: "Fujii Masao"
On Sun, Jan 27, 2013 at 12:17 AM, MauMau wrote:
Although you said the fix will solve my problem, I don't feel it will.
The
discussion is about the crash when the standby "re"starts after the
primary
vacuums and truncates a table. On the other hand, in my case, the
standb
On Sun, Jan 27, 2013 at 12:42:48PM +0800, Chen Huajun wrote:
> I found the ecpg programs can not output the native language messages which
> defined in ecpglib6-9.x.mo.
> The reason is a misstake in "src/interfaces/ecpg/ecpglib/misc.c",
> and i mad a patch for that.
Thanks for finding an fixing th
All,
So while testing some replication stuff on 9.2.2 I discovered that it's
completely possible to connect a replica to itself. Seems like we ought
to at least be able to detect and log *that*.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing lis
On Sun, Jan 27, 2013 at 12:17 AM, MauMau wrote:
> From: "Fujii Masao"
>>
>> On Thu, Jan 24, 2013 at 11:53 PM, MauMau wrote:
>>>
>>> I'm wondering if the fix discussed in the above thread solves my problem.
>>> I
>>> found the following differences between Horiguchi-san's case and my case:
>>>
>>
On 25 January 2013 17:19, Robert Haas wrote:
> We
> could easily run across a system where pg_class order happens to be
> better than anything else we come up with.
I think you should read that back to yourself and see if you still
feel the word "easily" applies here.
I agree with Tom that its
On 25 January 2013 20:29, Robert Haas wrote:
>> The checksums patch also introduces another behavior into
>> SetBufferCommitInfoNeedsSave, which is to write an XLOG_HINT WAL record
>> if checksums are enabled (to avoid torn page hazards). That's only
>> necessary for changes where the caller does
48 matches
Mail list logo
