> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Amit Langote
> Sent: Friday, September 19, 2014 2:13 PM
> To: robertmh...@gmail.com
> Cc: pgsql-hackers@postgresql.org; br...@momjian.us;
Hi,
> On Mon, Oct 13, 2014 at 04:38:39PM -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > I realize there hasn't been much progress on this thread, but I wanted
> > > to chime in to say I think our current partitioning implementation is
> > > too heavy administratively, error-prone, an
Hi,
> From: Andres Freund [mailto:and...@2ndquadrant.com]
> On 2014-10-27 06:29:33 -0300, Alvaro Herrera wrote:
> > Amit Langote wrote:
> > > FWIW, I think Robert's criticism regarding not basing this on
inheritance
> > > scheme was not responded to.
> &g
Hi,
On Sat, Nov 1, 2014 at 1:21 PM, Eric Ridge wrote:
> On Fri, Oct 31, 2014 at 6:07 PM, Tom Lane wrote:
>>
>> I don't know if/when that will happen as such, but Simon was making noises
>> about writing code to treat hash indexes as unlogged automatically, which
>> would more or less fix the wor
Hi,
> ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: Tuesday, October 28, 2014 9:20 PM
>
> On Tue, Oct 28, 2014 at 6:06 AM, Andres Freund
> wrote:
> > In my opinion we can reuse (some of) the existing logic for INHERITS to
> > implement "proper" partitioning, but that should be an imple
On Sun, Nov 9, 2014 at 10:30 PM, Fujii Masao wrote:
> On Sat, Nov 8, 2014 at 4:56 AM, Alvaro Herrera
> wrote:
>>
>> I just pushed this, after some more minor tweaks.
>
> Nice!
>
>> Thanks, and please do continue testing!
>
> I got the following PANIC error in the standby server when I set up
> t
Hi,
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Saturday, November 08, 2014 5:41 AM
>
> I'd be in favor of that.
Thanks!
> I am not sure whether the code is close
> enough to what we need to be really useful, but that's for you to
> decide.
Hmm, I'm not entirely convinced about
On Tue, Nov 11, 2014 at 5:10 PM, Michael Paquier
wrote:
> On Mon, Nov 10, 2014 at 5:26 PM, Michael Paquier
> wrote:
>> I'll go through the patch once again a bit later, but feel free to comment.
> Reading again the patch with a fresher mind, I am not sure if the
> current approach taken is really
> From: Stephen Frost [mailto:sfr...@snowman.net]
> Sent: Thursday, November 13, 2014 3:40 PM
>
> > The point for me is just that range and list partitioning probably
> > need different structure, and hash partitioning, if we want to support
> > that, needs something else again. Range partitioni
> ow...@postgresql.org] On Behalf Of Amit Langote
> Sent: Thursday, November 13, 2014 3:50 PM
>
> Greenplum uses a single table for this purpose with separate columns for
range
> and list cases, for example. They store allowed values per partition though.
> They have 6 pa
Robert,
>
> I thought putting the partition boundaries into pg_inherits was a
> strange choice. I'd put it in pg_class, or in pg_partition if we
> decide to create that.
Hmm, yeah I guess we are better off using pg_inherits for just saying that a
partition is an inheritance child. Other deta
Hi,
I found in pg_dump.c what I believe to be a typo.
-* relationships are set up by doing ALTER INHERIT rather than
using
+* relationships are set up by doing ALTER TABLE INHERIT
rather than using
Attached fixes this if appropriate to do so.
Thanks,
Amit
2014
Hi,
> > I'm wondering here if it's better to keep partition values per partition
> > wherein we have two catalogs, say, pg_partitioned_rel and pg_partition_def.
> >
> > pg_partitioned_rel stores information like partition kind, key (attribute
> > number(s)?), key opclass(es). Optionally, we could
Sorry, a correction:
> CREATE TABLE pg_catalog.pg_partitioned_rel
> (
>partrelidoidNOT NULL,
>partkindoidNOT NULL,
>partissub bool NOT NULL,
>partkey int2vector NOT NULL, -- partitioning attributes
>partopcl
On 2015/11/10 17:02, Amit Langote wrote:
> On 2015/10/29 23:22, Syed, Rahila wrote:
>> Please find attached an updated patch.
>
> A few more comments on v6:
I backed up a little, studied the proposal and the patch in little some
more detail. Here are still more comments -
Go
On 2015/11/19 16:18, Amit Langote wrote:
> I'm marking this as "Waiting on author" in the commitfest app. Also, let's
> hear from more people.
Well, it seems Michael beat me to it.
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On 2015/11/19 17:48, konstantin knizhnik wrote:
> Hi,
>
> I want to use logical replication for implementing multimaster (so all nodes
> are both sending and receiving changes).
> But there is one "stupid" problem: how to prevent infinite recursion and not
> to rereplicate replicated data.
> I.e
Attached fixes $SUBJECT:
s/replication_origin.c/origin.c/g
Thanks,
Amit
diff --git a/src/backend/access/rmgrdesc/replorigindesc.c b/src/backend/access/rmgrdesc/replorigindesc.c
index 60cf0f6..479e3b4 100644
--- a/src/backend/access/rmgrdesc/replorigindesc.c
+++ b/src/backend/access/rmgrdesc/replo
On 2015/11/20 10:24, Robert Haas wrote:
> On Thu, Nov 19, 2015 at 5:04 AM, Amit Langote
> wrote:
>> Attached fixes $SUBJECT:
>>
>> s/replication_origin.c/origin.c/g
>
> Committed.
Thanks!
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
On 2015/11/20 0:57, Jim Nasby wrote:
> On 11/19/15 1:18 AM, Amit Langote wrote:
>> 1) General purpose interface for (maintenance?) commands to report a set
>
> I'm surprised no one has picked up on using this for DML. Certainly anyone
> works with ETL processes would love
On 2015/11/06 1:29, Robert Haas wrote:
> On Fri, Oct 30, 2015 at 6:08 AM, Amit Langote
> wrote:
>> The DDL and catalogs part are not much different from what I had last
>> described though I took a few steps to simplify things. I dropped the
>> multi-level partitioning bi
On Fri, Nov 20, 2015 at 7:20 PM, Simon Riggs wrote:
> On 20 November 2015 at 09:18, Amit Langote
> wrote:
>>
>> On 2015/11/06 1:29, Robert Haas wrote:
>> > On Fri, Oct 30, 2015 at 6:08 AM, Amit Langote
>> > wrote:
>> >> The DDL and catalogs
While going through nodeGather.c, I noticed portions of the file header
comment that may have been obsoleted by recent revisions of the relevant
parellelism code. For example, there is a reference to PartialSeqScan node
which did not make it into the tree. Attached fixes it. Also, wondering if
the
On 2015/11/21 14:38, Jim Nasby wrote:
> On 11/19/15 7:29 PM, Amit Langote wrote:
>>> Another option is to provide the means for the index scan routines to
>>> >report their progress. Maybe every index AM won't use it, but it'd
>>> >certainly be a lot
On 2015/11/21 5:46, Robert Haas wrote:
> On Thu, Nov 19, 2015 at 2:18 AM, Amit Langote
> wrote:
>> As someone pointed out upthread, the final heap truncate phase can take
>> arbitrarily long and is outside the scope of lazy_scan_heap() to
>> instrument. Perhaps a bool,
On 2015/11/25 9:32, Jim Nasby wrote:
> On 11/24/15 2:02 AM, Amit Langote wrote:
>> Just to clarify, does this mean we report index vacuum progress in terms
>> of index items processed (not pages)? If so, how do we get total number of
>> index items to process (presumably acro
On 2015/11/25 11:31, Robert Haas wrote:
> On Tue, Nov 24, 2015 at 1:06 AM, Amit Langote
> wrote:
>> While going through nodeGather.c, I noticed portions of the file header
>> comment that may have been obsoleted by recent revisions of the relevant
>> parellelism code.
On 2015/12/01 3:06, Robert Haas wrote:
> On Tue, Nov 24, 2015 at 9:43 PM, Amit Langote
> wrote:
>> On 2015/11/25 11:31, Robert Haas wrote:
>>>
>>> Well I think "scanning a plan" is clear enough even if it's
>>> technically a Scan.
>&
On 2015/12/01 16:25, Kyotaro HORIGUCHI wrote:
> At Mon, 30 Nov 2015 19:10:44 -0700 (MST), Vinayak wrote
>> Thanks for the v7.
>> Please check the comment below.
>> -Table name in the vacuum progress
>>
>> + snprintf(progress_message[0], PROGRESS_MESSAGE_LENGTH, "%s.%s",
>> schemaname,relname);
>>
On 2015/12/02 15:41, Michael Paquier wrote:
> It seems that the consensus is to rework a bit more this patch.
> Returned with feedback then?
Yes, as far as this commitfest is concerned. Or "moved to the next
commitfest"? Not sure exactly which makes sense.
Thanks,
Amit
--
Sent via pgsql-hack
Currently find_inheritance_children() is smart enough to skip a child
table that it finds has been dropped concurrently after it gets a lock on
the same. It does so by looking up the child relid in syscache. It seems
it should also check if the table is still in the list of children of the
parent.
On 2015/12/03 13:47, Kyotaro HORIGUCHI wrote:
> At Wed, 2 Dec 2015 15:48:20 -0300, Alvaro Herrera
> wrote
>>
>> Actually, do we really need to have the table name as a string at all
>> here? Why not just report the table OID? Surely whoever wants to check
>> the progress can connect to the data
On 2015/12/03 13:09, Tom Lane wrote:
> Amit Langote writes:
>> Currently find_inheritance_children() is smart enough to skip a child
>> table that it finds has been dropped concurrently after it gets a lock on
>> the same. It does so by looking up the child relid in sys
Hi,
On 2015/12/03 15:27, Kyotaro HORIGUCHI wrote:
> At Thu, 3 Dec 2015 14:18:50 +0900, Amit Langote wrote
>> On 2015/12/03 13:47, Kyotaro HORIGUCHI wrote:
>>>
>>> Apart from the representation of the relation, OID would be
>>> better as a field in beentry.
>
Hi Amul!
On 2015/12/03 17:52, amul sul wrote:
> Hi ALL,
>
> Need your suggestions.
> initially_valid flag is added to make column constraint valid. (commit :
> http://www.postgresql.org/message-id/e1q2ak9-0006hk...@gemulon.postgresql.org)
>
>
> IFAICU, initially_valid and skip_validation valu
On 2015/12/03 20:44, amul sul wrote:
>> On Thursday, 3 December 2015 4:36 PM, Amit Langote
>> wrote:
>> Especially from a readability standpoint, I think using skip_validation may
>> be more apt.
>> Why - the corresponding parameter of StoreRelCheck()
On 2015/12/03 21:26, Ashutosh Bapat wrote:
> Session 1
> postgres=# begin;
> BEGIN
> postgres=# update t1 set val = 2 where val2 = 1;
> UPDATE 1
>
> Session 2
> postgres=# select * from t1 left join t2 on (t1.val = t2.val) for update of
> t1;
>
> query waits
>
> Session 1
> postgres=# commit;
>
On 2015/12/07 2:52, Andreas Seltenreich wrote:
> Hi,
>
> I've added new grammar rules to sqlsmith and improved some older ones.
> This was rewarded with a return of "failed to generate plan" errors.
> The failing queries all contain a lateral subquery. The shortest of the
> failing queries are be
Hi,
On 2015/12/03 19:05, Kyotaro HORIGUCHI wrote:
> At Thu, 3 Dec 2015 16:24:32 +0900, Amit Langote
> wrote
>> By the way, there are some non-st_progress_* fields that I was talking
>> about in my previous message. For example, st_activity_flag (which I have
>>
On 2015/12/09 5:50, Robert Haas wrote:
> On Thu, Dec 3, 2015 at 3:52 AM, amul sul wrote:
>> Can we pass initially_valid instead of !skip_validation to StoreRelCheck()
>> in AddRelationNewConstraints(), as shown below?
>
> The comments say this:
>
> * If skip_validation is true then we skip che
On 2015/12/09 11:19, Amit Langote wrote:
> On 2015/12/09 5:50, Robert Haas wrote:
>> I suspect this is an oversight. We allowed FOREIGN KEY constraints to
>> be not valid in 722bf7017bbe796decc79c1fde03e7a83dae9ada by Simon
>> Riggs, but didn't add allow it for CHECK
On Wednesday, 9 December 2015, amul sul wrote:
> >On Wednesday, 9 December 2015 12:55 PM, Amit Langote <
> langote_amit...@lab.ntt.co.jp > wrote:
>
> >Thoughts?
>
> Wondering, have you notice failed regression tests?
I did, I couldn't send an updated pat
On 2015/12/09 18:07, amul sul wrote:
>> On Wednesday, 9 December 2015 12:55 PM, Amit Langote
>> wrote:
>
>> Thoughts?
>
> Wondering, have you notice failed regression tests?
Here is the updated patch.
> I have tried with new transformCheckConstraints() functio
On 2015/12/10 13:12, amul sul wrote:
>> On Thursday, 10 December 2015 8:22 AM, Amit Langote
>> wrote:
>
>
>> You forgot to put braces around the if block.
>
>
> Does this really required?
If nothing else, for consistency with surrounding code.
Take
On 2015/12/10 13:38, Amit Langote wrote:
>
> Take a look at a similar code block in transformFKConstraints
> (parse_utilcmd.c: line 1935), or transformIndexConstraint
> (parse_utilcmd.c: line 1761).
Oops, forget the second one.
Thanks,
Amit
--
Sent via pgsql-hackers mailing
On 2015/12/10 4:40, Robert Haas wrote:
> It's going to be *really* important that this facility provides a
> lightweight way of updating progress, so I think this whole API is
> badly designed. VACUUM, for example, is going to want a way to update
> the individual counter for the number of pages i
On 2015/12/10 15:28, Michael Paquier wrote:
> On Thu, Dec 10, 2015 at 4:40 AM, Robert Haas wrote:
>> It's going to be *really* important that this facility provides a
>> lightweight way of updating progress, so I think this whole API is
>> badly designed. VACUUM, for example, is going to want a w
On 2015/12/10 20:46, Michael Paquier wrote:
> On Thu, Dec 10, 2015 at 7:23 PM, Amit Langote
> wrote:
>> AIUI, the counts published via stats collector are updated asynchronously
>> w.r.t. operations they count and mostly as aggregate figures. For example,
>> PgStat_Sta
On 2015/12/11 14:41, Kyotaro HORIGUCHI wrote:
> Sorry, I misunderstood the meaning of PgStat_*.
I should've just said "messages to the stats collector" instead of
"PgStat_Msg's".
>
> At Fri, 11 Dec 2015 09:41:04 +0900, Amit Langote
> wrote
>>&
On 2015/11/24 2:23, Robert Haas wrote:
> To me, it seems like there is a pretty obvious approach here: each
> table can be either a plain table, or a partition root (which can look
> just like an empty inheritance parent). Then multi-level partitioning
> falls right out of that design without need
Hi,
On 2015/12/14 17:34, Kyotaro HORIGUCHI wrote:
> At Tue, 8 Dec 2015 10:40:20 -0500, Robert Haas wrote
>> But is it important enough to be worthwhile? Maybe, maybe not. I
>> think we should be working toward a world where the Gather is at the
>> top of the plan tree as often as possible, in
On 2015/12/03 15:30, Amit Langote wrote:
> On 2015/12/03 13:09, Tom Lane wrote:
>> Amit Langote writes:
>>> Currently find_inheritance_children() is smart enough to skip a child
>>> table that it finds has been dropped concurrently after it gets a lock on
>>>
In prepare_new_cluster(), following looks like a typo:
- * would cause us to lose the frozenids restored by the load. We use
+ * would cause us to lose the frozenxids restored by the load. We use
Attached find the patch.
Thanks,
Amit
diff --git a/src/bin/pg_upgrade/pg_upgrade.c b/src/bin
I think the following may be a typo:
* Caller is responsible for ensuring that no other backend can access the
* storage underlying this tuple, either by holding an exclusive lock on the
- * buffer containing it (which is what lazy VACUUM does), or by having it by
+ * buffer containing it (whi
On 2015/12/18 14:53, Amit Langote wrote:
> In prepare_new_cluster(), following looks like a typo:
>
> - * would cause us to lose the frozenids restored by the load. We use
> + * would cause us to lose the frozenxids restored by the load. We use
Or maybe not, because &q
On 2015/12/19 2:05, Robert Haas wrote:
> On Fri, Dec 18, 2015 at 1:25 AM, Amit Langote
> wrote:
>> I think the following may be a typo:
>>
>> * Caller is responsible for ensuring that no other backend can access the
>> * storage underlying this tuple, either b
On 2015/12/18 3:56, Robert Haas wrote:
> On Mon, Dec 14, 2015 at 2:14 AM, Amit Langote
> wrote:
>> Syntax to create a partitioned table (up to 2 levels of partitioning):
>>
>> CREATE TABLE foo (
>> ...
>> )
>> PARTITION BY R/L ON (key0)
>> SUBPAR
On 2015/12/22 14:05, Michael Paquier wrote:
> On Tue, Dec 22, 2015 at 1:41 AM, Stephen Frost wrote:
>> Updated and rebased patch attached which takes the 'pg_switch_xlog'
>> default role back out, leaving us with:
>>
>> pg_monitor - View privileged info
>> pg_backup - start/stop backups, switch xl
On 2015/12/22 15:24, Michael Paquier wrote:
> On Thu, Dec 10, 2015 at 1:32 AM, Robert Haas wrote:
>> If we get the feature - join pushdown for postgres_fdw -
>> working, then we might get some feedback from users about what they
>> like about it or don't, and certainly if this is a frequent compla
On 2015/12/23 8:45, Peter Geoghegan wrote:
> On Tue, Dec 22, 2015 at 3:38 PM, Robert Haas wrote:
>> In my opinion a term more closely coupled to the concrete syntax would
>> be easier to understand. I have no objection to referring to the
>> *process* of trying to deduce a suitable index from the
Hi,
On 2015/12/23 7:23, Stephen Frost wrote:
> Updated patch attached. I'll give it another good look and then commit
> it, barring objections.
Just a minor nitpick about a code comment -
/*
+ * Check that the user is not trying to create a role in the reserved
+ * "pg_" namespace
Attached fixes the following comment typo (copy-pasto):
-Oid toast_oid; /* for restore toast frozen xid */
+Oid toast_oid; /* for restore toast table oid */
Thanks,
Amit
diff --git a/src/bin/pg_dump/pg_dump.h b/src/bin/pg_dump/pg_dump.h
index 3c64a82..9c63abd 100
On 2015/12/25 0:44, Tom Lane wrote:
> Amit Langote writes:
>> Attached fixes the following comment typo (copy-pasto):
>> -Oid toast_oid; /* for restore toast frozen xid */
>> +Oid toast_oid; /* for restore toast table oid */
>
> That c
I wonder if the following error detail text could say more than it does
currently for the following rather artificial example case:
CREATE TABLE p1(a char(3));
CREATE TABLE p2(a char(2));
CREATE TABLE c(d int) INHERITS (p1, p2);
NOTICE: merging multiple inherited definitions of column "a"
ERROR:
On 2015/12/27 3:11, Tom Lane wrote:
> I wrote:
>> Amit Langote writes:
>>> Any specific reason why it doesn't spell out typmods in the above detail
>>> message?
>
>> * There's a rough policy in the parser to prefer TypeNameToString
>>
Hi Vinayak,
On 2015/12/25 21:46, Vinayak Pokale wrote:
> Hi,
> Please find attached patch addressing following comments.
>
>> The relation OID should be reported and not its name. In case of a
>> relation rename that would not be cool for tracking, and most users
>> are surely going to join with
On 2016/01/04 14:43, Haribabu Kommi wrote:
>>
>> Here I attached new series of patches with a slightly different approach.
>> Instead of creating the policies on the system catalog tables whenever
>> the catalog security command is executed, just enable row level security
>> on the system catalog t
Hi,
On Mon, Jan 4, 2016 at 8:11 PM, amul sul wrote:
> Hi,
>
> In inheritance, child column's pg_attribute.attislocal flag not getting
> updated, if it is inherited using ALTER TABLE INHERIT .
>
> Due to this, if we try to drop column(s) from parent table, which are not
> getting drop from chil
On 2016/01/05 3:53, Atri Sharma wrote:
> I was wary to use SPI inside the executor for node evaluation functions.
> Does it seem safe?
What is "node evaluation functions"? Is it "Plan" nodes or "Expr" nodes
that you are talking about? I guess you'd know to use ExecProcNode() or
ExecEvalExpr() for
On 2016/01/05 14:30, Atri Sharma wrote:
> On Tue, Jan 5, 2016 at 9:54 AM, Amit Langote
>> On 2016/01/05 3:53, Atri Sharma wrote:
>>> I was wary to use SPI inside the executor for node evaluation functions.
>>> Does it seem safe?
>>
>> What is "node
On 2016/01/06 10:17, Haribabu Kommi wrote:
> On Mon, Jan 4, 2016 at 10:43 PM, Haribabu Kommi
>>
>> Thanks for the test. Yes, the issue happens at backend startup itself.
>> I will give a try by separating the initialization of security
>> policies after init phase 3.
>
> Here I attached updated pa
Hi,
I stumbled upon a possibly strange behavior which may be related to recent
initdb changes. For a freshly initdb'd cluster, the following looks fishy:
postgres=# SELECT relname, relnamespace::regnamespace FROM pg_class
WHERE relnamespace != 'pg_catalog'::regnamespace
AND relnamespace != 'pg_to
Hi,
Attached fixes a typo: s/non-exstant/non-existant.
Alternatively, it could be spelled as 'existent' but the patch doesn't.
Nor does it drop the 's' and spell it 'non-extant' which may have been the
original intent.
Thanks,
Amit
diff --git a/src/backend/catalog/namespace.c b/src/backend/cata
On 2016/01/06 17:32, Amit Langote wrote:
> Hi,
>
> I stumbled upon a possibly strange behavior which may be related to recent
> initdb changes. For a freshly initdb'd cluster, the following looks fishy:
>
> postgres=# SELECT relname, relnamespace::regnamespace FROM pg_cla
On Wed, Jan 6, 2016 at 11:51 PM, Tom Lane wrote:
> Amit Langote writes:
>> Attached fixes a typo: s/non-exstant/non-existant.
>> Alternatively, it could be spelled as 'existent' but the patch doesn't.
>
> "non-existant" is flat wrong, so if we'
On 2016/01/07 1:03, Tom Lane wrote:
> Amit Langote writes:
>> On Wed, Jan 6, 2016 at 11:51 PM, Tom Lane wrote:
>>> "non-existant" is flat wrong, so if we're going to fix typos, let's
>>> fix them to actually be English.
>
>> So, non-exis
On 2016/01/06 23:50, Tom Lane wrote:
> Amit Langote writes:
>> On 2016/01/06 17:32, Amit Langote wrote:
>>> I stumbled upon a possibly strange behavior which may be related to recent
>>> initdb changes. For a freshly initdb'd cluster, the following looks fis
On 2016/01/06 13:07, Haribabu Kommi wrote:
> On Wed, Jan 6, 2016 at 1:43 PM, Amit Langote
>>
>> Patch 4_database_catalog_tenancy_v5 fails to apply:
>
> May be you missed to apply the 3_shared_catalog_tenancy_v4 path,
> because 4_database_catalog_tenancy_v5 patch depe
On 2016/01/08 21:20, Rahila Syed wrote:
>> I suspect you need to create a new CF entry for this patch in CF 2016-01.
>
> Unless I am missing something, there seems to be no entry for this patch
> into CF 2016-01 page: https://commitfest.postgresql.org/8/.
> Regrettably, we have exceeded the deadli
On 2016/01/12 10:30, Amit Langote wrote:
> I'm slightly concerned that the latest patch doesn't incorporate any
> revisions to the original pgstat interface per Robert's comments in [1].
I meant to say "originally proposed pgstat interface on this thread".
Than
ing useful.
regards,
Amit Langote
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Failing-start-up-archive-recovery-at-Standby-mode-in-PG9-2-4-tp5753110p5753221.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hacke
How would code after applying this patch behave if a recycled segment gets
renamed using the newest timeline (say 3) while we are still recovering from
a lower timeline (say 2)? In that case, since XLogFileReadAnyTLI returns
that recycled segment as the next segment to recover from, we get the err
How would code after applying this patch behave if a recycled segment gets
renamed using the newest timeline (say 3) while we are still recovering from
a lower timeline (say 2)? In that case, since XLogFileReadAnyTLI returns
that recycled segment as the next segment to recover from, we get the err
What would happen if a recycled segment gets assigned a newer timeline than
the one we are currently recovering from? In the reported erroneous
behavior, that is what happens causing XLogFileReadAnyTLI() to return such
bogus segment causing the error. Since, expectedTLIs contains a newer
timeline a
I was just going through the xlog.c and I came across following which
confused me:
Given,
src/include/access/xlogdefs.h
#define XLogSegsPerFile (((uint32) 0x) / XLogSegSize)
#define XLogFileSize(XLogSegsPerFile * XLogSegSize)
Also,
typedef struct XLogRecPtr
{
uint32
se, should the comment be "/* Check for crossing of xlog
file boundary */"
instead of /* Check for crossing of xlog segment boundary */, since
( RecPtr->xrecoff >= XLogFileSize )
would mean crossing the xlog "file" (not segment) boundary, right?
Am I still missing something a
> Yeah, that would be more correct. The phrase we seem to use elsewhere in
> xlog.c is "crossing a logid boundary".
Should we change it in 9.2 to clear the confusion?
(Attached is a rather small patch to fix that! :) )
--
Amit Langote
minor-xlog-comment.patch (914 bytes)
&l
Attached patch fixes this.
--
Amit Langote
minor-xlog-comment-fix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ss restarting at 0/300
amit 8085 5648 0 14:13 ?00:00:00 postgres: wal sender
process amit [local] idle
Is this related to the assertion failure that you have reported?
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
both cases with TPS result
(after applying the patch) not being significantly different (as in
not twice as much on my system).
Using:
pgbench scale=10
shared_buffers=256MB
max_connections=1000
checkpoint_segments=15
synchronous_commit=on
Comments?
--
Amit Langote
--
Sent via pgsql-hacke
the patch not being significantly different (as in not
twice as much on my system).
I used:
pgbench scale=10
shared_buffers=256MB
max_connections=1000
checkpoint_segments=15
synchronous_commit=on
Comments?
--
Amit Langote
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgs
able to proceed to
next transactions faster and hence cause XLogFlush() to be invoked
more often. So, any rise in number of XLogFlush() calls should roughly
be accounted for by increased throughput. Am I right in interpreting
it this way?
--
Amit Langote
--
Sent via pgsql-hackers mail
d for by increase in
throughput that we see. In earlier mail, it might have been wrong of
me to conclude that the throughput rise and rise in #invocations of
XLogFlush() are not proportional. I think they are, though not
rigorously as far as I could measure. I am wondering if this line of
interpreting i
differently in response to the psql's first
connection request in that case. But, pam method leads to it being
logged.
Is this a problem?
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
only thing that needs
to be fixed is unnecessary logging or is there a problem with
authentication exchange itself in case of PAM? Also, when you say PAM
layer, is that pam_passwd_conv_proc() that needs to be able to return
an alternative status code?
--
Amit Langote
--
Sent via pgsql-hackers mailing li
s made
(without password), since the STATUS_EOF is not passed to it in that
case.
If we did not drop the connection (unlike what we do now) and
re-attempted connection with the password added to conn, would the
backend's authentication state still be waiting for the password? Can
we do away wi
ing otherwise that I am unaware of.
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
f the reasons why this has not already been
implemented?
Comments?
On Tue, May 14, 2013 at 11:22 AM, Amit Langote wrote:
>> Well, if we are allowed to use a bit ugry way, the attached patch
>> seems to cope with this issue. As far as I can see there's no
>> problem since
shared memory using SysV facilities
*
* These routines represent a fairly thin layer on top of SysV shared
* memory functionality.
*
?
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
away without having to create more new functions than
necessary and make appropriate changes.
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
901 - 1000 of 1334 matches
Mail list logo
