Re: [HACKERS] Small typo in pageinspect heapfuncs

2016-10-26 Thread Heikki Linnakangas 

On 10/26/2016 09:52 AM, Daniel Gustafsson wrote:

Spotted a tiny typo in contrib/pageinspect/heapfuncs.c: 
s/accordindly/accordingly/


Fixed, thanks.

- Heikki



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Small typo in pageinspect heapfuncs

2016-10-26 Thread Daniel Gustafsson 
Spotted a tiny typo in contrib/pageinspect/heapfuncs.c: 
s/accordindly/accordingly/

cheers ./daniel



typo-pageinspect_heapfuncs.diff
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

Re: [HACKERS] Small typo in a comment in pg_regress.c

2016-04-02 Thread Stephen Frost 
Andreas,

* Andreas 'ads' Scherbaum (adsm...@wars-nicht.de) wrote:
> stumbled over this while looking into the source. Patch attached.

Fix pushed, thanks!

Stephen


signature.asc
Description: Digital signature

[HACKERS] Small typo in a comment in pg_regress.c

2016-04-02 Thread Andreas 'ads' Scherbaum 


Hi,

stumbled over this while looking into the source. Patch attached.


Regards,

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
index 416829d..343fd19 100644
--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -1329,7 +1329,7 @@ results_differ(const char *testname, const char *resultsfile, const char *defaul
 	if (platform_expectfile)
 	{
 		/*
-		 * Replace everything afer the last slash in expectfile with what the
+		 * Replace everything after the last slash in expectfile with what the
 		 * platform_expectfile contains.
 		 */
 		char	   *p = strrchr(expectfile, '/');

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Small typo in timeline.h regarding the meaning of infinity for timeline history entry

2015-09-15 Thread Michael Paquier 
On Tue, Sep 15, 2015 at 7:38 AM, Fujii Masao wrote:
> Thanks for the report and patch! Applied.

Thanks!
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Small typo in timeline.h regarding the meaning of infinity for timeline history entry

2015-09-15 Thread Fujii Masao 
On Thu, Sep 10, 2015 at 2:37 PM, Michael Paquier
 wrote:
> Hi all,
>
> timeline.h quotes that the end point of timeline history entry means
> infinity when its value is 0. But that's not completely true, I think
> that what is meant here is InvalidXLogRecPtr:
>  {
> TimeLineID  tli;
> XLogRecPtr  begin;  /* inclusive */
> -   XLogRecPtr  end;/* exclusive, 0 means
> infinity */
> +   XLogRecPtr  end;/* exclusive,
> InvalidXLogRecPtr means
> +* infinity */
>  } TimeLineHistoryEntry;
>
> And the code leads into this direction as well.

Thanks for the report and patch! Applied.

Regards,

-- 
Fujii Masao


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Small typo in timeline.h regarding the meaning of infinity for timeline history entry

2015-09-09 Thread Michael Paquier 
Hi all,

timeline.h quotes that the end point of timeline history entry means
infinity when its value is 0. But that's not completely true, I think
that what is meant here is InvalidXLogRecPtr:
 {
TimeLineID  tli;
XLogRecPtr  begin;  /* inclusive */
-   XLogRecPtr  end;/* exclusive, 0 means
infinity */
+   XLogRecPtr  end;/* exclusive,
InvalidXLogRecPtr means
+* infinity */
 } TimeLineHistoryEntry;

And the code leads into this direction as well.
Regards,
-- 
Michael
diff --git a/src/include/access/timeline.h b/src/include/access/timeline.h
index 2b62a56..01437c0 100644
--- a/src/include/access/timeline.h
+++ b/src/include/access/timeline.h
@@ -26,7 +26,8 @@ typedef struct
 {
 	TimeLineID	tli;
 	XLogRecPtr	begin;			/* inclusive */
-	XLogRecPtr	end;			/* exclusive, 0 means infinity */
+	XLogRecPtr	end;			/* exclusive, InvalidXLogRecPtr means
+ * infinity */
 } TimeLineHistoryEntry;
 
 extern List *readTimeLineHistory(TimeLineID targetTLI);

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] small typo

2015-05-20 Thread Heikki Linnakangas 

On 05/20/2015 06:55 AM, Euler Taveira wrote:

Attached is a small typo.


Fixed, thanks.

- Heikki


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] small typo

2015-05-19 Thread Euler Taveira 
Hi,

Attached is a small typo.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
diff --git a/contrib/pg_buffercache/pg_buffercache_pages.c b/contrib/pg_buffercache/pg_buffercache_pages.c
index 98016fc..761c277 100644
--- a/contrib/pg_buffercache/pg_buffercache_pages.c
+++ b/contrib/pg_buffercache/pg_buffercache_pages.c
@@ -142,7 +142,7 @@ pg_buffercache_pages(PG_FUNCTION_ARGS)
 			LWLockAcquire(BufMappingPartitionLockByIndex(i), LW_SHARED);
 
 		/*
-		 * Scan though all the buffers, saving the relevant fields in the
+		 * Scan through all the buffers, saving the relevant fields in the
 		 * fctx-record structure.
 		 */
 		for (i = 0; i  NBuffers; i++)

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] small typo in src/backend/access/transam/xlog.c

2014-04-26 Thread Tom Lane 
Bruce Momjian br...@momjian.us writes:
 On Mon, Jul 22, 2013 at 07:32:20PM -0400, Tom Lane wrote:
 We could for instance keep the high half as tv_sec, while making the low
 half be something like (tv_usec  12) | (getpid()  0xfff).  This would
 restore the intended ability to reverse-engineer the exact creation time
 from the sysidentifier, and also add a little more uniqueness by way of
 the creating process's PID.  (Note tv_usec must fit in 20 bits.)

 Can someone make a change here so we can close the issue?

Done.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] small typo about comment in xlog.c

2014-04-10 Thread Heikki Linnakangas 
On 04/10/2014 07:19 AM, Tomonari Katsumata wrote:
 Hi,
 
 I'm reading xlog.c, and I noticed a comment of
 do_pg_abort_backup is typo.
 
 ...
 10247 * NB: This is only for aborting a non-exclusive backup that
 doesn't write
 10248 * backup_label. A backup started with pg_stop_backup() needs to be
 finished
 10249 * with pg_stop_backup().
 ...
 
 I think A backup started with pg_stop_backup() should be
 A backup started with pg_start_backup().
 
 This is a bug about source comment, so it's not big problem.
 But I want to fix the comment.
 See attached patch.

Fixed, thanks.

- Heikki


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] small typo about comment in xlog.c

2014-04-09 Thread Tomonari Katsumata 
Hi,

I'm reading xlog.c, and I noticed a comment of
do_pg_abort_backup is typo.

...
10247 * NB: This is only for aborting a non-exclusive backup that
doesn't write
10248 * backup_label. A backup started with pg_stop_backup() needs to be
finished
10249 * with pg_stop_backup().
...

I think A backup started with pg_stop_backup() should be
A backup started with pg_start_backup().

This is a bug about source comment, so it's not big problem.
But I want to fix the comment.
See attached patch.

regards,
--
Tomonari Katsumata

diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 0b4a5f6..3551d94 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -10245,7 +10245,7 @@ do_pg_stop_backup(char *labelfile, bool waitforarchive, TimeLineID *stoptli_p)
  * an error handler.
  *
  * NB: This is only for aborting a non-exclusive backup that doesn't write
- * backup_label. A backup started with pg_stop_backup() needs to be finished
+ * backup_label. A backup started with pg_start_backup() needs to be finished
  * with pg_stop_backup().
  */
 void

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] small typo in src/backend/access/transam/xlog.c

2014-01-31 Thread Bruce Momjian 
On Mon, Jul 22, 2013 at 07:32:20PM -0400, Tom Lane wrote:
 Andres Freund and...@2ndquadrant.com writes:
  On 2013-07-22 15:55:46 -0400, Robert Haas wrote:
  And why is that?
 
  The comment above tells: while the lower half is the XOR of tv_sec and
  tv_usec.
 
 Yeah, the code doesn't match the comment; this mistake seems to be
 aboriginal.
 
  I don't think it really matters. the bitwise OR has the tenency to
  collect too many set bits, but ... who cares?
 
 This is making the value less unique than intended, so I think it's
 worth doing something about.  However, it's also worth noting that the
 intended behavior (as described by the comment) was designed to allow
 for the possibility that uint64 is really only 32 bits --- a
 possibility we stopped supporting several versions ago.  So rather than
 just quickly s/|/^/, maybe we should step back and think about whether
 we want to change the sysid generation algorithm altogether.
 
 We could for instance keep the high half as tv_sec, while making the low
 half be something like (tv_usec  12) | (getpid()  0xfff).  This would
 restore the intended ability to reverse-engineer the exact creation time
 from the sysidentifier, and also add a little more uniqueness by way of
 the creating process's PID.  (Note tv_usec must fit in 20 bits.)

Can someone make a change here so we can close the issue?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + Everyone has their own god. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] small typo in src/backend/access/transam/xlog.c

2013-07-22 Thread didier 
Hi

in void
BootStrapXLOG(void)

  * to seed it other than the system clock value...)  The upper half of
the
 * uint64 value is just the tv_sec part, while the lower half is
the XOR
 * of tv_sec and tv_usec.  This is to ensure that we don't lose
uniqueness
 * unnecessarily if uint64 is really only 32 bits wide.  A person
 * knowing this encoding can determine the initialization time of
the
 * installation, which could perhaps be useful sometimes.
 */
gettimeofday(tv, NULL);
sysidentifier = ((uint64) tv.tv_sec)  32;
sysidentifier |= (uint32) (tv.tv_sec | tv.tv_usec);

should be
sysidentifier |= (uint32) (tv.tv_sec ^ tv.tv_usec);

Regards
Didier

Re: [HACKERS] small typo in src/backend/access/transam/xlog.c

2013-07-22 Thread Robert Haas 
On Mon, Jul 22, 2013 at 6:45 AM, didier did...@gmail.com wrote:
 Hi

 in void
 BootStrapXLOG(void)

   * to seed it other than the system clock value...)  The upper half of
 the
  * uint64 value is just the tv_sec part, while the lower half is the
 XOR
  * of tv_sec and tv_usec.  This is to ensure that we don't lose
 uniqueness
  * unnecessarily if uint64 is really only 32 bits wide.  A person
  * knowing this encoding can determine the initialization time of
 the
  * installation, which could perhaps be useful sometimes.
  */
 gettimeofday(tv, NULL);
 sysidentifier = ((uint64) tv.tv_sec)  32;
 sysidentifier |= (uint32) (tv.tv_sec | tv.tv_usec);

 should be
 sysidentifier |= (uint32) (tv.tv_sec ^ tv.tv_usec);

And why is that?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] small typo in src/backend/access/transam/xlog.c

2013-07-22 Thread Andres Freund 
On 2013-07-22 15:55:46 -0400, Robert Haas wrote:
 On Mon, Jul 22, 2013 at 6:45 AM, didier did...@gmail.com wrote:
  Hi
 
  in void
  BootStrapXLOG(void)
 
* to seed it other than the system clock value...)  The upper half of
  the
   * uint64 value is just the tv_sec part, while the lower half is the
  XOR
   * of tv_sec and tv_usec.  This is to ensure that we don't lose
  uniqueness
   * unnecessarily if uint64 is really only 32 bits wide.  A person
   * knowing this encoding can determine the initialization time of
  the
   * installation, which could perhaps be useful sometimes.
   */
  gettimeofday(tv, NULL);
  sysidentifier = ((uint64) tv.tv_sec)  32;
  sysidentifier |= (uint32) (tv.tv_sec | tv.tv_usec);
 
  should be
  sysidentifier |= (uint32) (tv.tv_sec ^ tv.tv_usec);
 
 And why is that?

The comment above tells: while the lower half is the XOR of tv_sec and
tv_usec.

I don't think it really matters. the bitwise OR has the tenency to
collect too many set bits, but ... who cares?
On the other hand, changing it is easy and shouldn't cause any problems.

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] small typo in src/backend/access/transam/xlog.c

2013-07-22 Thread Tom Lane 
Andres Freund and...@2ndquadrant.com writes:
 On 2013-07-22 15:55:46 -0400, Robert Haas wrote:
 And why is that?

 The comment above tells: while the lower half is the XOR of tv_sec and
 tv_usec.

Yeah, the code doesn't match the comment; this mistake seems to be
aboriginal.

 I don't think it really matters. the bitwise OR has the tenency to
 collect too many set bits, but ... who cares?

This is making the value less unique than intended, so I think it's
worth doing something about.  However, it's also worth noting that the
intended behavior (as described by the comment) was designed to allow
for the possibility that uint64 is really only 32 bits --- a
possibility we stopped supporting several versions ago.  So rather than
just quickly s/|/^/, maybe we should step back and think about whether
we want to change the sysid generation algorithm altogether.

We could for instance keep the high half as tv_sec, while making the low
half be something like (tv_usec  12) | (getpid()  0xfff).  This would
restore the intended ability to reverse-engineer the exact creation time
from the sysidentifier, and also add a little more uniqueness by way of
the creating process's PID.  (Note tv_usec must fit in 20 bits.)

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Small typo in syncrep.h

2013-05-23 Thread Pavan Deolasee 
Hello,

While reading code, I noticed a small typo in syncrep.h. It
says SyncRepUpdateSyncStandbysDefined() is called by wal writer whereas its
called by the checkpointer process, at least in the HEAD. Previously, it
was being called by the bgwriter process.

Attached patches fix this in the relevant releases.

Thanks,
Pavan

-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee


syncrep-typo-91.patch
Description: Binary data


syncrep-typo-head.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

Re: [HACKERS] Small typo in syncrep.h

2013-05-23 Thread Robert Haas 
On Thu, May 23, 2013 at 4:44 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
 While reading code, I noticed a small typo in syncrep.h. It says
 SyncRepUpdateSyncStandbysDefined() is called by wal writer whereas its
 called by the checkpointer process, at least in the HEAD. Previously, it was
 being called by the bgwriter process.

 Attached patches fix this in the relevant releases.

Committed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers