On Fri, Jun 27, 2014 at 9:11 AM, Amit Kapila
wrote:
> On Thu, Jun 26, 2014 at 1:49 PM, Christoph Berg wrote:
> > Re: Amit Kapila 2014-06-26
> > >
> > > How about adding a note in Alter System so that users are aware of
> > > such behaviour and can ensure that they don't have duplicate entries?
>
On Fri, Jul 4, 2014 at 12:01:37AM -0400, Bruce Momjian wrote:
> > The most robust, but not trivial, approach seems to be to prevent toast
> > table creation if there wasn't a set_next_toast_pg_class_oid(). Then,
> > after all relations are created, iterate over all pg_class entries that
> > possib
On 07/02/2014 10:15 PM, Andrew Gierth wrote:
> (Had one request so far for a mode() variant that returns the unique
> modal value if one exists, otherwise null; so the current set of
> ordered-set aggs by no means exhausts the possible applications.)
I resemble that remark. :)
But seriously, am I
On 07/05/2014 02:17 AM, Thomas Munro wrote:
> As an exercise I hacked up the simplest code I could think of that would
> demonstrate a faster DISTINCT based on skipping ahead to the next
> distinct value in an index-only scan. Please see the attached (extremely
> buggy) patch, and the example sessi
Hello
As an exercise I hacked up the simplest code I could think of that would
demonstrate a faster DISTINCT based on skipping ahead to the next distinct
value in an index-only scan. Please see the attached (extremely buggy)
patch, and the example session below. (It's against my natural instinct
> Kaigai,
>
> On Thursday, July 3, 2014, Kouhei Kaigai wrote:
>
>
> Sorry for my late responding, now I'm catching up the discussion.
>
> > * Robert Haas (robertmh...@gmail.com ) wrote:
> > > On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed
> >
> > wrote:
> > > > If
Re: Craig Ringer 2014-07-02 <53b39638.9010...@2ndquadrant.com>
> > +1. The buildfarm has one such member already, anchovy, and I recall it
> > having given at least one helpful forewarning. It shows as "Arch Linux
> > testing [updated daily]", which is sufficient annotation for me. Its
> > fail
At 2014-07-04 13:43:46 -0400, alvhe...@2ndquadrant.com wrote:
>
> Now, I see that pg_xlogdump is checking for NULL return, but I'm not
> sure this is the best possible API.
Note that the patched pg_xlogdump will display "rm_name/0xNN" for any
records that rm_identify returns a NULL for.
Earlier,
Andres Freund wrote:
> On 2014-07-04 18:31:34 +0800, gotoschool6g wrote:
> > Carp the code:
> >
> > const char *
> > clog_identify(uint8 info)
> > {
> > switch (info)
> > {
> > case CLOG_ZEROPAGE:
> >return "ZEROPAGE";
> > case CLOG_TRUNCATE:
> >return "TRUNCATE";
>
At 2014-07-04 21:02:33 +0530, a...@2ndquadrant.com wrote:
>
> > +/*
> > + */
> > +static const struct config_enum_entry backup_block_compression_options[] =
> > {
Oh, I forgot to mention that the configuration setting changes are also
pending. I think we had a working consensus to use full_page_c
At 2014-07-02 15:51:08 -0700, p...@heroku.com wrote:
>
> Attached revision factors in everyone's concerns here, I think.
Is anyone planning to review Peter's revised patch?
> These new measures make the coding somewhat more complex than that of
> the initial version, although overall the parser c
Kaigai,
On Thursday, July 3, 2014, Kouhei Kaigai wrote:
> Sorry for my late responding, now I'm catching up the discussion.
>
> > * Robert Haas (robertmh...@gmail.com ) wrote:
> > > On Tue, Jul 1, 2014 at 3:20 PM, Dean Rasheed >
> > wrote:
> > > > If RLS quals are instead regarded as constraint
At 2014-07-04 19:27:10 +0530, rahilasye...@gmail.com wrote:
>
> Please find attached patches with no whitespace error and improved
> formatting.
Thanks.
There are still numerous formatting changes required, e.g. spaces around
"=" and correct formatting of comments. And "git diff --check" still ha
Kohei KaiGai writes:
> Here is no other reason than what Alvaro mentioned in the upthread.
> We intended to store security label of SELinux (less than 100bytes at most),
> so I didn't think it leads any problem actually.
> On the other hands, pg_seclabel was merged in another development cycle.
>
Vik Fearing writes:
>> You mean that if synchronous_standby_names is an empty it automatically
>> should be set to cluster_name?
> No, I mean that synchronous_standby_names should look at cluster_name
> first, and if it's not set then unfortunately look at application_name
> for backward compatib
Ashoke writes:
> Thank you Ashutosh*.* That was the issue. But, could you please explain why
> it worked from command line?
Simple vs extended query protocol, probably --- the former avoids copying
the constructed parsetree, but I think the latter doesn't. Or maybe the
JDBC driver tried to prepa
Hello,
My customer reported a strange connection hang problem. He and I couldn't
reproduce it. I haven't been able to understand the cause, but I can think
of one hypothesis. Could you give me your opinions on whether my hypothesis
is correct, and a direction on how to fix the problem? I'm
Updated patch attached, thanks.
Amit: what's your conclusion from the review?
-- Abhijit
diff --git a/src/backend/access/nbtree/nbtxlog.c b/src/backend/access/nbtree/nbtxlog.c
index 5f9fc49..dc90c02 100644
--- a/src/backend/access/nbtree/nbtxlog.c
+++ b/src/backend/access/nbtree/nbtxlog.c
@@ -501
Here is no other reason than what Alvaro mentioned in the upthread.
We intended to store security label of SELinux (less than 100bytes at most),
so I didn't think it leads any problem actually.
On the other hands, pg_seclabel was merged in another development cycle.
We didn't have deep discussion
At 2014-07-04 11:34:21 +0200, and...@2ndquadrant.com wrote:
>
> I think we're going to have to redefine the
> PGAC_FUNC_SNPRINTF_LONG_LONG_INT_FORMAT callsite in configure.in to
> define INT64_MODIFIER='"ll/l/I64D"'
I've attached a patch to do this, and also add INT64_MODIFIER to
pg_config.h.in: 0
On 02/07/14 22:10, Tom Lane wrote:
Greg Stark writes:
I think log_error_verbosity is a strange variable. It's useless for
expected user-facing errors but essential for unexpected errors that
indicate bugs in the code -- and you can only have it on for
everything or off for everything.
I'm fi
> > Thanks for reviewing the patch!
> >
> > I think that this refactoring patch is useful for improving source
> > code readability and making the future patches simpler, whether we
> > adopt your patch or not. So, barring any objections, I'm thinking to
> > commit this refactoring patch.
>
> Comm
On 2014-07-04 18:31:34 +0800, gotoschool6g wrote:
> >
> > I'm pretty sure that most committers would want to apply the
> > rm_identity part in a separate commit first. Could you make it
> > two patches, one introducing rm_identity, and another with
> > xlogdump using it?
>
> Carp the code:
>
>
> I'm pretty sure that most committers would want to apply the
> rm_identity part in a separate commit first. Could you make it
> two patches, one introducing rm_identity, and another with
> xlogdump using it?
Carp the code:
const char *
clog_identify(uint8 info)
{
switch (info)
{
On 2014-07-04 11:50:17 +0200, Andres Freund wrote:
> Hi,
>
> postgres=# SELECT oid::regclass, reltoastrelid FROM pg_class WHERE relname IN
> ('pg_seclabel', 'pg_shseclabel');
> oid | reltoastrelid
> ---+---
> pg_seclabel | 3598
> pg_shseclabel |
On 2014-07-04 15:34:14 +0530, Abhijit Menon-Sen wrote:
> At 2014-07-04 11:34:21 +0200, and...@2ndquadrant.com wrote:
> >
> > So we're leaking memory here? For --stats that could well be
> > relevant...
>
> Will fix (I think using a static buffer would be OK here).
In that place, yes. There there'
On 2014-07-04 11:59:23 +0200, Fabien COELHO wrote:
>
> >Yea. I certainly disagree with the patch in it's current state because it
> >copies the same 15 lines several times with a two word difference.
> >Independent of whether we want those options, I don't think that's going
> >to fly.
>
> I like
At 2014-07-04 11:34:21 +0200, and...@2ndquadrant.com wrote:
>
> So we're leaking memory here? For --stats that could well be
> relevant...
Will fix (I think using a static buffer would be OK here).
> I think we're going to have to redefine the
> PGAC_FUNC_SNPRINTF_LONG_LONG_INT_FORMAT callsite in
Yea. I certainly disagree with the patch in it's current state because
it copies the same 15 lines several times with a two word difference.
Independent of whether we want those options, I don't think that's going
to fly.
I liked a simple static string for the different variants, which means
Hello, thank you for keeping this discussion moving.
> > I think there's no such a reasonable time. The behavior might
> > should be determined from another point.. On alternative would be
> > let pg_terminate_backend() have a parameter instructing force
> > shutodwn (how to propagate it?), or mak
Hi,
postgres=# SELECT oid::regclass, reltoastrelid FROM pg_class WHERE relname IN
('pg_seclabel', 'pg_shseclabel');
oid | reltoastrelid
---+---
pg_seclabel | 3598
pg_shseclabel | 0
(2 rows)
Isn't that a somewhat odd choice? Why do we as
Hello,
At Tue, 1 Jul 2014 21:21:38 +0200, Martijn van Oosterhout
wrote in <20140701192138.gb20...@svana.org>
> On Tue, Jul 01, 2014 at 12:26:43PM +0900, Kyotaro HORIGUCHI wrote:
> > > 1. I think it's the case that there are platforms around where a
> > > signal won't cause send() to return EINTR
Hello,
At Thu, 3 Jul 2014 14:48:50 +0900, Michael Paquier
wrote in
> TODO
...
> > Each type of page can be confirmed by the following way *if*
> > its type is previously *hinted* except for gin.
> >
> > btree: 32bit magic at pd->opaque
> > gin : No magic
> > gist : 16-bit
On 3 July 2014 16:59, Simon Riggs wrote:
>
> I think we should say this though
>
> LockBufHdr(buf);
> valid = ((buf->flags & BM_VALID) != 0);
> if (valid)
> PinBuffer_Locked(buf);
> else
> UnlockBufHdr(buf);
>
> since otherwise we would access the buffer flags without the spinlock
> and w
Hello, thank you for considering my comments, including somewhat
impractical ones.
I'll have a look at the latest patch sooner.
At Fri, 4 Jul 2014 15:29:51 +0900, Michael Paquier
wrote in
> OK, I have been working more on this patch, improving on-the-fly the
> following things on top of what
Hi,
On 2014-07-04 14:42:03 +0530, Abhijit Menon-Sen wrote:
> Sure, attached.
>
> +const char *
> +heap_identify(uint8 info)
> +{
> + const char *id = NULL;
> +
> + switch (info & XLOG_HEAP_OPMASK)
> + {
> + case XLOG_HEAP_INSERT:
> + id = "INSERT";
> +
At 2014-07-04 10:54:08 +0200, and...@2ndquadrant.com wrote:
>
> I'm pretty sure that most committers would want to apply the
> rm_identity part in a separate commit first. Could you make it
> two patches, one introducing rm_identity, and another with
> xlogdump using it?
Sure, attached.
-- Abhiji
On 2014-07-04 14:16:42 +0530, Abhijit Menon-Sen wrote:
> At 2014-07-04 08:38:17 +, dilip.ku...@huawei.com wrote:
> >
> > Once you fix above erros, I think patch is ok from my side.
>
> I've attached two updated patches here, including the fix to the usage
> message. I'll mark this ready for co
At 2014-07-04 08:38:17 +, dilip.ku...@huawei.com wrote:
>
> Once you fix above erros, I think patch is ok from my side.
I've attached two updated patches here, including the fix to the usage
message. I'll mark this ready for committer now. (The rm_identify patch
is posted separately from the x
On 04 July 2014 12:07, Abhijit Menon-Sen Wrote,
> -Original Message-
> From: Abhijit Menon-Sen [mailto:a...@2ndquadrant.com]
> Sent: 04 July 2014 12:07
> To: Dilip kumar
> Cc: pgsql-hackers@postgresql.org; furu...@pm.nttdata.co.jp
> Subject: Re: [HACKERS] pg_xlogdump --stats
>
> At 2014-0
On Fri, Jul 4, 2014 at 12:30 PM, Ashoke wrote:
> Thank you Ashutosh*.* That was the issue. But, could you please explain
> why it worked from command line?
>
>
I do not know. Any time we add a member to a node and find it's value
coming out NULL or 0 instead of the one set, corresponding _copy* i
On 07/04/2014 08:50 AM, Fujii Masao wrote:
> On Wed, Jul 2, 2014 at 3:45 AM, Vik Fearing wrote:
>> Is there a reason for not using this in synchronous_standby_names,
>> perhaps falling back to application_name if not set?
>
> You mean that if synchronous_standby_names is an empty it automatically
Thank you Ashutosh*.* That was the issue. But, could you please explain why
it worked from command line?
On Fri, Jul 4, 2014 at 11:49 AM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> You may have to add code to copy inp_str to _copyVacuumStmt(). See how a
> character array being co
43 matches
Mail list logo
