process' badness to be lower than postnaster's
$ sudo echo -101 > /proc/1837/oom_score_adj
[sudo] password for gurjeet:
$ for p in $(echo $(pgserverPIDList)| cut -d , ...
1835 -100
/home/gurjeet/dev/pgdbuilds/oom_guc/db/bin/postgres-D/home/gurjeet/dev/pgdbuilds/oom_guc/db/data
1837 -1
ing killed by
OOM killer, but let the child processes be still subject to OOM
killer's whim.
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
EDB www.EnterpriseDB.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
eak the intended behavior.
>
> Robert's idea of having the start script set an environment variable to
> control the OOM adjustment reset seems like it would satisfy my concern.
I'm fine with this solution. Should this be a constant 0, or be
configurable based on env. variable'
On Tue, Jun 10, 2014 at 1:13 PM, David G Johnston
wrote:
> Gurjeet Singh-4 wrote
>> So the argument that this GUC is a security concern, can be ignored.
>> Root user (one with control of start script) still controls the lowest
>> badness setting of all Postgres processes. If
re
present in original DB's shared-buffers at the time of shutdown. So,
this would fetch blocks into shared-buffers that may be completely
unrelated to the blocks recently operated on by the recovery process.
And it's probably accepted by now that such a bahviour is not
catastrophic, mer
On Sun, Jun 8, 2014 at 3:24 AM, Amit Kapila wrote:
> On Fri, Jun 6, 2014 at 5:31 PM, Gurjeet Singh wrote:
>> On Thu, Jun 5, 2014 at 11:32 PM, Amit Kapila
>> wrote:
>
>> > Buffer saver process itself can crash while saving or restoring
>> > buffers.
>>
On Wed, Jun 11, 2014 at 12:25 AM, Amit Kapila wrote:
> On Wed, Jun 11, 2014 at 7:59 AM, Gurjeet Singh wrote:
>> On Sun, Jun 8, 2014 at 3:24 AM, Amit Kapila
>> wrote:
>> > Yeap, but if it crashes before writing checkpoint record, it will lead
>> > to
&
On Wed, Jun 11, 2014 at 10:56 AM, Robert Haas wrote:
> On Tue, Jun 10, 2014 at 10:03 PM, Gurjeet Singh wrote:
>> And it's probably accepted by now that such a bahviour is not
>> catastrophic, merely inconvenient.
>
> I think the whole argument for having pg_hibernator i
JUST_VALUE is defined, that's
> the string we write, otherwise we write "0".
Please find attached the patch. It includes the doc changes as well.
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
EDB www.EnterpriseDB.com
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sg
Thanks!
On Mon, Jun 16, 2014 at 3:58 PM, Tom Lane wrote:
> I wrote:
>> Gurjeet Singh writes:
>>> I tried to eliminate the 'pending' list, but I don't see a way around it.
>>> We need temporary storage somewhere to store the branches encountered on
>&
On Wed, Jun 18, 2014 at 8:15 PM, Tom Lane wrote:
> Gurjeet Singh writes:
>
>> Please find attached the patch. It includes the doc changes as well.
>
> Applied with some editorialization.
Thanks!
would it be possible to include this in 9.4 as well?
Best regards,
--
On Mon, Jun 23, 2014 at 11:52 AM, Tom Lane wrote:
> Gurjeet Singh writes:
>> would it be possible to include this in 9.4 as well?
>
> While this is clearly an improvement over what we had before, it's
> impossible to argue that it's a bug fix, and we are way p
On Mon, Jun 23, 2014 at 12:49 PM, Tom Lane wrote:
> Gurjeet Singh writes:
>> While I'd love to reduce the number of future installations without
>> this fix in place, I respect the decision to honor project policy. At
>> the same time, this change does not break a
a bit old, but I'm sure I would've tested the patch before
submitting.
> I have attached a suggested patch which I think
> would work. Gurjeet, could you take a look at it?
The patch, when considered together with Tom's suggestion upthread,
looks good to me.
Best regards,
-
AICT was part of 8.3.
So I guess all the supported releases it is.
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
EDB : www.EnterpriseDB.com : The Enterprise PostgreSQL Company
diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c
index 3ab1428..c7f41a5 100644
-
On Sun, Jun 15, 2014 at 2:51 AM, Amit Kapila wrote:
> On Thu, Jun 12, 2014 at 9:31 AM, Gurjeet Singh wrote:
>>
>> I don't have intimate knowledge of recovery but I think the above
>> assessment of recovery's operations holds true. If you still think
>> this i
On Sat, Jun 7, 2014 at 6:48 AM, Cédric Villemain wrote:
> Le lundi 3 février 2014 19:18:54 Gurjeet Singh a écrit :
>
>> Possible enhancements:
>> - Ability to save/restore only specific databases.
>> - Control how many BlockReaders are active at a time; to avoid I/O
&g
On Wed, Jul 2, 2014 at 3:49 PM, Kevin Grittner wrote:
> In preparing to push the patch, I noticed I hadn't responded to this:
>
> Gurjeet Singh wrote:
>> Kevin Grittner wrote:
>>> I have reviewed this patch, and think we should do what the patch
>>>
y
-23:37:00' == '00:23:00', then it seems pointless to confuse the user
by showing two different representations of the same datum. This also
increases the code complexity required in applications/ORMs to parse
interval data's text representation.
Best regards,
--
Gurjeet Singh http:
t this as a bug, and "fix" the bug
by disallowing an index with attributes that cannot be present in an index
created by PRIMARY KEY constraint. The collation attribute on one of the
keys may be just one of many such attributes.
In the long term, we may want to allow coll
fails if there are any FKeys
pointing to this table.
[2]: http://www.postgresql.org/docs/9.4/static/sql-altertable.html
--
Gurjeet Singh http://gurjeet.singh.im/
On Jul 22, 2015 12:07 PM, "Jolly Chen" wrote:
>
> Hey everyone,
>
> You have probably heard that Mike Stonebraker recently won the Turing
award. A recording of his award lecture is available at:
> https://www.youtube.com/watch?v=BbGeKi6T6QI
>
> It is an entertaining talk overall. If you fast forw
On Jul 30, 2015 2:23 PM, "Tom Lane" wrote:
>
> Gavin Flower writes:
> > On 31/07/15 02:24, Heikki Linnakangas wrote:
> >> There is a big downside to expanding xmin/xmax to 64 bits: it takes
> >> space. More space means more memory needed for caching, more memory
> >> bandwidth, more I/O, etc.
>
>
On Mon, Aug 10, 2015 at 7:12 AM, Andres Freund wrote:
> On 2015-07-07 09:42:54 -0700, Gurjeet Singh wrote:
> > /*
> > + * Grab and save an LSN value to prevent WAL recycling past that point.
> > + */
> > +void
> > +ReplicationSlotRegisterRestartLSN()
> >
Please find attached the patch that fixes a couple of comments, and adds
'static' qualifier to functions that are not used anywhere else in the code
base.
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
EDB www.EnterpriseDB.com <http://www.enterprisedb.com>
diff --git a
pg_buffercache where relblocknumber is not
null group by reldatabase;'
count
---
2264
17
(2 rows)
There are a few more blocks than the time they were saved, but all the
blocks from before the restart are present in shared buffers after the
restart.
Best regards,
--
Gurjeet
On Mon, Mar 10, 2014 at 8:12 PM, Alvaro Herrera wrote:
> Gurjeet Singh wrote:
> > On Tue, Nov 26, 2013 at 12:37 PM, Tom Lane wrote:
> >
> > > Gurjeet Singh writes:
> > > > I was looking for ways to reduce the noise in Postgres make output,
> > &
Just a small patch; hopefully useful.
Best regards,
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterpriseDB Inc.
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index ccb8b86..48dc7af 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend
On Thu, Oct 31, 2013 at 11:20 PM, Tom Lane wrote:
> Amit Kapila writes:
> > On Thu, Oct 31, 2013 at 2:41 AM, Gurjeet Singh wrote:
> >> Just a small patch; hopefully useful.
>
> > This is valid saving as we are filling array ListenSocket[] in
> > Strea
plies), not in postmaster
shutdown. I hope that adds some weight to the argument.
Best regards,
--
Gurjeet Singh gurjeet.singh.im
EnterpriseDB Inc. www.enterprisedb.com
(XLR_MAX_BLOCK_ID).
The attached patch redefines GIST_MAX_SPLIT_PAGES so that in case of a
split, gistplacetopage() now throws an error when the block-ids needed
exceed 32.
I have used Min(75, XLR_MAX_BLOCK_ID) as the macro expansion, but I believe
it can be set to plain XLR_MAX_BLOCK_ID.
--
Gurjeet
(adding Heikki, since that macro was touched by his commit 04e298b8)
Does my previous description of the problem make sense, or am I fretting
over something that's a non-issue.
Best regards,
On Sun, Sep 20, 2015 at 7:03 PM, Gurjeet Singh wrote:
> Gin code respects the XLR_MAX_BLOCK
t
non-recursively.
This is I guess the right thing to do, but then we'll have to make
similar tree-traversal changes in other places, for eg. in BoolExpr walking
in expression_tree_walker() or maybe just the stack below
assign_expr_collations().
Best regards,
--
Gurjeet Singh
http:
On Sat, May 25, 2013 at 9:56 AM, Gurjeet Singh wrote:
> When Postgres encounters a long list of AND/OR chains, it errors out at
> check_stack_depth() after a limit of few thousand. At around 10,000
> elements, the recursion at assign_expr_collations() causes the error. But
> at a l
IN construct. But the
point remains that Postgres should be capable of handling this simple
construct efficiently.
Best regards,
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterpriseDB Inc.
this logic to turn
> out happily. I'd rather fix Slony (as done in the above patch).
>
Yes, by all means, fix the application, but that doesn't preclude the
argument that the database should be a bit more smarter and efficient,
especially if it is easy to do.
Best regards,
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterpriseDB Inc.
where the UPDATE statement from any given client
always updates the same logical row.
Best regards,
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterpriseDB Inc.
pgbench_add_cleint_number_variable.patch
Description: Binary data
test_update.sql
Description: Binary data
--
Sent via pgsql-
On Mon, May 27, 2013 at 10:32 AM, Christopher Browne wrote:
> On Mon, May 27, 2013 at 1:42 AM, Gurjeet Singh wrote:
>
>>
>>
>>> Joking about "640K" aside, it doesn't seem reasonable to expect a truly
>>> enormous query as is generated by the
root_kind == AEXPR_AND ?
> "AND" : "OR");
> + exprs = lcons(expr, exprs);
> + }
>
> I don't see any other issues, so after fixing comments this patch is
> ready for commit
>
> Regards
>
> Pavel Stehule
>
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterpriseDB Inc.
quot; cannot be changed without restarting the
server
DEBUG: configuration file
"/home/gurjeet/dev/pgdbuilds/report_guc_chanege_pre_reload/db/data/postgresql.conf"
contains errors; unaffected changes were applied
pg_test_reload_conf
-
t
(1 row)
postgres=# select
is
> ready for commit
>
Thanks for the review Pavel.
Attached is the updated patch, v4. It has the above edits, and a few code
improvements, like not repeating the (root_kind == AEPR_AND ? .. : ..)
ternary expression.
Best regards,
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterpriseDB
, but more correct. Same not best name is
> "root_char", maybe "root_bool_op_name"
>
> or root_expr_type and root_op_name ???
>
How about naming those 3 variables as follows:
root_expr_kind
root_expr_name
root_bool_expr_type
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterpriseDB Inc.
On Sun, Jun 30, 2013 at 11:46 AM, Pavel Stehule wrote:
> 2013/6/30 Gurjeet Singh :
> > On Sun, Jun 30, 2013 at 11:13 AM, Pavel Stehule >
> > wrote:
> >
> > How about naming those 3 variables as follows:
> >
> > root_expr_kind
> > root_expr_name
&
On Sun, Jun 30, 2013 at 11:46 AM, Pavel Stehule wrote:
> 2013/6/30 Gurjeet Singh :
> > On Sun, Jun 30, 2013 at 11:13 AM, Pavel Stehule >
> > wrote:
> >
> > How about naming those 3 variables as follows:
> >
> > root_expr_kind
> > root_expr_name
&
further discussion of this patch, or do I return it?
>
> Considering it's not been updated, nor my comments responded to, in
> almost two weeks, I think we return it at this point.
>
Sorry, I didn't notice that this patch was put back in 'Waiting on Author'
state.
Be
dure of moving a patch to the next commitfest? Do I make a
fresh submission there with a link to current submission, or is the move
doable somehow in the application itself.
Best regards,
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterpriseDB Inc.
On Wed, Jul 17, 2013 at 8:21 AM, Gurjeet Singh wrote:
>
> What's the procedure of moving a patch to the next commitfest?
>
Never mind, I see an email from Josh B. regarding this on my corporate
account.
Best regards,
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterpriseDB Inc.
On Wed, Jul 17, 2013 at 1:25 PM, Robert Haas wrote:
> On Mon, Jul 15, 2013 at 12:45 AM, Gurjeet Singh wrote:
> > Agreed that there's overhead in allocating list items, but is it more
> > overhead than pushing functions on the call stack? Not sure, so I leave
> it
>
etrees that haven't reached the
> planner. It doesn't appear to me that you've done any research on that
> point whatsoever
No, I haven't, and I might not be able to research it for a few more weeks.
> you have not even updated the comment for BoolExpr
> (in p
On Dec 13, 2015 9:56 PM, "Michael Paquier"
wrote:
>
> If the node has no WAL receiver active, a tuple with NULL values is
> returned instead.
IMO, in the absence of a WAL receiver the SRF (and the view) should not
return any rows.
On Sun, Dec 13, 2015 at 10:15 PM, Michael Paquier wrote:
> On Mon, Dec 14, 2015 at 3:09 PM, Gurjeet Singh
> wrote:
> > On Dec 13, 2015 9:56 PM, "Michael Paquier"
> > wrote:
> >> If the node has no WAL receiver active, a tuple with NULL values is
>
900 GB of disk space.
Linux 3.2.6-3.fc16.ppc64 #1 SMP Fri Feb 17 21:41:20 UTC 2012 ppc64
ppc64 ppc64 GNU/Linux
Best regards,
PS: The primary source of patch is this branch:
https://github.com/gurjeet/postgres/tree/64bit_pgbench
--
Gurjeet Singh
http://gurjeet.singh.im/
pgbe
error out because of a
conflict. But the following line in the docs [1] confirms otherwise:
"read-only transactions will never have serialization conflicts"
So no doc patch necessary :)
[1] http://www.postgresql.org/docs/9.2/static/transaction-iso.html
--
Gurjeet Singh
http://gurjeet.singh.im/
Can somebody explain why a standalone count(*) returns 1?
postgres=# select count(*);
count
---
1
(1 row)
I agree it's an odd thing for someone to query, but I feel it should return
0, and not 1.
--
Gurjeet Singh
http://gurjeet.singh.im/
On Sun, Jan 13, 2013 at 4:43 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > Can somebody explain why a standalone count(*) returns 1?
> > postgres=# select count(*);
> > count
> > ---
> > 1
> > (1 row)
>
> The Oracle equivalent of that wo
On Mon, Jan 14, 2013 at 3:09 PM, David Johnston wrote:
> What does "SELECT * FROM dual" in Oracle yield?
>
AFAICR, 'dual' table has one column named 'DUMMY' and one row with value,
single character X.
--
Gurjeet Singh
http://gurjeet.singh.im/
;
> 1. It's not legal (the SQL spec's answer).
> 2. It implicitly means a table of no columns and 1 row (PG's answer).
> 3. It implicitly means a table of no columns and 0 rows (which is what
>I take Gurjeet to be advocating for).
>
I wasn't advocating it, but was trying to wrap my head around why Postgres
would do something like count(*) of nothing == 1.
--
Gurjeet Singh
http://gurjeet.singh.im/
On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > Please find attached two patches, implementing two different approaches
> to
> > fix the issue of COMMIT truncating empty TEMP tables that have the ON
> > COMMIT DELETE ROWS attribute.
>
On Mon, Jan 14, 2013 at 11:03 PM, Alvaro Herrera
wrote:
> Gurjeet Singh escribió:
>
> > Interesting to note that SELECT * FROM table_with_zero_cols does not
> > complain of anything.
> >
> > postgres=# select * from test1;
> > --
> > (0 rows)
> &g
On Wed, Jan 16, 2013 at 1:21 AM, Pavan Deolasee wrote:
>
>
> On Wed, Jan 9, 2013 at 6:42 AM, Gurjeet Singh wrote:
>
>>
>>>
>> I have updated the commitfest submission to link to the correct patch
>> email.
>>
>>
> Thanks Gurjeet.
>
>
&
On Sun, Dec 5, 2010 at 2:09 PM, Peter Eisentraut wrote:
> On fre, 2010-12-03 at 15:27 -0500, Robert Haas wrote:
> > On Fri, Dec 3, 2010 at 2:56 PM, r t wrote:
> > > What exactly was the objection to the following -->
> > > ALTER TABLE table_name ADD PRIMARY KEY (column_list) USING index_name;
>
On Tue, Dec 21, 2010 at 6:24 PM, Robert Haas wrote:
> On Mon, Dec 20, 2010 at 1:10 PM, Noah Misch wrote:
> > When the caller knows the smaller string length, memcmp and strncmp are
> > functionally equivalent. Since memcmp need not watch each byte for a
> NULL
> > terminator, it often compares
On Tue, Dec 21, 2010 at 9:01 PM, Robert Haas wrote:
> On Tue, Dec 21, 2010 at 8:29 PM, Gurjeet Singh
> wrote:
> > On Tue, Dec 21, 2010 at 6:24 PM, Robert Haas
> wrote:
> >>
> >> On Mon, Dec 20, 2010 at 1:10 PM, Noah Misch wrote:
> >> > When the c
On Mon, Dec 6, 2010 at 7:22 PM, Tom Lane wrote:
> Josh Berkus writes:
> >> However, if you were doing something like parallel pg_dump you could
> >> just run the parent and child instances all against the slave, so the
> >> pg_dump scenario doesn't seem to offer much of a supporting use-case for
On Tue, Dec 28, 2010 at 5:13 AM, Jie Li wrote:
> Hi,
>
> Please see the following plan:
>
> postgres=# explain select * from small_table left outer join big_table
> using (id);
> QUERY PLAN
>
>
>
On Tue, Dec 28, 2010 at 11:36 AM, Tom Lane wrote:
>
> I can see the point of, say, a primary_host_address() function returning
> inet, which would be way better on both those dimensions than the
> current proposal. But I'm not sure what else would be needed.
>
>
+1, since it bypasses security ri
On Tue, Dec 28, 2010 at 11:00 AM, Joel Jacobson wrote:
> Dear fellow hackers,
>
> Problem: A normal diff of two slightly different schema dump files (pg_dump
> -s), will not produce a user-friendly diff, as you get all changes in the
> same file.
>
> Solution: I propose a new option to pg_dump, -
On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas wrote:
> On Dec 28, 2010, at 10:34 AM, Tom Lane wrote:
> > I'm still wondering what's the actual use-case for exposing this inside
> > SQL. Those with a legitimate need-to-know can look at the slave
> > server's config files, no?
>
> SQL access is f
On Tue, Dec 28, 2010 at 1:30 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas
> wrote:
> >> SQL access is frequently more convenient, though. Although maybe now
> that
> >> we've made recovery.conf use th
On Tue, Dec 28, 2010 at 2:39 PM, Joel Jacobson wrote:
> 2010/12/28 Gurjeet Singh
>
>> I would suggest the directory structure as:
>>
>> /crypt/pg.dump-split/schema-name-1/VIEWS/view-name-1.sql
>> /crypt/pg.dump-split/schema-name-1/TABLES/table-name-1.sql
>>
On Tue, Dec 28, 2010 at 4:57 PM, Andrew Dunstan wrote:
>
>
> On 12/28/2010 04:44 PM, Joel Jacobson wrote:
>
>>
>>
>>
>>
>> The problem I see with suffixing a sequence id to the objects with name
>>> collision is that one day the dump may name myfunc(int) as myfunc.sql and
>>> after an overloaded
On Wed, Dec 29, 2010 at 5:09 AM, Magnus Hagander wrote:
> > Ok, here's an updated patch that does both these and includes
> > documentation and regression test changes. With that, I think we're
> > good to go.
>
> I've applied this version (with some minor typo-fixes).
>
>
Do you think we could ha
On Wed, Dec 29, 2010 at 8:31 AM, Joel Jacobson wrote:
>
>
> 2010/12/29 Aidan Van Dyk
>
> On Wed, Dec 29, 2010 at 2:27 AM, Joel Jacobson
>> wrote:
>>
>>
>>
>> So, how different (or not) is this to the "directory" format that was
>> coming out of the desire of a parallel pg_dump?
>>
>
> Not sure
On Wed, Dec 29, 2010 at 1:42 PM, Robert Haas wrote:
> On Dec 29, 2010, at 1:01 PM, Tom Lane wrote:
> > Is it really stable enough for bin/? My impression of the state of
> > affairs is that there is nothing whatsoever about replication that
> > is really stable yet.
>
> Well, that's not stoppin
On Thu, Dec 9, 2010 at 2:48 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > But I still hold a bias towards renaming the index to match constraint
> name
> > (with a NOTICE), rather than require that the constraint name match the
> > index name, because the constraint n
Sorry for not being on top of this.
On Tue, Jan 25, 2011 at 9:01 AM, Tom Lane wrote:
> I wrote:
> > ... If that's the only issue then I don't see any need to wait on
> > the author, so will take this one.
>
> I find myself quite dissatisfied with the way that this patch adds yet
> another bool f
On Sat, Jan 26, 2013 at 11:24 PM, Satoshi Nagayasu wrote:
> Hi,
>
> I have reviewed this patch.
>
> https://commitfest.postgresql.org/action/patch_view?id=1068
>
> 2012/12/21 Gurjeet Singh :
> > The patch is very much what you had posted, except for a couple of
>
On Mon, Feb 4, 2013 at 2:38 PM, Alvaro Herrera wrote:
> I just noticed that contrib programs don't build in USE_PGXS=1
> environment:
>
> $ pwd
> /pgsql/build/HEAD/contrib/pg_upgrade
> $ LC_ALL=C USE_PGXS=1 make
> make: *** No rule to make target `check.o', needed by `pg_upgrade'. Stop.
>
FWIW,
On Mon, Feb 4, 2013 at 3:37 PM, Alvaro Herrera wrote:
> Gurjeet Singh wrote:
> > On Mon, Feb 4, 2013 at 2:38 PM, Alvaro Herrera >wrote:
> >
> > > I just noticed that contrib programs don't build in USE_PGXS=1
> > > environment:
> > >
>
views. As
others have said, I don't see a reason why both can't coexist, maybe in
pgxn. I am all ears if you think otherwise.
Best regards,
--
Gurjeet Singh
http://gurjeet.singh.im/
2013 at 10:13 AM
Subject: Successful post to pgsql-hackers
To: Gurjeet Singh
Your message to the pgsql-hackers list, posted on
Sat, 9 Feb 2013 10:11:05 -0500
with subject
Re: pg_prewarm
is currently being delivered.
--
Gurjeet Singh
http://gurjeet.singh.im/
haps you set it by mistake.
>
> You shold be able to set it from https://mail.postgresql.org. The
> setting you're looking for is "ackpost", and you'll want to turn it
> off.
>
> //Magnus
>
>
> On Sat, Feb 9, 2013 at 4:17 PM, Gurjeet Singh wrote:
>
On Sat, Feb 9, 2013 at 5:09 PM, Euler Taveira wrote:
> On 09-02-2013 13:45, Gurjeet Singh wrote:
> > BTW, I hope I understand what selfcopy is: send a copy to yourself. Why
> would
> > that be turned on by default?
> >
> If you want to reply to yourself...
Wouldn&
like a black-magic before the patch.
src/tools/pgindent/pgindent --build
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterprsieDB Inc.
pgindent.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
Hopefully I am not wrong.
+/* Size of a varlena data, excluding header */
#define VARSIZE_ANY_EXHDR(PTR) \
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterprsieDB Inc.
exhdr_comment.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
] src/backend/access/heap/heapam.c
[2]
http://www.postgresql.org/docs/9.2/static/runtime-config-compatible.html#GUC-SYNCHRONIZE-SEQSCANS
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterpriseDB Inc.
On Wed, Apr 10, 2013 at 11:10 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > If I'm reading the code right [1], this GUC does not actually
> *synchronize*
> > the scans, but instead just makes sure that a new scan starts from a
> block
> > that was reported by
On Wed, Apr 10, 2013 at 11:56 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > So, again, it is not guaranteed that all the scans on a relation will
> > synchronize with each other. Hence my proposal to include the term
> > 'probability' in the definition
On Fri, Apr 12, 2013 at 11:44 AM, Bruce Momjian wrote:
> On Tue, Feb 19, 2013 at 04:50:45PM -0500, Gurjeet Singh wrote:
> > Please find attached the patch for some cleanup and fix bit rot in
> pgindent
> > script.
> >
> > There were a few problems with the script.
&
On Fri, Apr 12, 2013 at 3:26 PM, Bruce Momjian wrote:
> On Fri, Apr 12, 2013 at 01:34:49PM -0400, Gurjeet Singh wrote:
> > Can you also improve the output when it dies upon failure to fetch
> something?
> > Currently the only error message it emits is "fetching xyz"
ve crashed Linux with Fincore
> > in the recent past).
>
> fincore is another soft, please provide a bugreport if you hit issue with
> pgfincore, I then be able to fix it and all can benefit.
>
> --
> Cédric Villemain +33 (0)6 20 30 22 52
> http://2ndQuadrant.fr/
> PostgreSQL: Support 24x7 - Développement, Expertise et Formation
>
--
Gurjeet Singh
n get lost on long rows that get
wrapped around on screen. Writing long-winded CASE expressions to get the
effect is too much for small ad-hoc queries.
I thought of inventing a data type whose out-function would emit these
strings, and tack a ::mybool to the expression I want modified. But that
would break the applications if somebody pasted the same query in an
application (JDBC or some such that understands boolean) and expected a
boolean data type instead of a text output of an expression.
I think there's a merit to psql supporting this feature, because psql is
most commonly used for ad-hoc interactive use, and true/false is more human
consumable than t/f (I have had a Java developer ask me what was that 't'
value in the resultset in psql).
--
Gurjeet Singh
tching in the first
snippet? The Wikipedia [1] article suggests so.
[1] http://en.wikipedia.org/wiki/Uname
Best regards,
--
Gurjeet Singh
Error messages when terminating xlog redo leads the user to believe that
there are parameters named max_prepared_xacts and max_locks_per_xact, which
is not true. This patch corrects the parameter names emitted in the logs.
Best regards,
--
Gurjeet Singh
proper_GUC_names.patch
Description
it's worth stating that this has a HUGE potential
> audience, and if we can get to this the deployment of Postgres could
> mushroom enormously. I'm really quite excited about it.
>
/me shares the feeling :)
--
Gurjeet Singh
he first application
disconnects (and hence shuts down the DB) before the second one can
successfully connect.
I haven't thought much about the security implications of this yet. Maybe
the socket permissions would restrict an unauthorized user user from
connecting to this instance.
--
Gurjeet Singh
http://gurjeet.singh.im/
On Mon, Sep 10, 2012 at 11:43 AM, Heikki Linnakangas wrote:
> On 10.09.2012 18:12, Gurjeet Singh wrote:
>
>> On Sun, Sep 2, 2012 at 8:23 PM, Tom Lane wrote:
>>
>> Notably, while the lack of any background processes is just what you want
>>> for pg_upgrade a
think the real reason is that we assume that read/write to an integer is
atomic, like we do for TransactionId variables:
heapam.c: "TransactionId read/write is assumed atomic anyway."
Best regards,
PS: As usual, I hope I am not missing something very obvious.
--
Gurjeet Singh
http://gurjeet.singh.im/
On Tue, Sep 11, 2012 at 11:19 PM, Amit Kapila wrote:
> On Wednesday, September 12, 2012 5:33 AM Gurjeet Singh wrote:
>
> ** **
>
> ** **
>
> > This comment in UpdateFullPageWrites() seems to be inaccurate:
>
> > * It's safe to check the sh
On Wed, Sep 12, 2012 at 4:08 PM, Noah Misch wrote:
> On Wed, Sep 12, 2012 at 06:44:37AM -0400, Gurjeet Singh wrote:
> > Thinking a bit more about the need for locks, I guess even the shared
> > variables whose read/write ops are considered atomic need to be protected
> >
1 - 100 of 427 matches
Mail list logo
