Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])
On Fri, Aug 16, 2013 at 11:12 PM, Alvaro Herrera wrote: > Robert Haas escribió: >> On Fri, Aug 9, 2013 at 8:44 AM, Stephen Frost wrote: >> > A shared catalog which defined which *database* to run the trigger in, >> > with a way to fire off a new backend worker in that database and tell it >> > to run the trigger, might be interesting and would deal with the issue >> > that the trigger would behave differently depending on the database >> > connected to. That would bring along other issues, of course, but it >> > seemed an interesting enough idea to mention. >> >> Eh, maybe. I'm not sure there's enough use case for that to justify >> the amount of infrastructure it would require. I'm happy with the >> recent enhancements to background workers, but there's an awful lot of >> ground to cover between that and what you're proposing. > > Yeah, agreed. There's a lot of infrastructure required for this; it > seems hard to justify it only to support disabling ALTER SYSTEM. I think disabling ALTER SYSTEM can be more easily supported if we choose one of below options: a. UI into contrib module, people who don't want doesn't include it b. Have an include file mechanism, so that user can comment the include in postgresql.conf and disable it. If I remember correctly, earlier you mentioned that by default auto file should be parsed after postgresql.conf, but how about reverting to previous mechanism of "include" such that if the file is mentioned in include then it will be parsed, else will be ignored. I think this can be reasonable way to disable. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fix Windows socket error checking for MinGW
On Fri, Aug 16, 2013 at 06:56:45PM -0500, Michael Cronenworth wrote: > I started a thread on the general list so read that for more info. > > http://www.postgresql.org/message-id/520a6e55.40...@cchtml.com > > I'm also going to submit the patch to CommitFest. > +#ifndef WIN32 > if (SOCK_ERRNO == EWOULDBLOCK) > +#else > + if (SOCK_ERRNO == WSAEWOULDBLOCK) > +#endif Thanks for looking into this. I suspect this patch is achieving the right runtime behavior, but some cleanup is in order. src/include/port/win32.h makes some effort to preempt the need for a patch like this, but the relevant code isn't used for MinGW: /* * For Microsoft Visual Studio 2010 and above we intentionally redefine * the regular Berkeley error constants and set them to the WSA constants. * Note that this will break if those constants are used for anything else * than Windows Sockets errors. */ #if _MSC_VER >= 1600 #pragma warning(disable:4005) #define EMSGSIZE WSAEMSGSIZE #define EAFNOSUPPORT WSAEAFNOSUPPORT #define EWOULDBLOCK WSAEWOULDBLOCK #define EPROTONOSUPPORT WSAEPROTONOSUPPORT #define ECONNRESET WSAECONNRESET #define EINPROGRESS WSAEINPROGRESS #define ENOBUFS WSAENOBUFS #define ECONNREFUSED WSAECONNREFUSED #define EOPNOTSUPP WSAEOPNOTSUPP #pragma warning(default:4005) #endif I suspect we should do one of the following: 1. Redefine those constants for more (all?) compilers. 2. Remove that block and put #ifdef around all usage of such constants in frontend code, as you have done. 3. Remove that block and make src/backend/port/win32/socket.c frontend-usable, so frontend code can treat errno like backend code treats errno. What do you recommend? Thanks, nm -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] pg_sleep(interval)
On 08/16/2013 05:15 PM, Tom Lane wrote: > Josh Berkus writes: >> Why not just call it pg_sleep_int()? > > To me, that looks like something that would take an int. I suppose you > could call it pg_sleep_interval(), but that's getting pretty verbose. > > The larger picture here though is that that's ugly as sin; it just flies > in the face of the fact that PG *does* have function overloading and we > do normally use it, not invent randomly-different function names to avoid > using it. We should either decide that this feature is worth the small > risk of breakage, or reject it. Not build a camel-designed-by-committee > because no one would speak up for consistency of design. Well, if that's the alternative, I'd vote for taking it. For me, personally, I think the usefulness of it would outstrip the number of functions I'd have to debug. For one thing, it's not like pg_sleep is exactly widely used, especially not from languages like PHP which tend to treat every variable as a string. So this is not going to be the kind of upgrade bomb that pg_size_pretty was. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- 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] [PATCH] pg_sleep(interval)
Josh Berkus writes: > Why not just call it pg_sleep_int()? To me, that looks like something that would take an int. I suppose you could call it pg_sleep_interval(), but that's getting pretty verbose. The larger picture here though is that that's ugly as sin; it just flies in the face of the fact that PG *does* have function overloading and we do normally use it, not invent randomly-different function names to avoid using it. We should either decide that this feature is worth the small risk of breakage, or reject it. Not build a camel-designed-by-committee because no one would speak up for consistency of design. 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] [PATCH] pg_sleep(interval)
On 08/16/2013 04:52 PM, Tom Lane wrote: > Since the same effect can be had by writing a user-defined SQL function, > I'm a bit inclined to say that the value-added by having this as a > built-in function doesn't justify the risk of breaking existing apps. > It's a close call though, because both the risk and the value-added seem > rather small from here. Why not just call it pg_sleep_int()? I, for one, would find it useful, but would be really unhappy about about having to debug a bunch of old code to figure out what was broken. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Fix Windows socket error checking for MinGW
I started a thread on the general list so read that for more info.
http://www.postgresql.org/message-id/520a6e55.40...@cchtml.com
I'm also going to submit the patch to CommitFest.
Thanks,
Michael
>From bb79da0013d5169b4530df28ece0c296004d1db4 Mon Sep 17 00:00:00 2001
From: Michael Cronenworth
Date: Fri, 16 Aug 2013 18:50:28 -0500
Subject: [PATCH] libpq: Fix Windows socket error checking for MinGW
---
src/interfaces/libpq/fe-connect.c | 12
src/interfaces/libpq/fe-misc.c| 32
src/interfaces/libpq/fe-secure.c | 16
3 files changed, 56 insertions(+), 4 deletions(-)
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index 18fcb0c..3693245 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -1779,11 +1779,15 @@ keep_going: /* We will come back to here until there is
if (connect(conn->sock, addr_cur->ai_addr,
addr_cur->ai_addrlen) < 0)
{
- if (SOCK_ERRNO == EINPROGRESS ||
-#ifdef WIN32
- SOCK_ERRNO == EWOULDBLOCK ||
+#ifndef WIN32
+ if (SOCK_ERRNO == EINPROGRESS ||
+ SOCK_ERRNO == EWOULDBLOCK ||
+ SOCK_ERRNO == EINTR)
+#else
+ if (SOCK_ERRNO == WSAEINPROGRESS ||
+ SOCK_ERRNO == WSAEWOULDBLOCK ||
+ SOCK_ERRNO == WSAEINTR)
#endif
- SOCK_ERRNO == EINTR)
{
/*
* This is fine - we're in non-blocking mode, and
diff --git a/src/interfaces/libpq/fe-misc.c b/src/interfaces/libpq/fe-misc.c
index 6be3249..112cd12 100644
--- a/src/interfaces/libpq/fe-misc.c
+++ b/src/interfaces/libpq/fe-misc.c
@@ -655,7 +655,11 @@ retry3:
conn->inBufSize - conn->inEnd);
if (nread < 0)
{
+#ifndef WIN32
if (SOCK_ERRNO == EINTR)
+#else
+ if (SOCK_ERRNO == WSAEINTR)
+#endif
goto retry3;
/* Some systems return EAGAIN/EWOULDBLOCK for no data */
#ifdef EAGAIN
@@ -663,12 +667,20 @@ retry3:
return someread;
#endif
#if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK != EAGAIN))
+#ifndef WIN32
if (SOCK_ERRNO == EWOULDBLOCK)
+#else
+ if (SOCK_ERRNO == WSAEWOULDBLOCK)
+#endif
return someread;
#endif
/* We might get ECONNRESET here if using TCP and backend died */
#ifdef ECONNRESET
+#ifndef WIN32
if (SOCK_ERRNO == ECONNRESET)
+#else
+ if (SOCK_ERRNO == WSAECONNRESET)
+#endif
goto definitelyFailed;
#endif
/* pqsecure_read set the error message for us */
@@ -748,7 +760,11 @@ retry4:
conn->inBufSize - conn->inEnd);
if (nread < 0)
{
+#ifndef WIN32
if (SOCK_ERRNO == EINTR)
+#else
+ if (SOCK_ERRNO == WSAEINTR)
+#endif
goto retry4;
/* Some systems return EAGAIN/EWOULDBLOCK for no data */
#ifdef EAGAIN
@@ -756,12 +772,20 @@ retry4:
return 0;
#endif
#if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK != EAGAIN))
+#ifndef WIN32
if (SOCK_ERRNO == EWOULDBLOCK)
+#else
+ if (SOCK_ERRNO == WSAEWOULDBLOCK)
+#endif
return 0;
#endif
/* We might get ECONNRESET here if using TCP and backend died */
#ifdef ECONNRESET
+#ifndef WIN32
if (SOCK_ERRNO == ECONNRESET)
+#else
+ if (SOCK_ERRNO == WSAECONNRESET)
+#endif
goto definitelyFailed;
#endif
/* pqsecure_read set the error message for us */
@@ -834,10 +858,18 @@ pqSendSome(PGconn *conn, int len)
break;
#endif
#if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK != EAGAIN))
+#ifndef WIN32
case EWOULDBLOCK:
+#else
+case WSAEWOULDBLOCK:
+#endif
break;
#endif
+#ifndef WIN32
case EINTR:
+#else
+case WSAEINTR:
+#endif
continue;
default:
diff --git a/src/interfaces/libpq/fe-secure.c b/src/interfaces/libpq/fe-secure.c
index b16968b..aa48bd8 100644
--- a/src/interfaces/libpq/fe-secure.c
+++ b/src/interfaces/libpq/fe-secure.c
@@ -451,12 +451,20 @@ rloop:
#if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK != EAGAIN))
case EWOULDBLOCK:
#endif
+#ifndef WIN32
case EINTR:
+#else
+case WSAEWOULDBLOCK:
+case WSAEINTR:
+#endif
/* no error message, caller is expected to retry */
break;
#ifdef ECONNRESET
case ECONNRESET:
+#ifdef WIN32
+case WSAECONNRESET:
+#endif
printfPQExpBuffer(&conn->errorMessage,
libpq_gettext(
"server closed the connection unexpectedly\n"
@@ -635,7 +643,12 @@ retry_masked:
#if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK != EAGAIN))
case EWOULDBLOCK:
#endif
+#ifndef WIN32
case EINTR:
+#else
+case WSAEWOULDBLOCK:
+case WSAEINTR:
+#endif
/* no error message, caller is expected to retry */
break;
@@ -647,6 +660,9 @@ retry_masked:
#ifdef ECONNRESET
case ECONNRESET:
#endif
+#ifdef WIN32
+case WSAECONNRESET:
+#endif
printfPQExpBuffer(&conn->errorMessage,
libpq_gettext(
"server closed the connection unexpectedly\n"
--
1.8.3.1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
Re: [HACKERS] [PATCH] pg_sleep(interval)
Peter Eisentraut writes:
> On 8/16/13 3:35 PM, Robert Haas wrote:
>> On Fri, Aug 16, 2013 at 2:57 PM, Greg Stark wrote:
>>> Except there are no data types that can be cast to both double and
>>> interval currently.
>> That, unfortunately, is not sufficient to avoid a problem.
> That example can be used as an argument against almost any kind of
> overloading.
True. I think the gripe here is that pg_sleep('42') has worked for
many releases now, and if we add this patch then it would suddenly
stop working. How common is that usage likely to be (probably not
very), and how useful is it to have a version of pg_sleep that
takes an interval (probably also not very)?
Since the same effect can be had by writing a user-defined SQL function,
I'm a bit inclined to say that the value-added by having this as a
built-in function doesn't justify the risk of breaking existing apps.
It's a close call though, because both the risk and the value-added seem
rather small from here.
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] 9.4 regression
On Thu, Aug 15, 2013 at 12:08:57PM -0500, Jon Nelson wrote: > > Where are we on this issue? > > I've been able to replicate it pretty easily with PostgreSQL and > continue to look into it. I've contacted Theodore Ts'o and have gotten > some useful information, however I'm unable to replicate the behavior > with the test program (even one that's been modified). What I've > learned is: > > - XLogWrite appears to take approx. 2.5 times longer when writing to a > file allocated with posix_fallocate, but only the first time the file > contents are overwritten. This is partially explained by how ext4 > handles extents and uninitialized data, but 2.5x is MUCH more > expensive than anticipated or expected here. > - Writing zeroes to a file allocated with posix_fallocate (essentially > adding a posix_fallocate step before the usual write-zeroes-in-a-loop > approach) not only doesn't seem to hurt performance, it seems to help > or at least have parity, *and* the space is guaranteed to exist on > disk. At the very least that seems useful. Is it time to revert this patch until we know more? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] pg_ctl initdb takes options, but pg_ctl --help doesn't document them?
On 8/15/13 2:58 PM, Jon Nelson wrote: > Taking a look at PostgreSQL HEAD today, I noticed that pg_ctl > documents that pg_ctl initdb takes OPTIONS but doesn't document them > (unlike for start and others). > > Is this intentional? The man page tells you that those are the options for regular initdb. I don't think we should replicate the initdb --help output in pg_ctl. Perhaps it can be made a bit clearer without any duplication. -- 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] [PATCH] pg_sleep(interval)
On 8/16/13 3:35 PM, Robert Haas wrote:
> On Fri, Aug 16, 2013 at 2:57 PM, Greg Stark wrote:
>> Except there are no data types that can be cast to both double and
>> interval currently.
>
> That, unfortunately, is not sufficient to avoid a problem.
>
> rhaas=# create or replace function foo(double precision) returns
> double precision as $$select $1$$ language sql;
> CREATE FUNCTION
> rhaas=# create or replace function foo(interval) returns interval as
> $$select $1$$ language sql;
> CREATE FUNCTION
> rhaas=# select foo('123');
> ERROR: function foo(unknown) is not unique
> LINE 1: select foo('123');
>^
> HINT: Could not choose a best candidate function. You might need to
> add explicit type casts.
That example can be used as an argument against almost any kind of
overloading.
--
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] pgstat_reset_remove_files ignores its argument
On 16.8.2013 21:38, Robert Haas wrote: > On Wed, Aug 14, 2013 at 12:13 AM, Jeff Janes > wrote: >> in 9.3 and 9.4, pgstat_reset_remove_files uses the global variable >> pgstat_stat_directory rather than the argument it is passed, >> "directory". On crash recovery, this means the tmp directory gets >> cleared twice and the permanent pg_stat doesn't get cleared at >> all. >> >> It seems like the obvious one line change would fix it, but I >> haven't tested it because I don't know how to cause a crash without >> pg_stat already being empty. > > I think there are three lines to change, as in the attached patch. > > Am I wrong? > > ...Robert I think the patch is OK. Tomas -- 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] pgstat_reset_remove_files ignores its argument
On Wed, Aug 14, 2013 at 12:13 AM, Jeff Janes wrote: > in 9.3 and 9.4, pgstat_reset_remove_files uses the global variable > pgstat_stat_directory rather than the argument it is passed, "directory". > On crash recovery, this means the tmp directory gets cleared twice and the > permanent pg_stat doesn't get cleared at all. > > It seems like the obvious one line change would fix it, but I haven't tested > it because I don't know how to cause a crash without pg_stat already being > empty. I think there are three lines to change, as in the attached patch. Am I wrong? ...Robert pgstat-reset-remove-files.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] [PATCH] pg_sleep(interval)
On Fri, Aug 16, 2013 at 2:57 PM, Greg Stark wrote:
> Except there are no data types that can be cast to both double and
> interval currently.
That, unfortunately, is not sufficient to avoid a problem.
rhaas=# create or replace function foo(double precision) returns
double precision as $$select $1$$ language sql;
CREATE FUNCTION
rhaas=# create or replace function foo(interval) returns interval as
$$select $1$$ language sql;
CREATE FUNCTION
rhaas=# select foo('123');
ERROR: function foo(unknown) is not unique
LINE 1: select foo('123');
^
HINT: Could not choose a best candidate function. You might need to
add explicit type casts.
rhaas=#
--
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] Regarding BGworkers
On Wed, Aug 14, 2013 at 8:04 AM, Michael Paquier wrote: > On Wed, Aug 14, 2013 at 10:10 AM, Robert Haas wrote: >> I think Alvaro's suggestion is better. It's shorter, and makes clear >> that at most one will be started. > OK cool. Here are patches for 9.3 and master respecting those comments. Thanks, 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
Re: [HACKERS] [PATCH] pg_sleep(interval)
Except there are no data types that can be cast to both double and interval currently. -- 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] Foreground vacuum and buffer access strategy
On Tue, Aug 13, 2013 at 4:11 PM, Greg Stark wrote: > I'm not convinced using a ring buffer is necessarily that bad even if > you want to vacuum as fast as possible. The reason we use a small ring > buffer is to avoid poisoning the entire cache with vacuum pages, not > to throttle the speed of vacuum by introducing synchronous wal > flushes. Right, but the DBA, being God, is entitled to override that. A regular user should not be able to change system policy here, but if a superuser wants to do it, who are we to say no? > I think we should increase the size of the ring buffer if we hit a > synchronous wal buffer flush and there is less than some amount of wal > pending. That amount is the relevant thing people might want to limit > to avoid slowing down other transaction commits. The walwriter might > even provide a relevant knob already for how much wal should be the > maximum pending. I doubt that would work out; the amount of WAL pending is going to change extremely rapidly. You can't increase the size of the ring buffer for a vacuum that might run for another 24 hours on the basis of an instantaneous measurement whose value might be completely different a few milliseconds later or earlier. Also, if there is a lot of WAL pending, then the system is likely I/O saturated, which might be exactly the wrong time to allow more cache poisoning. Auto-tuning is nice when we can do it, but you can't auto-guess-what-the-human-wants. ...Robert -- 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] [PATCH] pg_sleep(interval)
On Thu, Aug 8, 2013 at 7:52 AM, Vik Fearing wrote: > Someone on IRC a while ago was complaining that there was no way to > specify an interval for pg_sleep, so I made one. Patch against today's > HEAD attached. > > Usage: SELECT pg_sleep(interval '2 minutes'); The problem with this is that then pg_sleep would be overloaded, and as we've found from previous experience (cf. pg_size_pretty) that can make things that currently work start failing as ambiguous. -- 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] Server crash when using bgw_main for a dynamic bgworker
On Mon, Aug 12, 2013 at 1:26 AM, Michael Paquier wrote: > While playing a bit with background workers (commit 527ea66), I found that > setting bgw_main for a dynamic bgworker, as well as bgw_library_name and > bgw_library_name, crashes to server if the library defining the function > defined in bgw_main is not loaded. Yep. As the documentation says: "bgw_main may be NULL; in that case, bgw_library_name and bgw_function_name will be used to determine the entrypoint. This is useful for background workers launched after postmaster startup, where the postmaster does not have the requisite library loaded." http://www.postgresql.org/docs/devel/static/bgworker.html > Wouldn't be clearer for the user to add a new flag in > BackgroundWorker:bgworker.h to define a class of bgworker? Or at least > specify clearly in the docs just to never set bgw_main if the library is not > loaded previously using for example shared_preload_libraries? I don't think adding a flag really eliminates any possibility for user confusion that doesn't already exist as things stand. However, changing the documentation might make sense. The key point is that if the function must be loaded into both the registering backend and the worker backend, and it must also be loaded into both backends *at the same address*. Anything that's loaded later than shared_preload_libraries isn't likely to be soon enough, and even if you do load the library at shared_preload_libraries time, I'm not clear that it's going to work reliably in an EXEC_BACKEND environment. What if the OS uses ASLR and puts the shared library at different addresses in different child processes? It'll crash, that's what. It's almost tempting to tell people "don't use bgw_main", but I think that might be going overboard. This is expert-level hackery; experts don't usually like being told what to do without being told why they must. -- 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: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])
Robert Haas escribió: > On Fri, Aug 9, 2013 at 8:44 AM, Stephen Frost wrote: > > A shared catalog which defined which *database* to run the trigger in, > > with a way to fire off a new backend worker in that database and tell it > > to run the trigger, might be interesting and would deal with the issue > > that the trigger would behave differently depending on the database > > connected to. That would bring along other issues, of course, but it > > seemed an interesting enough idea to mention. > > Eh, maybe. I'm not sure there's enough use case for that to justify > the amount of infrastructure it would require. I'm happy with the > recent enhancements to background workers, but there's an awful lot of > ground to cover between that and what you're proposing. Yeah, agreed. There's a lot of infrastructure required for this; it seems hard to justify it only to support disabling ALTER SYSTEM. -- Álvaro Herrerahttp://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: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])
On Fri, Aug 9, 2013 at 8:44 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Sun, Aug 4, 2013 at 4:26 PM, Dimitri Fontaine >> wrote: >> > What I'm yet unsure about is that there's a consensus that the use cases >> > are worthy of a new shared catalog in the system. Also I didn't look how >> > hard it is to actually provide for it. >> >> A new shared catalog wouldn't actually help, because the actual >> procedure to be run has to live in pg_proc, which is not shared. And >> that has references to all sorts of other things (like pg_language) >> that aren't shared either. > > A shared catalog which defined which *database* to run the trigger in, > with a way to fire off a new backend worker in that database and tell it > to run the trigger, might be interesting and would deal with the issue > that the trigger would behave differently depending on the database > connected to. That would bring along other issues, of course, but it > seemed an interesting enough idea to mention. Eh, maybe. I'm not sure there's enough use case for that to justify the amount of infrastructure it would require. I'm happy with the recent enhancements to background workers, but there's an awful lot of ground to cover between that and what you're proposing. -- 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] Re: [PATCH] Re: [BUGS] BUG #7815: Upgrading PostgreSQL from 9.1 to 9.2 with pg_upgrade/postgreql-setup fails - invalid status retrieve
On Mon, Aug 12, 2013 at 04:44:12PM -0400, Bruce Momjian wrote: > On Mon, Aug 12, 2013 at 10:08:07PM +0200, Pavel Raiskup wrote: > > > The patch moves the atexit setting up, as you suggested, but only does > > > that when pg_ctl succeeds (we know we started the server), > > > > Yes, of course! > > > > > PG 9.1+ will allow pg_ctl -w start to succeed even if there are > > > permissions problems; earlier versions will not and will keep the > > > server running --- the user will have to stop the server after > > > pg_upgrade says it is running. > > > > This makes it a complex, really.. We may not easily make the > > stop_postmaster resistant to non-running server. Thus your solution must > > be good enough. > > Well, stop_postmaster can run just fine with a stopped server, as we > allow the atexit() shutdown to ignore errors. The larger question is > whether we should ever stop a server we are not sure we started. > > The existing pg_upgrade logic checks if the servers are running first > with start_postmaster(throw_error = false), so in our existing code, we > could probably unconditionally shutdown the server even with a pg_ctl > error when using throw_error = true, but pg_upgrade is complex so I am > hesitant to make such a bold change. Does anyone else have an opinion? > > > > I am not going to backpatch this beyond 9.3 as it is risky code. I have > > > improved the comments in this area. > > > > Agree, it is OK for me — thanks for your work. > > Sure. You gave me something to study today, and highlighted an area of > the code that was very unclear. I have applied a patch to shutdown the server on successful pg_ctl start, but authentication failure. I have also added code that we might want to be more aggressive someday. I backpatched this to 9.3, but not further back as this is a risky area of the code. Does anyone want to advocate further backpatching? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 回复： [pgsql-zh-general] R: Re: [HACKERS] Chinese in Postgres
maybe your C++ program has something (such as charset or configuation) causing this strange thing mark 发件人： "ciifrance...@tiscali.it" 收件人： ha...@2ndquadrant.com 抄送： pgsql-hackers@postgresql.org; pgsql-zh-gene...@postgresql.org; pgsql-ru-gene...@postgresql.org 发送日期： 2013年8月16日, 星期五, 8:40 下午 主题: [pgsql-zh-general] R: Re: [HACKERS] Chinese in Postgres Thanks for your answer. Yes, the client is also UTF8: MyDB=# show client_encoding; client_encoding - UTF8 (1 row) Cheers Francesco Messaggio originale Da: ha...@2ndquadrant.com Data: 16/08/2013 14.16 A: "ciifrance...@tiscali.it" Cc: , , Ogg: Re: [HACKERS] Chinese in Postgres On 08/16/2013 01:25 PM, ciifrance...@tiscali.it wrote: > Hello all, > before writing this message, I wrote about this in other mailing lists > without solving my problem. > Maybe some of you can help me. > > I have problems with a DB in postgres, when i try to insert Chinese > strings in UTF-8 format. > If I insert the data using a C++ program I have empty squares, in this > format: ��� (3 empty squares for each chinese ideogram as that is the > length in UTF-8) > If the string contains chinese mixed with ASCII, the ASCII is OK but > the Chinese is broken: > 漢語1-3漢語 --> ��1- 3�� Can you cehck that your client encoding is also UTF8 hannu=# show client_encoding ; client_encoding - UTF8 (1 row) Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql- hackers Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/ -- Sent via pgsql-zh-general mailing list (pgsql-zh-gene...@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-zh-general
Re: [HACKERS] LDAP: bugfix and deprecated OpenLDAP API
On Tue, Jul 23, 2013 at 11:53 AM, Albe Laurenz wrote: > Magnus Hagander wrote: >> In that case, doesn't this patch break Windows? We no longer do the >> anonymous bind on Windows, since it's now in the #ifdef HAVE_LIBLDAP. >> >> Don't we need to keep the ldap_simple_bind() call in the Windows case, >> or break it up so the call to ldap_sasl_bind_s() is moved outside the >> #ifdef? At least I can't find anything in the docs that indicate that >> ldap_connect() on Windows would actually call that for us - only the >> other way around? > > > This patch works for the Windows case, because ldap_connect performs > an anonymous bind, see > http://msdn.microsoft.com/en-us/library/windows/desktop/aa366171%28v=vs.85%29.aspx > > If the call to ldap_connect succeeds, the client is connected > to the LDAP server as an anonymous user. The session handle > should be freed with a call to ldap_unbind when it is no longer required. > >> I'm going to set this patch as returned with feedback for now, but >> please feel free to comment on above and possibly resubmit if >> necessary before the CF and I'll see if I can deal with it before the >> next CF anyway, as it's a bug fix. > > The patch should still be good, but if we keep the deprecated > OpenLDAP API, it might be more consistent to use ldap_simple_bind_s > instead of ldap_sasl_bind_s. > > If you agree, I'll change that. Sorry, you got this one in just as my vacation started. Yes, I agree with that. So please do. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
R: 回复： [pgsql-zh-general] R: Re: [HACKERS] Chinese in Postgres
[I reply to both in one email] Song: that C++ program has a log file. In the log file the queries look like this: UPDATE MY_table SET UTF8_field = '<8f><20><31><32><33><34><27><20><57><48><45><52><45><20><49><44><20><3d><20><31> starting from the first chinese letter, all the rest of the query is in hexa. But this is not a problem, because the query is inserted fine (excepted the chinese letter). And if i use a hexa converter, i get the correct query: UPDATE MY_table SET UTF8_field = '台 1234' WHERE ID = 1 Hannu: the length in the database is counting each of the empty squares: UTF8_field | length + ��� 1234 | 8 cheers Francesco Messaggio originale Da: mark3...@yahoo.cn Data: 16/08/2013 14.52 A: "ciifrance...@tiscali.it" , "ha...@2ndquadrant.com" Cc: "pgsql-hackers@postgresql.org", "pgsql-zh-gene...@postgresql.org", "pgsql-ru-gene...@postgresql.org" Ogg: 回复： [pgsql-zh-general] R: Re: [HACKERS] Chinese in Postgres maybe your C++ program has something (such as charset or configuation) causing this strange thing mark 发件人： "ciifrance...@tiscali.it" 收件人： ha...@2ndquadrant.com 抄送： pgsql-hackers@postgresql.org; pgsql-zh- gene...@postgresql.org; pgsql-ru-gene...@postgresql.org 发送日期： 2013年8月16 日, 星期五, 8:40 下午 主题: [pgsql-zh-general] R: Re: [HACKERS] Chinese in Postgres Thanks for your answer. Yes, the client is also UTF8: MyDB=# show client_encoding; client_encoding - UTF8 (1 row) Cheers Francesco Messaggio originale Da: ha...@2ndquadrant.com Data: 16/08/2013 14.16 A: "ciifrancesco@tiscali. it" Cc: , , Ogg: Re: [HACKERS] Chinese in Postgres On 08/16/2013 01:25 PM, ciifrance...@tiscali.it wrote: > Hello all, > before writing this message, I wrote about this in other mailing lists > without solving my problem. > Maybe some of you can help me. > > I have problems with a DB in postgres, when i try to insert Chinese > strings in UTF-8 format. > If I insert the data using a C++ program I have empty squares, in this > format: ��� (3 empty squares for each chinese ideogram as that is the > length in UTF-8) > If the string contains chinese mixed with ASCII, the ASCII is OK but > the Chinese is broken: > 漢語1-3漢語 --> ��1- 3�� Can you cehck that your client encoding is also UTF8 hannu=# show client_encoding ; client_encoding - UTF8 (1 row) Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql- hack...@postgresql.org) To make changes to your subscription: http: //www.postgresql.org/mailpref/pgsql- hackers Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/ -- Sent via pgsql-zh-general mailing list (pgsql-zh-general@postgresql. org) To make changes to your subscription: http://www.postgresql. org/mailpref/pgsql-zh-general Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
R: Re: [HACKERS] Chinese in Postgres
Thanks for your answer. Yes, the client is also UTF8: MyDB=# show client_encoding; client_encoding - UTF8 (1 row) Cheers Francesco Messaggio originale Da: ha...@2ndquadrant.com Data: 16/08/2013 14.16 A: "ciifrance...@tiscali.it" Cc: , , Ogg: Re: [HACKERS] Chinese in Postgres On 08/16/2013 01:25 PM, ciifrance...@tiscali.it wrote: > Hello all, > before writing this message, I wrote about this in other mailing lists > without solving my problem. > Maybe some of you can help me. > > I have problems with a DB in postgres, when i try to insert Chinese > strings in UTF-8 format. > If I insert the data using a C++ program I have empty squares, in this > format: ��� (3 empty squares for each chinese ideogram as that is the > length in UTF-8) > If the string contains chinese mixed with ASCII, the ASCII is OK but > the Chinese is broken: > 漢語1-3漢語 --> ��1- 3�� Can you cehck that your client encoding is also UTF8 hannu=# show client_encoding ; client_encoding - UTF8 (1 row) Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql- hackers Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: R: Re: [HACKERS] Chinese in Postgres
On 08/16/2013 02:40 PM, ciifrance...@tiscali.it wrote:
> Thanks for your answer.
> Yes, the client is also UTF8:
>
> MyDB=# show
> client_encoding;
> client_encoding
> -
> UTF8
> (1 row)
Strange, it works for me :
hannu@hannu-900X3E:~/workspace/my-app$ psql
psql (9.3beta2, server 9.2.4)
Type "help" for help.
hannu=# select * from pg_stat_activity;
hannu=# show client_encoding ;
client_encoding
-
UTF8
(1 row)
hannu=# create table tchinese(data text);
CREATE TABLE
hannu=# insert into tchinese values('漢語1-3漢語');
INSERT 0 1
hannu=# select * from tchinese ;
data
-
漢語1-3漢語
(1 row)
hannu=# \q
Are you sure that the client-encoding is also the same when you are
actually doing the import ?
Or when you are getting the wrong results when reading
what does length() of the bad field give you ?
hannu=# select data, length(data) from tchinese ;
data | length
-+
漢語1-3漢語 | 7
(1 row)
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ
--
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] Chinese in Postgres
On 08/16/2013 01:25 PM, ciifrance...@tiscali.it wrote: > Hello all, > before writing this message, I wrote about this in other mailing lists > without solving my problem. > Maybe some of you can help me. > > I have problems with a DB in postgres, when i try to insert Chinese > strings in UTF-8 format. > If I insert the data using a C++ program I have empty squares, in this > format: ��� (3 empty squares for each chinese ideogram as that is the > length in UTF-8) > If the string contains chinese mixed with ASCII, the ASCII is OK but > the Chinese is broken: > 漢語1-3漢語 --> ��1-3�� Can you cehck that your client encoding is also UTF8 hannu=# show client_encoding ; client_encoding - UTF8 (1 row) Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Chinese in Postgres
Hello all, before writing this message, I wrote about this in other mailing lists without solving my problem. Maybe some of you can help me. I have problems with a DB in postgres, when i try to insert Chinese strings in UTF-8 format. If I insert the data using a C++ program I have empty squares, in this format: ��� (3 empty squares for each chinese ideogram as that is the length in UTF-8) If the string contains chinese mixed with ASCII, the ASCII is OK but the Chinese is broken: 漢語1-3漢語 --> ��1-3�� All the data is read from a binary file. It seems it's read correctly, but something happens when the query is executed. (If the text is in a different language that uses only 2 bytes for each letter, I will see only 2 empty squares per character, ex. hebrew, but this is not good anyway...) Strange things: 1. if i insert the record doing a query from command line (putty), the chinese text is OK. This problem is only when i insert by the C++ program. 2. I checked the C++ functions involved by creating unitary tests; if i run some other tests (on another virtual machine) the text is not damaged. These strange things are confusing me, but maybe they will be useful informations for somebody who had the same problem. The DB is set for UTF-8 Name | Owner | Encoding | Collate |Ctype| Access privileges --+---+--+-+-+-- postgres | pgsql | UTF8 | en_US.UTF-8 | en_US.UTF-8 | MyDB | pgsql | UTF8 | en_US.UTF-8 | en_US.UTF-8 | template0| pgsql | UTF8 | en_US.UTF-8 | en_US.UTF-8 | template1| pgsql | UTF8 | en_US.UTF-8 | en_US.UTF-8 | Previously I also tried with: Name | Owner | Encoding | Collate |Ctype| Access privileges --+---+--+-+-+-- postgres | pgsql | UTF8 | C | C | MyDB | pgsql | UTF8 | C | C | ... But the problem was the same. I know that you would like to see the code, but it's too long (anyway if you want i can try to write some lines of code, like connection to Db and so on). I don't know if there is some log create by postgres when inserting damaged data, sould be useful. For now, in order to save your time my question is: did anybody of you have the same problem? (and how did you solve it?) Thanks, Francesco Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/
