Re: [PATCHES] win32mak_patch
Hiroshi Saito wrote: Anyway. If you get references to it, you need to pull in port/dirmod.c into psql as well. Normally, it would get this through libpgport, but it looks like your custom makfile is pulling the files in directly instead. So adding dirmod to the list of stuff from src/port should hopefully fix your problem. Um, win32.mak of libpq needed to add dirmod.c -- libpq.lib(fe-connect.obj) : error LNK2001: (snip-sjis message) _pgwin32_safestat Then, Is containing in libpq wrong? I'm confused for a while... Yes, you are missing something :-) The patch for win32.mak I'm happy to apply, it looks fine. The patch for exports.txt does not look fine. Can you confirm that you can build things properly *with* the patch to win32.mak but *without* the patch to exports.txt? Also, I assume this needs to be backpatched? //Magnus -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] Proposed patch - psql wraps at window width
Bryce Nesbitt wrote: Bruce Momjian wrote: I have updated the documentation for this patch. I consider it ready to apply. I think it is as close to a middle ground as we are going to get. Further adjustment will have to happen when we have more reports from the field. I heard a pretty compelling argument to make wrapped part of aligned, and thus I think the patch is ready to go only after adjusting the user-facing syntax: \pset border 2 \pset format aligned Output format is aligned, no wrapping. \pset format aligned autowrap Output format is aligned, with automatic wrapping to the window width for terminals. \pset format aligned 80 Output format is aligned, with a target width of 80 characters. \a Output format is unaligned, no wrapping. \a Output format is aligned, with a target width of 80 characters. If the wrapping code can't fit the column headings in the wrap width, it gives up and produces aligned output. To do otherwise is totally unreadable. Please give the patch a try, before complaining about this particular aspect of it. Uh, well, we can do that, though looking at the psql code \pset only wants two arguments. We would have to modify how \pset works. Also, I am afraid making wrapping part of aligned is overly complicating the API. For example, I specificially kept \pset columns rather than allowing a third argument to pset because it was starting to look too complicated to describe in the manual. I am not 100% sure myself so hopefully others will comment. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT
Hi, Here is the patch. Check it, please. Locations of the added files: src\include\port\win32_msvc\sys\stat.inl src\port\stat_pg_fixed.c Thank you. -Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: Saturday, March 29, 2008 4:18 PM To: Zubkovsky, Sergey Cc: Tom Lane; Alvaro Herrera; Gregory Stark; [EMAIL PROTECTED]; Magnus Hagander Subject: Re: [HACKERS] [DOCS] pg_total_relation_size() and CHECKPOINT Zubkovsky, Sergey wrote: In the prepared custom build of PG 8.3.1 the native MSVC's stat() was rewrote by adding GetFileAttributesEx() to correct stat's st_size value. I had seen that a result of MSVC's stat() and a result of GetFileAttributesEx() may be differ by the file size values at least. The most important thing is the test in the original post ( http://archives.postgresql.org/pgsql-docs/2008-03/msg00041.php ) doesn't reproduce any inconsistence now. All work fine. This was tested on my WinXP SP2 platform but I suppose it will work on any NT-based OS. If you have a patch, please send it to the -patches list. cheers andrew Mkvcbuild.pm.patch Description: Mkvcbuild.pm.patch stat_pg_fixed.c Description: stat_pg_fixed.c stat.inl Description: stat.inl -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] win32mak_patch
Hi Magnus. - Original Message - From: Magnus Hagander [EMAIL PROTECTED] Um, win32.mak of libpq needed to add dirmod.c -- libpq.lib(fe-connect.obj) : error LNK2001: (snip-sjis message) _pgwin32_safestat Then, Is containing in libpq wrong? I'm confused for a while... Yes, you are missing something :-) Ahh Sure, I had missed discussion of this improvement. Then, It seems that win32.mak has been forgotten. The patch for win32.mak I'm happy to apply, it looks fine. Yeah, Anyway I think that the equipment is required. The patch for exports.txt does not look fine. About it, I do not have firm belief yet. However, It does not put in there. Can you confirm that you can build things properly *with* the patch to win32.mak but *without* the patch to exports.txt? http://winpg.jp/~saito/pg_work/WIN32_BUILD_INF/psql_win32_n.mak I checked the build without correction of exports.txt. Also, I assume this needs to be backpatched? Yes, Since you have already done, I think that it is required. Thanks! Regards, Hiroshi Saito -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] Proposed patch - psql wraps at window width
Bruce Momjian wrote: Bryce Nesbitt wrote: Bruce Momjian wrote: I have updated the documentation for this patch. I consider it ready to apply. I think it is as close to a middle ground as we are going to get. Further adjustment will have to happen when we have more reports from the field. I heard a pretty compelling argument to make wrapped part of aligned, and thus I think the patch is ready to go only after adjusting the user-facing syntax: I think this is what makes the most sense of what I've seen so far. Wrapped is a special case of aligned anyway (there's no wrapped unaligned or wrapped HTML for example, nor would we want there to be.) Output format is aligned, no wrapping. \pset format aligned autowrap Output format is aligned, with automatic wrapping to the window width for terminals. \pset format aligned 80 Output format is aligned, with a target width of 80 characters. Uh, well, we can do that, though looking at the psql code \pset only wants two arguments. I think that could be fixed easily by having the syntax be something like \pset format aligned:80 \pset format aligned:autowrap etc. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Documentation: ALTER ROLE - no password
Hello, i've seen the question how to remove a password now several times in the last weeks. Attached is a small patch which add a new example for the ALTER ROLE documentation. Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group --- alter_role.sgml.orig 2007-09-03 20:46:29.0 +0200 +++ alter_role.sgml 2008-04-30 02:02:00.0 +0200 @@ -218,6 +218,14 @@ /para para + Remove a role's password: + +programlisting +ALTER ROLE davide WITH PASSWORD NULL; +/programlisting + /para + + para Change a password expiration date, specifying that the password should expire at midday on 4th May 2015 using the time zone which is one hour ahead of acronymUTC/: -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] Proposed patch - psql wraps at window width
Alvaro Herrera [EMAIL PROTECTED] writes: Bruce Momjian wrote: Bryce Nesbitt wrote: Bruce Momjian wrote: I have updated the documentation for this patch. I consider it ready to apply. I think it is as close to a middle ground as we are going to get. Further adjustment will have to happen when we have more reports from the field. I heard a pretty compelling argument to make wrapped part of aligned, and thus I think the patch is ready to go only after adjusting the user-facing syntax: I think this is what makes the most sense of what I've seen so far. Wrapped is a special case of aligned anyway (there's no wrapped unaligned or wrapped HTML for example, nor would we want there to be.) Well there's no unaligned HTML or aligned unaligned either... I think that could be fixed easily by having the syntax be something like \pset format aligned:80 \pset format aligned:autowrap I suppose. It seems kind of inconvenient though, what advantage does it have? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] fourat wants to keep up with you on Twitter
To find out more about Twitter, visit the link below: http://twitter.com/i/c895aa0264f0088097d8012ea371a9a3cc8f1a77 Thanks, -The Twitter Team About Twitter Twitter is a unique approach to communication and networking based on the simple concept of status. What are you doing? What are your friends doing—right now? With Twitter, you may answer this question over SMS, IM, or the Web and the responses are shared between contacts. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] pg_postmaster_reload_time() patch
I've done a quick write up for reload time reporting from the
administration TODO. I was a little paranoid with the locking, but
didn't want problems to occur with signals on the postmaster and the
read side.
-George
*** ./doc/src/sgml/func.sgml.orig 2008-04-29 23:47:39.378726574 -0400
--- ./doc/src/sgml/func.sgml 2008-04-29 23:51:12.346237119 -0400
***
*** 10892,10897
--- 10892,10903
/row
row
+entryliteralfunctionpg_postmaster_reload_time/function()/literal/entry
+entrytypetimestamp with time zone/type/entry
+entryserver last reload time/entry
+ /row
+
+ row
entryliteralfunctionsession_user/function/literal/entry
entrytypename/type/entry
entrysession user name/entry
***
*** 11037,11042
--- 11043,11062
/para
indexterm
+ primarypg_postmaster_reload_time/primary
+/indexterm
+
+para
+ functionpg_postmaster_reload_time/function returns the
+ typetimestamp with time zone/type when the
+ server was last reloaded.
+/para
+
+indexterm
+ primaryversion/primary
+/indexterm
+
+indexterm
primaryversion/primary
/indexterm
*** ./src/backend/postmaster/postmaster.c.orig 2008-04-29 23:48:07.374455697 -0400
--- ./src/backend/postmaster/postmaster.c 2008-04-29 23:51:12.346237119 -0400
***
*** 112,117
--- 112,118
#include storage/pg_shmem.h
#include storage/pmsignal.h
#include storage/proc.h
+ #include storage/spin.h
#include tcop/tcopprot.h
#include utils/builtins.h
#include utils/datetime.h
***
*** 390,395
--- 391,398
InheritableSocket pgStatSock;
pid_t PostmasterPid;
TimestampTz PgStartTime;
+ TimestampTz PgReloadTime;
+ slock_t PgReloadTimeLock;
bool redirection_done;
#ifdef WIN32
HANDLE PostmasterHandle;
***
*** 1008,1013
--- 1011,1018
* Remember postmaster startup time
*/
PgStartTime = GetCurrentTimestamp();
+ PgReloadTime = PgStartTime;
+ SpinLockInit(PgReloadTimeLock);
/* PostmasterRandom wants its own copy */
gettimeofday(random_start_time, NULL);
***
*** 1931,1936
--- 1936,1948
/* Update the starting-point file for future children */
write_nondefault_variables(PGC_SIGHUP);
#endif
+
+ /*
+ * Remember postmaster reload time
+ */
+ SpinLockAcquire(PgReloadTimeLock);
+ PgReloadTime = GetCurrentTimestamp();
+ SpinLockRelease(PgReloadTimeLock);
}
PG_SETMASK(UnBlockSig);
***
*** 4263,4268
--- 4275,4282
param-PostmasterPid = PostmasterPid;
param-PgStartTime = PgStartTime;
+ param-PgReloadTime = PgReloadTime;
+ param-PgReloadTimeLock = PgReloadTimeLock;
param-redirection_done = redirection_done;
*** ./src/backend/tcop/postgres.c.orig 2008-04-29 23:48:58.866600196 -0400
--- ./src/backend/tcop/postgres.c 2008-04-29 23:51:12.346237119 -0400
***
*** 58,63
--- 58,64
#include storage/ipc.h
#include storage/proc.h
#include storage/sinval.h
+ #include storage/spin.h
#include tcop/fastpath.h
#include tcop/pquery.h
#include tcop/tcopprot.h
***
*** 3373,3380
/*
* Remember stand-alone backend startup time
*/
! if (!IsUnderPostmaster)
PgStartTime = GetCurrentTimestamp();
/*
* POSTGRES main processing loop begins here
--- 3374,3384
/*
* Remember stand-alone backend startup time
*/
! if (!IsUnderPostmaster) {
PgStartTime = GetCurrentTimestamp();
+ PgReloadTime = PgStartTime;
+ SpinLockInit(PgReloadTimeLock);
+ }
/*
* POSTGRES main processing loop begins here
***
*** 3550,3555
--- 3554,3566
{
got_SIGHUP = false;
ProcessConfigFile(PGC_SIGHUP);
+
+ /*
+ * Remember postmaster reload time
+ */
+ SpinLockAcquire(PgReloadTimeLock);
+ PgReloadTime = GetCurrentTimestamp();
+ SpinLockRelease(PgReloadTimeLock);
}
/*
*** ./src/backend/utils/adt/timestamp.c.orig 2008-04-29 23:49:46.359354923 -0400
--- ./src/backend/utils/adt/timestamp.c 2008-04-29 23:51:12.346237119 -0400
***
*** 27,32
--- 27,33
#include libpq/pqformat.h
#include miscadmin.h
#include parser/scansup.h
+ #include storage/spin.h
#include utils/array.h
#include utils/builtins.h
#include utils/datetime.h
***
*** 42,47
--- 43,50
/* Set at postmaster start */
TimestampTz PgStartTime;
+ TimestampTz PgReloadTime;
+ slock_t PgReloadTimeLock;
static TimeOffset time2t(const int hour, const int min, const int sec, const fsec_t fsec);
***
*** 1162,1167
--- 1165,1180
PG_RETURN_TIMESTAMPTZ(PgStartTime);
}
+ Datum
+ pgsql_postmaster_reload_time(PG_FUNCTION_ARGS)
+ {
+ TimestampTz timestamp;
+ SpinLockAcquire(PgReloadTimeLock);
+ timestamp = PgReloadTime;
+ SpinLockRelease(PgReloadTimeLock);
+
Re: [PATCHES] pg_postmaster_reload_time() patch
On Wed, Apr 30, 2008 at 9:53 AM, George Gensure [EMAIL PROTECTED] wrote: I've done a quick write up for reload time reporting from the administration TODO. I was a little paranoid with the locking, but didn't want problems to occur with signals on the postmaster and the read side. IMHO, the function should return NULL if the postmaster never reloaded; that is, it was started, but never signaled to reload. Best regards, -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | indiatimes | yahoo }.com EnterpriseDB http://www.enterprisedb.com Mail sent from my BlackLaptop device
