Re: psql JSON output format

Re: Robert Haas > IMHO, the big problem here is that different people want different > corner-case behaviors and it's not clear what to do about that. I > don't think there's a single vote for "don't do this at all". So if > there is a desire to take this work forward, the goal probably ought > to

Re: psql: Allow editing query results with \gedit

Re: Robert Haas > Based on these comments and the one from David Johnston, I think there > is a consensus that we do not want this patch, so I'm marking it as > Rejected in the CommitFest application. If I've misunderstood the > situation, then please feel free to change the status accordingly.

Re: pgsql: meson: Add initial version of meson based build system

Re: Andres Freund > > This commit broke VPATH builds when the original source directory > > contains symlinks. > > I.e. a symlink to the source directory, not a symlink inside the source > directory. Yes. > Argh, this is missing spaces around the '=', leading to the branch always > being

Re: pgsql: meson: Add initial version of meson based build system

Re: Andres Freund > https://git.postgresql.org/pg/commitdiff/e6927270cd18d535b77cbe79c55c6584351524be This commit broke VPATH builds when the original source directory contains symlinks. The $PWD is /home/myon/postgresql/pg/master, but the actual directory is

Re: RFC: Additional Directory for Extensions

> Fwiw, I wrote this patch to solve the problem of testing extensions at > build-time where the build process does not have write access to > PGSHAREDIR. It solves that problem quite well, almost all PG > extensions have build-time test coverage now (where there was > basically 0 before). Also,

Re: RFC: Additional Directory for Extensions

Re: David E. Wheeler > > Yes, I like the suggestion to make it require a restart, which lets the > > sysadmin control it and not limited to whatever the person who compiled it > > thought would make sense. > > Here’s a revision of the Debian patch that requires a server start. Thanks for

Re: LLVM 18

Re: Thomas Munro > By the way, while testing on my Debian system with apt.llvm.org > packages, I discovered that we crash with its latest llvm-18 package, > namely: Ubuntu in their infinite wisdom have switched to LLVM 18 as default for their upcoming 24.04 "noble" LTS release while Debian is

Re: Printing backtrace of postgres processes

Re: Michael Paquier > Something like this can be measured with a bunch of concurrent > connections attempting connections and a very high rate, like pgbench > with an empty script and -C, for local connections. I tried that now. Mind that I'm not a benchmarking expert, and there's been quite some

Re: Printing backtrace of postgres processes

Re: Michael Paquier > >>• backtrace() and backtrace_symbols_fd() don't call malloc() > >> explic‐ > >> itly, but they are part of libgcc, which gets loaded > >> dynamically > >> when first used. Dynamic loading usually triggers a call to > >> mal‐ > >>

Re: cpluspluscheck complains about use of register

Re: Tom Lane > > I hit this again while porting cplupluscheck to be invoked by meson as > > well. ISTM that we should just remove the uses of register. > > OK by me. > > > I tried to use -Wregister to keep us honest going forward, but unfortunately > > it only works with a C++ compiler... > > I

Re: psql JSON output format

Re: Laurenz Albe > > I'd just stop the flood right before it starts... > > I'd stop the flood right after json/jsonb. Nod. I do see a point here, given it's "json in json", and not "something else in json". Will try to make it work with \gedit. > Arrays as database columns are probably too rare

Re: psql JSON output format

Re: Laurenz Albe > If you import the data into an existing structure, you don't need the > metadata. Also, since you were running the query yourself, you should know what columns you were expecting. Christoph

Re: psql JSON output format

Re: Laurenz Albe > I am kind of unhappy about this change. It seems awkward and undesirable > so have JSON values decorated with weird quoting in JSON output. > I understand the motivation, but I bet it's not what will make users > happy. Well, why stop at JSON, and not represent any array type

Re: psql: Allow editing query results with \gedit

Re: Pavel Stehule > It looks great for simple queries, but if somebody uses it like SELECT * > FROM pg_proc \gedit What's wrong with that? If the pager can handle the amount of data, the editor can do that as well. (If not, the fix is to just not run the command, and not blame the feature.) > I

Re: psql: Allow editing query results with \gedit

Re: David G. Johnston > Building off the other comments, I'd suggest trying to get rid of the > intermediate JSOn format and also just focus on a single row at any given > time. We need *some* machine-readable format. It doesn't have to be JSON, but JSON is actually pretty nice to read - and if

Re: psql: Allow editing query results with \gedit

Re: Pavel Stehule > Introduction of \gedit is interesting idea, but in this form it looks too > magic > > a) why the data are in JSON format, that is not native for psql (minimally > now) Because we need something machine-readable. CSV would be an alternative, but that is hardly human-readable.

Re: psql JSON output format

I think the default should be to show NULL columns.) Christoph >From 2b575846fee609237256fe8eaf38fd45005fe8da Mon Sep 17 00:00:00 2001 From: Christoph Berg Date: Fri, 8 Sep 2023 15:59:29 +0200 Subject: [PATCH] Add JSON output format to psql Query results are formatted as an array of JSON objects. In non-expanded mode,

psql: Allow editing query results with \gedit

DATE messages SET message = 'Hello world' WHERE id = '2'; UPDATE 1 In this example, typing "WHERE id = 2" would not be too hard, but the primary key might be a composite key, with complex non-numeric values. This is supported as well. If expanded mode (\x) is enabled, \gedit will use the expan

Re: plperl and perl 5.38

Re: Andrew Dunstan > > +WARNING: could not determine encoding for locale "C.utf8": codeset is > > "ANSI_X3.4-1968" > > I can't reproduce this on my Ubuntu 22.04 ARM64 instance with perl 5.38.2 > installed via perlbrew, nor on a fresh Debian unstable with it's perl > 5.38.2. In both instances my

plperl and perl 5.38

Perl 5.38 has landed in Debian unstable, and plperl doesn't like it: diff -U3 /home/myon/projects/postgresql/pg/postgresql/src/pl/plperl/expected/plperl_elog_1.out /home/myon/projects/postgresql/pg/postgresql/build/testrun/plperl/regress/results/plperl_elog.out ---

Re: psql JSON output format

d composite values nicely. Adding format-specific options could also be used to switch the output between "array of json objects" and "one json object per line". Christoph >From add569c7e1636a6e6146e903894c4c84aee5c21a Mon Sep 17 00:00:00 2001 From: Christoph Berg Date: Fri,

Re: psql JSON output format

Re: Dean Rasheed > I can see the appeal in this feature. However, as it stands, this > isn't compatible with copy format json, and I think it would need to > duplicate quite a lot of the JSON output code in client-side code to > make it compatible. I can see we probably wouldn't want two

Re: Set log_lock_waits=on by default

Re: Robert Haas > On Thu, Dec 21, 2023 at 8:29 AM Laurenz Albe wrote: > > Here is a patch to implement this. > > Being stuck behind a lock for more than a second is almost > > always a problem, so it is reasonable to turn this on by default. > > I think it depends somewhat on the lock type, and

int4->bool test coverage

The first cast is the int4_bool function, but it isn't covered by the regression tests at all. The attached patch adds tests. Christoph >From 5752d75122db323b4066dd604d0c7a19077641a6 Mon Sep 17 00:00:00 2001 From: Christoph Berg Date: Thu, 21 Dec 2023 11:43:28 +0100 Subject: [PATCH] Add tests

Re: psql JSON output format

Re: Jelte Fennema-Nio > This seems useful to me too, but my usecases would also be solved (and > possibly better solved) by adding JSON support to COPY as proposed > here: > https://www.postgresql.org/message-id/flat/CALvfUkBxTYy5uWPFVwpk_7ii2zgT07t3d-yR_cy4sfrrLU%3Dkcg%40mail.gmail.com Thanks

Re: psql JSON output format

Re: To PostgreSQL Hackers > On the command line, the format is selected by `psql --json` and `psql -J`. Among other uses, it enables easy post-processing of psql output using `jq`: $ psql -lJ | jq [ { "Name": "myon", "Owner": "myon", "Encoding": "UTF8", "Locale Provider":

psql JSON output format

re optimized for readability while still saving screen space. Both formats output the same JSON structure, an array of objects. Other variants like array-of-arrays or line-separated objects ("jsonline") might be possible, but I didn't want to overengineer it. On the command line, the format is sele

Re: [PATCH] Native spinlock support on RISC-V

Re: Thomas Munro > I randomly remembered this topic after seeing an s390x announcement > from Christoph[1], and figured he or someone else might be interested > in the same observation about that platform. That is, we finally got > around to defining this for ARM, but I bet one internet point

Re: pgsql: Don't trust unvalidated xl_tot_len.

That's a lot of questions :). Let me try: > In your chroot after it fails, can you please find xlog_internal.h > somewhere under tmp_install and tell us the full path, and can you ./build/tmp_install/usr/include/postgresql/13/server/access/xlog_internal.h ./src/include/access/xlog_internal.h >

Re: pgsql: Don't trust unvalidated xl_tot_len.

Re: Thomas Munro > But then why does that only happen on the salsa build, > not on the apt.postgresql.org one? The build chroots there have postgresql-NN already installed so extension builds don't have to download 7 PG versions over and over. My guess would be that that's the difference and it's

Re: pgsql: Don't trust unvalidated xl_tot_len.

Re: Thomas Munro > In the 13 branch we see that's in the new scan_server_header() > subroutine where it tries to open the header, after asking pg_config > --includedir-server where it lives. Hmm... It's no ok to use pg_config at test time since `make install` might not have been called yet:

Re: pgsql: Don't trust unvalidated xl_tot_len.

Re: To Thomas Munro > > src/test/recovery/t/039_end_of_wal.pl | 460 > > > > I haven't investigated the details yet, and it's not affecting the > builds on apt.postgresql.org, but the Debian amd64 and i386 regression > tests just failed this test on PG13 (11 and

Re: pgsql: Don't trust unvalidated xl_tot_len.

Re: To Thomas Munro > I haven't investigated the details yet, and it's not affecting the > builds on apt.postgresql.org, but the Debian amd64 and i386 regression > tests just failed this test on PG13 (11 and 15 are ok): That's on Debian bullseye, fwiw. (But the 13 build on apt.pg.o/bullseye

Re: pgsql: Don't trust unvalidated xl_tot_len.

Re: Thomas Munro > Don't trust unvalidated xl_tot_len. > src/test/recovery/t/039_end_of_wal.pl | 460 I haven't investigated the details yet, and it's not affecting the builds on apt.postgresql.org, but the Debian amd64 and i386 regression tests just failed this

Re: meson documentation build open issues

Re: Peter Eisentraut > > If the problem is broken doc patches, then maybe a solution is to > > include the `xmllint --noout --valid` target in whatever the check-world > > equivalent is for meson. Looking at doc/src/sgml/meson.build, we don't > > seem to do that anywhere. Doing the no-output

Re: meson documentation build open issues

Re: Andres Freund > > We might get around that by introducing a new postgresql-manpages-XX > > arch:all package, but that might be too much micropackaging. > > I've not done packaging in, uh, a fair while, but isn't the common solution to > that a -common package? There might be a few more files

Re: meson documentation build open issues

Re: Andres Freund > > > The reason for that is simply that the docs take too long to build. > > > > That why I'd prefer to be able to separate arch:all and arch:any > > builds, yes. > > What's stopping you from doing that? I think the only arch:any content we > have is the docs, and those you

Re: meson documentation build open issues

Re: Andres Freund > The reason for that is simply that the docs take too long to build. That why I'd prefer to be able to separate arch:all and arch:any builds, yes. > The summary does include both. LLVM is 'llvm', man/html docs is 'docs' and pdf > docs as 'docs_pdf'. Sorry, I should have

Re: meson documentation build open issues

Re: Andres Freund > > > You can control this with the "docs" option for meson, as of recently. > > > > I've been looking into switching the Debian PG 17 build to meson, but > > I'm running into several problems. > > > > * The docs are still not built by default, and -Ddocs=enabled doesn't > >

Re: meson documentation build open issues

Re: Peter Eisentraut > > "meson compile" doesn't seem to build the docs by default ( see > > ), > > and I'd rather it didn't, building the docs is a separate and optional > > step for the

Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges

Re: Tom Lane > Well, the idea was exactly to forbid that sort of setup. Fwiw, pgsphere has remove the problematic operators now: https://github.com/postgrespro/pgsphere/commit/e810f5ddd827881b06a92a303c5c9fbf997b892e > However, if we get sufficient pushback maybe we should > reconsider --- for

Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges

Re: Tom Lane > > We might be able to simply delete the @ operators, but doesn't this > > new check break the general possibility to have more than one spelling > > for the same operator? > > You can have more than one operator atop the same function. > But why didn't you make the @ operators

Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges

Re: Tommy Pavlicek > I've added another patch (0002-require_unused_neg_com-v1.patch) that > prevents using a commutator or negator that's already part of a pair. Hmm. I agree with the general idea of adding sanity checks, but this might be overzealous: This change is breaking pgsphere which has

Re: pgsql: Generate automatically code and documentation related to wait ev

Re: Michael Paquier > Will fix as per the attached. Thanks for the report. Thanks for the lightning-fast fix :) Christoph

Re: pgsql: Generate automatically code and documentation related to wait ev

Re: Michael Paquier > Generate automatically code and documentation related to wait events Hi, I'm not entirely sure this is the commit to blame, but it's certainly close: A Debian user is complaining that in PG17, the installed /usr/include/postgresql/17/server/utils/wait_event.h file is

Re: A failure in 031_recovery_conflict.pl on Debian/s390x

Re: Thomas Munro > I have now disabled the test in 15 and 16 (like the older branches). > I'll see about getting the fixes into master today, and we can > contemplate back-patching later, after we've collected a convincing > volume of test results from the build farm, CI and hopefully your > s390x

Re: A failure in 031_recovery_conflict.pl on Debian/s390x

Re: Thomas Munro > 2022), and then backpatched to all releases. They were disabled again > in release branches 10-14 (discussion at > https://postgr.es/m/3447060.1652032...@sss.pgh.pa.us): > > +plan skip_all => "disabled until after minor releases, due to instability"; Right:

Re: A failure in 031_recovery_conflict.pl on Debian/s390x

Re: Andres Freund > > Thanks. I realised that it's easy enough to test that theory about > > cleanup locks by hacking ConditionalLockBufferForCleanup() to return > > false randomly. Then the test occasionally fails as described. Seems > > like we'll need to fix that test, but it's not evidence

Reproducibility (Re: Remove distprep)

Re: Michael Paquier > Is reproducibility something you've brought to a separate thread? > FWIW, I'd be interested in improving this area for the in-core code, > if need be. (Not material for this thread, of course). All the "normal" things like C compilation are actually already reproducible.

Re: Remove distprep

Re: Michael Paquier > This one comes down to Debian that patches autoconf with its own set > of options, requiring a new ./configure in the tree, right? Yes, mostly. Since autoconf had not seen a new release for so long, everyone started to patch it, and one of the things that Debian and others

Re: A failure in 031_recovery_conflict.pl on Debian/s390x

Re: Thomas Munro > On Thu, Aug 10, 2023 at 9:15 PM Christoph Berg wrote: > > No XXX lines this time either, but I've seen then im logfiles that > > went through successfully. > > Do you still have the data directories around from that run, so we can > see if the expected

Re: A failure in 031_recovery_conflict.pl on Debian/s390x

Re: To Thomas Munro > 603 iterations later it hit again, but didn't log anything. (I believe > I did run "make" in the right directory.) This time it took 3086 iterations to hit the problem. Running c27f8621eedf7 + Debian patches + v8 + pgstat-report-conflicts-immediately.patch + the XXX

Re: Remove distprep

Re: Tom Lane > Meh ... the fact that it works fine for you doesn't mean it will work > fine elsewhere. Since we're trying to get out from under maintaining > the autoconf build system, I don't think it makes sense to open > ourselves up to having to do more work on it. A policy of benign >

Re: A failure in 031_recovery_conflict.pl on Debian/s390x

Re: To Thomas Munro > 603 iterations later it hit again, but didn't log anything. (I believe > I did run "make" in the right directory.) Since that didn't seem right I'm running the tests again. There are XXX lines in the output, but it hasn't hit yet. Christoph

Re: A failure in 031_recovery_conflict.pl on Debian/s390x

Re: Thomas Munro > On Wed, Aug 9, 2023 at 2:01 AM Christoph Berg wrote: > > Putting that patch on top of v8 made it pass 294 times before exiting > > like this: > > > > [08:52:34.134](0.032s) ok 1 - buffer pin conflict: cursor with conflicting > > pin established

Re: Remove distprep

Re: Tom Lane > Have we yet run this concept past the packagers list? I'm still > wondering if they will raise any objection to getting rid of all > the prebuilt files. No problem for Debian, we are building snapshot releases from plain git already without issues. In fact, there are already some

Re: A failure in 031_recovery_conflict.pl on Debian/s390x

Re: Andres Freund > Hm, that could just be a "harmless" race. Does it still happen if you apply > the attached patch in addition? Putting that patch on top of v8 made it pass 294 times before exiting like this: [08:52:34.134](0.032s) ok 1 - buffer pin conflict: cursor with conflicting pin

Re: A failure in 031_recovery_conflict.pl on Debian/s390x

Re: Thomas Munro > Thanks for testing! Would you mind trying v8 from that thread? V7 > had a silly bug (I accidentally deleted a 'case' label while cleaning > some stuff up, resulting in the above error...) v8 worked better. It succeeded a few times (at least 12, my screen scrollback didn't

Re: A failure in 031_recovery_conflict.pl on Debian/s390x

Re: Thomas Munro > It's great that you can reproduce this semi-reliably! I've rebased > the patch, hoping you can try it out. Unfortunately very semi, today I didn't get to the same point where it exited after test 7, but got some other timeouts. Not even sure they are related to this (?)

A failure in 031_recovery_conflict.pl on Debian/s390x

Re: Noah Misch > On Tue, Jul 25, 2023 at 01:56:41PM +0530, Bharath Rupireddy wrote: > > I've observed the following failure once in one of my Cirrus CI runs > > on Windows Server on HEAD: > > > > timed out waiting for match: (?^:User was holding shared buffer pin > > for too long) at > >

New PostgreSQL Contributors

The PostgreSQL contributors team has been looking over the community activity and, over the first half of this year, has been recognizing new contributors to be listed on https://www.postgresql.org/community/contributors/ New PostgreSQL Contributors: Ajin Cherian Alexander Kukushkin

Re: could not extend file "base/5/3501" with FileFallocate(): Interrupted system call

Re: Alvaro Herrera > > Christoph, could you verify this fixes your issue? > > So, is anyone making progress on this? I don't see anything in the > thread. Well, I had reported that I haven't been seeing any problems since I applied the patch to the postgresql-16.deb package. So for me, the

Re: testing dist tarballs

Re: Andres Freund > That's due to MAKELEVEL: > > submake-generated-headers: > ifndef NO_GENERATED_HEADERS > ifeq ($(MAKELEVEL),0) > $(MAKE) -C $(top_builddir)/src/backend generated-headers > endif > endif > > So the distcheck target needs to reset MAKELEVEL=0 - unless somebody has a >

Re: pgsql: Move snowball_create.sql creation into perl file

Re: Tom Lane > I think the attached will do for a proper fix. I'm not inclined > to re-wrap just for this. Sure, I just posted it here in case others run into the same problem. Thanks! Christoph

Re: could not extend file "base/5/3501" with FileFallocate(): Interrupted system call

Re: Andres Freund > A prototype of that approach is attached. I pushed the retry handling into the > pg_* routines where applicable. I guess we could add pg_* routines for > FileFallocate(), FilePrewarm() etc as well, but I didn't do that here. > > Christoph, could you verify this fixes your

Re: pgsql: Move snowball_create.sql creation into perl file

Re: To Andres Freund > this seems to have broken out-of-tree builds from tarballs: > > /usr/bin/install -c -m 644 snowball_create.sql > '/srv/projects/postgresql/debian/16/build/tmp_install/usr/share/postgresql/16' > /usr/bin/install: cannot stat 'snowball_create.sql': No such file or directory

Re: pgsql: Move snowball_create.sql creation into perl file

Re: Andres Freund > Move snowball_create.sql creation into perl file > > This is in preparation for building postgres with meson / ninja. > > We already have duplicated code for this between the make and msvc > builds. Adding a third copy seems like a bad plan, thus move the generation > into a

Re: could not extend file "base/5/3501" with FileFallocate(): Interrupted system call

Re: Andres Freund > A prototype of that approach is attached. I pushed the retry handling into the > pg_* routines where applicable. I guess we could add pg_* routines for > FileFallocate(), FilePrewarm() etc as well, but I didn't do that here. > > Christoph, could you verify this fixes your

could not extend file "base/5/3501" with FileFallocate(): Interrupted system call

Re: Andres Freund > Add smgrzeroextend(), FileZero(), FileFallocate() Hi, I'm often seeing PG16 builds erroring out in the pgbench tests: 00:33:12 make[2]: Entering directory '/<>/build/src/bin/pgbench' 00:33:12 echo "# +++ tap check in src/bin/pgbench +++" && rm -rf

Re: Direct I/O

Re: Thomas Munro > Linux/tmpfs: 1..0 # SKIP pre-flight test if we can open a file with > O_DIRECT failed: Invalid argument I confirm it's working now: t/004_io_direct.pl .. skipped: pre-flight test if we can open a file with O_DIRECT failed: Invalid argument All tests successful.

Re: Direct I/O

Hi, I'm hitting a panic in t_004_io_direct. The build is running on overlayfs on tmpfs/ext4 (upper/lower) which is probably a weird combination but has worked well for building everything over the last decade. On Debian unstable: PANIC: could not open file "pg_wal/00010001":

Re: Make EXPLAIN generate a generic plan for a parameterized query

Re: Tom Lane > I don't actually see why a postgres_fdw test case is needed at all? > The tests in explain.sql seem sufficient. When I asked Laurenz about that he told me that local tables wouldn't exercise the code specific for EXEC_FLAG_EXPLAIN_GENERIC. (Admittedly my knowledge of the planner

Re: Make EXPLAIN generate a generic plan for a parameterized query

Re: Laurenz Albe > And here is v10, which includes tab completion for the new option. IMHO everything looks good now. Marking as ready for committer. Thanks! Christoph

Re: Make EXPLAIN generate a generic plan for a parameterized query

Hi, I reviewed the patch and find the idea of allowing $placeholders with EXPLAIN very useful, it will solve relevant real-world use-cases. (Queries from pg_stat_statements, found in the log, or in application code.) I have some comments: > This allows EXPLAIN to generate generic plans for

Re: lz4 --rm on Ubuntu 18.04 (Add LZ4 compression to pg_dump)

Re: Tomas Vondra > and I don't think there's a good place to inject the 'rm' so I ended up > adding a 'cleanup_cmd' right after 'compress_cmd'. But it seems a bit > strange / hacky. Maybe there's a better way? Does the file need to be removed at all? Could we leave it there and have "make clean"

lz4 --rm on Ubuntu 18.04 (Add LZ4 compression to pg_dump)

Re: Tomas Vondra > Add LZ4 compression to pg_dump This broke the TAP tests on Ubuntu 18.04 (bionic): [17:06:45.513](0.000s) ok 1927 - compression_lz4_custom: should not dump test_table with 4-row INSERTs # Running: pg_dump --jobs=2 --format=directory --compress=lz4:1

Re: [PATCH] Support % wildcard in extension upgrade filenames

Re: Sandro Santilli > I'm attaching an updated version of the patch. This time the patch > is tested. Nothing changes unless the .control file for the subject > extension doesn't have a "wildcard_upgrades = true" statement. > > When wildcard upgrades are enabled, a file with a "%" symbol as > the

Re: [PATCH] Support % wildcard in extension upgrade filenames

Re: Tom Lane > The existing logic to find multi-step upgrade paths is going to make > this a very pressing problem. For example, if you provide both > extension--%--2.0.sql and extension--%--2.1.sql, it's not at all > clear whether the code would try to use both of those or just one > to get from

Re: [postgis-devel] PostGIS and json_categorize_type (Re: pgsql: Revert SQL/JSON features)

Re: Justin Pryzby > > I guess either PostgreSQL or PostGIS need to make a new release to fix that. > > Postgis is already planning on it. > https://lists.osgeo.org/pipermail/postgis-devel/2022-September/thread.html Thanks. I was skimming the postgis-devel list, but did not read the subjects

Re: PostGIS and json_categorize_type (Re: pgsql: Revert SQL/JSON features)

Re: To Andrew Dunstan > The "< 17" part was added on 2022-09-03, probably because of this > breakage. > > Recompiling the (unmodified) 3.3.0 against 15beta4 seems to fix the > problem. Err sorry, my local build environment was still on beta3. PostGIS 3.3.0 is broken now with 15beta4: 10:52:29

PostGIS and json_categorize_type (Re: pgsql: Revert SQL/JSON features)

Re: Andrew Dunstan > Revert SQL/JSON features > > The reverts the following and makes some associated cleanups: -void +static void json_categorize_type(Oid typoid, JsonTypeCategory *tcategory, Oid *outfuncoid) This chunk broke PostGIS 3.3.0 compiled

Re: (doc patch) psql version compatibility

Re: Tom Lane > Christoph Berg writes: > > I didn't understand the current wording of the NOTES section in > > psql(1) on which major versions psql is compatible with, so here's a > > patch to make that more explicit. > > This seems both very repetitive and incorre

psql -l and locales (Re: pgsql: Add option to use ICU as global locale provider)

Re: Tom Lane > Christoph Berg writes: > > A possible solution might be to rip out all the locale columns except > > "Encoding" from \l, and leave them in place for \l+. > > I'd rather see a single column summarizing the locale situation. > Perhaps it could be

pg_upgrade major version compatibility

The pg_upgrade manpage in PG 14 and earlier claims that upgrades from 8.4 are supported, but that doesn't work: /usr/lib/postgresql/14/bin/pg_upgrade -b /usr/lib/postgresql/8.4/bin -B /usr/lib/postgresql/14/bin -p 5432 -P 5433 -d /var/lib/postgresql/8.4/upgr -o -D /etc/postgresql/8.4/upgr -D

(doc patch) psql version compatibility

Hi, I didn't understand the current wording of the NOTES section in psql(1) on which major versions psql is compatible with, so here's a patch to make that more explicit. Christoph >From 89f947c215c679004e1f3fbf88751fe527e16f91 Mon Sep 17 00:00:00 2001 From: Christoph Berg Date: Tue, 6 Sep 2

Re: plpgsql-trigger.html: Format TG_ variables as table (patch)

the definite article and initial capital, > e.g. "The table that triggered ….". Since that's not a complete sentence anyway, I think "The" isn't necessary. > > - NEW > > + NEW (record) > > The type names should still be wrapped in , like they were befor

Re: plpgsql-trigger.html: Format TG_ variables as table (patch)

me "name of table" to just "table". Since the data type is "name", it's clear what "table" means. Christoph >From a281bbb3ba80e14645f83d464ca6df892a85c1bb Mon Sep 17 00:00:00 2001 From: Christoph Berg Date: Wed, 31 Aug 2022 11:52:50 +0200 Subject: [PAT

Re: plpgsql-trigger.html: Format TG_ variables as table (patch)

ot; or something > similar? Right, that felt strange to me as well, but I couldn't think of something better. "string containing" is again pretty boilerplatish, how about just "contains"? Christoph >From b675a9e63ac663817cf90ca3aee2acf398b3fa97 Mon Sep 17 00:00:00 2001

Re: plpgsql-trigger.html: Format TG_ variables as table (patch)

Sep 17 00:00:00 2001 From: Christoph Berg Date: Wed, 31 Aug 2022 11:52:50 +0200 Subject: [PATCH] plpgsql-trigger.html: Use more concise wording for TG_ variables To improve readability of the TG_ variables definition list, this moves the datatypes up to the defined term to avoid having each en

Re: plpgsql-trigger.html: Format TG_ variables as table (patch)

ginnings of each description: https://www.df7cb.de/s/2022-08-31.115857.LkkKl8.png Christoph >From 61bcef4b3a0a8a17c86114ef9747c6e793a5b48f Mon Sep 17 00:00:00 2001 From: Christoph Berg Date: Wed, 31 Aug 2022 11:52:50 +0200 Subject: [PATCH] plpgsql-trigger.html: Use more concise wording

Re: \pset xheader_width page as default? (Re: very long record lines in expanded psql output)

Re: Pavel Stehule > pspg requires all lines to have the same width. It can do some corrections > - but it is hard to detect wanted differences or just plain text format. > > can be nice to have the first invisible row with some information about > used formatting. pspg does some heuristic but

\pset xheader_width page as default? (Re: very long record lines in expanded psql output)

Re: Andrew Dunstan > >> +   pg_log_error("\\pset: allowed xheader_width values are full > >> (default), column, page, or an number specifying exact width."); > Committed. There were a couple of bits missing, which I filled in, and I > changed the behaviour when the option is given

plpgsql-trigger.html: Format TG_ variables as table (patch)

k. Thanks to ilmari for the idea and some initial reviews. Christoph >From 708c05277e6e2a93e9ceb1e52fda5991cef8b545 Mon Sep 17 00:00:00 2001 From: Christoph Berg Date: Tue, 30 Aug 2022 15:09:39 +0200 Subject: [PATCH] plpgsql-trigger.html: Format TG_ variables as table Format list as table, and r

Re: pg_receivewal and SIGTERM

Re: Daniel Gustafsson > The attached adds the Exit Status section to pg_recvlogical docs which is > present in pg_receivewal to make them more aligned, and tweaks comments to > pgindent standards. This is the version I think is ready to commit. Looks good to me. Thanks, Christoph

Re: pg_receivewal and SIGTERM

Re: Michael Paquier > FWIW, I've worked on an archiver integration a few years ago and got > annoyed that we use SIGINT while SIGTERM was the default (systemd was > not directly used there but the signal problem was the same, so we had > to go through some loops to make the stop signal

Re: pg_receivewal and SIGTERM

hing this stuff is not an issue here. Do you mean it can, or can not be backpatched? (I'd argue for backpatching since the behaviour is slightly broken at the moment.) Christoph >From 3d17d6f77566047fc63e05c2f33106a09b2c9793 Mon Sep 17 00:00:00 2001 From: Christoph Berg Date: Mon, 15 Aug 2022 14:2

Re: pg_receivewal and SIGTERM

Re: Bharath Rupireddy > pg_receivewal will exit with status 0 when > - terminated by the SIGINT signal. (That is the > + terminated by the SIGINT or > + SIGTERM signal. (That is the > normal way to end it. Hence it is not an error.) For fatal errors or > other signals, the

Re: pg_receivewal and SIGTERM

ll run until terminated by the SIGINT > + ( action="simul">ControlC) > + or SIGTERM signal. Coped that from pg_receivewal(1) now. Christoph >From 6c51c559a86754623cd33fe4cef3563c18fccea3 Mon Sep 17 00:00:00 2001 From: Christoph Berg Date: Mon, 15 Aug 2022 14:29:43 +0200 S

Re: pg_receivewal and SIGTERM

Re: Daniel Gustafsson > In general that's a good idea, but they are so trivial that I don't really see > much point in doing that in this particular case. Plus the variable they set is called differently... Christoph

Re: pg_receivewal and SIGTERM

lso a sighup_handler and "sig_handler" would be confusing there. Christoph >From beb3bcb32a9eabf2bf83e259706f89ccdac276d3 Mon Sep 17 00:00:00 2001 From: Christoph Berg Date: Mon, 15 Aug 2022 14:29:43 +0200 Subject: [PATCH] pg_receivewal, pg_recvlogical: Exit cleanly on SIGTERM I

  1   2   3   4   >