Re: [HACKERS] Typo in a comment?
On 02/07/2014 08:15 AM, Amit Langote wrote: In src/backend/storage/freespace/freespace.c, * * MaxFSMRequestSize depends on the architecture and BLCKSZ, but assuming * default 8k BLCKSZ, and that MaxFSMRequestSize is 24 bytes, the categories * look like this * Is 24 bytes a typo considering that #define MaxFSMRequestSize MaxHeapTupleSize ? Yeah. I think it's supposed to say SizeOfPageHeaderData is 24 bytes, which would make for a MaxFSMRequestSize of 8164 bytes, as in the example. It'd probably be more clear to say directly MaxFSMRequestSize is 8164 bytes, though. I'll go fix it that way, thanks for the report! - 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] [GENERAL] client encoding that psql command sets
[CC'ed -hackers]
Tsubasa Sakamoto wrote:
Not sure that it makes a difference but the docs say psql looks at
LC_CTYPE not LANG for Unix systems. You did not say what OS you are
working on though from the examples I am guessing some form of Unix.
The LC_CTYPE environment variable was set up and re-verified.
The result of psql command is following.
[Result]
% setenv LC_CTYPE ja_JP.eucJP
% psql postgres -f test.txt -o result.txt EUC_JP
% psql postgres -f test.txt result.txt
UTF8
% psql postgres -o result.txt test.txt
UTF8
% psql postgres test.txt result.txt
UTF8
Even when a LC_CTYPE environment variable was set up, the result did not
change.
What do you think?
I think that the documentation contradicts the code.
In bin/psql/settings.h:
typedef struct _psqlSettings
{
[...]
boolnotty; /* stdin or stdout is not a tty (as determined
* on startup) */
[...]
} PsqlSettings;
extern PsqlSettings pset;
In bin/psql/command.c and bin/psql/startup.c:
keywords[6] = client_encoding;
values[6] = (pset.notty || getenv(PGCLIENTENCODING)) ? NULL : auto;
That matches your observations: client_encoding=auto is only
used if both stdin and stdout are attached to a tty.
I suggest the attached documentation fix.
Yours,
Laurenz Albe
psql-doc.patch
Description: psql-doc.patch
--
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] Inconsistency between pg_stat_activity and log_duration
One idea is, calling pgstat_report_activity(STATE_IDLE) in exec_execute_message() of postgres.c. The function has already called pgstat_report_activity(STATE_RUNNING) which shows active state in pg_stat_actviity view. So why cann't we call pgstat_report_activity(STATE_IDLE) here. Somebody might claim that idle is a transaction state term. Idle means The backend is waiting for a new client command., which is certainly not true especially in case of 'E' message as still sync message processing is left. In the case, I propose to add new state name, say finished. So above proposal would calling pgstat_report_activity(STATE_FINISHED) instead. Okay, so by state finish, it can mean The backend has finished execution of a query.. In that case I think this might need to be called at end of exec_simple_query() as well, but then there will be very less difference between idle and finish for simple query. Of course. The argument here could be do we really need a new state for such a short window between completion of 'E' message and processing of 'S' sync message considering updation of state is not a very light call which can be called between processing of 2 messages. It might make sense for cases where sync message processing can take longer time. Would it be not sufficient, If we just explain this in docs. Do users really face any inconvenience or it's a matter of clear understanding for users? Well... maybe it's a matter of doc. Pgpool-II issues such SELECTs intenally to retrieve system catalog info. The query is piggy backed on the same connection to PostgreSQL opend by user (pgpool-II cannot issue sync because it closes the transaction, which in turn closes user's unnamed portal). If user's query is SELECT, it can be sent to standbys because of load balance. After such internal queries are sent to master, which will remain active for long time because sync is not issued. I got many inquries from pgpool-II users Hey, when I looked at pg_stat_activity, I noticed querys is running for so long time. why?. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- 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] specifying repeatable read in PGOPTIONS
Hi Tom,
On 2014-02-04 12:02:45 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-02-04 11:36:22 -0500, Tom Lane wrote:
-1. This is not a general solution to the problem. There are other
GUCs for which people might want spaces in the value.
Sure, I didn't say it was. But I don't see any oother values that are
likely being passed via PGOPTIONS that frequently contain spaces.
application_name --- weren't we just reading about people passing entire
command lines there? (They must be using some other way of setting it
currently, but PGOPTIONS doesn't seem like an implausible source.)
You can't easily use PGOPTIONS to set application_name in many cases
anyway, libpq's support for it gets in the way since it takes effect
later. And I think libpq is much more likely way to set it. Also you can
simply circumvent the problem by using a different naming convention,
that's not problem with repeatable read.
So I still think we should add read_committed, repeatable_read as aliases.
Yeah. See pg_split_opts(), which explicitly acknowledges that it'll fall
down for space-containing options. Not sure what the most appropriate
quoting convention would be there, but I'm sure we can think of something.
No argument against introducing it. What about simply allowing escaping
of the next character using \?
The same thought had occurred to me. Since it'll typically already be
inside some levels of quoting, any quoted-string convention seems like
it'd be a pain to use. But a straight backslash-escapes-the-next-char
thing wouldn't be too awful, I think.
Ok, here's a patch implementing that. There's a slight backward concern
in that a \ would earlier have been passed through unmodified, but now
would be taken as a escape. I think that's not too much of a problem
though.
I thought about simply outputting the escape unless it's been used as an
escape before a speace, but that seems like a bad idea, barring future
uses to me.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
From 8baed020afeda57d2e292a7f37e3c9a97ceaf524 Mon Sep 17 00:00:00 2001
From: Andres Freund and...@anarazel.de
Date: Fri, 7 Feb 2014 10:59:23 +0100
Subject: [PATCH] Allow escaping of option values for options passed at
connection start.
This is primarily useful because it allows to set a per-connection
default_transaction_isolation value of 'repeatable read' which
previously was not possible, but other usecases like seach_path do
also exist.
---
src/backend/postmaster/postmaster.c | 3 +--
src/backend/utils/init/postinit.c | 51 +++--
2 files changed, 38 insertions(+), 16 deletions(-)
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index 5bc5213..7619fb5 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -4065,8 +4065,7 @@ BackendRun(Port *port)
/*
* Pass any backend switches specified with -o on the postmaster's own
- * command line. We assume these are secure. (It's OK to mangle
- * ExtraOptions now, since we're safely inside a subprocess.)
+ * command line. We assume these are secure.
*/
pg_split_opts(av, ac, ExtraOptions);
diff --git a/src/backend/utils/init/postinit.c b/src/backend/utils/init/postinit.c
index 2a57ed3..6f25777 100644
--- a/src/backend/utils/init/postinit.c
+++ b/src/backend/utils/init/postinit.c
@@ -407,31 +407,55 @@ InitCommunication(void)
/*
* pg_split_opts -- split a string of options and append it to an argv array
*
- * NB: the input string is destructively modified! Also, caller is responsible
- * for ensuring the argv array is large enough. The maximum possible number
- * of arguments added by this routine is (strlen(optstr) + 1) / 2.
+ * The caller is responsible for ensuring the argv array is large enough. The
+ * maximum possible number of arguments added by this routine is
+ * (strlen(optstr) + 1) / 2.
*
- * Since no current POSTGRES arguments require any quoting characters,
- * we can use the simple-minded tactic of assuming each set of space-
- * delimited characters is a separate argv element.
- *
- * If you don't like that, well, we *used* to pass the whole option string
- * as ONE argument to execl(), which was even less intelligent...
+ * Because some option values can contain spaces we allow escaping using
+ * backslashes, with a \\ representing a literal backslash.
*/
void
pg_split_opts(char **argv, int *argcp, char *optstr)
{
+ StringInfoData s;
+
+ initStringInfo(s);
+
while (*optstr)
{
+ bool last_was_escape = false;
+
+ resetStringInfo(s);
+
+ /* skip over leading space */
while (isspace((unsigned char) *optstr))
optstr++;
+
if (*optstr == '\0')
break;
- argv[(*argcp)++] = optstr;
- while (*optstr !isspace((unsigned char) *optstr))
+
+ /*
+ * Parse a single option +
Re: [HACKERS] Recovery inconsistencies, standby much larger than primary
On 2014-02-06 20:06:03 -0500, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: That reminds me, not that I directly see how it could be responsible, there's still 20131029011623.gj20...@awork2.anarazel.de ff. around. I don't think we came to a agreement in that thread how to fix the problem. Hm, yeah. I'm not sure I believe Heikki's argument that we need to avoid closing the smgr relation. If that stuff is being used in any performance-critical paths then we've got trouble already. Me neither. And I still am hesitant to start doing an unconditional smgropen(rnode, InvalidBackendId), but maybe that's also misplaced. My gut feeling would either to go with the very simple closing the smgr (which was the case before the current form of the fake relcache infrastructure!) or add support of unowning the smgr rel (as in 20131105193632.gd14...@awork2.anarazel.de). After being slightly more awake it's even harder to see how it could be the cause for this thread's problem. True, it's a rogue write into palloc()ed memory that's used by somebody else, but afaics it will only ever write a NULL. While not impossible it seems a bit of a stretch how that could cause the symptoms. 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] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
On Thu, Jan 16, 2014 at 12:35 AM, Heikki Linnakangas hlinnakan...@vmware.com wrote: I think you should consider breaking off the relcache parts of my patch and committing them, because they're independently useful. Makes sense. Can you extract that into a separate patch, please? Perhaps you can take a look at this again, when you get a chance. -- Peter Geoghegan -- 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] inherit support for foreign tables
Hi Hanada-san, Sorry for the delay. (2014/01/30 14:01), Shigeru Hanada wrote: 2014-01-27 Etsuro Fujita fujita.ets...@lab.ntt.co.jp: While still reviwing this patch, I feel this patch has given enough consideration to interactions with other commands, but found the following incorrect? behabior: postgres=# CREATE TABLE product (id INTEGER, description TEXT); CREATE TABLE postgres=# CREATE FOREIGN TABLE product1 () INHERITS (product) SERVER fs OPTIONS (filename '/home/foo/product1.csv', format 'csv'); CREATE FOREIGN TABLE postgres=# ALTER TABLE product ALTER COLUMN description SET STORAGE EXTERNAL; ERROR: product1 is not a table or materialized view ISTN the ALTER TABLE simple recursion mechanism (ie ATSimpleRecursion()) should be modified for the ALTER COLUMN SET STORAGE case. It seems little bit complex than I expected. Currently foreign tables deny ALTER TABLE SET STORAGE with message like below, because foreign tables don't have storage in the meaning of PG heap tables. ERROR: pgbench1_accounts_c1 is not a table or materialized view At the moment we don't use attstorage for foreign tables, so allowing SET STORAGE against foreign tables never introduce visible change except \d+ output of foreign tables. But IMO such operation should not allowed because users would be confused. So I changed ATExecSetStorage() to skip on foreign tables. This allows us to emit ALTER TABLE SET STORAGE against ordinary tables in upper level of inheritance tree, but it have effect on only ordinary tables in the tree. This also allows direct ALTER FOREIGN TABLE SET STORAGE against foreign table but the command is silently ignored. SET STORAGE support for foreign tables is not documented because it may confuse users. With attached patch, SET STORAGE against wrong relations produces message like this. Is it confusing to mention foreign table here? ERROR: pgbench1_accounts_pkey is not a table, materialized view, or foreign table ITSM that would be confusing to users. So, I've modified the patch so that we continue to disallow SET STORAGE on a foreign table *in the same manner as before*, but, as your patch does, allow it on an inheritance hierarchy that contains foreign tables, with the semantics that we quietly ignore the foreign tables and apply the operation to the plain tables, by modifying the ALTER TABLE simple recursion mechanism. Attached is the updated version of the patch. I'll continue the patch review a bit more, though the patch looks good generally to me except for the abobe issue and the way that the ANALYZE command works. For the latter, if there are no objections, I'll merge the ANALYZE patch [1] with your patch. Thanks, [1] http://www.postgresql.org/message-id/52eb10ac.4070...@lab.ntt.co.jp Best regards, Etsuro Fujita *** a/doc/src/sgml/ddl.sgml --- b/doc/src/sgml/ddl.sgml *** *** 258,263 CREATE TABLE products ( --- 258,274 even if the value came from the default value definition. /para + note +para + Note that constraints can be defined on foreign tables too, but such + constraints are not enforced on insert or update. Those constraints are + assertive, and work only to tell planner that some kind of optimization + such as constraint exclusion can be considerd. This seems useless, but + allows us to use foriegn table as child table (see + xref linkend=ddl-inherit) to off-load to multiple servers. +/para + /note + sect2 id=ddl-constraints-check-constraints titleCheck Constraints/title *** *** 2021,2028 CREATE TABLE capitals ( /para para !In productnamePostgreSQL/productname, a table can inherit from !zero or more other tables, and a query can reference either all rows of a table or all rows of a table plus all of its descendant tables. The latter behavior is the default. For example, the following query finds the names of all cities, --- 2032,2039 /para para !In productnamePostgreSQL/productname, a table or foreign table can !inherit from zero or more other tables, and a query can reference either all rows of a table or all rows of a table plus all of its descendant tables. The latter behavior is the default. For example, the following query finds the names of all cities, *** a/doc/src/sgml/ref/alter_foreign_table.sgml --- b/doc/src/sgml/ref/alter_foreign_table.sgml *** *** 42,47 ALTER FOREIGN TABLE [ IF EXISTS ] replaceable class=PARAMETERname/replaceab --- 42,49 ALTER [ COLUMN ] replaceable class=PARAMETERcolumn_name/replaceable SET ( replaceable class=PARAMETERattribute_option/replaceable = replaceable class=PARAMETERvalue/replaceable [, ... ] ) ALTER [ COLUMN ] replaceable class=PARAMETERcolumn_name/replaceable RESET ( replaceable class=PARAMETERattribute_option/replaceable [, ... ] ) ALTER [ COLUMN ] replaceable
[HACKERS] Breaking compile-time dependency cycles of Postgres subdirs?
This question is mostly just curiosity... There are build-time dependency cycles between some of Postgres' code subdirectories. For example, storage and access have such a cycle: storage/buffpage.h #includes access/xlogdefs.h access/visibilitymap.h #includes storage/block.h Has there been any discussion about reorganizing these directories so that no such cycles exist? As someone very new to this code base, I think these cycles make it a little harder to figure out the runtime and compile-time dependencies between the subsystems these directories seem to represent. I wonder if that's a problem others face as well?
Re: [HACKERS] extension_control_path
Hi, On 06/02/14 18:14, Greg Stark wrote: Installing into /usr/local is a global system change. Only root should be able to do that and any user that can do that can easily acquire root privileges. The idea behind Homebrew is copied from FreeBSD, where you also install 3rd party software to /usr/local. This is felt as cleaner and nicer by these guys. Homebrew goes one step further: with Homebrew you are able to completely remove all 3rd party software installed via Homebrew as well as Homebrew itself by simply removing /usr/local. And since most of the time OS X is used as a desktop software, they simplified things for users by chown-ing /usr/local (which, in a clean OS X installation, is either empty or does not exist, depending on the version) at installation time to the user installing Homebrew. Of course you can avoid this by installing Homebrew as root, but using the root user is not very popular in OS X land. Best regards, -- Christian Kruse http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services pgpZntl0SyG93.pgp Description: PGP signature
Re: [HACKERS] GIN improvements part2: fast scan
On 02/06/2014 01:22 PM, Alexander Korotkov wrote: Difference is very small. For me, it looks ready for commit. Great, committed! Now, to review the catalog changes... - 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] Inconsistency between pg_stat_activity and log_duration
Tatsuo Ishii is...@postgresql.org writes: The argument here could be do we really need a new state for such a short window between completion of 'E' message and processing of 'S' sync message considering updation of state is not a very light call which can be called between processing of 2 messages. It might make sense for cases where sync message processing can take longer time. I concur with this objection --- we are not going to add reasons for extended query mode to be slower than plain mode, especially not reasons that are totally useless in normal usage. The query is piggy backed on the same connection to PostgreSQL opend by user (pgpool-II cannot issue sync because it closes the transaction, which in turn closes user's unnamed portal). This argument (and usage) seems pretty broken. If you don't issue sync then how do you know you've gotten all of the command's output? If you're issuing a flush instead, maybe we could consider whether it's reasonable to do an extra pgstat_report_activity() upon receipt of a flush message. But -1 for putting it into the normal control flow. I'd also vote against inventing a new pgstat state code for this. Most people will never see it, which would prompt questions in itself. 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] open and close columns in the NEW record not allowed
On Thu, Feb 6, 2014 at 10:27 AM, k...@rice.edu k...@rice.edu wrote: Thanks for the feedback. Our problem is that an application decides the name of the columns in the tables and XDB replication from EnterpriseDB decides the triggers. We have no control over the code :-( It sounds like a bug in the XDB trigger generation code. Maybe file a bug report. +1. If you are using XDB, presumably that means you are an EntepriseDB customer and can file a support ticket. Zahid's team is usually very responsive, and this definitely sounds like a bug. -- 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] dynamic shared memory and locks
On Tue, Jan 21, 2014 at 11:37 AM, Robert Haas robertmh...@gmail.com wrote: One idea I just had is to improve the dsm_toc module so that it can optionally set up a tranche of lwlocks for you, and provide some analogues of RequestAddinLWLocks and LWLockAssign for that case. That would probably make this quite a bit simpler to use, at least for people using it with dynamic shared memory. But I think that's a separate patch. I played with this a bit today and it doesn't actually seem to simplify things very much. The backend that creates the DSM needs to do this: lwlocks = shm_toc_allocate(toc, sizeof(LWLockPadded) * nlwlocks); for (i = 0; i nlwlocks; ++i) LWLockInitialize(lwlocks[i].lock, tranche_id); Since that's all of three lines, encapsulating it doesn't look all that helpful. Then each backend needs to do something like this: static LWLockTranche mytranche; mytranche.name = some descriptive module name; mytranche.array_base = lwlocks; mytranche.array_stride = sizeof(LWLockPadded); LWLockRegisterTranche(tranche_id, mytranche); That's not a lot of code either, and there's no obvious way to reduce it much by hooking into shm_toc. I thought maybe we needed some cleanup when the dynamic shared memory segment is unmapped, but looks like we really don't. One can do something like LWLockRegisterTranche(tranche_id, NULL) for debugging clarity, but it isn't strictly needed; one can release all lwlocks from the tranche or assert that none are held, but that should really only be a problem if the user does something like LWLockAcquire(lock_in_the_segment); dsm_detach(seg), because error recovery starts by releasing *all* lwlocks. And if the user does it explicitly, I'm kinda OK with that just seg faulting. After all, the user could equally well have done dsm_detach(seg); LWLockAcquire(lock_in_the_segment) and there's no way at all to cross-check for that sort of mistake. I do see one thing about the status quo that does look reasonably annoying: the code expects that tranche IDs are going to stay relatively small. For example, consider a module foobar that uses DSM + LWLocks. It won't do at all for each backend, on first use of the foobar module, to do LWLockNewTrancheId() and then reuse that tranche_id repeatedly for each new DSM - because over a system lifetime of months, tranche IDs could grow into the millions, causing LWLockTrancheArray to get really big (and eventually repalloc will fail). Rather, the programmer needs to ensure that LWLockNewTrancheId() gets called *once per postmaster lifetime*, perhaps by allocating a chunk of permanent shared memory and using that to store the tranche_id that should be used each time an individual backend fires up a DSM. Considering that one of the goals of dynamic shared memory is to allow modules to be loaded after postmaster startup and still be able to do useful stuff, that's kind of obnoxious. I don't have a good idea what to do about it, though; making LWLockTrancheArray anything other than a flat array looks likely to slow down --enable-dtrace builds unacceptably. Bottom line, I guess, is that I don't currently have any real idea how to make this any better than it already is. Maybe that will become more clear as this facility (hopefully) acquires some users. -- 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] GiST support for inet datatypes
On Thu, Feb 6, 2014 at 12:14 PM, Emre Hasegeli e...@hasegeli.com wrote: I have misread the name, rename was not necessary. I removed the DEFAULT keywords for the inet and the cidr operator classes from btree_gist--1.0.sql on the inet-gist patch. Generally, modifying already-release .sql files for extensions is a no-no... -- 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] Changeset Extraction v7.5
On 7 February 2014 20:58, Thom Brown t...@linux.com wrote: On 7 February 2014 19:35, Andres Freund and...@2ndquadrant.com wrote: 0004: wal_decoding: Documentation for replication slots and changeset extraction The usage of pg_create_decoding_replication_slot does show the (1 row) line. I mean doesn't show of course. :) -- Thom -- 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] Changeset Extraction v7.5
On February 7, 2014 9:58:14 PM CET, Thom Brown t...@linux.com wrote:
On 7 February 2014 19:35, Andres Freund and...@2ndquadrant.com wrote:
0004: wal_decoding: Documentation for replication slots and changeset
extraction
The usage of pg_create_decoding_replication_slot does show the (1
row) line.
The output of SELECT * FROM pg_replication_slots; is out-of-date.
There appears to be a column named slot_name and slottype. Could
one of these have or not have the underscore for consistency?
The example also shows output from pg_decoding_slot_get_changes after
inserting 2 rows, but when I run the same example, there are no rows
returned:
# BEGIN;
BEGIN
*# INSERT INTO data(data) VALUES('1');
INSERT 0 1
*# INSERT INTO data(data) VALUES('1');
INSERT 0 1
*# COMMIT;
COMMIT
# SELECT * FROM pg_decoding_slot_get_changes('regression_slot', 'now',
'include-xids', '0');
location | xid | data
--+-+--
(0 rows)
I inserted a single row outside of a transaction, and got the expected
output. Then I ran the above again, and got an output, but an
unexpected one:
SELECT * FROM pg_decoding_slot_get_changes('regression_slot', 'now',
'include-xids', '0');
location | xid | data
---+-+---
0/16C8B90 | 769 | BEGIN
0/16C8D50 | 769 | table data: INSERT: id[int4]:3 data[text]:1
0/16C8D50 | 769 | COMMIT
(3 rows)
And running the transaction with inserts again, there's no output from
that same function command. I always get an output from isolated
INSERT statements. I should point out that in my .psqlrc file I have
\set ON_ERROR_ROLLBACK. If I use psql -X, this symptom no longer
occurs, so I think the automatic savepoints are interfering, and the
effect appears to be inconsistent.
More complete answer later, but any chance you're using synchronous commit =
off?
Thanks for looking,
Andres
--
Please excuse brevity and formatting - I am writing this on my mobile phone.
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] Release schedule for 9.3.3?
Greg Stark st...@mit.edu writes: On Thu, Feb 6, 2014 at 10:55 PM, Sean Chittenden s...@chittenden.org wrote: Are there any tentative plans for the 9.3.3 release date? 9.3.2 was released in December and it's getting close to the two month mark for another micro release, or at least one seems like one should be right around the corner. Bug fix releases are released when we find bugs, not on a schedule. That said, there were some bugs fixed in the last few weeks including one fairly serious one so I would expect one in not too long. We're trying to get something organized right now, actually. Barring objections from the packagers list, it'll be week after next. 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] Changeset Extraction v7.5
On 7 February 2014 21:04, Andres Freund and...@2ndquadrant.com wrote:
On February 7, 2014 9:58:14 PM CET, Thom Brown t...@linux.com wrote:
On 7 February 2014 19:35, Andres Freund and...@2ndquadrant.com wrote:
0004: wal_decoding: Documentation for replication slots and changeset
extraction
The usage of pg_create_decoding_replication_slot does show the (1
row) line.
The output of SELECT * FROM pg_replication_slots; is out-of-date.
There appears to be a column named slot_name and slottype. Could
one of these have or not have the underscore for consistency?
The example also shows output from pg_decoding_slot_get_changes after
inserting 2 rows, but when I run the same example, there are no rows
returned:
# BEGIN;
BEGIN
*# INSERT INTO data(data) VALUES('1');
INSERT 0 1
*# INSERT INTO data(data) VALUES('1');
INSERT 0 1
*# COMMIT;
COMMIT
# SELECT * FROM pg_decoding_slot_get_changes('regression_slot', 'now',
'include-xids', '0');
location | xid | data
--+-+--
(0 rows)
I inserted a single row outside of a transaction, and got the expected
output. Then I ran the above again, and got an output, but an
unexpected one:
SELECT * FROM pg_decoding_slot_get_changes('regression_slot', 'now',
'include-xids', '0');
location | xid | data
---+-+---
0/16C8B90 | 769 | BEGIN
0/16C8D50 | 769 | table data: INSERT: id[int4]:3 data[text]:1
0/16C8D50 | 769 | COMMIT
(3 rows)
And running the transaction with inserts again, there's no output from
that same function command. I always get an output from isolated
INSERT statements. I should point out that in my .psqlrc file I have
\set ON_ERROR_ROLLBACK. If I use psql -X, this symptom no longer
occurs, so I think the automatic savepoints are interfering, and the
effect appears to be inconsistent.
More complete answer later, but any chance you're using synchronous commit =
off?
No:
# show synchronous_commit ;
synchronous_commit
on
(1 row)
My custom config is:
wal_level = 'logical'
max_replication_slots = '1'
shared_buffers = 3900MB
temp_buffers = 16MB
work_mem = 16MB
maintenance_work_mem = 256MB
checkpoint_segments = 32
random_page_cost = 1.1
effective_cache_size = 12GB
logging_collector = on
log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d,client=%h '
--
Thom
--
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] Changeset Extraction v7.5
On 7 February 2014 19:35, Andres Freund and...@2ndquadrant.com wrote:
0004: wal_decoding: Documentation for replication slots and changeset
extraction
The usage of pg_create_decoding_replication_slot does show the (1 row) line.
The output of SELECT * FROM pg_replication_slots; is out-of-date.
There appears to be a column named slot_name and slottype. Could
one of these have or not have the underscore for consistency?
The example also shows output from pg_decoding_slot_get_changes after
inserting 2 rows, but when I run the same example, there are no rows
returned:
# BEGIN;
BEGIN
*# INSERT INTO data(data) VALUES('1');
INSERT 0 1
*# INSERT INTO data(data) VALUES('1');
INSERT 0 1
*# COMMIT;
COMMIT
# SELECT * FROM pg_decoding_slot_get_changes('regression_slot', 'now',
'include-xids', '0');
location | xid | data
--+-+--
(0 rows)
I inserted a single row outside of a transaction, and got the expected
output. Then I ran the above again, and got an output, but an
unexpected one:
SELECT * FROM pg_decoding_slot_get_changes('regression_slot', 'now',
'include-xids', '0');
location | xid | data
---+-+---
0/16C8B90 | 769 | BEGIN
0/16C8D50 | 769 | table data: INSERT: id[int4]:3 data[text]:1
0/16C8D50 | 769 | COMMIT
(3 rows)
And running the transaction with inserts again, there's no output from
that same function command. I always get an output from isolated
INSERT statements. I should point out that in my .psqlrc file I have
\set ON_ERROR_ROLLBACK. If I use psql -X, this symptom no longer
occurs, so I think the automatic savepoints are interfering, and the
effect appears to be inconsistent.
--
Thom
--
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] Changeset Extraction v7.5
On Fri, February 7, 2014 22:09, Thom Brown wrote:
The example also shows output from pg_decoding_slot_get_changes after
inserting 2 rows, but when I run the same example, there are no rows
FWIW, works for me:
testdb=# SELECT * FROM pg_decoding_slot_get_changes('regression_slot', 'now',
'include-xids', '0');
location | xid | data
--+-+--
(0 rows)
testdb=# BEGIN; INSERT INTO data(data) VALUES('1'); INSERT INTO data(data)
VALUES('1'); COMMIT;
testdb=# SELECT * FROM pg_decoding_slot_get_changes('regression_slot', 'now',
'include-xids', '0');
location | xid | data
---+--+
0/2B81ED0 | 1973 | BEGIN
0/2B823A8 | 1973 | table data: INSERT: id[int4]:14 data[text]:1
0/2B823A8 | 1973 | table data: INSERT: id[int4]:15 data[text]:1
0/2B823A8 | 1973 | COMMIT
(4 rows)
testdb=# SELECT * FROM pg_decoding_slot_get_changes('regression_slot', 'now',
'include-xids', '0');
location | xid | data
--+-+--
(0 rows)
( output of SELECT * FROM pg_replication_slots; is, indeed, out-of-date.)
--
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] Minor performance improvement in transition to external sort
On 06/02/14 22:12, Jeremy Harris wrote: Did you try sorting already-sorted, reverse sorted, or pipe-organ shaped data sets? Summary (low numbers better): Random ints: 83% compares, level on time. Sorted ints: level compares, 70% time. Reverse-sorted ints: 10% compares, 15% time (!) Constant ints: 200% compares, 360% time(ouch, and not O(n)) Pipe-organ ints: 80% compares, 107% time Random text: 83% compares, 106% time -- Cheers, Jeremy siftdown_performance.ods Description: application/vnd.oasis.opendocument.spreadsheet -- 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] Changeset Extraction v7.5
On 7 February 2014 21:28, Erik Rijkers e...@xs4all.nl wrote: On Fri, February 7, 2014 22:09, Thom Brown wrote: The example also shows output from pg_decoding_slot_get_changes after inserting 2 rows, but when I run the same example, there are no rows FWIW, works for me: Can you confirm you're running it with ON_ERROR_ROLLBACK set? -- Thom -- 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] Changeset Extraction v7.5
On Fri, February 7, 2014 22:29, Thom Brown wrote: On 7 February 2014 21:28, Erik Rijkers e...@xs4all.nl wrote: On Fri, February 7, 2014 22:09, Thom Brown wrote: The example also shows output from pg_decoding_slot_get_changes after inserting 2 rows, but when I run the same example, there are no rows FWIW, works for me: Can you confirm you're running it with ON_ERROR_ROLLBACK set? Ah, no, I missed that. You're right: with that, behaviour is the same here as you described. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Review of RLS on inheritance schema HL7 RIM (was Re: [HACKERS] Row-security on updatable s.b. views)
On 06/02/14 15:19, Craig Ringer wrote: Thanks to the simplified requirements for inheritance, this turns out to be fairly easy. There's a version rewritten to use the rewriter in the tag: rls-9.4-upd-sb-views-v6 on https://github.com/ringerc/postgres.git Hi Craig, list, This is review of the current RLS patch on a database schema that uses inheritance in the 'classical' sense (not partitioning). The review was done on rls-9.4-upd-sb-views-v4 and hence all comments are about that version. Comparing output of the minisql script between v4 and v6 gives differences, as v6 seems to be WIP. Our goal is to implement the HL7 Reference Information Model (RIM) in PostgreSQL. A fine-grained access control on the tables would have a practical use in the context of RIM. So, we have made some preliminary tests of the Row Security patch for such a specific data model. For the purpose of reviewing RLS, we have restricted the full RIM to just a few tables which we call the mini-RIM. It is important to observe that the RIM uses inheritance, and we use PostgreSQL inheritance to implement the RIM's inheritance. More details about the RIM are presented below. In the attached SQL script we list a mini-RIM, along with examples of RLS enforcement. General comments about RLS applied on (a minimalistic version of) the RIM can be summarized as follows: 1. The current RLS implementation works for use cases where confidentiality attributes are specified in the inheritance root relation. Since security labelling in the RIM is done on confidentialitycodes that are present in the inheritance roots (e.g., Role and Act), the current RLS works for the RIM. 2. Infinite recursion is well captured in case of recursive restrictions to tables. 3. RLS syntax is readable and easy to use. 4. Documentation needs work. 5. Subqueries in RLS quals can be pulled up, so opens the ability for fast processing. Overall from a users perspective the patch gave a solid impression. regards, Yeb Havinga Albana Gaba Henk-Jan Meijer Portavita B.V. The Netherlands BACKGROUND ON THE REFERENCE INFORMATION MODEL: To understand how The HL7 Reference Information Model (RIM) uses PostgreSQL inheritance, it is helpful to understand the meaning of the content of the parent and child tables. This section describes the background of the RIM, and describes a few classes of the “Act” hierarchy. The HL7 RIM[1] is not just yet another information model. It is a mature, standard information model that has been used and refined over the course of many years [2][3]. Its purpose is to capture detailed information for medical records. Pivotal in the RIM is its action-based modelling, based on ideas that can be traced back to the American philosopher C.S. Peirce. A direct line from Peirce’s Logic of Relatives to the foundations of relational databases has been introduced in [4]. Versions of the RIM are now being released as an ANSI standard. An illustration of the RIM is available at http://www.healthintersections.com.au/wp-content/uploads/2011/05/RIM.png The RIM is a set of UML classes, each containing one or more attributes. The classes are an abstraction of subjects or other concepts that are relevant within the healthcare domain. To avoid a model with a huge number of classes, the RIM defines six core classes whereas the vast majority of the classes are defined as specializations based on the core ones. The specialization classes inherit all the properties of the generalization classes while adding specific attributes of its own. To make matters concrete, let us look at Act class. “Act”: Looking at the right hand side of the RIM illustration referenced above, we can see the class “Act” and its specializations, and this is the focal point for the RIM’s action based modeling. Description from the standard: “Acts are the pivot of the RIM: domain information and process records are represented primarily in Acts. Any profession or business, including healthcare, is primarily constituted of intentional and occasionally non-intentional actions, performed and recorded by responsible actors. An Act-instance is a record of such an action.” Notable attributes of “Act” are: “id” - A unique identifier for the Act. Each Act is associated with a unique id. All specialization of Act inherit this id. This means that if there is, for example, an instance of Observation with id 5, there exist no other acts with id 5. In fact, since technically in the RIM all identifiers stem from a single infrastructure root, the identifiers are globally unique: there exists a single object with id 5. This single object is an instance of Observation, and since Observation is a specialization of Act, it is also an instance of Act. “classCode” – The major class of Acts to which an Act-instance belongs. The allowed codes in classCode form a hierarchical code system. In the 2011 RIM, there are 124 different class codes. This
Re: [HACKERS] Inconsistency between pg_stat_activity and log_duration
The query is piggy backed on the same connection to PostgreSQL opend by user (pgpool-II cannot issue sync because it closes the transaction, which in turn closes user's unnamed portal). This argument (and usage) seems pretty broken. If you don't issue sync then how do you know you've gotten all of the command's output? If you're issuing a flush instead, maybe we could consider whether it's reasonable to do an extra pgstat_report_activity() upon receipt of a flush message. But -1 for putting it into the normal control flow. Pgpool-II issues flush of course. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- 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] Changeset Extraction v7.5
On 2014-02-07 20:58:14 +, Thom Brown wrote: On 7 February 2014 19:35, Andres Freund and...@2ndquadrant.com wrote: 0004: wal_decoding: Documentation for replication slots and changeset extraction The usage of pg_create_decoding_replication_slot does show the (1 row) line. The output of SELECT * FROM pg_replication_slots; is out-of-date. Thanks, refreshed. There appears to be a column named slot_name and slottype. Could one of these have or not have the underscore for consistency? That's luckily already fixed... The example also shows output from pg_decoding_slot_get_changes after inserting 2 rows, but when I run the same example, there are no rows returned: And running the transaction with inserts again, there's no output from that same function command. I always get an output from isolated INSERT statements. I should point out that in my .psqlrc file I have \set ON_ERROR_ROLLBACK. If I use psql -X, this symptom no longer occurs, so I think the automatic savepoints are interfering, and the effect appears to be inconsistent. Thanks, that's a bug indeed. I have experimentally fixed the bug, not sure whether I like the fix yet, or not. I've already fixed two issues caused by the rebase onto 858ec11858a914d4c380971985709b6d6b7dd6fc. Is pushing to git sufficient for you, or shall I rebase and resend the series? Thanks! 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] Changeset Extraction v7.5
On 7 February 2014 23:43, Andres Freund and...@2ndquadrant.com wrote: On 2014-02-07 20:58:14 +, Thom Brown wrote: On 7 February 2014 19:35, Andres Freund and...@2ndquadrant.com wrote: 0004: wal_decoding: Documentation for replication slots and changeset extraction The usage of pg_create_decoding_replication_slot does show the (1 row) line. The output of SELECT * FROM pg_replication_slots; is out-of-date. Thanks, refreshed. There appears to be a column named slot_name and slottype. Could one of these have or not have the underscore for consistency? That's luckily already fixed... The example also shows output from pg_decoding_slot_get_changes after inserting 2 rows, but when I run the same example, there are no rows returned: And running the transaction with inserts again, there's no output from that same function command. I always get an output from isolated INSERT statements. I should point out that in my .psqlrc file I have \set ON_ERROR_ROLLBACK. If I use psql -X, this symptom no longer occurs, so I think the automatic savepoints are interfering, and the effect appears to be inconsistent. Thanks, that's a bug indeed. I have experimentally fixed the bug, not sure whether I like the fix yet, or not. I've already fixed two issues caused by the rebase onto 858ec11858a914d4c380971985709b6d6b7dd6fc. Is pushing to git sufficient for you, or shall I rebase and resend the series? Sure, push it to git, I'll add your remote repo and checkout that branch. -- Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] commit fest 2014-01 week 3 report
Last week: Status Summary. Needs Review: 49, Waiting on Author: 18, Ready for Committer: 9, Committed: 33, Returned with Feedback: 3, Rejected: 1. Total: 113. This week: Status Summary. Needs Review: 47, Waiting on Author: 15, Ready for Committer: 12, Committed: 37, Returned with Feedback: 3, Rejected: 2. Total: 116. As predicted, progress has slowed down. On the positive side, most patches now have reviewers. Those who don't probably won't until a committer or other expert has time to take on the patch. Assuming a 2-month commit fest, we're still not at the half-way point, so there is still time for discussion etc. At the half-way point we should probably start wrapping things up. -- 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] New option for pg_basebackup, to specify a different directory for pg_xlog
On 1/29/14, 7:37 PM, Haribabu Kommi wrote: On Tue, Jan 28, 2014 at 1:17 PM, Peter Eisentraut wrote: On 11/30/13, 6:59 AM, Haribabu kommi wrote: To detect provided data and xlog directories are same or not, I reused the Existing make_absolute_path() code as follows. I note that initdb does not detect whether the data and xlog directories are the same. I think there is no point in addressing this only in pg_basebackup. If we want to forbid it, it should be done in initdb foremost. Thanks for pointing it. if the following approach is fine for identifying the identical directories then I will do the same for initdb also. I wouldn't bother. It's a lot of work for little benefit. Any mistake a user would make can easily be fixed. I'm not sure it's worth the trouble, but if I were to do it, I'd just stat() the two directories and compare their inodes. That seems much easier and more robust than comparing path strings stat() is having problems in windows, because of that reason the patch is written to identify the directories with string comparison. If stat() is having problems on Windows, then those problems would need to be addressed. I don't think a string comparison is going to be reliable. It can easily be tricked by using multiple slashes for example, or various kinds of links or bind mounts. You'd need to put in an awful lot of work, and it still wouldn't work all the time. -- 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] Relocation of tablespaces in pg_basebackup
On 1/29/14, 12:07 PM, Steeve Lennmark wrote: We need to think about how to handle this on platforms without symlinks. I don't like just printing an error message and moving on. It should be either pass or fail or an option to choose between them. I hope someone with experience with those kind of systems can come up with suggestions on how to solve that. I only run postgres on Linux. I would still love some input on this. Currently, pg_basebackup aborts if it has to create a symlink on a platform that doesn't support it. So your code that updates the symlinks would never come into play anyway. I'd just update that code with a shouldn't get here comment and add an exit(1). -- 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] Move unused buffers to freelist
Bump. I’m interested in many of the issues that were discussed in this thread. Was this patch ever wrapped up (I can’t find it in any CF), or did this thread die off? —Jason On Aug 6, 2013, at 12:18 AM, Amit Kapila amit.kap...@huawei.com wrote: On Friday, June 28, 2013 6:20 PM Robert Haas wrote: On Fri, Jun 28, 2013 at 12:52 AM, Amit Kapila amit.kap...@huawei.com wrote: Currently it wakes up based on bgwriterdelay config parameter which is by default 200ms, so you means we should think of waking up bgwriter based on allocations and number of elements left in freelist? I think that's what Andres and I are proposing, yes. As per my understanding Summarization of points raised by you and Andres which this patch should address to have a bigger win: 1. Bgwriter needs to be improved so that it can help in reducing usage count and finding next victim buffer (run the clock sweep and add buffers to the free list). Check. I think one way to handle it is that while moving buffers to freelist, if we find that there are not enough buffers (= high watermark) which have zero usage count, then move through buffer list and reduce usage count. Now here I think it is important how do we find that how many times we should circulate the buffer list to reduce usage count. Currently I have kept it proportional to number of times it failed to move enough buffers to freelist. 2. SetLatch for bgwriter (wakeup bgwriter) when elements in freelist are less. Check. The way to do this is to keep a variable in shared memory in the same cache line as the spinlock protecting the freelist, and update it when you update the free list. Added a new variable freelistLatch in BufferStrategyControl 3. Split the workdone globallock (Buffreelist) in StrategyGetBuffer (a spinlock for the freelist, and an lwlock for the clock sweep). Check. Added a new variable freelist_lck in BufferStrategyControl which will be used to protect freelist. Still Buffreelist will be used to protect clock sweep part of StrategyGetBuffer. 4. Separate processes for writing dirty buffers and moving buffers to freelist I think this part might be best pushed to a separate patch, although I agree we probably need it. 5. Bgwriter needs to be more aggressive, logic based on which it calculates how many buffers it needs to process needs to be improved. This is basically overlapping with points already made. I suspect we could just get rid of bgwriter_delay, bgwriter_lru_maxpages, and bgwriter_lru_multiplier altogether. The background writer would just have a high and a low watermark. When the number of buffers on the freelist drops below the low watermark, the allocating backend sets the latch and bgwriter wakes up and begins adding buffers to the freelist. When the number of buffers on the free list reaches the high watermark, the background writer goes back to sleep. Some experimentation might be needed to figure out what values are appropriate for those watermarks. In theory this could be a configuration knob, but I suspect it's better to just make the system tune it right automatically. Currently in Patch I have used low watermark as 1/6 and high watermark as 1/3 of NBuffers. Values are hardcoded for now, but I will change to guc's or hash defines. As far as I can think there is no way to find number of buffers on freelist, so I had added one more variable to maintain it. Initially I thought that I could use existing variables firstfreebuffer and lastfreebuffer to calculate it, but it may not be accurate as once the buffers are moved to freelist, these don't give exact count. The main doubt here is what if after traversing all buffers, it didn't find enough buffers to meet high watermark? Currently I just move out of loop to move buffers and just try to reduce usage count as explained in point-1 6. There can be contention around buffer mapping locks, but we can focus on it later 7. cacheline bouncing around the buffer header spinlocks, is there anything we can do to reduce this? I think these are points that we should leave for the future. This is just a WIP patch. I have kept older code in comments. I need to further refine it and collect performance data. I had prepared one script (perf_buff_mgmt.sh) to collect performance data for different shared buffers/scalefactor/number_of_clients Top level points which still needs to be taken care: 1. Choose Optimistically used buffer in StrategyGetBuffer(). Refer Simon's Patch: https://commitfest.postgresql.org/action/patch_view?id=743 2. Don't bump the usage count on every time buffer is pinned. This idea I got when reading archives about improvements in this area. With Regards, Amit Kapila. changed_freelist_mgmt.patchperf_buff_mgmt.sh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:
Re: [HACKERS] Viability of text HISTORY/INSTALL/regression README files (was Re: [COMMITTERS] pgsql: Document a few more regression test hazards.)
On 2/3/14, 8:48 PM, Tom Lane wrote: That's a very fair question. It's a reasonable bet that pretty much nobody actually looks at the text versions of either HISTORY or regress_README anymore. It's conceivable that somebody somewhere makes use of the text version of INSTALL when trying to get PG going on some bare-bones platform ... but really, can't they look it up on the net? How'd they get the PG sources they're installing, anyway? I think having an INSTALL file is good form, and it costs us little to maintain it. The other files could be removed, IMO. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [DOCS] Re: Viability of text HISTORY/INSTALL/regression README files (was Re: [COMMITTERS] pgsql: Document a few more regression test hazards.)
On 2/4/14, 3:28 PM, Robert Haas wrote: Right. I mean, a lot of the links say things like Section 26.2 which obviously makes no sense in a standalone text file. The man pages have the same issue. For example from man postgres: Other possible file layouts are discussed in Section 18.2, File Locations, in the documentation. The same could (probably) be done with the INSTALL 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] Move unused buffers to freelist
On Sat, Feb 8, 2014 at 7:16 AM, Jason Petersen ja...@citusdata.com wrote: Bump. I'm interested in many of the issues that were discussed in this thread. Was this patch ever wrapped up (I can't find it in any CF), or did this thread die off? This and variant of this patch have been discussed multiple times, some of the CF entries are as below: Recent https://commitfest.postgresql.org/action/patch_view?id=1113 Previous https://commitfest.postgresql.org/action/patch_view?id=932 The main thing about this idea is to arrive with tests/scenario's where we can show the benefit of this patch. I didn't get time during 9.4 to work on this again, but might work on it in next version, if you could help with some scenarios/test where this patch can show benefit, it would be really good. 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] Viability of text HISTORY/INSTALL/regression README files (was Re: [COMMITTERS] pgsql: Document a few more regression test hazards.)
Peter Eisentraut pete...@gmx.net writes: On 2/3/14, 8:48 PM, Tom Lane wrote: That's a very fair question. It's a reasonable bet that pretty much nobody actually looks at the text versions of either HISTORY or regress_README anymore. It's conceivable that somebody somewhere makes use of the text version of INSTALL when trying to get PG going on some bare-bones platform ... but really, can't they look it up on the net? How'd they get the PG sources they're installing, anyway? I think having an INSTALL file is good form, and it costs us little to maintain it. The other files could be removed, IMO. That seems like a reasonable compromise to me. The HISTORY file is certainly the worst pain-in-the-rear among these, since it's generated from files that we change constantly, and so we're always tripping over the link restrictions. 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] Viability of text HISTORY/INSTALL/regression README files (was Re: [COMMITTERS] pgsql: Document a few more regression test hazards.)
On 08/02/14 19:05, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: On 2/3/14, 8:48 PM, Tom Lane wrote: That's a very fair question. It's a reasonable bet that pretty much nobody actually looks at the text versions of either HISTORY or regress_README anymore. It's conceivable that somebody somewhere makes use of the text version of INSTALL when trying to get PG going on some bare-bones platform ... but really, can't they look it up on the net? How'd they get the PG sources they're installing, anyway? I think having an INSTALL file is good form, and it costs us little to maintain it. The other files could be removed, IMO. That seems like a reasonable compromise to me. The HISTORY file is certainly the worst pain-in-the-rear among these, since it's generated from files that we change constantly, and so we're always tripping over the link restrictions. regards, tom lane How about adding URL's for the online versions of HISTORY README's (or their rough equivalents - perhaps the online version of the latest 'Appendix E. Release Notes' would be sufficient?) to the INSTALL file? Cheers, Gavin -- 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] Viability of text HISTORY/INSTALL/regression README files (was Re: [COMMITTERS] pgsql: Document a few more regression test hazards.)
Gavin Flower gavinflo...@archidevsys.co.nz writes: How about adding URL's for the online versions of HISTORY README's (or their rough equivalents - perhaps the online version of the latest 'Appendix E. Release Notes' would be sufficient?) to the INSTALL file? Actually, what I had in mind was to replace the dynamically-generated HISTORY and README files with small text files that contain those URL references. If we remove those files from the distribution tarballs altogether, it'd likely break some packagers' recipes (I know for sure it'd break the Red Hat RPM specs, for instance). But packaging should still work if they're there but smaller. 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] Retain dynamic shared memory segments for postmaster lifetime
On Thu, Feb 6, 2014 at 3:42 PM, Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp wrote: Hello, I've understood how this works and seems working as expected. The orphan section handles on postmaster have become a matter of documentation. I had explained this in function header of dsm_keep_segment(). Besides all above, I'd like to see a comment for the win32 code about the 'DuplicateHandle hack', specifically, description that the DuplicateHandle pushes the copy of the section handle to the postmaster so the section can retain for the postmaster lifetime. I had added a new function in dsm_impl.c for platform specific handling and explained about new behaviour in function header. - Global/PostgreSQL.%u is the same literal constant with that occurred in dsm_impl_windows. It should be defined as a constant (or a macro). Changed to hash define. - dms_impl_windows uses errcode_for_dynamic_shared_memory() for ereport and it finally falls down to errcode_for_file_access(). I think it is preferable, maybe Changed as per suggestion. Please find new version of patch attached with this mail containing above changes. Thanks for review. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com dsm_keep_segment_v3.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
