Re: [HACKERS] PostgreSQL in Windows console and Ctrl-C
* From: Amit Kapila
Another thing to decide about this fix is that whether it is okay to fix
it for CTRL+C and leave the problem open for CTRL+BREAK?
(The current option used (CREATE_NEW_PROCESS_GROUP) will handle only
CTRL+C).
I can think of three situations in which a postgres process can run on
Windows:
- single backend
- console background via pg_ctl
- service
The only way to deliver a console event to a service process is by
calling GenerateConsoleCtrlEvent() with that process( group)'s PID. If
anyone does that, they will know what they are doing, so we can disregard
that. The other two are tricky. In single-backend mode, we probably expect
both to work as usual (ending the process), while in the pg_ctl case,
they should both be ignored.
Ignoring Ctrl-C in the postmaster and all children is simple, this is what
my patch does. Ctrl-Break is more difficult to do. It is not limited to
the foreground process group, but is delivered to all processes attached
to the console that originates it. To ignore it, every process (postmaster,
backends, workers, etc.) will have to handle it in their own console
event handling function.
backend/port/win32/signal.c explicitly turns several of the console events,
including Ctrl-C and Ctrl-Break, into SIGINT. The simplest fix would be to
ignore Ctrl-Break there, effectively disabling it entirely under all
circumstances. I tried that, and it appears to work, but I don't know
enough about the signal emulation and the interactions between the various
processes to be sure this is the right place to do it. Single-backend mode
has no need for signal handling and does not use the emulation layer, so
it is unaffected.
Below is a new (right now very much proof-of-concept) patch to replace
my earlier one. It has the same effect on Ctrl-C the change to pg_ctl had,
and additionally ignores Ctrl-Break as well.
Please be gentle.
diff --git a/src/backend/port/win32/signal.c b/src/backend/port/win32/signal.c
index 322b857..7ce5051 100644
--- a/src/backend/port/win32/signal.c
+++ b/src/backend/port/win32/signal.c
@@ -347,8 +347,12 @@ static BOOL WINAPI
pg_console_handler(DWORD dwCtrlType)
{
if (dwCtrlType == CTRL_C_EVENT ||
- dwCtrlType == CTRL_BREAK_EVENT ||
- dwCtrlType == CTRL_CLOSE_EVENT ||
+ dwCtrlType == CTRL_BREAK_EVENT)
+ {
+ /* Ignore */
+ return TRUE;
+ }
+ else if (dwCtrlType == CTRL_CLOSE_EVENT ||
dwCtrlType == CTRL_SHUTDOWN_EVENT)
{
pg_queue_signal(SIGINT);
--
Christian
--
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] Problem with txid_snapshot_in/out() functionality
On 04/12/2014 12:07 AM, Jan Wieck wrote: Hackers, the Slony team has been getting seldom reports of a problem with the txid_snapshot data type. The symptom is that a txid_snapshot on output lists the same txid multiple times in the xip list part of the external representation. This string is later rejected by txid_snapshot_in() when trying to determine if a particular txid is visible in that snapshot using the txid_visible_in_snapshot() function. I was not yet able to reproduce this problem in a lab environment. It might be related to subtransactions and/or two phase commit (at least one user is using both of them). The reported PostgreSQL version involved in that case was 9.1. It's two-phase commit. When preparing a transaction, the state of the transaction is first transfered to a dummy PGXACT entry, and then the PGXACT entry of the backend is cleared. There is a transient state when both PGXACT entries have the same xid. You can reproduce that by putting a sleep or breakpoint in PrepareTransaction(), just before the ProcArrayClearTransaction(MyProc); call. If you call txid_current_snapshot() from another session at that point, it will output two duplicate xids. (you will have to also commit one more unrelated transaction to bump up xmax). At this point I would find it extremely helpful to sanitize the external representation in txid_snapshot_out() while emitting some NOTICE level logging when this actually happens. I am aware that this does amount to a functional change for a back release, but considering that the _out() generated external representation of an existing binary datum won't pass the type's _in() function, I argue that such change is warranted. Especially since this problem could possibly corrupt a dump. Hmm. Do we snapshots to be stored in tables, and included in a dump? I don't think we can guarantee that will work, at least not across versions, as the way we handle snapshot internally can change. But yeah, we probably should do something about that. The most straightforward fix would be to scan the array in txid_current_snapshot() and remove any duplicates. - Heikki -- 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] [bug fix] pg_ctl always uses the same event source
Hello, Amit san, Tom san, I'm sorry for my late response. I've just caught up with the discussion. I'm almost convinced. Please find attached the revised patch. I'd like to follow the idea of adding a switch to pg_ctl. The newly added -e event_source sets the event source name for pg_ctl to use. When -e is used with pg_ctl register, it will be added to the command line for Windows service (pg_ctl runservice). Regards MauMau pg_ctl_eventsrc_v7.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
[HACKERS] Add the number of pinning backends to pg_buffercache's output
Hi, The last week I twice had the need to see how many backends had some buffers pinned. Once during development and once while analyzing a stuck vacuum (waiting for a cleanup lock). I'd like to add a column to pg_buffercache exposing that. The name I've come up with is 'pinning_backends' to reflect the fact that it's not the actual pincount due to the backend private arrays. I'll add this patch to to 2014-06 CF. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services From 32564c87e3323253ac8f77badc27628c2f4033c8 Mon Sep 17 00:00:00 2001 From: Andres Freund and...@anarazel.de Date: Fri, 11 Apr 2014 22:01:36 +0200 Subject: [PATCH] Add pinning_backends column to the pg_buffercache extension. --- contrib/pg_buffercache/Makefile| 2 +- .../pg_buffercache/pg_buffercache--1.0--1.1.sql| 11 ++ contrib/pg_buffercache/pg_buffercache--1.0.sql | 20 --- contrib/pg_buffercache/pg_buffercache--1.1.sql | 21 +++ contrib/pg_buffercache/pg_buffercache.control | 2 +- contrib/pg_buffercache/pg_buffercache_pages.c | 42 +++--- doc/src/sgml/pgbuffercache.sgml| 7 7 files changed, 61 insertions(+), 44 deletions(-) create mode 100644 contrib/pg_buffercache/pg_buffercache--1.0--1.1.sql delete mode 100644 contrib/pg_buffercache/pg_buffercache--1.0.sql create mode 100644 contrib/pg_buffercache/pg_buffercache--1.1.sql diff --git a/contrib/pg_buffercache/Makefile b/contrib/pg_buffercache/Makefile index 323c0ac..5458a56 100644 --- a/contrib/pg_buffercache/Makefile +++ b/contrib/pg_buffercache/Makefile @@ -4,7 +4,7 @@ MODULE_big = pg_buffercache OBJS = pg_buffercache_pages.o EXTENSION = pg_buffercache -DATA = pg_buffercache--1.0.sql pg_buffercache--unpackaged--1.0.sql +DATA = pg_buffercache--1.1.sql pg_buffercache--1.0--1.1.sql pg_buffercache--unpackaged--1.0.sql ifdef USE_PGXS PG_CONFIG = pg_config diff --git a/contrib/pg_buffercache/pg_buffercache--1.0--1.1.sql b/contrib/pg_buffercache/pg_buffercache--1.0--1.1.sql new file mode 100644 index 000..4fd0ce4 --- /dev/null +++ b/contrib/pg_buffercache/pg_buffercache--1.0--1.1.sql @@ -0,0 +1,11 @@ +/* contrib/pg_buffercache/pg_buffercache--1.0--1.1.sql */ + +-- complain if script is sourced in psql, rather than via CREATE EXTENSION +\echo Use CREATE EXTENSION pg_buffercache to load this file. \quit + +-- Upgrade view to 1.1. format +CREATE OR REPLACE VIEW pg_buffercache AS + SELECT P.* FROM pg_buffercache_pages() AS P + (bufferid integer, relfilenode oid, reltablespace oid, reldatabase oid, + relforknumber int2, relblocknumber int8, isdirty bool, usagecount int2, + pincount int8); diff --git a/contrib/pg_buffercache/pg_buffercache--1.0.sql b/contrib/pg_buffercache/pg_buffercache--1.0.sql deleted file mode 100644 index 4ca4c44..000 --- a/contrib/pg_buffercache/pg_buffercache--1.0.sql +++ /dev/null @@ -1,20 +0,0 @@ -/* contrib/pg_buffercache/pg_buffercache--1.0.sql */ - --- complain if script is sourced in psql, rather than via CREATE EXTENSION -\echo Use CREATE EXTENSION pg_buffercache to load this file. \quit - --- Register the function. -CREATE FUNCTION pg_buffercache_pages() -RETURNS SETOF RECORD -AS 'MODULE_PATHNAME', 'pg_buffercache_pages' -LANGUAGE C; - --- Create a view for convenient access. -CREATE VIEW pg_buffercache AS - SELECT P.* FROM pg_buffercache_pages() AS P - (bufferid integer, relfilenode oid, reltablespace oid, reldatabase oid, - relforknumber int2, relblocknumber int8, isdirty bool, usagecount int2); - --- Don't want these to be available to public. -REVOKE ALL ON FUNCTION pg_buffercache_pages() FROM PUBLIC; -REVOKE ALL ON pg_buffercache FROM PUBLIC; diff --git a/contrib/pg_buffercache/pg_buffercache--1.1.sql b/contrib/pg_buffercache/pg_buffercache--1.1.sql new file mode 100644 index 000..c63b8af --- /dev/null +++ b/contrib/pg_buffercache/pg_buffercache--1.1.sql @@ -0,0 +1,21 @@ +/* contrib/pg_buffercache/pg_buffercache--1.1.sql */ + +-- complain if script is sourced in psql, rather than via CREATE EXTENSION +\echo Use CREATE EXTENSION pg_buffercache to load this file. \quit + +-- Register the function. +CREATE FUNCTION pg_buffercache_pages() +RETURNS SETOF RECORD +AS 'MODULE_PATHNAME', 'pg_buffercache_pages' +LANGUAGE C; + +-- Create a view for convenient access. +CREATE VIEW pg_buffercache AS + SELECT P.* FROM pg_buffercache_pages() AS P + (bufferid integer, relfilenode oid, reltablespace oid, reldatabase oid, + relforknumber int2, relblocknumber int8, isdirty bool, usagecount int2, + pincount int8); + +-- Don't want these to be available to public. +REVOKE ALL ON FUNCTION pg_buffercache_pages() FROM PUBLIC; +REVOKE ALL ON pg_buffercache FROM PUBLIC; diff --git a/contrib/pg_buffercache/pg_buffercache.control b/contrib/pg_buffercache/pg_buffercache.control index 709513c..5494e2f 100644 ---
Re: [HACKERS] Problem with txid_snapshot_in/out() functionality
On 04/12/14 03:27, Heikki Linnakangas wrote: On 04/12/2014 12:07 AM, Jan Wieck wrote: Hackers, the Slony team has been getting seldom reports of a problem with the txid_snapshot data type. The symptom is that a txid_snapshot on output lists the same txid multiple times in the xip list part of the external representation. This string is later rejected by txid_snapshot_in() when trying to determine if a particular txid is visible in that snapshot using the txid_visible_in_snapshot() function. I was not yet able to reproduce this problem in a lab environment. It might be related to subtransactions and/or two phase commit (at least one user is using both of them). The reported PostgreSQL version involved in that case was 9.1. It's two-phase commit. When preparing a transaction, the state of the transaction is first transfered to a dummy PGXACT entry, and then the PGXACT entry of the backend is cleared. There is a transient state when both PGXACT entries have the same xid. You can reproduce that by putting a sleep or breakpoint in PrepareTransaction(), just before the ProcArrayClearTransaction(MyProc); call. If you call txid_current_snapshot() from another session at that point, it will output two duplicate xids. (you will have to also commit one more unrelated transaction to bump up xmax). Thanks, that explains it. At this point I would find it extremely helpful to sanitize the external representation in txid_snapshot_out() while emitting some NOTICE level logging when this actually happens. I am aware that this does amount to a functional change for a back release, but considering that the _out() generated external representation of an existing binary datum won't pass the type's _in() function, I argue that such change is warranted. Especially since this problem could possibly corrupt a dump. Hmm. Do we snapshots to be stored in tables, and included in a dump? I don't think we can guarantee that will work, at least not across versions, as the way we handle snapshot internally can change. At least Londiste and Slony do store snapshots as well as xids in tables and assuming that the txid epoch is properly bumped, that information is useful and valid after a restore. But yeah, we probably should do something about that. The most straightforward fix would be to scan the array in txid_current_snapshot() and remove any duplicates. The code in txid_snapshot_in() checks that the xip list is ascending. txid_snapshot_out() does not sort the list, so it must already be sorted when the snapshot itself is created. That scan would be fairly simple. Jan -- Jan Wieck Senior Software Engineer http://slony.info -- 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] Problem with txid_snapshot_in/out() functionality
On 2014-04-12 10:27:16 +0300, Heikki Linnakangas wrote: On 04/12/2014 12:07 AM, Jan Wieck wrote: The symptom is that a txid_snapshot on output lists the same txid multiple times in the xip list part of the external representation. This string is later rejected by txid_snapshot_in() when trying to determine if a particular txid is visible in that snapshot using the txid_visible_in_snapshot() function. It's two-phase commit. When preparing a transaction, the state of the transaction is first transfered to a dummy PGXACT entry, and then the PGXACT entry of the backend is cleared. There is a transient state when both PGXACT entries have the same xid. Which I find to be a pretty bad idea independent of this bug. But I think that's nothing fixable in the back branches. Hmm. Do we snapshots to be stored in tables, and included in a dump? I don't think we can guarantee that will work, at least not across versions, as the way we handle snapshot internally can change. Hm. I don't think we'll earn much love changing that - there's at the very least slony and londiste out there using it... IIRC both store the result in tables. But yeah, we probably should do something about that. The most straightforward fix would be to scan the array in txid_current_snapshot() and remove any duplicates. Since it's sorted there, that should be fairly straightforward. Won't fix already created and stored datums tho. Maybe _in()/parse_snapshot() should additionally skip over duplicate values? Looks easy enough. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with txid_snapshot_in/out() functionality
On 04/12/14 08:38, Andres Freund wrote: Since it's sorted there, that should be fairly straightforward. Won't fix already created and stored datums tho. Maybe _in()/parse_snapshot() should additionally skip over duplicate values? Looks easy enough. There is the sort ... missed that when glancing over the code earlier. Right, that is easy enough and looks like an acceptable fix for back branches too. Thanks, Jan -- Jan Wieck Senior Software Engineer http://slony.info -- 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] Problem with txid_snapshot_in/out() functionality
Heikki Linnakangas hlinnakan...@vmware.com writes: On 04/12/2014 12:07 AM, Jan Wieck wrote: the Slony team has been getting seldom reports of a problem with the txid_snapshot data type. The symptom is that a txid_snapshot on output lists the same txid multiple times in the xip list part of the external representation. It's two-phase commit. When preparing a transaction, the state of the transaction is first transfered to a dummy PGXACT entry, and then the PGXACT entry of the backend is cleared. There is a transient state when both PGXACT entries have the same xid. Hm, yeah, but why is that intermediate state visible to anyone else? Don't we have exclusive lock on the PGPROC array while we're doing this? If we don't, aren't we letting other backends see non-self-consistent state in regards to who holds which locks, for example? I'm worried that the proposed fix is just band-aiding one particular symptom of inadequate locking. 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] Problem with txid_snapshot_in/out() functionality
On 2014-04-12 09:47:24 -0400, Tom Lane wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: On 04/12/2014 12:07 AM, Jan Wieck wrote: the Slony team has been getting seldom reports of a problem with the txid_snapshot data type. The symptom is that a txid_snapshot on output lists the same txid multiple times in the xip list part of the external representation. It's two-phase commit. When preparing a transaction, the state of the transaction is first transfered to a dummy PGXACT entry, and then the PGXACT entry of the backend is cleared. There is a transient state when both PGXACT entries have the same xid. Hm, yeah, but why is that intermediate state visible to anyone else? Don't we have exclusive lock on the PGPROC array while we're doing this? It's done outside the remit of ProcArray lock :(. And documented to lead to duplicate xids in PGXACT. EndPrepare(): /* * Mark the prepared transaction as valid. As soon as xact.c marks * MyPgXact as not running our XID (which it will do immediately after * this function returns), others can commit/rollback the xact. * * NB: a side effect of this is to make a dummy ProcArray entry for the * prepared XID. This must happen before we clear the XID from MyPgXact, * else there is a window where the XID is not running according to * TransactionIdIsInProgress, and onlookers would be entitled to assume * the xact crashed. Instead we have a window where the same XID appears * twice in ProcArray, which is OK. */ MarkAsPrepared(gxact); It doesn't sound too hard to essentially move PrepareTransaction()'s ProcArrayClearTransaction() into MarkAsPrepared() and rejigger the locking to remove the intermediate state. But I think it'll lead to bigger changes than we'd be comfortable backpatching. If we don't, aren't we letting other backends see non-self-consistent state in regards to who holds which locks, for example? I think that actually works out ok, because the locks aren't owned by xids/xacts, but procs. Otherwise we'd be in deep trouble in CommitTransaction() as well where ProcArrayEndTransaction() clearing that state. After the whole xid transfer, there's PostPrepare_Locks() transferring the locks. Brr. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with txid_snapshot_in/out() functionality
On 12 Apr 2014 08:35, Jan Wieck j...@wi3ck.info wrote: On 04/12/14 03:27, Heikki Linnakangas wrote: On 04/12/2014 12:07 AM, Jan Wieck wrote: Hackers, Hmm. Do we snapshots to be stored in tables, and included in a dump? I don't think we can guarantee that will work, at least not across versions, as the way we handle snapshot internally can change. At least Londiste and Slony do store snapshots as well as xids in tables and assuming that the txid epoch is properly bumped, that information is useful and valid after a restore. As I understand it the epoch increments whenever the xid wraps. A physical restore would continue the same xid space in the same epoch which should work fine as long as no system stores any txids outside the database from the future. A pg_restore would start a new xid space from FirstNormalXid which would obviously not work with any stored txids.
Re: [HACKERS] Problem with txid_snapshot_in/out() functionality
On 04/12/14 10:09, Greg Stark wrote: A pg_restore would start a new xid space from FirstNormalXid which would obviously not work with any stored txids. http://www.postgresql.org/docs/9.3/static/app-pgresetxlog.html Regards, Jan -- Jan Wieck Senior Software Engineer http://slony.info -- 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] Problem with txid_snapshot_in/out() functionality
On 2014-04-12 11:15:09 -0400, Jan Wieck wrote: On 04/12/14 10:09, Greg Stark wrote: A pg_restore would start a new xid space from FirstNormalXid which would obviously not work with any stored txids. http://www.postgresql.org/docs/9.3/static/app-pgresetxlog.html Using that as part of any sort of routine task IMNSHO is a seriously bad idea. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with txid_snapshot_in/out() functionality
On 04/12/14 11:18, Andres Freund wrote: On 2014-04-12 11:15:09 -0400, Jan Wieck wrote: On 04/12/14 10:09, Greg Stark wrote: A pg_restore would start a new xid space from FirstNormalXid which would obviously not work with any stored txids. http://www.postgresql.org/docs/9.3/static/app-pgresetxlog.html Using that as part of any sort of routine task IMNSHO is a seriously bad idea. Nobody is advocating doing so. Jan -- Jan Wieck Senior Software Engineer http://slony.info -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] test failure on latest source
Anyone seeing similar failure ? testing on latest $ git log |head commit 3c41b812c5578fd7bd5c2de42941012d7d56dde2 Author: Bruce Momjian br...@momjian.us Date: Thu Apr 10 17:16:22 2014 -0400 docs: psql '--' comments are not passed to the server C-style block comments are passed to the server. $ cat /pub/devel/postgresql/prova/build_orig/src/test/regress /log/postmaster.log LOG: could not resolve localhost: Non-recoverable failure in name resolution LOG: disabling statistics collector for lack of working socket WARNING: autovacuum not started because of misconfiguration HINT: Enable the track_counts option. LOG: invalid IP address 127.0.0.1: Non-recoverable failure in name resolution CONTEXT: line 86 of configuration file /pub/devel/postgresql/prova/build_orig/src/test/regress/./tmp_check/data/pg_hba.conf FATAL: could not load pg_hba.conf built as usual on cygwin with ../postgresql_orig/configure LDFLAGS=-Wl,-no-undefined --enable-nls --with-openssl --with-perl --with-python --with-ldap Regards Marco -- 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] test failure on latest source
On 2014-04-12 18:39:54 +0200, Marco Atzeri wrote: LOG: invalid IP address 127.0.0.1: Non-recoverable failure in name resolution That sounds like a local setup problem. Is 127.0.0.1 pingable? Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] test failure on latest source
On 04/12/2014 12:39 PM, Marco Atzeri wrote: Anyone seeing similar failure ? testing on latest $ git log |head commit 3c41b812c5578fd7bd5c2de42941012d7d56dde2 Author: Bruce Momjian br...@momjian.us Date: Thu Apr 10 17:16:22 2014 -0400 docs: psql '--' comments are not passed to the server C-style block comments are passed to the server. $ cat /pub/devel/postgresql/prova/build_orig/src/test/regress /log/postmaster.log LOG: could not resolve localhost: Non-recoverable failure in name resolution LOG: disabling statistics collector for lack of working socket WARNING: autovacuum not started because of misconfiguration HINT: Enable the track_counts option. LOG: invalid IP address 127.0.0.1: Non-recoverable failure in name resolution CONTEXT: line 86 of configuration file /pub/devel/postgresql/prova/build_orig/src/test/regress/./tmp_check/data/pg_hba.conf FATAL: could not load pg_hba.conf built as usual on cygwin with ../postgresql_orig/configure LDFLAGS=-Wl,-no-undefined --enable-nls --with-openssl --with-perl --with-python --with-ldap Why can't it resolve localhost? That's a local issue you need to fix. cheers andrew -- 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] test failure on latest source
On 12/04/2014 19:11, Andrew Dunstan wrote: Why can't it resolve localhost? That's a local issue you need to fix. cheers andrew Andrew, just to be clear - localhost is resolved to 127.0.0.1 - 127.0.0.1 is pingable - same test on 9.3.4 works All 135 tests passed. - same test, few days ago, on trunk was fine so it is only failing on recent trunk Regards Marco -- 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] test failure on latest source
On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote: On 12/04/2014 19:11, Andrew Dunstan wrote: Why can't it resolve localhost? That's a local issue you need to fix. cheers andrew Andrew, just to be clear - localhost is resolved to 127.0.0.1 - 127.0.0.1 is pingable - same test on 9.3.4 works All 135 tests passed. - same test, few days ago, on trunk was fine so it is only failing on recent trunk Does it work on a commit before fc752505a99a4e2c781a070d3d42a25289c22e3c? E.g. f33a71a7865a1dd54f04b370e2637f88665f8db8? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with txid_snapshot_in/out() functionality
On 04/12/14 10:03, Andres Freund wrote:
On 2014-04-12 09:47:24 -0400, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 04/12/2014 12:07 AM, Jan Wieck wrote:
the Slony team has been getting seldom reports of a problem with the
txid_snapshot data type.
The symptom is that a txid_snapshot on output lists the same txid
multiple times in the xip list part of the external representation.
It's two-phase commit. When preparing a transaction, the state of the
transaction is first transfered to a dummy PGXACT entry, and then the
PGXACT entry of the backend is cleared. There is a transient state when
both PGXACT entries have the same xid.
Hm, yeah, but why is that intermediate state visible to anyone else?
Don't we have exclusive lock on the PGPROC array while we're doing this?
It's done outside the remit of ProcArray lock :(. And documented to lead
to duplicate xids in PGXACT.
EndPrepare():
/*
* Mark the prepared transaction as valid. As soon as xact.c marks
* MyPgXact as not running our XID (which it will do immediately after
* this function returns), others can commit/rollback the xact.
*
* NB: a side effect of this is to make a dummy ProcArray entry for the
* prepared XID. This must happen before we clear the XID from
MyPgXact,
* else there is a window where the XID is not running according to
* TransactionIdIsInProgress, and onlookers would be entitled to assume
* the xact crashed. Instead we have a window where the same XID
appears
* twice in ProcArray, which is OK.
*/
MarkAsPrepared(gxact);
It doesn't sound too hard to essentially move PrepareTransaction()'s
ProcArrayClearTransaction() into MarkAsPrepared() and rejigger the
locking to remove the intermediate state. But I think it'll lead to
bigger changes than we'd be comfortable backpatching.
If we don't, aren't we letting other backends see non-self-consistent
state in regards to who holds which locks, for example?
I think that actually works out ok, because the locks aren't owned by
xids/xacts, but procs. Otherwise we'd be in deep trouble in
CommitTransaction() as well where ProcArrayEndTransaction() clearing
that state.
After the whole xid transfer, there's PostPrepare_Locks() transferring
the locks.
Since it doesn't seem to produce any side effects, I'd think that making
the snapshot unique within txid_current_snapshot() and filtering
duplicates on input should be sufficient and eligible for backpatching.
The attached patch adds a unique loop to the internal sort_snapshot()
function and skips duplicates on input. The git commit is here:
https://github.com/wieck/postgres/commit/a88a2b2c25b856478d7e2b012fc718106338fe00
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
diff --git a/src/backend/utils/adt/txid.c b/src/backend/utils/adt/txid.c
index a005e67..44f7880 100644
*** a/src/backend/utils/adt/txid.c
--- b/src/backend/utils/adt/txid.c
*** cmp_txid(const void *aa, const void *bb)
*** 131,146
}
/*
! * sort a snapshot's txids, so we can use bsearch() later.
*
* For consistency of on-disk representation, we always sort even if bsearch
! * will not be used.
*/
static void
sort_snapshot(TxidSnapshot *snap)
{
if (snap-nxip 1)
qsort(snap-xip, snap-nxip, sizeof(txid), cmp_txid);
}
/*
--- 131,161
}
/*
! * unique sort a snapshot's txids, so we can use bsearch() later.
*
* For consistency of on-disk representation, we always sort even if bsearch
! * will not be used.
*/
static void
sort_snapshot(TxidSnapshot *snap)
{
+ txidlast = 0;
+ int nxip, idx1, idx2;
+
if (snap-nxip 1)
+ {
qsort(snap-xip, snap-nxip, sizeof(txid), cmp_txid);
+ nxip = snap-nxip;
+ idx1 = idx2 = 0;
+ while (idx1 nxip)
+ {
+ if (snap-xip[idx1] != last)
+ last = snap-xip[idx2++] = snap-xip[idx1];
+ else
+ snap-nxip--;
+ idx1++;
+ }
+ }
}
/*
*** parse_snapshot(const char *str)
*** 294,304
val = str2txid(str, endp);
str = endp;
! /* require the input to be in order */
! if (val xmin || val = xmax || val = last_val)
goto bad_format;
! buf_add_txid(buf, val);
last_val = val;
if (*str == ',')
--- 309,320
val = str2txid(str, endp);
str = endp;
! /* require the input to be in order and skip duplicates */
! if (val xmin || val = xmax || val last_val)
goto bad_format;
! if (val !=
Re: [HACKERS] test failure on latest source
On 12/04/2014 19:48, Andres Freund wrote: On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote: - same test, few days ago, on trunk was fine so it is only failing on recent trunk Does it work on a commit before fc752505a99a4e2c781a070d3d42a25289c22e3c? E.g. f33a71a7865a1dd54f04b370e2637f88665f8db8? f33a71a7865a1dd54f04b370e2637f88665f8db8 works. Greetings, Andres Freund I will look on bisecting from there Regards Marco -- 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] test failure on latest source
Andres Freund and...@2ndquadrant.com writes: On 2014-04-12 19:45:59 +0200, Marco Atzeri wrote: so it is only failing on recent trunk Does it work on a commit before fc752505a99a4e2c781a070d3d42a25289c22e3c? In principle, that commit shouldn't have affected behavior for pg_hba entries with numeric address fields ... Is this failure occurring with the default contents of pg_hba.conf, or have you changed it? If so, how? 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] Signaling of waiting for a cleanup lock?
On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund and...@2ndquadrant.com wrote: VACUUM sometimes waits synchronously for a cleanup lock on a heap page. Sometimes for a long time. Without reporting it externally. Rather confusing ;). Since we only take cleanup locks around vacuum, how about we report at least in pgstat that we're waiting? At the moment, there's really no way to know if that's what's happening. That seems like a pretty good idea to me. I think we've avoided doing this for LWLocks for fear that there might be too much overhead, but it's hard for me to imagine a workload where you're waiting for cleanup locks often enough for the overhead to matter. -- 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] WIP patch (v2) for updatable security barrier views
All, * Tom Lane (t...@sss.pgh.pa.us) wrote: Yeah, the point of the gotcha is that a FOR UPDATE specified *outside* a security-barrier view would act as though it had appeared *inside* the view, since it effectively gets pushed down even though outer quals don't. Alright, I've committed this with an updated note regarding the locking, and a few additional regression tests (which appear to have upset some of the buildfarm- will look at that...). Please let me know if you see any issues. I'm planning to spend more-or-less all of tomorrow looking over the RLS patch. As it's rather large, I'm not sure I'll be able to get through it all, but I'm gonna give it a go. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] WIP patch (v2) for updatable security barrier views
Greg, * Gregory Smith (gregsmithpg...@gmail.com) wrote: Now that Tom has given some guidance on the row locking weirdness, maybe it's time for me to start updating those into make check form. If you have time, that'd certainly be helpful. The documentation has been in a similar holding pattern. I have lots of resources to help document what does and doesn't work here to the quality expected in the manual. I just need a little more confidence about which feature set is commit worthy. The documentation that makes sense is very different if only updatable security barrier views is committed. Guess I see that a bit differently- the two features, while they might be able to be used together, should both be documented appropriately and at the level that each can be used independently. I'm not sure that documentation about how to build RLS on top of updatable security barrier views w/o actual RLS support being in PG would be something we'd want to include in the PG documentation, which I guess is what you're getting at here. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] PostgreSQL in Windows console and Ctrl-C
On Sat, Apr 12, 2014 at 12:36 PM, Christian Ullrich ch...@chrullrich.net wrote: * From: Amit Kapila Another thing to decide about this fix is that whether it is okay to fix it for CTRL+C and leave the problem open for CTRL+BREAK? (The current option used (CREATE_NEW_PROCESS_GROUP) will handle only CTRL+C). Below is a new (right now very much proof-of-concept) patch to replace my earlier one. It has the same effect on Ctrl-C the change to pg_ctl had, and additionally ignores Ctrl-Break as well. This fix won't allow CTRL+C for other cases like when server is started directly with postgres binary. ./postgres -D data_dir_path I think this doesn't come under your original complaint and as such I don't see any problem in allowing CTRL+C for above case. One another way could be to use CREATE_NEW_CONSOLE instead of CREATE_NEW_PROCESS_GROUP in you previous fix, but I am not sure if it's acceptable to users to have a new console window for server. 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
[HACKERS] Patch to fix a couple of compiler warnings from 80a5cf64
The attached patch fixes a couple of compiler warnings seen by the MSVC build. contrib\pg_trgm\trgm_regexp.c(234): warning C4305: 'initializing' : truncation from 'double' to 'const float4' [D:\Postgres\b\pg_trgm.vcxproj] contrib\pg_trgm\trgm_regexp.c(235): warning C4305: 'initializing' : truncation from 'double' to 'const float4' [D:\Postgres\b\pg_trgm.vcxproj] 2 Warning(s) I'm not quite sure why I get 2 warnings rather than 8, but the attached seems to make them go away, for what it's worth. Regards David Rowley trgm_regexp_warning_fix.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] [COMMITTERS] pgsql: Add ALTER TABLESPACE ... MOVE command
* Tom Lane (t...@sss.pgh.pa.us) wrote: Ick. That's just plain sloppy. Please create a separate production, *and* a separate comment header. Done. Commit d86d51a95 was pretty damn awful in this regard as well, but let's clean them both up, not make it worse. Yeah, I think I noticed this in passing but probably did the same as Robert and figured oh, I'm just playing with this, I'll go back and clean it up later.. and then promptly forgot about it 'cause it worked just fine. Existing precedent would suggest inventing two new productions named the same as the parse node types they produce, viz AlterTableSpaceMoveStmt and AlterTableSpaceOptionsStmt. This felt a bit like overkill to me for these few, so I just did them under a single 'AlterTblSpcStmt'. I'm not against going back and changing it if others feel differently. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] proposal: interprocess EXPLAIN PID
On Fri, Apr 11, 2014 at 12:13 PM, Pavel Stehule pavel.steh...@gmail.com wrote: Hello I propose a enhancing of EXPLAIN statement about possibility get a plan of other PostgreSQL process. Does this mean that you want to track plan (and other info Explain provides) of statements running in particular backend? Could you please explain this in bit more detail w.r.t how this will work? 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
