Re: [HACKERS] narwhal and PGDLLIMPORT
On 09/02/2014 00:06, Andrew Dunstan wrote: On 02/08/2014 05:34 PM, Tom Lane wrote: Hiroshi Inoue writes: Though I'm not a MINGW expert at all, I know dllwrap is a deprecated tool and dlltool is almost a deprecated tool. Cygwin port is removing the use of dllwrap and dlltool now. Isn't it better for MINGW port to follow it? Only way to make that happen is to prepare and test a patch ... Yeah. Incidentally, we didn't quite get rid of dlltool for Cygwin. We did get rid of dllwrap. But I agree this is worth trying for Mingw. cheers andrew we should have get rid of dlltool on cygwin. At least it is not used on my build 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] Review: tests for client programs
2014-02-09 4:16 GMT+01:00 Peter Eisentraut : > I posted an updated patch in the original thread. Please see the commit > fest web site for the URL. > > > On Thu, 2014-01-30 at 19:50 +0100, Pavel Stehule wrote: > > > 6. I found only few issues: > > > > > > a) Configure doesn't check a required IRC::Run module > > Clearly, we will need to figure out something about how to require this > module, and possibly others in the future, as we expand the tests. > Having configure check for it is not necessarily the best solution -- > What is configure supposed to do if it can't find it? > there can be option "--with-client-tests" and this option should to require IRC::Run > > We could perhaps use Test::More skip_all to just skip these tests > depending on what modules are available. And add appropriate > documentation. > > > > b) Prepared tests fails when PostgreSQL server was up - should be > > checked and should to raise a valuable error message > > The original patch used a hard-coded port number, which was a mistake. > I have changed this now to use a nonstandard port number that is > different from the compiled-in one, similar to how pg_regress used to do > it. It's still not bullet-proof. Do we need to do more? > you can check before starting test if some Postgres on this port is living or not. We have pg_isready. It can be enough > > > c) I am not sure if infrastructure is enough - for test pg_dump I miss > > a comparation of produced file with some other expected file. This > > objection is not blocker - someone can enhance it (when will write > > tests of pg_dump for example). > > Yes, some more infrastructure will need to be added for pg_dump. But > that's a separate project. I don't see anything where the current setup > would be in the way of that. > > ok regards Pavel
Re: [HACKERS] Review: tests for client programs
I posted an updated patch in the original thread. Please see the commit fest web site for the URL. On Thu, 2014-01-30 at 19:50 +0100, Pavel Stehule wrote: > 6. I found only few issues: > > > a) Configure doesn't check a required IRC::Run module Clearly, we will need to figure out something about how to require this module, and possibly others in the future, as we expand the tests. Having configure check for it is not necessarily the best solution -- What is configure supposed to do if it can't find it? We could perhaps use Test::More skip_all to just skip these tests depending on what modules are available. And add appropriate documentation. > > b) Prepared tests fails when PostgreSQL server was up - should be > checked and should to raise a valuable error message The original patch used a hard-coded port number, which was a mistake. I have changed this now to use a nonstandard port number that is different from the compiled-in one, similar to how pg_regress used to do it. It's still not bullet-proof. Do we need to do more? > > c) I am not sure if infrastructure is enough - for test pg_dump I miss > a comparation of produced file with some other expected file. This > objection is not blocker - someone can enhance it (when will write > tests of pg_dump for example). Yes, some more infrastructure will need to be added for pg_dump. But that's a separate project. I don't see anything where the current setup would be in the way of that. -- 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] tests for client programs
On Wed, 2014-01-15 at 20:56 +0100, Erik Rijkers wrote:
> 2 tests stumbled:
>
> 1. One test ( pg_ctl/t/001_start_stop.pl ) failed because I had PGDATA set.
> I unset all PG+ vars after that. No a big
> problem but nonetheless it might be better if the test suite removes
> /controls the variables before running.
>
> 2. The pg_isready test failed command_fails() ('fails with no server
> running') because it defaults to the compiled-in
> server-port (and that server was running). I added the test-designated port
> (65432, as defined in TestLib.pm). This
> simple change is in the attached patch.
>
>
> With these two changes the whole test suite passed.
Fixed those two things by unsetting environment variables and picking a
different port.
New patch attached.
>From 5af8f6849506b993ab7cb3fc8bb167d2f93424fc Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Sat, 8 Feb 2014 22:05:09 -0500
Subject: [PATCH v2] Add TAP tests for client programs
---
GNUmakefile.in | 4 +-
configure | 47 +++
configure.in | 5 +
src/Makefile.global.in | 19 ++-
src/bin/initdb/.gitignore | 2 +
src/bin/initdb/Makefile| 7 +
src/bin/initdb/t/001_initdb.pl | 37 +
src/bin/pg_basebackup/.gitignore | 2 +
src/bin/pg_basebackup/Makefile | 6 +
src/bin/pg_basebackup/t/010_pg_basebackup.pl | 67 ++
src/bin/pg_basebackup/t/020_pg_receivexlog.pl | 8 ++
src/bin/pg_config/.gitignore | 1 +
src/bin/pg_config/Makefile | 6 +
src/bin/pg_config/t/001_pg_config.pl | 12 ++
src/bin/pg_controldata/.gitignore | 1 +
src/bin/pg_controldata/Makefile| 6 +
src/bin/pg_controldata/t/001_pg_controldata.pl | 14 ++
src/bin/pg_ctl/.gitignore | 1 +
src/bin/pg_ctl/Makefile| 6 +
src/bin/pg_ctl/t/001_start_stop.pl | 21 +++
src/bin/pg_ctl/t/002_status.pl | 14 ++
src/bin/scripts/.gitignore | 2 +
src/bin/scripts/Makefile | 7 +
src/bin/scripts/t/010_clusterdb.pl | 18 +++
src/bin/scripts/t/011_clusterdb_all.pl | 9 ++
src/bin/scripts/t/020_createdb.pl | 16 +++
src/bin/scripts/t/030_createlang.pl| 18 +++
src/bin/scripts/t/040_createuser.pl| 26
src/bin/scripts/t/050_dropdb.pl| 16 +++
src/bin/scripts/t/060_droplang.pl | 15 +++
src/bin/scripts/t/070_dropuser.pl | 16 +++
src/bin/scripts/t/080_pg_isready.pl| 15 +++
src/bin/scripts/t/090_reindexdb.pl | 21 +++
src/bin/scripts/t/091_reindexdb_all.pl | 11 ++
src/bin/scripts/t/100_vacuumdb.pl | 17 +++
src/bin/scripts/t/101_vacuumdb_all.pl | 9 ++
src/test/perl/TestLib.pm | 178 +
37 files changed, 677 insertions(+), 3 deletions(-)
create mode 100644 src/bin/initdb/t/001_initdb.pl
create mode 100644 src/bin/pg_basebackup/t/010_pg_basebackup.pl
create mode 100644 src/bin/pg_basebackup/t/020_pg_receivexlog.pl
create mode 100644 src/bin/pg_config/t/001_pg_config.pl
create mode 100644 src/bin/pg_controldata/t/001_pg_controldata.pl
create mode 100644 src/bin/pg_ctl/t/001_start_stop.pl
create mode 100644 src/bin/pg_ctl/t/002_status.pl
create mode 100644 src/bin/scripts/t/010_clusterdb.pl
create mode 100644 src/bin/scripts/t/011_clusterdb_all.pl
create mode 100644 src/bin/scripts/t/020_createdb.pl
create mode 100644 src/bin/scripts/t/030_createlang.pl
create mode 100644 src/bin/scripts/t/040_createuser.pl
create mode 100644 src/bin/scripts/t/050_dropdb.pl
create mode 100644 src/bin/scripts/t/060_droplang.pl
create mode 100644 src/bin/scripts/t/070_dropuser.pl
create mode 100644 src/bin/scripts/t/080_pg_isready.pl
create mode 100644 src/bin/scripts/t/090_reindexdb.pl
create mode 100644 src/bin/scripts/t/091_reindexdb_all.pl
create mode 100644 src/bin/scripts/t/100_vacuumdb.pl
create mode 100644 src/bin/scripts/t/101_vacuumdb_all.pl
create mode 100644 src/test/perl/TestLib.pm
diff --git a/GNUmakefile.in b/GNUmakefile.in
index 40ab280..3910abb 100644
--- a/GNUmakefile.in
+++ b/GNUmakefile.in
@@ -66,9 +66,9 @@ check check-tests: all
check check-tests installcheck installcheck-parallel installcheck-tests:
$(MAKE) -C src/test/regress $@
-$(call recurse,check-world,src/test src/pl src/interfaces/ecpg contrib,check)
+$(call recurse,check-world,src/test src/pl src/interfaces/ecpg contrib src/bin,check)
-$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg contrib,installcheck)
+$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg contrib src/bin,installcheck)
GNUmakefile:
Re: [HACKERS] clang's -Wmissing-variable-declarations shows some shoddy programming
On Fri, 2013-12-20 at 00:09 +0100, Andres Freund wrote: > The attached patch fixes some of the easiest cases, where either an > include was missing o a variable should have been static. committed -- 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] plpgsql.warn_shadow
On 1/27/14, 12:04 PM, Simon Riggs wrote: Florian's point was well made and we must come up with something that allows warning/errors at compile time and once accepted, nothing at run time. I've been thinking about this, and I'm not sure I like this idea all that much. For compile-time warnings this would probably be the ideal behaviour, but if we were to add any run-time warnings (e.g. consistent_into) I'm not sure how I would use such a feature. Say I run my test suite with all warnings enabled, and now I want to know that it didn't produce any warnings. How would I do that? I guess I could grep the log for warning messages, but then I'd have to maintain a list of all warnings somewhere, which seems quite ugly. A special SQLSTATE for PL/PgSQL warnings doesn't seem that much better. But maybe I'm overthinking this and we'd only ever have one runtime warning (or maybe none at all, even) and this would not be an issue in practice. Regards, Marko Tiikkaja -- 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 9 February 2014 01:06, Andres Freund wrote:
> On 2014-02-09 00:49:31 +, Thom Brown wrote:
>> # ALTER TABLE test ADD COLUMN a decimal DEFAULT 2.22;
>> ALTER TABLE
>>
>> # ALTER TABLE test ADD COLUMN b json DEFAULT '{"a":[1,2,3],"b":[4,5,6]}';
>> ALTER TABLE
>>
>> The output generated by those last 2 statements is:
>>
>> BEGIN 891
>> table "pg_temp_16552": INSERT: id[int4]:1 val[int4]:1 a[numeric]:2.22
>> table "pg_temp_16552": INSERT: id[int4]:2 val[int4]:2 a[numeric]:2.22
>> table "pg_temp_16552": INSERT: id[int4]:3 val[int4]:3 a[numeric]:2.22
>> COMMIT 891
>> BEGIN 892
>> table "pg_temp_16552": INSERT: id[int4]:1 val[int4]:1 a[numeric]:2.22
>> b[json]:{"a":[1,2,3],"b":[4,5,6]}
>> table "pg_temp_16552": INSERT: id[int4]:2 val[int4]:2 a[numeric]:2.22
>> b[json]:{"a":[1,2,3],"b":[4,5,6]}
>> table "pg_temp_16552": INSERT: id[int4]:3 val[int4]:3 a[numeric]:2.22
>> b[json]:{"a":[1,2,3],"b":[4,5,6]}
>> COMMIT 892
>>
>> This is showing inserts into the temp table as part of the operation.
>> Is that sufficient?
>
> I think it's a good thing for now. We don't have support for DDL
> replication so it's not yet that interesting, but having the new values
> allows to safely handle things like DEFAULTs that produce
> nondeterministic data.
> What do you think?
Okay, I'm just checking. If it's expected behaviour to you, it's good
enough for me.
--
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 2014-02-09 00:49:31 +, Thom Brown wrote:
> # ALTER TABLE test ADD COLUMN a decimal DEFAULT 2.22;
> ALTER TABLE
>
> # ALTER TABLE test ADD COLUMN b json DEFAULT '{"a":[1,2,3],"b":[4,5,6]}';
> ALTER TABLE
>
> The output generated by those last 2 statements is:
>
> BEGIN 891
> table "pg_temp_16552": INSERT: id[int4]:1 val[int4]:1 a[numeric]:2.22
> table "pg_temp_16552": INSERT: id[int4]:2 val[int4]:2 a[numeric]:2.22
> table "pg_temp_16552": INSERT: id[int4]:3 val[int4]:3 a[numeric]:2.22
> COMMIT 891
> BEGIN 892
> table "pg_temp_16552": INSERT: id[int4]:1 val[int4]:1 a[numeric]:2.22
> b[json]:{"a":[1,2,3],"b":[4,5,6]}
> table "pg_temp_16552": INSERT: id[int4]:2 val[int4]:2 a[numeric]:2.22
> b[json]:{"a":[1,2,3],"b":[4,5,6]}
> table "pg_temp_16552": INSERT: id[int4]:3 val[int4]:3 a[numeric]:2.22
> b[json]:{"a":[1,2,3],"b":[4,5,6]}
> COMMIT 892
>
> This is showing inserts into the temp table as part of the operation.
> Is that sufficient?
I think it's a good thing for now. We don't have support for DDL
replication so it's not yet that interesting, but having the new values
allows to safely handle things like DEFAULTs that produce
nondeterministic data.
What do you think?
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] Changeset Extraction v7.5
On 8 February 2014 23:08, Andres Freund wrote:
> On 2014-02-08 22:58:35 +, Thom Brown wrote:
>> Another question: in order for logical decoding/replication to be
>> useful, presumably one would need a primary key on every table? It's
>> just I haven't seen this mentioned on the changeset extraction page in
>> the docs.
>
> Hm, that's a good point. 07cacba983ef79be4a84fcd0e0ca3b5fcb85dd65 added
> configurability for that, but there at least should be a link to
> http://www.postgresql.org/docs/devel/static/sql-altertable.html with
> some additional words.
# CREATE TABLE test (id serial primary key, val int);
CREATE TABLE
# INSERT INTO test (val) SELECT generate_series(1,3);
INSERT 0 3
# ALTER TABLE test ADD COLUMN a decimal DEFAULT 2.22;
ALTER TABLE
# ALTER TABLE test ADD COLUMN b json DEFAULT '{"a":[1,2,3],"b":[4,5,6]}';
ALTER TABLE
The output generated by those last 2 statements is:
BEGIN 891
table "pg_temp_16552": INSERT: id[int4]:1 val[int4]:1 a[numeric]:2.22
table "pg_temp_16552": INSERT: id[int4]:2 val[int4]:2 a[numeric]:2.22
table "pg_temp_16552": INSERT: id[int4]:3 val[int4]:3 a[numeric]:2.22
COMMIT 891
BEGIN 892
table "pg_temp_16552": INSERT: id[int4]:1 val[int4]:1 a[numeric]:2.22
b[json]:{"a":[1,2,3],"b":[4,5,6]}
table "pg_temp_16552": INSERT: id[int4]:2 val[int4]:2 a[numeric]:2.22
b[json]:{"a":[1,2,3],"b":[4,5,6]}
table "pg_temp_16552": INSERT: id[int4]:3 val[int4]:3 a[numeric]:2.22
b[json]:{"a":[1,2,3],"b":[4,5,6]}
COMMIT 892
This is showing inserts into the temp table as part of the operation.
Is that sufficient?
--
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] narwhal and PGDLLIMPORT
Andres Freund writes: > I think that there's a small problem with your patch, namely that you > made the explicit PGDLLEXPORT definition empty, but that's currently > used in fmgr.h for the function and module magic, I think we actually > need those to be __declspec(dllexport)ed when building an extension, > right? The comment next to that says that we're relying on --export-all. If PGDLLEXPORT were being used for other contrib-module functions, you would have a point, but AFAICS no one ever bothered. (If this patch works, we could go around and clean up stuff like that, but that's a bit premature at this point...) 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 2014-02-08 22:58:35 +, Thom Brown wrote: > Another question: in order for logical decoding/replication to be > useful, presumably one would need a primary key on every table? It's > just I haven't seen this mentioned on the changeset extraction page in > the docs. Hm, that's a good point. 07cacba983ef79be4a84fcd0e0ca3b5fcb85dd65 added configurability for that, but there at least should be a link to http://www.postgresql.org/docs/devel/static/sql-altertable.html with some additional words. 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] narwhal and PGDLLIMPORT
On 02/08/2014 05:34 PM, Tom Lane wrote: Hiroshi Inoue writes: Though I'm not a MINGW expert at all, I know dllwrap is a deprecated tool and dlltool is almost a deprecated tool. Cygwin port is removing the use of dllwrap and dlltool now. Isn't it better for MINGW port to follow it? Only way to make that happen is to prepare and test a patch ... Yeah. Incidentally, we didn't quite get rid of dlltool for Cygwin. We did get rid of dllwrap. But I agree this is worth trying for Mingw. 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] narwhal and PGDLLIMPORT
On 2014-02-08 17:34:32 -0500, Tom Lane wrote: > Hiroshi Inoue writes: > > Though I'm not a MINGW expert at all, I know dllwrap is a deprecated > > tool and dlltool is almost a deprecated tool. Cygwin port is removing > > the use of dllwrap and dlltool now. Isn't it better for MINGW port to > > follow it? > > Only way to make that happen is to prepare and test a patch ... > > In the meantime, here's a short patch trying the "#define extern" approach. > Anyone want to try this on a Windows machine or two? Or we could just > commit it in HEAD for long enough to see what the buildfarm says. I'd be fine with committing it to see what happens. Any chance you (or better somebody else!) could rename BUILDING_DLL while at it? The name is really misleading, since it's set when building the core postgres. I think that there's a small problem with your patch, namely that you made the explicit PGDLLEXPORT definition empty, but that's currently used in fmgr.h for the function and module magic, I think we actually need those to be __declspec(dllexport)ed when building an extension, right? 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] Changeset Extraction v7.5
On 8 February 2014 22:47, Andres Freund wrote:
> Hi Thom,
>
> On 2014-02-08 22:26:59 +, Thom Brown wrote:
>> Got a question about ranges and arrays usage with timestamps... why
>> are quotes added to these?
>>
>> timestamptz (no quotes with input or output):
>> table "a": INSERT: moo[timestamptz]:2014-02-08 22:09:33+00
>>
>> tstzrange (no quotes with input, but quotes with output):
>> table "b": INSERT: moo[tstzrange]:["2014-02-08
>> 13:45:22+00","2014-02-08 14:45:42+00")
>>
>> timestamptz[] (no quotes with input, but quotes with output):
>> table "c": INSERT: moo[_timestamptz]:{"2010-01-01
>> 13:45:22+00","2010-01-03 14:45:42+00"}
>>
>> tstzrange[] (one set of quotes with input, two sets of quotes with
>> output, one set of which are escaped):
>> table "d": INSERT: moo[_tstzrange]:{"(\"2014-02-08
>> 13:45:22+00\",\"2014-02-08 13:45:42+00\"]","[\"2014-02-07
>> 10:12:19+00\",\"2014-02-07 13:51:16+00\"]"}
>
> The test_decoding output plugin just uses the default text output
> functions for all types, other plugins could do differently. I.e. in all
> these cases a SELECT, COPY, pg_dump will also include those quotes.
> E.g.
> postgres=# SELECT ARRAY[tstzrange(NOW(), NOW() + interval '1 day')];
> will format it's output similarly:
> {"[\"2014-02-08 23:44:19.82007+01\",\"2014-02-09 23:44:19.82007+01\")"}
> (1 row)
>
> Does that answer make sense?
Ah, okay. Thanks.
Another question: in order for logical decoding/replication to be
useful, presumably one would need a primary key on every table? It's
just I haven't seen this mentioned on the changeset extraction page in
the docs.
--
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
Hi Thom,
On 2014-02-08 22:26:59 +, Thom Brown wrote:
> Got a question about ranges and arrays usage with timestamps... why
> are quotes added to these?
>
> timestamptz (no quotes with input or output):
> table "a": INSERT: moo[timestamptz]:2014-02-08 22:09:33+00
>
> tstzrange (no quotes with input, but quotes with output):
> table "b": INSERT: moo[tstzrange]:["2014-02-08
> 13:45:22+00","2014-02-08 14:45:42+00")
>
> timestamptz[] (no quotes with input, but quotes with output):
> table "c": INSERT: moo[_timestamptz]:{"2010-01-01
> 13:45:22+00","2010-01-03 14:45:42+00"}
>
> tstzrange[] (one set of quotes with input, two sets of quotes with
> output, one set of which are escaped):
> table "d": INSERT: moo[_tstzrange]:{"(\"2014-02-08
> 13:45:22+00\",\"2014-02-08 13:45:42+00\"]","[\"2014-02-07
> 10:12:19+00\",\"2014-02-07 13:51:16+00\"]"}
The test_decoding output plugin just uses the default text output
functions for all types, other plugins could do differently. I.e. in all
these cases a SELECT, COPY, pg_dump will also include those quotes.
E.g.
postgres=# SELECT ARRAY[tstzrange(NOW(), NOW() + interval '1 day')];
will format it's output similarly:
{"[\"2014-02-08 23:44:19.82007+01\",\"2014-02-09 23:44:19.82007+01\")"}
(1 row)
Does that answer make sense?
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] narwhal and PGDLLIMPORT
Hiroshi Inoue writes: > Though I'm not a MINGW expert at all, I know dllwrap is a deprecated > tool and dlltool is almost a deprecated tool. Cygwin port is removing > the use of dllwrap and dlltool now. Isn't it better for MINGW port to > follow it? Only way to make that happen is to prepare and test a patch ... In the meantime, here's a short patch trying the "#define extern" approach. Anyone want to try this on a Windows machine or two? Or we could just commit it in HEAD for long enough to see what the buildfarm says. regards, tom lane *** /home/postgres/pgsql/src/include/c.h Fri Jan 17 15:57:23 2014 --- new/c.h Sat Feb 8 17:19:00 2014 *** extern int vsnprintf(char *str, size_t c *** 961,973 #define memmove(d, s, c) bcopy(s, d, c) #endif ! /* no special DLL markers on most ports */ ! #ifndef PGDLLIMPORT #define PGDLLIMPORT - #endif - #ifndef PGDLLEXPORT #define PGDLLEXPORT - #endif /* * The following is used as the arg list for signal handlers. Any ports --- 961,969 #define memmove(d, s, c) bcopy(s, d, c) #endif ! /* we don't use special DLL markers in declarations anymore */ #define PGDLLIMPORT #define PGDLLEXPORT /* * The following is used as the arg list for signal handlers. Any ports *** /home/postgres/pgsql/src/include/port/cygwin.h Tue Jul 23 13:41:12 2013 --- new/cygwin.h Sat Feb 8 17:22:32 2014 *** *** 10,18 #endif #ifdef BUILDING_DLL ! #define PGDLLIMPORT __declspec (dllexport) #else ! #define PGDLLIMPORT __declspec (dllimport) #endif - - #define PGDLLEXPORT --- 10,16 #endif #ifdef BUILDING_DLL ! #define extern extern __declspec (dllexport) #else ! #define extern extern __declspec (dllimport) #endif *** /home/postgres/pgsql/src/include/port/win32.h Sun Jan 26 22:38:59 2014 --- new/win32.h Sat Feb 8 17:26:53 2014 *** *** 73,93 */ #if defined(WIN32) || defined(__CYGWIN__) - #ifdef BUILDING_DLL ! #define PGDLLIMPORT __declspec (dllexport) #else /* not BUILDING_DLL */ ! #define PGDLLIMPORT __declspec (dllimport) ! #endif ! ! #ifdef _MSC_VER ! #define PGDLLEXPORT __declspec (dllexport) ! #else ! #define PGDLLEXPORT #endif - #else /* not CYGWIN, not MSVC, not MingW */ - #define PGDLLIMPORT - #define PGDLLEXPORT #endif --- 73,83 */ #if defined(WIN32) || defined(__CYGWIN__) #ifdef BUILDING_DLL ! #define extern extern __declspec (dllexport) #else /* not BUILDING_DLL */ ! #define extern extern __declspec (dllimport) #endif #endif *** typedef int pid_t; *** 347,354 /* In backend/port/win32/signal.c */ ! extern PGDLLIMPORT volatile int pg_signal_queue; ! extern PGDLLIMPORT int pg_signal_mask; extern HANDLE pgwin32_signal_event; extern HANDLE pgwin32_initial_signal_pipe; --- 337,344 /* In backend/port/win32/signal.c */ ! extern volatile int pg_signal_queue; ! extern int pg_signal_mask; extern HANDLE pgwin32_signal_event; extern HANDLE pgwin32_initial_signal_pipe; -- 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 8 February 2014 21:25, Andres Freund wrote:
> On 2014-02-08 21:07:03 +, Thom Brown wrote:
>> > I'll continue to play around with the feature.
>>
>> Next issue. Firstly, an out-of-date example:
>>
>> doc/src/sgml/changesetextraction.sgml
>>
>> pg_recvlogical --slot test --init -d testdb
>>
>> There's no option --init. I think this is supposed to be --create.
>
> Fixed. It used to be --init, but that has changed. Thanks.
>
>> $ pg_recvlogical --slot test --create -d testdb
>> pg_recvlogical: could not send replication command
>> "CREATE_REPLICATION_SLOT "test" LOGICAL "test_decoding"": extraneous
>> data in "T" message
>
> Gah. Another merge issue. Fixed. We really need to have infrastructure
> for testing binaries...
Thanks, no issue with that now.
Got a question about ranges and arrays usage with timestamps... why
are quotes added to these?
timestamptz (no quotes with input or output):
table "a": INSERT: moo[timestamptz]:2014-02-08 22:09:33+00
tstzrange (no quotes with input, but quotes with output):
table "b": INSERT: moo[tstzrange]:["2014-02-08
13:45:22+00","2014-02-08 14:45:42+00")
timestamptz[] (no quotes with input, but quotes with output):
table "c": INSERT: moo[_timestamptz]:{"2010-01-01
13:45:22+00","2010-01-03 14:45:42+00"}
tstzrange[] (one set of quotes with input, two sets of quotes with
output, one set of which are escaped):
table "d": INSERT: moo[_tstzrange]:{"(\"2014-02-08
13:45:22+00\",\"2014-02-08 13:45:42+00\"]","[\"2014-02-07
10:12:19+00\",\"2014-02-07 13:51:16+00\"]"}
--
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: [DOCS] [HACKERS] Viability of text HISTORY/INSTALL/regression README files (was Re: [COMMITTERS] pgsql: Document a few more regression test hazards.)
I wrote: > Gavin Flower 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. Here's a proposed patch against HEAD for this. It also gets rid of some rather quaint instructions for using Netscape to construct these files ;-) Barring objection, I'd like to update all the live branches this way before the upcoming releases. I'm tired of having to worry about whether the release notes will build as plain text; but that worry won't go away unless we nuke the text output in all the branches. regards, tom lane diff --git a/GNUmakefile.in b/GNUmakefile.in index 40ab280..a573880 100644 *** a/GNUmakefile.in --- b/GNUmakefile.in *** distdir: *** 103,112 fi || exit; \ done $(MAKE) -C $(distdir) distprep ! $(MAKE) -C $(distdir)/doc/src/sgml/ HISTORY INSTALL regress_README ! cp $(distdir)/doc/src/sgml/HISTORY $(distdir)/ cp $(distdir)/doc/src/sgml/INSTALL $(distdir)/ - cp $(distdir)/doc/src/sgml/regress_README $(distdir)/src/test/regress/README $(MAKE) -C $(distdir) distclean rm -f $(distdir)/README.git --- 103,110 fi || exit; \ done $(MAKE) -C $(distdir) distprep ! $(MAKE) -C $(distdir)/doc/src/sgml/ INSTALL cp $(distdir)/doc/src/sgml/INSTALL $(distdir)/ $(MAKE) -C $(distdir) distclean rm -f $(distdir)/README.git diff --git a/HISTORY b/HISTORY index ...360c7f6 . *** a/HISTORY --- b/HISTORY *** *** 0 --- 1,6 + Release notes for all versions of PostgreSQL can be found on-line at + http://www.postgresql.org/docs/devel/static/release.html + + In a distribution file set, release notes for the current version can be + found prebuilt under doc/src/sgml/html/. Visit the index.html file with + an HTML browser, then consult the "Release Notes" appendix. diff --git a/README b/README index 49d55af..302028e 100644 *** a/README --- b/README *** See the file INSTALL for instructions on *** 17,24 PostgreSQL. That file also lists supported operating systems and hardware platforms and contains information regarding any other software packages that are required to build or run the PostgreSQL ! system. Changes between all PostgreSQL releases are recorded in the ! file HISTORY. Copyright and license information can be found in the file COPYRIGHT. A comprehensive documentation set is included in this distribution; it can be read as described in the installation instructions. --- 17,23 PostgreSQL. That file also lists supported operating systems and hardware platforms and contains information regarding any other software packages that are required to build or run the PostgreSQL ! system. Copyright and license information can be found in the file COPYRIGHT. A comprehensive documentation set is included in this distribution; it can be read as described in the installation instructions. diff --git a/README.git b/README.git index d5378b4..0bf2b56 100644 *** a/README.git --- b/README.git *** *** 1,12 (This file does not appear in release tarballs.) ! In a release or snapshot tarball of PostgreSQL, documentation files named ! INSTALL and HISTORY will appear in this directory. However, these files are ! not stored in git and so will not be present if you are using a git checkout. ! If you are using git, you can view the most recent install instructions at: http://www.postgresql.org/docs/devel/static/installation.html - and the current release notes at: - http://www.postgresql.org/docs/devel/static/release.html Users compiling from git will also need compatible versions of Bison, Flex, and Perl, as discussed in the install documentation. These programs are not --- 1,12 (This file does not appear in release tarballs.) ! In a release or snapshot tarball of PostgreSQL, a documentation file named ! INSTALL will appear in this directory. However, this file is not stored in ! git and so will not be present if you are using a git checkout. ! ! If you are using a git checkout, you can view the most recent installation ! instructions at: http://www.postgresql.org/docs/devel/static/installation.html Users compiling from git will also need compatible versions of Bison, Flex, and Perl, as discussed in the install documentation. These programs are not diff --git a/doc/src/sgml/.gitignore b/doc/src/sgml/.gitignore index e1b84b4..2f0329c 100644 *** a/doc/src/sgml/.gitignore --- b/doc/src/sgml/.gitignore *** *** 6,14 /man7/ /man-stamp # Other popular build targets - /HISTORY /INSTALL - /regress_README /postgres-US.pdf /postgres-A4.pdf /postgres.html --- 6,12
Re: [HACKERS] Changeset Extraction v7.5
On 2014-02-08 21:07:03 +, Thom Brown wrote: > > I'll continue to play around with the feature. > > Next issue. Firstly, an out-of-date example: > > doc/src/sgml/changesetextraction.sgml > > pg_recvlogical --slot test --init -d testdb > > There's no option --init. I think this is supposed to be --create. Fixed. It used to be --init, but that has changed. Thanks. > $ pg_recvlogical --slot test --create -d testdb > pg_recvlogical: could not send replication command > "CREATE_REPLICATION_SLOT "test" LOGICAL "test_decoding"": extraneous > data in "T" message Gah. Another merge issue. Fixed. We really need to have infrastructure for testing binaries... 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 8 February 2014 19:35, Thom Brown wrote: > On 8 February 2014 17:52, Andres Freund wrote: >> Hi, >> >> Only got to this now, was a bit too tired and needed to catch up on some >> real-world stuff... >> >> On 2014-02-08 00:16:07 +, Thom Brown wrote: >>> On 7 February 2014 23:43, Andres Freund wrote: >>> > 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. >> >> Ok, I roughly went with my initial plan to fix this and I've added (and >> fixed) a regression for this. >> >> Pushed this and some other improvements to >> http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=summary >> branch xlog-decoding-rebasing-remapping > > This appears to be working now. Thanks. > > I'll continue to play around with the feature. Next issue. Firstly, an out-of-date example: doc/src/sgml/changesetextraction.sgml pg_recvlogical --slot test --init -d testdb There's no option --init. I think this is supposed to be --create. But also: $ pg_recvlogical --slot test --create -d testdb pg_recvlogical: could not send replication command "CREATE_REPLICATION_SLOT "test" LOGICAL "test_decoding"": extraneous data in "T" message But this seems to have created it anyway: # SELECT * FROM pg_replication_slots; slot_name |plugin | slot_type | datoid | database | active | xmin | catalog_xmin | restart_lsn ---+---+---++--++--+--+- test | test_decoding | logical | 16396 | testdb | t | | | 0/16E2030 (1 row) If I drop it and run the same command, the same message is emitted. -- 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] notify duplicate elimination performance
Tom Lane schrieb:
> Hardy Falk writes:
>>> Well, you didn't add any code, so it's hard to say... Simple ways of
>>> doing what I think you describe will remove the queue's order. Do you
>>> preserve the ordering guarantees?
>
>> Yes, the order is preserved.
>> I didn't remove the the original list code.
>> The tree is just an additional access path.
>
> It seems likely that this approach would be a net loss for small numbers
> of notify events (which is surely the common case). Have you done any
> measurements of the performance tradeoff?
>
> regards, tom lane
>
>
I can easily keep the tail test. This avoids the hash computation in a
common case. The tree search compares only uint32 values, this should be
quite fast. Even a degenerate tree is no worse than the list. Im my
first tests I didn't use murmurhash, a select
pg_notify('alasys',format('Hello %s',x) from generate_series(1,100)
as x triggered this worst case. With murmurhash2 the average search
depth for 10^6 entries is 24.57.
I am about to prepare a patch, should I do some performance tests with
rtdsc first?
--
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 8 February 2014 17:52, Andres Freund wrote: > Hi, > > Only got to this now, was a bit too tired and needed to catch up on some > real-world stuff... > > On 2014-02-08 00:16:07 +, Thom Brown wrote: >> On 7 February 2014 23:43, Andres Freund wrote: >> > 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. > > Ok, I roughly went with my initial plan to fix this and I've added (and > fixed) a regression for this. > > Pushed this and some other improvements to > http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=summary > branch xlog-decoding-rebasing-remapping This appears to be working now. Thanks. I'll continue to play around with the feature. -- 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] notify duplicate elimination performance
Hardy Falk writes: >> Well, you didn't add any code, so it's hard to say... Simple ways of >> doing what I think you describe will remove the queue's order. Do you >> preserve the ordering guarantees? > Yes, the order is preserved. > I didn't remove the the original list code. > The tree is just an additional access path. It seems likely that this approach would be a net loss for small numbers of notify events (which is surely the common case). Have you done any measurements of the performance tradeoff? 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] notify duplicate elimination performance
Hi, On 2014-02-08 19:28:56 +0100, Hardy Falk wrote: > > Well, you didn't add any code, so it's hard to say... Simple ways of > > doing what I think you describe will remove the queue's order. Do you > > preserve the ordering guarantees? > > > > Greetings, > > > > Andres Freund > > > Yes, the order is preserved. > I didn't remove the the original list code. > The tree is just an additional access path. How about actually attaching a patch? 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] notify duplicate elimination performance
> Well, you didn't add any code, so it's hard to say... Simple ways of
> doing what I think you describe will remove the queue's order. Do you
> preserve the ordering guarantees?
>
> Greetings,
>
> Andres Freund
>
Yes, the order is preserved.
I didn't remove the the original list code.
The tree is just an additional access path.
> oldcontext = MemoryContextSwitchTo(CurTransactionContext);
>
> n = (Notification *) palloc(sizeof(Notification));
> n->channel = pstrdup(channel);
> if (payload)
> n->payload = pstrdup(payload);
> else
> n->payload = "";
> n->hash = hash ;
> n->left = NULL ;
> n->right= NULL ;
> *tt = n ;
tt is a Notification** obtained by the search.
> static Notification **search(const char *channel, const char *payload )
> {
> Notification *t,**tt ;
> uint32 hash ;
> t = hashroot ;
> tt = &hashroot ;
> hash = hashf(channel,691) ;
> hash = hashf(payload,hash) ;
> while ( t )
> {
> if ( hash < t->hash )
> {
> tt = &t->left ;
> t = t->left ;
> }
> else if ( hash > t->hash )
> {
> tt = &t->right ;
> t = t->right ;
> }
> else
> {
> if (0==strcmp(t->channel,channel) &&
> 0==strcmp(t->payload,payload))
> {
> return NULL
> }
> else
> {
> tt = &t->left ;
> t = t->left ;
> }
> }
> }
> return tt ;
> }
--
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] notify duplicate elimination performance
Hi,
On 2014-02-08 18:56:41 +0100, Hardy Falk wrote:
> I know that it is not a big problem for most users, but allowing a very
> large number of notifications while using linear search is a bit dumb.
> I can fix this with a very small modification to
> struct Notification:
> {
> char *channel ;
> char *payload ;
> uint32 hash ;
> struct Notification *left ;
> struct Notification *right ;
> }
> AsyncExistsPendingNotify does an iterative binary tree search.
> The tree is insert-only, there is no need for rebalancing, and the code
> is quite simple.
> Any comments?
Well, you didn't add any code, so it's hard to say... Simple ways of
doing what I think you describe will remove the queue's order. Do you
preserve the ordering guarantees?
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
[HACKERS] notify duplicate elimination performance
I know that it is not a big problem for most users, but allowing a very
large number of notifications while using linear search is a bit dumb.
I can fix this with a very small modification to
struct Notification:
{
char *channel ;
char *payload ;
uint32 hash ;
struct Notification *left ;
struct Notification *right ;
}
AsyncExistsPendingNotify does an iterative binary tree search.
The tree is insert-only, there is no need for rebalancing, and the code
is quite simple.
Any comments?
--
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
Hi, Only got to this now, was a bit too tired and needed to catch up on some real-world stuff... On 2014-02-08 00:16:07 +, Thom Brown wrote: > On 7 February 2014 23:43, Andres Freund wrote: > > 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. Ok, I roughly went with my initial plan to fix this and I've added (and fixed) a regression for this. Pushed this and some other improvements to http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=summary branch xlog-decoding-rebasing-remapping 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
[HACKERS] Postgres back-branch minor updates coming soon
Now that the dust seems to have settled around 9.3's multixact bugs, it's time to push out another set of minor releases. The plan is to wrap tarballs on Monday Feb 17 for announcement on Thursday Feb 20. 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
