Re: [HACKERS] building libpq.a static library

2017-07-12 Thread Jan de Visser 
On Wednesday, July 12, 2017 6:31:09 AM EDT Jeroen Ooms wrote:
> I maintain static libraries for libpq for the R programming language
> (we need static linking to ship with the binary packages).
> Unfortunately currently the standard postgres makefile only generates
> a shared library for libpq, not a static one.
> 
> In order to make a static library I always manually edit
> ./src/interfaces/libpq/Makefile and add a target:
> 
> libpq.a: $(OBJS)
>   ar rcs $@ $^
> 
> And then run 'make libpq.a' in the libpq directory.
> 
> This works but it's a bit of a pain to maintain. I was wondering if
> this hack could be merged so that the standard 'configure
> --enable-static' script would install a static library for libpq
> alongside the shared one.

I have no idea what the consensus about this is, but providing a patch file and 
registering it at https://commitfest.postgresql.org/ increases your chances.

I wish you good luck hacking autoconf hell (which is what you'll need to do to 
get the command line switch) though (*shudder*).



-- 
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] SQL MERGE patches for PostgreSQL Versions

2017-06-22 Thread Jan de Visser 
On Thursday, June 22, 2017 12:32:14 PM EDT Kang Yuzhe wrote:
> Here is a sample what I did after applying the patch.
> 
> testdb=# BEGIN;
> BEGIN
> testdb=#
> testdb=# MERGE INTO Stock USING Buy ON Stock.item_id = Buy.item_id
> testdb-#  WHEN MATCHED THEN UPDATE SET balance = balance + Buy.volume
> testdb-#  WHEN NOT MATCHED THEN DO NOTHING;
> MERGE 1
> testdb=# SELECT * FROM Stock;
>  item_id | balance
> -+-
>   20 |1900
>   10 |3200
> (2 rows)
> 
> testdb=# ROLLBACK;
> ROLLBACK

I am not quite sure what you're trying to achieve, but are you aware that 
pgsql 9.6 introduced the ON CONFLICT clause, which allows you to do the same 
with a different syntax?

https://www.postgresql.org/docs/9.6/static/sql-insert.html

Look for ON CONFLICT.




-- 
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] my open items vs. my vacation

2017-04-12 Thread Jan de Visser 
On Tuesday, April 11, 2017 1:36:44 PM EDT Robert Haas wrote:
> I apologize for any disruption this may cause, but I'm hopeful that it
> won't be too bad.

Spoken like a true American - apologizing for taking vacation :-)

Enjoy your time off. You probably deserved it, and more than the week you're 
taking now.



-- 
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] Removing binaries (was: createlang/droplang deprecated)

2017-03-20 Thread Jan de Visser 
On Monday, March 20, 2017 3:30:49 PM EDT Robert Haas wrote:
> On Sat, Mar 18, 2017 at 4:12 PM, Magnus Hagander  
wrote:
> > createdb, dropdb - also not clear they're about postgres, more likely to
> > be
> > used by mistake but not that bad. That said, do they add any *value*
> > beyond
> > what you can do with psql -c "CREATE DATABASE"? I don't really see one, so
> > I'd suggest dropping these too.
> 
> That would annoy me, because I use these constantly.  I also think
> that they solve a problem for users, which is this:
> 
> [rhaas ~]$ psql
> psql: FATAL:  database "rhaas" does not exist
> [rhaas ~]$ psql -c 'create database rhaas;'
> psql: FATAL:  database "rhaas" does not exist
> [rhaas ~]$ gosh, i know i need to connect to a database in order to
> create the database to which psql tries to connect by default, so
> there must be an existing database with some name, but what exactly is
> that name, anyway?
> -bash: gosh,: command not found
> 
> There was an occasion when this exact problem almost caused me to give
> up on using PostgreSQL.  Everybody here presumably knows that
> template1 and postgres are the magic words you can add to the end of
> that command line to make it work, but that is NOT self-evident to
> newcomers.

Same here. I worked on a system with a shrink-wrap installer which installed 
pgsql as well and initialized it for use by the system user of our software. 
If a tester or sales engineer wanted to play with the DB, it would be about 30 
minutes before they would end up at my desk, in tears.


-- 
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] RustgreSQL

2017-01-10 Thread Jan de Visser 
On Monday, January 9, 2017 7:39:49 PM EST Joel Jacobson wrote:
> On Mon, Jan 9, 2017 at 6:03 PM, Craig Ringer  wrote:
> > Immutable functions can and do use functionality from all over the
> > server. They just don't depend on user-visible mutable _state_
> > elsewhere in the server.
> 
> OK, fair point, but at least the functionality *could* be written without
> using existing C functions, since its only the input that determine what
> output will be returned. The dependencies used by the immutable
> functions can also be ported, function by function, until there are
> no dependencies.

Be that as it may, I don't think you have convinced anybody that that is 
something worth doing. The fact it *could* be done doesn't mean it *should* be 
done.

You're proposing to introduce a metric eff-ton of instability in a project 
that routinely spends ten-message email threads discussing changing an elog to 
ereport.

To give you some perspective: *everybody* agrees autotools (the mechanism used 
to generate makefiles) is aweful. Everybody. About a year ago somebody showed 
saying "Hey, I have a draft patch replacing autotools with cmake". Cmake is 
infinitely better (mostly because it was developed in this century as opposed 
to the early 80s, and so is more in tune with current toolchains). Yury has 
been working on it for a year now, and I personally don't think it's going to 
land in version 10. And this is "just" the make infrastructure.

What you are proposing is not going to happen unless you get some serious buy-
in from a significant number of veteran contributors. And those are exactly the 
people that say "C? What's the problem?"



-- 
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] RustgreSQL

2017-01-08 Thread Jan de Visser 
On Monday, January 9, 2017 7:06:21 AM EST Craig Ringer wrote:
> On 9 Jan. 2017 05:51, "Jan de Visser" <j...@de-visser.net> wrote:
> 
> On Sunday, January 8, 2017 6:28:17 AM EST Joel Jacobson wrote:
> > I don't want to learn the complicated details of C, that's true.
> 
> And this is where I think you're wrong, and why conversion would be hard. C
> has very few complicated details. I don't think it has any, frankly.
> 
> 
> Oh, that's really rather optimistic.
> 
[snip]

Allow me to be snarky and summarize your (very true) points as: "writing 
complicated software systems is hard". 

That's not the fault of the language (in most cases). The complexity can 
somewhat be abstracted by the language, which Rust and Java try to do, or 
completely left to the design, as you're forced to do in C. The former gives 
you either a more complicated language or severly limit what you can do, and 
in the end you will find walls to bang your head against and edges of cliffs to 
fall off of.

The latter, of course, makes your head explode if your system is large enough 
and you don't have Tom Lane and Robert Haas around.



-- 
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] RustgreSQL

2017-01-08 Thread Jan de Visser 
On Sunday, January 8, 2017 6:28:17 AM EST Joel Jacobson wrote:
> I don't want to learn the complicated details of C, that's true.

And this is where I think you're wrong, and why conversion would be hard. C 
has very few complicated details. I don't think it has any, frankly. It 
basically says "If you want your datastructure to outlive a function call, 
I'll give you a chunk of memory and you're now responsible for it. Have fun". 
That's not complicated: it's two functions, malloc() and free(), basically. 

What's hard and complicated is keeping track of all those little chunks of 
memory you have laying around. That management is deeply intertwined with the 
algorithmics of the system, and separating memory management from the actual 
work done will be very hard. In many cases the algorithm will have been 
implemented with cheap memory management in mind, and porting it to a 
different paradigm (garbage collection or rust's reference ownership) can 
result in either a lot of work and probably bugs, or bad performing code.

I personally find keeping track of allocated memory easier than rust's 
convoluted (to me) rules regarding reference ownership.

Your fear of C in unfounded. The definitive c89 reference is a little book of 
about 250 pages, more than half of which is about the standard library of 
which you'll never use more than half. If you have some notepaper laying about 
on which to scribble pointer diagrams you can be a C programmer to :-)



-- 
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] Do we need use more meaningful variables to replace 0 in catalog head files?

2016-11-10 Thread Jan de Visser 

On 2016-11-09 10:47 AM, Tom Lane wrote:


Amit Langote  writes:

On Wed, Nov 9, 2016 at 11:47 PM, Tom Lane  wrote:

Hmm, that's from 2009.  I thought I remembered something much more recent,
like last year or so.

This perhaps:
* Re: Bootstrap DATA is a pita *
https://www.postgresql.org/message-id/flat/CAOjayEfKBL-_Q9m3Jsv6V-mK1q8h%3Dca5Hm0fecXGxZUhPDN9BA%40mail.gmail.com

Yeah, that's the thread I remembered.  I think the basic conclusion was
that we needed a Perl script that would suck up a bunch of data from some
representation that's more edit-friendly than the DATA lines, expand
symbolic representations (regprocedure etc) into numeric OIDs, and write
out the .bki script from that.  I thought some people had volunteered to
work on that, but we've seen no results ...

regards, tom lane




Would a python script converting something like json or yaml be 
acceptable? I think right now only perl is used, so it would be a new 
build chain tool, albeit one that's in my (very humble) opinion much 
better suited to the task.




--
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] Death by regexp_replace

2016-01-15 Thread Jan de Visser 

On 2016-01-15 10:25 AM, Robert Haas wrote:

On Fri, Jan 15, 2016 at 10:12 AM, Benedikt Grundmann
 wrote:

Today we discovered that we had a backend whose client had gone away, the
automatic query watching process had send both pg_cancel and
pg_terminate_backend but nevertheless the process was sitting there
consuming resources and had been for over 1 day...

gdb revealed that we were sitting in pg_regexec  (we forced it to return 16
aka invalid regex to return our system into a good state).

Here is the regular expression and the text to run on:

WARNING DO NOT DO THIS ON A PRODUCTION BOX

select regexp_replace('VODI GR,VOD LN,VOD LN,VODN MM,VODPF US,VOD US,VZC
LN', '([^,]+)(,*\1)+', '\1');

This was in postgres 9.2

9.2.what?  Tom just fixed a whole bunch of bugs in this area, so if
you're running less than 9.2.14, please test whether this can be
reproduced with that version.



I just tried this on 9.4.5 (stock Ubuntu 15.10 release), waited a minute 
and killed the backend.




--
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] Idea: closing the loop for pg_ctl reload

2015-08-25 Thread Jan de Visser 
On August 25, 2015 09:31:35 PM Michael Paquier wrote:
 On Thu, Jul 23, 2015 at 5:06 PM, Heikki Linnakangas wrote:
  Other comments:
  [...]
 
 This patch had feedback, but there has been no update in the last
 month, so I am now marking it as returned with feedback.

It was suggested that this mechanism became superfluous with the inclusion of 
the view postgresql.conf (pg_settings?) in 9.5. I left it to Tom (being the 
one that suggested the feature) to indicate if he still thinks it's useful.

jan



-- 
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] Idea: closing the loop for pg_ctl reload

2015-08-25 Thread Jan de Visser 
On August 25, 2015 08:36:52 PM Tom Lane wrote:
 Jan de Visser j...@de-visser.net writes:
  On August 25, 2015 09:31:35 PM Michael Paquier wrote:
  This patch had feedback, but there has been no update in the last
  month, so I am now marking it as returned with feedback.
  
  It was suggested that this mechanism became superfluous with the inclusion
  of the view postgresql.conf (pg_settings?) in 9.5. I left it to Tom
  (being the one that suggested the feature) to indicate if he still thinks
  it's useful.
 I think there's still a fair argument for pg_ctl reload being able to
 return a simple yes-or-no result.  We had talked about trying to shoehorn
 textual error messages into the protocol, and I'm now feeling that that
 complication isn't needed, but a bare-bones feature would still be worth
 the trouble IMO.

OK, I'll have a look at the review comments and submit something updated soon.


-- 
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] Idea: closing the loop for pg_ctl reload

2015-07-06 Thread Jan de Visser 
On July 6, 2015 09:23:12 AM Stephen Frost wrote:
  I wonder whether we should consider inventing similar views for
  pg_hba.conf and pg_ident.conf.
 
 Yes.  That's definitely something that I'd been hoping someone would
 work on.

There actually is a patch in the current CF that provides a view for pg_hba. I 
could look at one for pg_ident, which seems much simpler.



-- 
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] Idea: closing the loop for pg_ctl reload

2015-07-03 Thread Jan de Visser 
On July 3, 2015 06:21:09 PM Tom Lane wrote:
 Jan de Visser j...@de-visser.net writes:
  Attached a new patch, rebased against the current head. Errors in
  pg_hba.conf and pg_ident.conf are now also noticed.
  
  I checked the documentation for pg_ctl reload, and the only place where
  it's explained seems to be runtime.sgml and that description is so
  high-level that adding this new bit of functionality wouldn't make much
  sense.
 
 BTW, it's probably worth pointing out that the recent work on the
 pg_file_settings view has taken away a large part of the use-case for
 this, in that you can find out more with less risk by inspecting
 pg_file_settings before issuing SIGHUP, instead of SIGHUP'ing and
 hoping you didn't break anything too nastily.  Also, you can use
 pg_file_settings remotely, unlike pg_ctl (though admittedly you
 still need contrib/adminpack or something to allow uploading a
 new config file if you're doing remote admin).
 
 I wonder whether we should consider inventing similar views for
 pg_hba.conf and pg_ident.conf.
 
 While that's not necessarily a reason not to adopt this patch anyway,
 it does mean that we should think twice about whether we need to add
 a couple of hundred lines for a facility that's less useful than
 what we already have.

Since you were the one proposing the feature, I'm going to leave it to you 
whether or not I should continue with this. I have no use for this feature; 
for me it just seemed like a nice bite-sized feature to get myself acquainted 
with the code base and the development process. As far as I'm concerned that 
goal has already been achieved, even though finalizing a patch towards commit 
(and having my name in the release notes ha ha) would be the icing on the 
cake.

 
 BTW, this version of this patch neglects to update the comments in
 miscadmin.h, and it makes the return convention for
 ProcessConfigFileInternal completely unintelligible IMO; the inaccuracy
 and inconsistency in the comments is a symptom of that.  I didn't read it
 in enough detail to say whether there are other problems.

OK, miscadmin.h. I'll go and look what that's all about. And would it make 
sense to find a better solution for the ProcessConfigFileInternal return value 
(which is convoluted, I agree - I went for the solution with the least impact 
on existing code), or should I improve documentation?

 
   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] Idea: closing the loop for pg_ctl reload

2015-07-03 Thread Jan de Visser 
On July 3, 2015 06:21:09 PM Tom Lane wrote:
 I wonder whether we should consider inventing similar views for
 pg_hba.conf and pg_ident.conf.

(Apologies for the flurry of emails).

Was there not an attempt at a view for pg_hba.conf which ended in a lot of 
bikeshedding and no decisions?


-- 
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] Idea: closing the loop for pg_ctl reload

2015-07-03 Thread Jan de Visser 
On July 3, 2015 09:24:36 PM Jan de Visser wrote:
 On July 3, 2015 06:21:09 PM Tom Lane wrote:
  BTW, this version of this patch neglects to update the comments in
  miscadmin.h, and it makes the return convention for
  ProcessConfigFileInternal completely unintelligible IMO; the inaccuracy
  and inconsistency in the comments is a symptom of that.  I didn't read it
  in enough detail to say whether there are other problems.
 
 OK, miscadmin.h. I'll go and look what that's all about. And would it make
 sense to find a better solution for the ProcessConfigFileInternal return
 value (which is convoluted, I agree - I went for the solution with the
 least impact on existing code), or should I improve documentation?
 

Heh. I actually touched that file. I completely missed those comments (or saw 
them, thought that I should update them, and then forgot about them - just as 
likely). I'll obviously fix this if we carry this to completion.


-- 
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] Idea: closing the loop for pg_ctl reload

2015-07-03 Thread Jan de Visser 
Attached a new patch, rebased against the current head. Errors in
pg_hba.conf and pg_ident.conf are now also noticed.

I checked the documentation for pg_ctl reload, and the only place where
it's explained seems to be runtime.sgml and that description is so
high-level that adding this new bit of functionality wouldn't make much
sense.

On Sat, Apr 25, 2015 at 10:03 AM, Jan de Visser j...@de-visser.net wrote:

 On April 22, 2015 06:04:42 PM Payal Singh wrote:
  The following review has been posted through the commitfest application:
  make installcheck-world:  not tested
  Implements feature:   tested, failed
  Spec compliant:   not tested
  Documentation:tested, failed
 
  Error in postgresql.conf gives the expected result on pg_ctl reload,
  although errors in pg_hba.conf file don't. Like before, reload completes
  fine without any information that pg_hba failed to load and only
  information is present in the log file. I'm assuming pg_ctl reload should
  prompt user if file fails to load irrespective of which file it is -
  postgresql.conf or pg_hba.conf.

 Will fix. Not hard, just move the code that writes the .pid file to after
 the
 pg_hba reload.

 
  There is no documentation change so far, but I guess that's not yet
  necessary.

 I will update the page for pg_ctl. At least the behaviour of -w/-W in
 relation
 to the reload command needs explained.

 
  gmake check passed all tests.
 
  The new status of this patch is: Waiting on Author

 jan


diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index df8037b..909a078 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -1235,6 +1235,15 @@ PostmasterMain(int argc, char *argv[])
 #endif
 
 	/*
+	 * Update postmaster.pid with startup time as the last reload time:
+	 */
+	{
+		char last_reload_info[32];
+		snprintf(last_reload_info, 32, %ld %d, (long) MyStartTime, 1);
+		AddToDataDirLockFile(LOCK_FILE_LINE_LAST_RELOAD, last_reload_info);
+	}
+
+	/*
 	 * Remember postmaster startup time
 	 */
 	PgStartTime = GetCurrentTimestamp();
@@ -2349,6 +2358,8 @@ static void
 SIGHUP_handler(SIGNAL_ARGS)
 {
 	int			save_errno = errno;
+	boolreload_success;
+	charlast_reload_info[32];
 
 	PG_SETMASK(BlockSig);
 
@@ -2356,7 +2367,8 @@ SIGHUP_handler(SIGNAL_ARGS)
 	{
 		ereport(LOG,
 (errmsg(received SIGHUP, reloading configuration files)));
-		ProcessConfigFile(PGC_SIGHUP);
+		reload_success = ProcessConfigFile(PGC_SIGHUP);
+
 		SignalChildren(SIGHUP);
 		SignalUnconnectedWorkers(SIGHUP);
 		if (StartupPID != 0)
@@ -2379,13 +2391,25 @@ SIGHUP_handler(SIGNAL_ARGS)
 			signal_child(PgStatPID, SIGHUP);
 
 		/* Reload authentication config files too */
-		if (!load_hba())
+		if (!load_hba()) {
+			reload_success = 0; 
 			ereport(WARNING,
 	(errmsg(pg_hba.conf not reloaded)));
+		}
 
-		if (!load_ident())
+		if (!load_ident()) {
+			reload_success = 0;
 			ereport(WARNING,
 	(errmsg(pg_ident.conf not reloaded)));
+		}
+
+		/*
+		 * Write the current time and the result of the reload to the
+		 * postmaster.pid file.
+		 */
+		snprintf(last_reload_info, 32, %ld %d,
+(long) time(NULL), reload_success);
+		AddToDataDirLockFile(LOCK_FILE_LINE_LAST_RELOAD, last_reload_info);
 
 #ifdef EXEC_BACKEND
 		/* Update the starting-point file for future children */
diff --git a/src/backend/utils/misc/guc-file.l b/src/backend/utils/misc/guc-file.l
index 5b5846c..2f5537d 100644
--- a/src/backend/utils/misc/guc-file.l
+++ b/src/backend/utils/misc/guc-file.l
@@ -117,12 +117,13 @@ STRING			\'([^'\\\n]|\\.|\'\')*\'
  * If a hard error occurs, no values will be changed.  (There can also be
  * errors that prevent just one value from being changed.)
  */
-void
+bool
 ProcessConfigFile(GucContext context)
 {
 	int			elevel;
 	MemoryContext config_cxt;
 	MemoryContext caller_cxt;
+bool  ok;
 
 	/*
 	 * Config files are processed on startup (by the postmaster only) and on
@@ -153,16 +154,19 @@ ProcessConfigFile(GucContext context)
 	/*
 	 * Read and apply the config file.  We don't need to examine the result.
 	 */
-	(void) ProcessConfigFileInternal(context, true, elevel);
+ok = ProcessConfigFileInternal(context, true, elevel) != NULL;
 
 	/* Clean up */
 	MemoryContextSwitchTo(caller_cxt);
 	MemoryContextDelete(config_cxt);
+	return ok;
 }
 
 /*
  * This function handles both actual config file (re)loads and execution of
- * show_all_file_settings() (i.e., the pg_file_settings view).  In the latter
+ * show_all_file_settings() (i.e., the pg_file_settings view).  In the former
+ * case, the settings are applied and this function returns the ConfigVariable
+ * list when this is successful, or NULL when it is not.  In the latter
  * case we don't apply any of the settings, but we make all the usual validity
  * checks, and we return the ConfigVariable list so that it can be printed out
  * by show_all_file_settings().
@@ -505,9 +509,13 @@ bail_out

Re: [HACKERS] Git humor

2015-06-14 Thread Jan de Visser 
On June 14, 2015 02:07:16 PM Bruce Momjian wrote:
 If you ever had trouble understanding a git manual page, this humorous
 random git man page generator is full of fun:
 
   http://git-man-page-generator.lokaltog.net/
 
 Try a few generate runs to find one that seems logical.  :-)

To my untrained eye those look an aweful lot like they're lifted from random 
pgsql-hackers threads. 


-- 
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] 9.5 release notes

2015-06-13 Thread Jan de Visser 
On June 13, 2015 09:30:12 PM Bruce Momjian wrote:
 Are there other countries where this would be appropriate?

I'm pretty sure Hungarian uses the family name-given name ordering, and it's 
also sometimes used in French, and therefore you often see French family names 
spelled in all caps. 



-- 
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] Problems with question marks in operators (JDBC, ECPG, ...)

2015-05-19 Thread Jan de Visser 
On May 19, 2015 09:31:32 PM Greg Sabino Mullane wrote:
 Jan de Visser wrote:
  Well, one could argue that it *is* their problem, as they should be using
  the standard Postgres way for placeholders, which is $1, $2, $3...
  
  Shirley you are joking: Many products use JDBC as an abstraction layer
  facilitating (mostly) seamless switching between databases. I know the
  product I worked on did. Are you advocating that every single statement
  should use SELECT * FROM foo WHERE bar = $1 on pg and SELECT * FROM
  foo WHERE bar = ? on every other database?
 
 I'm not joking, and don't call me Shirley. If you are running into
 situations where you have question mark operators in your queries, you have
 already lost the query abstraction battle. There will be no seamless
 switching if you are using jsonb, hstore, ltree, etc. My statement was more
 about pointing out that Postgres already offers a complete placeholder
 system, which drivers are free to implement if they want.

I must have misunderstood you strikeShirley/strike Greg, because to me it 
parsed as if you were suggesting (paraphrasing) ah forget about those pesky 
standardized drivers and their pesky syntax requirements. Just use ours like a 
big boy.

I understand that once you start using '?' as (part of) operator names in your 
queries you're not portable anymore. I just thought that your proposed 
solution was to throw all portability out the window. But I was probably 
(hopefully?) wrong.

jan



-- 
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] Problems with question marks in operators (JDBC, ECPG, ...)

2015-05-19 Thread Jan de Visser 
On May 19, 2015 07:04:56 PM Greg Sabino Mullane wrote:
 Bruno Harbulot asked for a devil's advocate by saying:
  My main point was that this is not specific to JDBC. Considering that even
  PostgreSQL's own ECPG is affected, the issue goes probably deeper than it
  seems. I'm just not convinced that passing the problem onto connectors,
  libraries and ultimately application developers is the right thing to do
  here.
 
 Well, one could argue that it *is* their problem, as they should be using
 the standard Postgres way for placeholders, which is $1, $2, $3...

Shirley you are joking: Many products use JDBC as an abstraction layer 
facilitating (mostly) seamless switching between databases. I know the product 
I worked on did. Are you advocating that every single statement should use 
SELECT * FROM foo WHERE bar = $1 on pg and SELECT * FROM foo WHERE bar = ? 
on every other database?

A database is only as valuable as the the part of the outside world it can 
interact with. Large parts of the data-consuming world are developed in java 
using JDBC. If your opinion is that JDBC developers should adapt themselves to 
pg then you instantaneously diminish the value of pg.

jan



-- 
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] mogrify and indent features for jsonb

2015-04-29 Thread Jan de Visser 
On April 29, 2015 03:09:51 PM Andrew Dunstan wrote:
 On 04/29/2015 01:19 PM, Robert Haas wrote:
  On Mon, Apr 27, 2015 at 6:41 PM, Andrew Dunstan and...@dunslane.net 
wrote:
  There's one exception I, at least, have to this rule, namely when there's
  a
  corresponding compound if or else. I personally find this unaesthetic to
  put 
  it mildly:
  if (condition)
  
  statement;
  
  else
  {
  
  block of statements;
  
  }
  
  Hmm, I don't dislike that style.  If somebody submitted a patch with
  braces around the lone statement, I would remove them before
  committing.
  
  ducks
 
 It's a matter of taste, but I find things a lot easier to understand
 when they are symmetrical. Thus I like all the branches of an if to be
 either in a block or not, and I like braces to line up either
 horizontally or vertically. Perhaps this reflects my history, where I
 wrote huge amounts of Ada and other non-C-like languages, well before I
 ever wrote lots of C or C-ish languages.
 
 
 Another case where I think putting a single statement in a block makes
 sense is where the condition of the if spreads across more than one
 line. This works particularly well with our BSD style brace placement.

I'm sure that many, many bits have been spilled over this, reaching way back 
into the stone age of computing, sometimes almost reaching emacs-vs-vi levels 
of intensity.

My position is the better-safe-than-sorry corner, which says to always add 
braces, even if there's only one statement. Because one day somebody will be 
in a rush, and will add a second statement without adding the braces, and 
things will explode horribly.

But that's just me.

jan



-- 
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] Idea: closing the loop for pg_ctl reload

2015-04-25 Thread Jan de Visser 
On April 22, 2015 06:04:42 PM Payal Singh wrote:
 The following review has been posted through the commitfest application:
 make installcheck-world:  not tested
 Implements feature:   tested, failed
 Spec compliant:   not tested
 Documentation:tested, failed
 
 Error in postgresql.conf gives the expected result on pg_ctl reload,
 although errors in pg_hba.conf file don't. Like before, reload completes
 fine without any information that pg_hba failed to load and only
 information is present in the log file. I'm assuming pg_ctl reload should
 prompt user if file fails to load irrespective of which file it is -
 postgresql.conf or pg_hba.conf.

Will fix. Not hard, just move the code that writes the .pid file to after the 
pg_hba reload.

 
 There is no documentation change so far, but I guess that's not yet
 necessary.

I will update the page for pg_ctl. At least the behaviour of -w/-W in relation 
to the reload command needs explained.

 
 gmake check passed all tests.
 
 The new status of this patch is: Waiting on Author

jan



-- 
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] Improve sleep processing of pg_rewind TAP tests

2015-04-22 Thread Jan de Visser 
On April 22, 2015 11:14:08 AM Heikki Linnakangas wrote:
 On 04/16/2015 06:51 AM, Alvaro Herrera wrote:
  Seems reasonable, but why are you sleeping 1s if pg_ctl -w is in use?  I
  thought the -w would wait until promotion has taken effect, so there's
  no need to sleep additional time.
 
 -w is not supported with pg_ctl promote. Only start, stop and restart.
 It's accepted, but it doesn't do anything. Which isn't very nice...

I'm futzing with the pg_ctl cmd line parameters for my patch notifying pg_ctl 
that restart didn't work. I'll fix this as well.

 
 - Heikki

jan



-- 
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] Idea: closing the loop for pg_ctl reload

2015-03-04 Thread Jan de Visser 
On March 4, 2015 11:08:09 PM Andres Freund wrote:
 Let's get the basic feature (notification of failed reloads) done
 first. That will be required with or without including the error
 message.  Then we can get more fancy later, if somebody really wants to
 invest the time.

Except for also fixing pg_reload_conf() to pay attention to what happens with 
postmaster.pid, the patch I submitted does exactly what you want I think.

And I don't mind spending time on stuff like this. I'm not smart enough to deal 
with actual, you know, database technology.



-- 
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] Idea: closing the loop for pg_ctl reload

2015-03-03 Thread Jan de Visser 
On March 3, 2015 10:29:43 AM Tom Lane wrote:
 Andres Freund and...@2ndquadrant.com writes:
  On 2015-03-03 15:21:24 +, Greg Stark wrote:
  Fwiw this concerns me slightly. I'm sure a lot of people are doing
  things like kill -HUP `cat .../postmaster.pid` or the equivalent.
  
  postmaster.pid already contains considerably more than just the pid. e.g.
 
 Yeah, that ship sailed long ago.  I'm sure anyone who's doing this is
 using head -1 not just cat, and what I suggest wouldn't break that.
 
   regards, tom lane

And what I've implemented doesn't either. The extra line is added to the back 
of the file.


-- 
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] Idea: closing the loop for pg_ctl reload

2015-03-03 Thread Jan de Visser 
On March 3, 2015 11:09:29 AM Jim Nasby wrote:
 On 3/3/15 9:26 AM, Andres Freund wrote:
  On 2015-03-03 15:21:24 +, Greg Stark wrote:
  Fwiw this concerns me slightly. I'm sure a lot of people are doing
  things like kill -HUP `cat .../postmaster.pid` or the equivalent.
  
  postmaster.pid already contains considerably more than just the pid. e.g.
  4071
  /srv/dev/pgdev-master
  1425396089
  5440
  /tmp
  localhost
  
 5440001  82345992
 
 If we already have all this extra stuff, why not include an actual error
 message then, or at least the first line of an error (or maybe just swap
 any newlines with spaces)?

Not impossible. I can play around with that and see if it's as straightforward 
as I think it is.


-- 
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] Idea: closing the loop for pg_ctl reload

2015-03-03 Thread Jan de Visser 
On March 3, 2015 04:57:58 PM Jim Nasby wrote:
 On 3/3/15 11:48 AM, Andres Freund wrote:
   I'm saying that you'll need a way to notice that a reload was processed
   or not. And that can't really be the message itself, there has to be
   some other field; like the timestamp Tom proposes.
 
 Ahh, right. We should make sure we don't go brain-dead if the system 
 clock moves backwards. I assume we couldn't just fstat the file...

The timestamp field is already there (in my patch). It gets populated when the 
server starts and repopulated by SIGHUP_handler. It's the only timestamp 
pg_ctl pays attention to.



-- 
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] Idea: closing the loop for pg_ctl reload

2015-03-03 Thread Jan de Visser 
On March 3, 2015 06:34:33 PM Jim Nasby wrote:
 On 3/3/15 5:24 PM, Jan de Visser wrote: On March 3, 2015 04:57:58 PM 
 Jim Nasby wrote:
   On 3/3/15 11:48 AM, Andres Freund wrote:
 I'm saying that you'll need a way to notice that a reload was 
 processed
  or not. And that can't really be the message itself, there has to be
 some other field; like the timestamp Tom proposes.
  
   Ahh, right. We should make sure we don't go brain-dead if the system
   clock moves backwards. I assume we couldn't just fstat the file...
  
   The timestamp field is already there (in my patch). It gets populated 
 when the
   server starts and repopulated by SIGHUP_handler. It's the only timestamp
   pg_ctl pays attention to.
 
 What happens if someone does a reload sometime in the future (perhaps 
 because they've messed with the system clock for test purposes). Do we 
 still detect a new reload?

Good point, and I had that scenario in the back of my head. What I do right 
now is read the 'last reload' timestamp from postmaster.pid (which can be the 
same as the startup time, since I make postmaster write an initial timestamp 
when it starts), send the SIGHUP, and wait until I read a later one or until 
timeout. What I could do is wait until I read a *different* one, and not just 
a later one. In that case you're only SOL if you manage to time it just so 
that your new server time is *exactly* the same as your old server time when 
you did your last reload (or startup). But even in that case it would time out 
and recommend you check the log.

That whole error message thing has one gotcha BTW; it's not hard, it's just 
that I have to find a way to make it bubble up from guc_file.l. Triggering an 
error was just changing the return value from void to bool, but returning the 
error string would mean returning a char buffer which would then need to be 
freed by other callers of ProcessConfig etc etc.

* /me scratches head

But I could just rename the current ProcessConfig, make it return a buffer, 
and have a *new*, void, ProcessConfig which calls the renamed function and 
just discards the result.

As an aside: I always found it interesting how feature threads explode 
around here. But it figures if even something as simple as this gets such 
detailed input. Definitely something to get used to...




-- 
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] Idea: closing the loop for pg_ctl reload

2015-03-03 Thread Jan de Visser 
On March 2, 2015 12:56:23 AM Jan de Visser wrote:
 
 Here's my first crack at this. Notes:
 1/ I haven't done the '-W' flag Tom mentions yet.
 2/ Likewise haven't touched pg_reload_conf()
 3/ Design details: I introduced a new struct in pg_ctl containing the
 parsed- out data from postmaster.pid, with functions to retrieve the data
 and to dispose memory allocated for it. This made the change in do_reload
 fairly straightforward. I think this struct can be used in other places in
 pg_ctl as well, and potentially in other files as well.
 4/ Question: Can I assume pg_malloc allocated memory is set to zero? If not,
 is it OK to do a memset(..., 0, ...)? I don't have much experience on any
 of the esoteric platforms pgsql supports...

Slight tweaks to better deal with pre-9.5 (6?) servers that don't write the 
reload timestamp. I tested with a 9.4 server and it seemed to work...

Also implemented -W/-w. Haven't done pg_reload_conf() yet.*** a/src/backend/postmaster/postmaster.c
--- b/src/backend/postmaster/postmaster.c
***
*** 883,888  PostmasterMain(int argc, char *argv[])
--- 883,899 
  	CreateDataDirLockFile(true);
  
  	/*
+ 	 * Update postmaster.pid with startup time as the last reload time:
+ 	 */
+ 	{
+ 		char last_reload_info[32];
+ 		snprintf(last_reload_info, 32, %ld %d,
+  (long) MyStartTime, 1);
+ 		AddToDataDirLockFile(LOCK_FILE_LINE_LAST_RELOAD, last_reload_info);
+ 	}
+ 
+ 
+ 	/*
  	 * Initialize SSL library, if specified.
  	 */
  #ifdef USE_SSL
***
*** 2341,2346  static void
--- 2352,2359 
  SIGHUP_handler(SIGNAL_ARGS)
  {
  	int			save_errno = errno;
+ 	boolreload_success;
+ 	charlast_reload_info[32];
  
  	PG_SETMASK(BlockSig);
  
***
*** 2348,2354  SIGHUP_handler(SIGNAL_ARGS)
  	{
  		ereport(LOG,
  (errmsg(received SIGHUP, reloading configuration files)));
! 		ProcessConfigFile(PGC_SIGHUP);
  		SignalChildren(SIGHUP);
  		SignalUnconnectedWorkers(SIGHUP);
  		if (StartupPID != 0)
--- 2361,2376 
  	{
  		ereport(LOG,
  (errmsg(received SIGHUP, reloading configuration files)));
! 		reload_success = ProcessConfigFile(PGC_SIGHUP);
! 
! 		/*
! 		 * Write the current time and the result of the reload to the
! 		 * postmaster.pid file.
! 		 */
! 		snprintf(last_reload_info, 32, %ld %d,
! (long) time(NULL), reload_success);
! 		AddToDataDirLockFile(LOCK_FILE_LINE_LAST_RELOAD, last_reload_info);
! 
  		SignalChildren(SIGHUP);
  		SignalUnconnectedWorkers(SIGHUP);
  		if (StartupPID != 0)
*** a/src/backend/utils/misc/guc-file.l
--- b/src/backend/utils/misc/guc-file.l
***
*** 112,118  STRING			\'([^'\\\n]|\\.|\'\')*\'
   * All options mentioned in the configuration file are set to new values.
   * If an error occurs, no values will be changed.
   */
! void
  ProcessConfigFile(GucContext context)
  {
  	bool		error = false;
--- 112,118 
   * All options mentioned in the configuration file are set to new values.
   * If an error occurs, no values will be changed.
   */
! bool
  ProcessConfigFile(GucContext context)
  {
  	bool		error = false;
***
*** 205,211  ProcessConfigFile(GucContext context)
  		 * the config file.
  		 */
  		if (head == NULL)
! 			return;
  	}
  
  	/*
--- 205,211 
  		 * the config file.
  		 */
  		if (head == NULL)
! 			return false;
  	}
  
  	/*
***
*** 433,438  ProcessConfigFile(GucContext context)
--- 433,439 
  	 * freed here.
  	 */
  	FreeConfigVariables(head);
+ 	return !error;
  }
  
  /*
*** a/src/bin/pg_ctl/pg_ctl.c
--- b/src/bin/pg_ctl/pg_ctl.c
***
*** 73,78  typedef enum
--- 73,92 
  	RUN_AS_SERVICE_COMMAND
  } CtlCommand;
  
+ typedef struct
+ {
+ 	pgpid_tpid;
+ 	char  *datadir;
+ 	time_t startup_ts;
+ 	intport;
+ 	char  *socketdir;
+ 	char  *listenaddr;
+ 	unsigned long  shmkey;
+ 	intshmid;
+ 	time_t reload_ts;
+ 	bool   reload_ok;
+ } PIDFileContents;
+ 
  #define DEFAULT_WAIT	60
  
  static bool do_wait = false;
***
*** 157,162  static int	CreateRestrictedProcess(char *cmd, PROCESS_INFORMATION *processInfo,
--- 171,178 
  static pgpid_t get_pgpid(bool is_status_request);
  static char **readfile(const char *path);
  static void free_readfile(char **optlines);
+ static PIDFileContents * get_pidfile_contents(const char *path);
+ static void free_pidfile_contents(PIDFileContents *contents);
  static int	start_postmaster(void);
  static void read_post_opts(void);
  
***
*** 419,424  free_readfile(char **optlines)
--- 435,512 
  }
  
  /*
+  * Read and parse the contents of a postmaster.pid file. These contents are
+  * placed in a PIDFileContents struct, a pointer to which is returned. If the
+  * file could not be read NULL is returned.
+  */
+ static PIDFileContents *
+ get_pidfile_contents(const char *path)
+ {
+ 	char**optlines = readfile(path

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-03-02 Thread Jan de Visser 
On March 2, 2015 09:50:49 AM Tom Lane wrote:
 However, you could and should use pg_malloc0, which takes care of that
 for you...

I am (using pg_malloc, that is). So, just to be sure: pg_malloc memsets the 
block to 0, right? 

My question was more along the lines if memsetting to 0 to ensure that pointer 
fields are NULL and int/long fields are 0. I know they are on Linux, but don't 
know if that applies to other platforms as well, or if I need to set fields 
explicitly to those 'zero'/'uninitialized' values.

jan




-- 
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] Idea: closing the loop for pg_ctl reload

2015-03-02 Thread Jan de Visser 
On March 2, 2015 12:44:40 PM Tom Lane wrote:
 No, it doesn't, but pg_malloc0 does.  Consult the code if you're confused:
 src/common/fe_memutils.c

Doh! I  read pg_malloc( ), not pg_malloc0. 


-- 
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] Idea: closing the loop for pg_ctl reload

2015-03-01 Thread Jan de Visser 
On February 19, 2015 08:26:45 PM Tom Lane wrote:
 Bug #12788 reminded me of a problem I think we've discussed before:
 if you use pg_ctl reload to trigger reload of the postmaster's
 config files, and there's something wrong with those files, there's
 no warning to you of that.  The postmaster just bleats to its log and
 keeps running.  If you don't think to look in the log to confirm
 successful reload, you're left with a time bomb: the next attempt
 to restart the postmaster will fail altogether because of the bad
 config file.
 
 I commented in the bug thread that there wasn't much that pg_ctl
 could do about this, but on reflection it seems like something we
 could fix, because pg_ctl must be able to read the postmaster.pid
 file in order to issue a reload signal.  Consider a design like this:
 
 1. Extend the definition of the postmaster.pid file to add another
 line, which will contain the time of the last postmaster configuration
 load attempt (might as well be a numeric Unix-style timestamp) and
 a boolean indication of whether that attempt succeeded or not.
 
 2. Change pg_ctl so that after sending a reload signal, it sleeps
 for a second and checks for a change in the config load timestamp
 (repeat as necessary till timeout).  Once it sees the timestamp
 change, it's in a position to report success or failure using the
 boolean.  I think this should become the default behavior, though
 you could define -W to mean that there should be no wait or feedback.
 
 It's tempting to think of storing a whole error message rather than
 just a boolean, but I think that would complicate the pidfile definition
 undesirably.  A warning to look in the postmaster log ought to be
 sufficient here.
 
 For extra credit, the pg_reload_conf() function could be made to behave
 similarly.
 
 I don't have the time to pursue this idea myself, but perhaps someone
 looking for a not-too-complicated project could take it on.
 
   regards, tom lane

Here's my first crack at this. Notes:
1/ I haven't done the '-W' flag Tom mentions yet.
2/ Likewise haven't touched pg_reload_conf()
3/ Design details: I introduced a new struct in pg_ctl containing the parsed-
out data from postmaster.pid, with functions to retrieve the data and to 
dispose memory allocated for it. This made the change in do_reload fairly 
straightforward. I think this struct can be used in other places in pg_ctl as 
well, and potentially in other files as well.
4/ Question: Can I assume pg_malloc allocated memory is set to zero? If not, 
is it OK to do a memset(..., 0, ...)? I don't have much experience on any of 
the esoteric platforms pgsql supports...

jan

*** a/src/backend/postmaster/postmaster.c
--- b/src/backend/postmaster/postmaster.c
***
*** 2341,2346  static void
--- 2341,2348 
  SIGHUP_handler(SIGNAL_ARGS)
  {
  	int			save_errno = errno;
+ 	boolreload_success;
+ 	charlast_reload_info[32];
  
  	PG_SETMASK(BlockSig);
  
***
*** 2348,2354  SIGHUP_handler(SIGNAL_ARGS)
  	{
  		ereport(LOG,
  (errmsg(received SIGHUP, reloading configuration files)));
! 		ProcessConfigFile(PGC_SIGHUP);
  		SignalChildren(SIGHUP);
  		SignalUnconnectedWorkers(SIGHUP);
  		if (StartupPID != 0)
--- 2350,2365 
  	{
  		ereport(LOG,
  (errmsg(received SIGHUP, reloading configuration files)));
! 		reload_success = ProcessConfigFile(PGC_SIGHUP);
! 
! 		/*
! 		 * Write the current time and the result of the reload to the
! 		 * postmaster.pid file.
! 		 */
! 		snprintf(last_reload_info, 32, %ld %d,
! (long) time(NULL), reload_success);
! 		AddToDataDirLockFile(LOCK_FILE_LINE_LAST_RELOAD, last_reload_info);
! 
  		SignalChildren(SIGHUP);
  		SignalUnconnectedWorkers(SIGHUP);
  		if (StartupPID != 0)
*** a/src/backend/utils/misc/guc-file.l
--- b/src/backend/utils/misc/guc-file.l
***
*** 112,118  STRING			\'([^'\\\n]|\\.|\'\')*\'
   * All options mentioned in the configuration file are set to new values.
   * If an error occurs, no values will be changed.
   */
! void
  ProcessConfigFile(GucContext context)
  {
  	bool		error = false;
--- 112,118 
   * All options mentioned in the configuration file are set to new values.
   * If an error occurs, no values will be changed.
   */
! bool
  ProcessConfigFile(GucContext context)
  {
  	bool		error = false;
***
*** 205,211  ProcessConfigFile(GucContext context)
  		 * the config file.
  		 */
  		if (head == NULL)
! 			return;
  	}
  
  	/*
--- 205,211 
  		 * the config file.
  		 */
  		if (head == NULL)
! 			return false;
  	}
  
  	/*
***
*** 433,438  ProcessConfigFile(GucContext context)
--- 433,439 
  	 * freed here.
  	 */
  	FreeConfigVariables(head);
+ 	return !error;
  }
  
  /*
*** a/src/bin/pg_ctl/pg_ctl.c
--- b/src/bin/pg_ctl/pg_ctl.c
***
*** 73,78  typedef enum
--- 73,92 
  	RUN_AS_SERVICE_COMMAND
  } CtlCommand;
  
+ typedef struct
+ {
+ 	pgpid_t

Re: [HACKERS] Idea: closing the loop for pg_ctl reload

2015-03-01 Thread Jan de Visser 
On March 2, 2015 12:56:23 AM Jan de Visser wrote:
... stuff ...

I seem to have mis-clicked something in the CF app - I created two entries 
somehow. I think one got created when I entered the msgid of Tom's original 
message with the enclosing '...'. If that's the case, then that may be a 
bug.

jan


-- 
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] Idea: closing the loop for pg_ctl reload

2015-02-20 Thread Jan de Visser 
On February 19, 2015 08:26:45 PM Tom Lane wrote:
 I don't have the time to pursue this idea myself, but perhaps someone
 looking for a not-too-complicated project could take it on.

I can have a crack at this. What's the process? Do I add it to a CF once I 
have a patch, or do I do that beforehand?

jan


-- 
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] Can a C function(server program) be a UDP or TCP server?

2007-10-18 Thread Jan de Visser 
On Thursday 18 October 2007 12:27:59 Billow Gao wrote:
 Thanks.  This is what I want to know :-)

 Regards,

 Billow

 Yeah, what he wants is to implement a function in Postgres which does
 something like an LDAP or DNS lookup or something like that.
 
 Sure you can do this. The only tricky bit is the thing you mentioned about
 reusing the connection. You could always leave the connection in a safe
  state and don't need to worry about cleaning it up then you could just
  store it in a static variable which would be the simplest option.
 
 If you want to use Postgres's facilities for allocating memory and
  cleaning it up when no longer in use you can use some of the Postgres
  internal API for memory contexts and resource owners. But I don't see any
  particular reason you should need to worry about this stuff for something
  simple you're implementing yourself.

 On 10/18/07, D'Arcy J.M. Cain [EMAIL PROTECTED] wrote:
  On Thu, 18 Oct 2007 11:24:24 -0400

 Billow Gao [EMAIL PROTECTED] wrote:
  I can write the network program.
  ...

Oh my. The worst kind of top-poster: the kind that copies *your* reply from 
the bottom to the top and top-posts above that.

Shudder...

:)

jan

-- 
--
Jan de Visser                     [EMAIL PROTECTED]

                Baruk Khazad! Khazad ai-menu!
--

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] 8.1.5 is out

2006-10-18 Thread Jan de Visser 
On Wednesday 18 October 2006 11:15, Oleg Bartunov wrote:
 On Wed, 18 Oct 2006, Teodor Sigaev wrote:
  1) Release notice mentions wronng
  (http://www.postgresql.org/docs/8.1/interactive/release.html#RELEASE-8-1-
 5): E.1.1. Migration to version 8.1.4
  ^ should be 8.1.5
  2) It's very pity that ours Win32 fixes isn't in 8.1.5 :(
  tarball:2006-10-13 02:05:40 commit: Fri Oct 13 14:00:17
  2006 UTC
  release date:   2006-10-16

 This fixes come from our real life experience on Win32 SMP platform
 (actually, Teodor demonstrated the problem even on uniprocessor Win32),
 so I suggest to quick release 8.1.6.

Is this fix going to make it into 8.2?


   Regards,
   Oleg

jan

 _
 Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
 Sternberg Astronomical Institute, Moscow University, Russia
 Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
 phone: +007(495)939-16-83, +007(495)939-23-83

 ---(end of broadcast)---
 TIP 5: don't forget to increase your free space map settings

-- 
--
Jan de Visser                     [EMAIL PROTECTED]

                Baruk Khazad! Khazad ai-menu!
--

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Block B-Tree concept

2006-09-29 Thread Jan de Visser 
On Friday 29 September 2006 10:55, Heikki Linnakangas wrote:
 Tom Lane wrote:
  Heikki Linnakangas [EMAIL PROTECTED] writes:
  I'm not very interested in the case where you have a lot of equal keys,
  I think the bitmap index am is more suitable for that.
 
  that indeed you meant to write consecutive, and I've got a problem
  with that: define consecutive.  In a datatype independent fashion,
  please.  I also wonder how you are going to implement splitting and
  merging of runs, which will certainly be necessary if this isn't to be
  a constantly-requires-REINDEX thing.

 I don't mean consecutive as in 1, 2, 3, 4, ... without gaps but as in
 A and B are consecutive in the index, if there's no value X in the
 index so that A  X  B. Maybe there's a better word for that.

http://en.wikipedia.org/wiki/Monotonic

jan

-- 
--
Jan de Visser                     [EMAIL PROTECTED]

                Baruk Khazad! Khazad ai-menu!
--

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Proposal for GUID datatype

2006-09-11 Thread Jan de Visser 
On Monday 11 September 2006 11:05, Thomas Hallgren wrote:
 Jan de Visser wrote:
  On Friday 08 September 2006 15:18, Gevik Babakhani wrote:
  2a) Three input formats are supported.
  example:
  insert into tbl (fld) values('1dfb39af-b56a-40b8-a903-b5b31567c3ce');
  insert into tbl (fld) values('{1dfb39af-b56a-40b8-a903-b5b31567c3ce}');
  insert into tbl (fld) values('1dfb39afb56a40b8a903b5b31567c3ce');
 
  Please extend your list. java's RMI package generates UIDs with the
  following format:
 
  [head order 21:19]$ bsh.sh
  BeanShell 1.3.0 - by Pat Niemeyer ([EMAIL PROTECTED])
  bsh % print(new java.rmi.server.UID());
  3b732da7:10d9029b3eb:-8000
  bsh %
 
  So forms that use colons instead of dashes seem appropriate.
 
  Or better still, make it configurable.
 
  jan

 RMI UID's has nothing in common with UUID's so I fail to see how they
 have any relevance here. I've never seen any other representation of the
 UUID's that the two that Gevik wants to support. Please note that UUID
 is a very well known concept and not an arbitrary 128 bit storage.

 http://en.wikipedia.org/wiki/UUID is a good source of information. The
 appointed RFC actually contains source code.

OK, good info, and something I was missing/didn't know. Apparently there is a 
JDK1.5 class that does the right thing.


 Kind Regards,
 Thomas Hallgren

Crawling back under my rock,

jan

-- 
--
Jan de Visser                     [EMAIL PROTECTED]

                Baruk Khazad! Khazad ai-menu!
--

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Proposal for GUID datatype

2006-09-09 Thread Jan de Visser 
On Saturday 09 September 2006 01:33, [EMAIL PROTECTED] wrote:
 I don't think so. If it isn't 128 bits - and you want to fit it into
 128 bits, it means padding. Where should the padding go? As application
 specific, it is up to the application to convert.

I am not saying that. I am just saying that you shouldn't limit yourself to 
any particular input formats. I understand that the example I gave is not a 
full GUID. As I said, I use that result as a base for a 128 bit GUID.

Aargh.

jan

-- 
--
Jan de Visser                     [EMAIL PROTECTED]

                Baruk Khazad! Khazad ai-menu!
--

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Proposal for GUID datatype

2006-09-08 Thread Jan de Visser 
On Friday 08 September 2006 15:18, Gevik Babakhani wrote:
 2a) Three input formats are supported.
 example:
 insert into tbl (fld) values('1dfb39af-b56a-40b8-a903-b5b31567c3ce');
 insert into tbl (fld) values('{1dfb39af-b56a-40b8-a903-b5b31567c3ce}');
 insert into tbl (fld) values('1dfb39afb56a40b8a903b5b31567c3ce');

Please extend your list. java's RMI package generates UIDs with the following 
format:

[head order 21:19]$ bsh.sh
BeanShell 1.3.0 - by Pat Niemeyer ([EMAIL PROTECTED])
bsh % print(new java.rmi.server.UID());
3b732da7:10d9029b3eb:-8000
bsh %  

So forms that use colons instead of dashes seem appropriate.

Or better still, make it configurable.

jan

-- 
--
Jan de Visser                     [EMAIL PROTECTED]

                Baruk Khazad! Khazad ai-menu!
--

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Proposal for GUID datatype

2006-09-08 Thread Jan de Visser 
On Friday 08 September 2006 21:34, [EMAIL PROTECTED] wrote:
 On Fri, Sep 08, 2006 at 09:24:19PM -0400, Jan de Visser wrote:
  On Friday 08 September 2006 15:18, Gevik Babakhani wrote:
   2a) Three input formats are supported.
   example:
   insert into tbl (fld) values('1dfb39af-b56a-40b8-a903-b5b31567c3ce');
   insert into tbl (fld) values('{1dfb39af-b56a-40b8-a903-b5b31567c3ce}');
   insert into tbl (fld) values('1dfb39afb56a40b8a903b5b31567c3ce');
 
  Please extend your list. java's RMI package generates UIDs with the
  following format:
 
  [head order 21:19]$ bsh.sh
  BeanShell 1.3.0 - by Pat Niemeyer ([EMAIL PROTECTED])
  bsh % print(new java.rmi.server.UID());
  3b732da7:10d9029b3eb:-8000
  bsh %

 That doesn't look like a UUID/GUID - unless it trims leading zeroes?

 UUID/GUID = 128-bits = 32 hexadecimal characters.

I know, it's a UID. Not a GUID. But many people (including myself) use it as a 
base to generate GUIDs. And that's not really the point. The point is that 
I'm afraid he's going to restrict himself to much.


 Cheers,
 mark

jan

-- 
--
Jan de Visser                     [EMAIL PROTECTED]

                Baruk Khazad! Khazad ai-menu!
--

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Proposal for GUID datatype

2006-09-08 Thread Jan de Visser 
On Saturday 09 September 2006 00:42, [EMAIL PROTECTED] wrote:
 But if the input isn't 32 hexadecimal characters - I don't see how
 it fits the UUID/GUID type.

Again, it wasn't about that particular *value* (which, as I concurred, is not 
a [GU]UID). It was about the fact that different tools spit out stuff in 
different formats, and that it would suck royally if you would have to 
convert because Gevik didn't think of the particular format of your 
particular tool. 

But I guess your suggestion of just ignoring punctuation would work just fine.

jan

-- 
--
Jan de Visser                     [EMAIL PROTECTED]

                Baruk Khazad! Khazad ai-menu!
--

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Build date for snapshots?

2006-09-07 Thread Jan de Visser 
On Thursday 07 September 2006 01:24, Marc G. Fournier wrote:

 How about adding a simple: 'touch snapshotdate' .. in the root directory?
 Would that suffice?

I'd say date +[something]  snapshotdate

I betcha that people that can't remember trivial things will muck up file 
timestamps by copying :)

jan

-- 
--
Jan de Visser                     [EMAIL PROTECTED]

                Baruk Khazad! Khazad ai-menu!
--

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] 8.2 features status

2006-08-04 Thread Jan de Visser 
On Friday 04 August 2006 09:37, Jonah H. Harris wrote:
 On 8/4/06, Andrew Dunstan [EMAIL PROTECTED] wrote:
  It's a pity that some expectations have been raised about features that
  we haven't seen patches for, MERGE/UPSERT  recursive queries

 Honestly, I've only had four people say it would be nice to have
 hierarchical queries (one of them wasn't even a PostgreSQL user).
 Almost everyone else seems to ask some variation of, what's a
 hierarchical query and why do I need it?  It's hard to get excited
 about writing a patch no one sees a real need for.

Make that five. I'll bless the day I can get rid of my recursive plsql 
functions.

jan

-- 
--
Jan de Visser                     [EMAIL PROTECTED]

                Baruk Khazad! Khazad ai-menu!
--

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] [PERFORM] Hanging queries on dual CPU windows

2006-03-13 Thread Jan de Visser 
On Sunday 12 March 2006 09:40, Magnus Hagander wrote:
 Looking a my system while testing this it still loooked like it was
 hanging on that plac ein the code, even though I saw no problems. So I'm
 not convinced we can actually trust the stacktrace from the non-default
 threads. So I don't think this patch will actually work :-( But it's
 worth a try.

I'm afraid you're right. Hangs again :(

jan


-- 
--
Jan de Visser                     [EMAIL PROTECTED]

                Baruk Khazad! Khazad ai-menu!
--

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] [PERFORM] Hanging queries on dual CPU windows

2006-03-13 Thread Jan de Visser 
On Monday 13 March 2006 09:26, Jan de Visser wrote:
 On Sunday 12 March 2006 09:40, Magnus Hagander wrote:
  Looking a my system while testing this it still loooked like it was
  hanging on that plac ein the code, even though I saw no problems. So I'm
  not convinced we can actually trust the stacktrace from the non-default
  threads. So I don't think this patch will actually work :-( But it's
  worth a try.

 I'm afraid you're right. Hangs again :(

I now have the toolchain set up, so if you want me to try stuff, please let me 
know. Resolving this is important to us.

On a whim, I replaced InitializeCriticalSection with 
InitializeCriticalSectionAndSpinCount, since MSDN told me that would be 
better for SMP. No joy.

jan

-- 
--
Jan de Visser                     [EMAIL PROTECTED]

                Baruk Khazad! Khazad ai-menu!
--

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] [PERFORM] Hanging queries on dual CPU windows

2006-03-13 Thread Jan de Visser 
On Monday 13 March 2006 12:27, Magnus Hagander wrote:
 Great. That'll certainly help - now you don't have to wait for binaries
 from me.

 What I'd be interested in seeing is new stackdumps from a version where
 you:
 1) Do *not* have the patch for mutexes applied
 2) Have removed static from all the function devlarations in signal.c
 and socket.c, bnoth in src/backend/port/win32.

I did that, and the interesting thing is that: 
1. It takes much longer to hang.
2. Once it hangs, the stacktraces are the same.
3 (and this is the kicker). The thing starts working again after a couple (+/- 
5) minutes ?

1. can probably be explained by the fact that I didn't compile with any 
optimization. Can you tell me what CFLAGS the binary distro uses? 2. I don't 
know (are there other tools I can use?), and 3. I frankly don't understand. I 
know for sure that with the stock 8.1.3 it would not revive itself (I let it 
running for a *long* time).


 If you can, it'd be interesting to see it from the pre-SP1 install as
 well - once it hangs.

I've never seen a pre-SP1 install hang.


  On a whim, I replaced InitializeCriticalSection with
  InitializeCriticalSectionAndSpinCount, since MSDN told me
  that would be better for SMP. No joy.

 No, that should make no difference - except possibly a tiny difference
 in speed.


 Do you have the ability to test 8.0 on the same machine? We did some
 extensive modifications to the signal stuff between 8.0 and 8.1, it'd be
 interesting to see if that changed things.

I seem to remember we made ourselves dependend on 8.1 somehow, but will check.

jan




-- 
--
Jan de Visser                     [EMAIL PROTECTED]

                Baruk Khazad! Khazad ai-menu!
--

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] [PERFORM] Hanging queries on dual CPU windows

2006-03-12 Thread Jan de Visser 
On Sunday 12 March 2006 09:40, Magnus Hagander wrote:
   If so,
   we could perhaps recode that part using a Mutex instead of
 
  a critical
 
   section - since it's not a performance critical path, the
 
  difference
 
   shouldn't be large. If I code up a patch for that, can you re-apply
   SP1 and test it? Or is this a production system you can't
 
  really touch?
 
  I can do whatever the hell I want with it, so if you could
  cook up a patch that would be great.
 
  As a BTW: I reinstalled SP1 and turned stats collection off.
  That also seems to work, but is not really a solution since
  we want to use autovacuuming.

 Ok, I've coded up a patch that changes the code to use a mutex instead.
 Patch attached. You can get a precompiled postgres.exe at
 http://www.hagander.net/download/postgres.exe_mutex.zip. You need to
 copy this file to postmaster.exe as well - they are supposed to be
 identical. It's based off a snapshot of 8.1-stable.

 Looking a my system while testing this it still loooked like it was
 hanging on that plac ein the code, even though I saw no problems. So I'm
 not convinced we can actually trust the stacktrace from the non-default
 threads. So I don't think this patch will actually work :-( But it's
 worth a try.

 (Oh, and I moved the thread over to -hackers, seems more correct at this
 time)

Thanks Magnus,

I'll try tomorrow. Will let you know ASAP (8:30 EST I guess :).

If this doesn't work, how do we progress? 


 //Magnus

jan

-- 
--
Jan de Visser                     [EMAIL PROTECTED]

                Baruk Khazad! Khazad ai-menu!
--

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster