Re: [HACKERS] some review comments on logical rep code

On Fri, Apr 21, 2017 at 1:19 AM, Fujii Masao wrote: > On Tue, Apr 18, 2017 at 5:16 PM, Masahiko Sawada > wrote: >> On Tue, Apr 18, 2017 at 12:24 PM, Kyotaro HORIGUCHI >> wrote: >>> Hi, >>> >>> Thank you for the

Re: [HACKERS] Interval for launching the table sync worker

Hello, At Thu, 20 Apr 2017 13:21:14 +0900, Masahiko Sawada wrote in

[HACKERS] On-disk format of SCRAM verifiers

The current format for SCRAM verifiers in pg_authid is: scram-sha-256 While reviewing Michael's patch to change that so that StoredKey and ServerKey are stored base64-encoded, rather than hex-encoded as they are currently [1], I looked again at RFC 5803. RFC 5803 specifies the format to

[HACKERS] Triggers and logical replication (10devel)

Hello, It seams that tiggers don't fire on subscriber's tables during logical replication. Is it a bug? # # publisher: simple table and publication # postgres@publisher=# SELECT version(); version

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Apr 21, 2017 at 1:34 AM, Robert Haas wrote: >> You seem to be suggesting that we keep as many sets of >> partition bounds as there are base relations participating in the join >> and then use appropriate partition bounds based on the columns in the >> join

Re: [HACKERS] identity columns

On Tue, Apr 18, 2017 at 11:53:36AM -0400, Peter Eisentraut wrote: > On 4/18/17 02:07, Noah Misch wrote: > > This PostgreSQL 10 open item is past due for your status update. Kindly > > send > > a status update within 24 hours, and include a date for your subsequent > > status > > update. Refer

Re: [HACKERS] some review comments on logical rep code

On Fri, Apr 21, 2017 at 11:55 AM, Masahiko Sawada wrote: > On Fri, Apr 21, 2017 at 4:41 AM, Peter Eisentraut > wrote: >> On 4/20/17 12:30, Fujii Masao wrote: >>> I've pushed several patches, and there is now only one remaining patch. >>> I

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Fri, Apr 21, 2017 at 01:20:05PM +0900, Masahiko Sawada wrote: > On Fri, Apr 21, 2017 at 12:02 PM, Noah Misch wrote: > > On Wed, Apr 19, 2017 at 01:52:53PM +0900, Masahiko Sawada wrote: > >> On Wed, Apr 19, 2017 at 12:34 PM, Noah Misch wrote: > >> > On

Re: [HACKERS] Declarative partitioning - another take

Hi, I have observed below with the statement triggers. I am able to create statement triggers at root partition, but these triggers, not getting fired on updating partition. CREATE TABLE pt (a INT, b INT) PARTITION BY RANGE(a); CREATE TABLE pt1 PARTITION OF pt FOR VALUES FROM (1) to (7); CREATE

[HACKERS] Why is get_cheapest_parallel_safe_total_inner() in pathkeys.c?

This probably ended up here because there's a bunch of other functions named get_cheapest* in that file, but all of those relate to getting a path for specific PathKeys. get_cheapest_parallel_safe_total_inner() does not do that. Maybe allpaths.c is a better home for it? It seems to have been

Re: [HACKERS] WITH clause in CREATE STATISTICS

On 21 April 2017 at 22:30, Tels wrote: > I'd rather see: > > CREATE STATISTICS stats_name ON table(col); > > as this both mirrors CREATE INDEX and foreign keys with REFERENCES. It > could also be extended to both more columns, expressions or other tables > like so:

Re: [HACKERS] On-disk format of SCRAM verifiers

Heikki, * Heikki Linnakangas (hlinn...@iki.fi) wrote: > I think we should adopt that exact format, so that our verifiers are > compatible with RFC 5803. It doesn't make any immediate difference, > but since there is a standard out there, might as well follow it. +1 > And just in case we get

Re: [HACKERS] WITH clause in CREATE STATISTICS

Moin, On Thu, April 20, 2017 8:21 pm, Tomas Vondra wrote: > On 04/21/2017 12:13 AM, Tom Lane wrote: >> Alvaro Herrera writes: >>> Simon just pointed out that having the WITH clause appear in the middle >>> of the CREATE STATISTICS command looks odd; apparently somebody

Re: [HACKERS] dtrace probes

On 04/20/2017 10:30 AM, Jesper Pedersen wrote: I think this fix is harmless and has some value in terms of consistency. One minor suggestion is that you should leave a space after typecasting. - TRACE_POSTGRESQL_LWLOCK_WAIT_DONE(T_NAME(lock), mode); +

Re: [HACKERS] On-disk format of SCRAM verifiers

On Fri, Apr 21, 2017 at 9:25 PM, Stephen Frost wrote: > * Heikki Linnakangas (hlinn...@iki.fi) wrote: >> I think we should adopt that exact format, so that our verifiers are >> compatible with RFC 5803. It doesn't make any immediate difference, >> but since there is a standard

Re: [HACKERS] Triggers and logical replication (10devel)

On 21.04.2017 16:29, Merlin Moncure wrote: On Fri, Apr 21, 2017 at 5:08 AM, Egor Rogov wrote: Hello, It seams that tiggers don't fire on subscriber's tables during logical replication. Is it a bug? Reading the documentation (which is TBH a bit hard to follow) it

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 4/20/17 14:29, Petr Jelinek wrote: > + /* Find unused worker slot. */ > + if (!w->in_use) > { > - worker = >workers[slot]; > - break; > + worker = w; > + slot = i; > +

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 4/20/17 22:24, Noah Misch wrote: > On Mon, Apr 17, 2017 at 02:09:54PM -0400, Peter Eisentraut wrote: >> I think we're not really sure yet what to do about this. Discussion is >> ongoing. I'll report back on Wednesday. > > This PostgreSQL 10 open item is past due for your status update, and

Re: [HACKERS] subscription worker doesn't start immediately on eabled

On 4/6/17 08:24, Kyotaro HORIGUCHI wrote: > Hello. I found dubious behavior while playing with logical > replication. > > When we disable a subscription, replication worker immediately stops. > > =# ALTER SUBSCRIPTION s1 DISABLE; > > On the other hand even if we enable a subscription, worker >

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

On 4/20/17 22:57, Michael Paquier wrote: > On Fri, Apr 21, 2017 at 11:34 AM, Petr Jelinek > wrote: >> On 20/04/17 23:30, Peter Eisentraut wrote: >>> On 4/20/17 10:19, Petr Jelinek wrote: Hmm well since this only affects the synchronization of table

Re: [HACKERS] On-disk format of SCRAM verifiers

On 21 April 2017 at 10:20, Heikki Linnakangas wrote: > But looking more closely, I think I misunderstood RFC 5803. It *does* in > fact specify a single string format to store the verifier in. And the format > looks like: > > SCRAM-SHA-256$:$: Could you explain where you are

[HACKERS] Old versions of Test::More

As we discovered yesterday via jacana, very old versions of Test::More don't support the note() function. It therefore seems prudent to specify a minimum version number for the module in those scripts that use the function. According to the changelog, version 0.82 (released in Oct 2008) should be

Re: [HACKERS] Triggers and logical replication (10devel)

On Fri, Apr 21, 2017 at 5:08 AM, Egor Rogov wrote: > Hello, > It seams that tiggers don't fire on subscriber's tables during logical > replication. Is it a bug? Reading the documentation (which is TBH a bit hard to follow) it appears that it is expected behavior.

Re: [HACKERS] On-disk format of SCRAM verifiers

Michael Paquier writes: > On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs wrote: >> On 21 April 2017 at 10:20, Heikki Linnakangas wrote: >>> But looking more closely, I think I misunderstood RFC 5803. It *does* in >>> fact

Re: [HACKERS] On-disk format of SCRAM verifiers

On 21 April 2017 at 14:20, Michael Paquier wrote: > On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs wrote: >> On 21 April 2017 at 10:20, Heikki Linnakangas wrote: >>> But looking more closely, I think I misunderstood RFC 5803. It

Re: [HACKERS] On-disk format of SCRAM verifiers

On 21 April 2017 16:20:56 EEST, Michael Paquier wrote: >On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs >wrote: >> On 21 April 2017 at 10:20, Heikki Linnakangas >wrote: >>> But looking more closely, I think I misunderstood RFC

Re: [HACKERS] Interval for launching the table sync worker

On 21/04/17 04:38, Masahiko Sawada wrote: > On Thu, Apr 20, 2017 at 8:43 PM, Petr Jelinek > wrote: >> On 20/04/17 06:21, Masahiko Sawada wrote: >>> On Thu, Apr 20, 2017 at 12:30 AM, Petr Jelinek >>> wrote: On 19/04/17 15:57,

Re: [HACKERS] Interval for launching the table sync worker

On 21/04/17 10:33, Kyotaro HORIGUCHI wrote: > Hello, > > At Thu, 20 Apr 2017 13:21:14 +0900, Masahiko Sawada > wrote in

Re: [HACKERS] On-disk format of SCRAM verifiers

On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs wrote: > On 21 April 2017 at 10:20, Heikki Linnakangas wrote: >> But looking more closely, I think I misunderstood RFC 5803. It *does* in >> fact specify a single string format to store the verifier in. And the

Re: [HACKERS] WITH clause in CREATE STATISTICS

Moin, On Fri, April 21, 2017 7:04 am, David Rowley wrote: > On 21 April 2017 at 22:30, Tels wrote: >> I'd rather see: >> >> CREATE STATISTICS stats_name ON table(col); >> >> as this both mirrors CREATE INDEX and foreign keys with REFERENCES. It >> could also be

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 21/04/17 16:09, Peter Eisentraut wrote: > On 4/20/17 14:29, Petr Jelinek wrote: >> +/* Find unused worker slot. */ >> +if (!w->in_use) >> { >> -worker = >workers[slot]; >> -break; >> +worker = w; >>

Re: [HACKERS] Old versions of Test::More

On 04/21/2017 10:36 AM, Daniel Gustafsson wrote: >> On 21 Apr 2017, at 15:08, Andrew Dunstan >> wrote: >> >> As we discovered yesterday via jacana, very old versions of Test::More >> don't support the note() function. It therefore seems prudent to specify >> a

Re: [HACKERS] Unportable implementation of background worker start

Andres Freund writes: > On 2017-04-20 00:50:13 -0400, Tom Lane wrote: >> My first reaction was that that sounded like a lot more work than removing >> two lines from maybe_start_bgworker and adjusting some comments. But on >> closer inspection, the slow-bgworker-start issue

Re: [HACKERS] Interval for launching the table sync worker

On Fri, Apr 21, 2017 at 5:33 PM, Kyotaro HORIGUCHI wrote: > Hello, > > At Thu, 20 Apr 2017 13:21:14 +0900, Masahiko Sawada > wrote in

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 4/21/17 10:11, Petr Jelinek wrote: > On 21/04/17 16:09, Peter Eisentraut wrote: >> On 4/20/17 14:29, Petr Jelinek wrote: >>> + /* Find unused worker slot. */ >>> + if (!w->in_use) >>> { >>> - worker = >workers[slot]; >>> -

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 21/04/17 16:23, Peter Eisentraut wrote: > On 4/21/17 10:11, Petr Jelinek wrote: >> On 21/04/17 16:09, Peter Eisentraut wrote: >>> On 4/20/17 14:29, Petr Jelinek wrote: + /* Find unused worker slot. */ + if (!w->in_use) { - worker

Re: [HACKERS] On-disk format of SCRAM verifiers

On 21 April 2017 at 14:42, Heikki Linnakangas wrote: SCRAM-SHA-256$:$: >>> >>> Could you explain where you are looking? I don't see that in RFC5803 >> > >From 1. Overview: > > Yeah, it's not easy to see, I missed it earlier too. You have to look at RFC > 5803 and RFC 3112

Re: [HACKERS] Old versions of Test::More

> On 21 Apr 2017, at 15:08, Andrew Dunstan > wrote: > > As we discovered yesterday via jacana, very old versions of Test::More > don't support the note() function. It therefore seems prudent to specify > a minimum version number for the module in those scripts

Re: [HACKERS] Old versions of Test::More

Andrew Dunstan writes: > As we discovered yesterday via jacana, very old versions of Test::More > don't support the note() function. It therefore seems prudent to specify > a minimum version number for the module in those scripts that use the > function. According

Re: [HACKERS] Unportable implementation of background worker start

Tom Lane wrote: > After sleeping and thinking more, I've realized that the > slow-bgworker-start issue actually exists on *every* platform, it's just > harder to hit when select() is interruptable. But consider the case > where multiple bgworker-start requests arrive while ServerLoop is >

Re: [HACKERS] Unportable implementation of background worker start

Attached is a lightly-tested draft patch that converts the postmaster to use a WaitEventSet for waiting in ServerLoop. I've got mixed emotions about whether this is the direction to proceed, though. It adds at least a couple of kernel calls per postmaster signal delivery, and probably to every

Re: [HACKERS] Range Merge Join v1

Hi, Jeff! I'm planning to provide the review for this patch in future. I've done some performance tesing (see attachment). All in all, nothing important, everything works fine. Tests were executed under current HEAD on Ubuntu 16 over MacBook Air. I observe that: 1. Patch brings performance

Re: [HACKERS] Unportable implementation of background worker start

I wrote: > Attached is a lightly-tested draft patch that converts the postmaster to > use a WaitEventSet for waiting in ServerLoop. I've got mixed emotions > about whether this is the direction to proceed, though. Attached are a couple of patches that represent a plausible Plan B. The first one

Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders

On Sat, Apr 22, 2017 at 9:04 AM, Tom Lane wrote: > Alvaro Herrera writes: >> Simon Riggs wrote: >>> Replication lag tracking for walsenders >>> >>> Adds write_lag, flush_lag and replay_lag cols to pg_stat_replication. > >> Did anyone notice that this

Re: [HACKERS] Unportable implementation of background worker start

On 2017-04-21 23:50:41 -0400, Tom Lane wrote: > Attached are a couple of patches that represent a plausible Plan B. > The first one changes the postmaster to run its signal handlers without > specifying SA_RESTART. I've confirmed that that seems to fix the > select_parallel-test-takes-a-long-time

Re: [HACKERS] snapbuild woes

On 2017-04-17 21:16:57 -0700, Andres Freund wrote: > I've since the previous update reviewed Petr's patch, which he since has > updated over the weekend. I'll do another round tomorrow, and will see > how it looks. I think we might need some more tests for this to be > committable, so it might

Re: [HACKERS] pgbench - allow to store select results into variables

Here is a v3 with a more precise comment. Looks good to me. I have marked the patch status as "Ready for committer". Ok. Thanks. When/if committed, it might trigger a few rebase of other pending patches. I'll see about that then. -- Fabien. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] snapbuild woes

On 2017-04-20 13:32:10 +0200, Petr Jelinek wrote: > On 20/04/17 02:09, Andres Freund wrote: > > On 2017-04-17 21:16:57 -0700, Andres Freund wrote: > > I'm working on some infrastructure around this. Not sure if it needs to > > be committed, but it's certainly useful for evaluation. Basically

Re: [HACKERS] Unportable implementation of background worker start

Hi, On 2017-04-21 12:50:04 -0400, Tom Lane wrote: > Attached is a lightly-tested draft patch that converts the postmaster to > use a WaitEventSet for waiting in ServerLoop. I've got mixed emotions > about whether this is the direction to proceed, though. It adds at least > a couple of kernel

Re: [HACKERS] Unportable implementation of background worker start

Alvaro Herrera writes: > Tom Lane wrote: >> I'm coming back to the idea that at least in the back branches, the >> thing to do is allow maybe_start_bgworker to start multiple workers. >> >> Is there any actual evidence for the claim that that might have >> bad side

Re: [HACKERS] Unportable implementation of background worker start

Andres Freund writes: > On 2017-04-21 12:50:04 -0400, Tom Lane wrote: >> Attached is a lightly-tested draft patch that converts the postmaster to >> use a WaitEventSet for waiting in ServerLoop. I've got mixed emotions >> about whether this is the direction to proceed,

Re: [HACKERS] Unportable implementation of background worker start

Andres Freund writes: > On 2017-04-21 14:08:21 -0400, Tom Lane wrote: >> but I see that SUSv2 >> mandates that fcntl.h provide both F_SETFD and FD_CLOEXEC, so by our own >> coding rules it ought to be okay to assume they're there. I'm tempted to >> rip out the quoted bit, as

Re: [HACKERS] Unportable implementation of background worker start

I wrote: > Andres Freund writes: >> On 2017-04-21 12:50:04 -0400, Tom Lane wrote: >>> +#ifndef FD_CLOEXEC >>> +#define FD_CLOEXEC 1 >>> +#endif >> Hm? Are we sure this is portable? Is there really cases that have >> F_SETFD, but not CLOEXEC? > Copied-and-pasted from our

Re: [HACKERS] Unportable implementation of background worker start

On 2017-04-21 14:08:21 -0400, Tom Lane wrote: > but I see that SUSv2 > mandates that fcntl.h provide both F_SETFD and FD_CLOEXEC, so by our own > coding rules it ought to be okay to assume they're there. I'm tempted to > rip out the quoted bit, as well as the #ifdef F_SETFD, from libpq and see >

Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders

Simon Riggs wrote: > Replication lag tracking for walsenders > > Adds write_lag, flush_lag and replay_lag cols to pg_stat_replication. Did anyone notice that this seems to be causing buildfarm member 'tern' to fail the recovery check? See here:

Re: [HACKERS] Old versions of Test::More

On 4/21/17 14:49, Andrew Dunstan wrote: > I'll add a comment, but doing it in PostgresNode.pm would mean jacana > (for instance) couldn't run any of the TAP tests. I'mm looking at > installing a sufficiently modern Test::Simple package (includes > Test::More and test::Build) there, but other

Re: [HACKERS] On-disk format of SCRAM verifiers

On 04/21/2017 05:33 PM, Simon Riggs wrote: On 21 April 2017 at 14:42, Heikki Linnakangas wrote: SCRAM-SHA-256$:$: Could you explain where you are looking? I don't see that in RFC5803 >From 1. Overview: Yeah, it's not easy to see, I missed it earlier too. You have to

Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders

On 2017-04-21 17:04:08 -0400, Tom Lane wrote: > Some excavation in the buildfarm database says that the coverage for > the recovery-check test has been mighty darn thin up until just > recently. Hm, not good. Just enabled it for most of my animals (there seems to be no point in having it on the

Re: [HACKERS] Old versions of Test::More

On 04/21/2017 10:45 AM, Tom Lane wrote: > Andrew Dunstan writes: >> As we discovered yesterday via jacana, very old versions of Test::More >> don't support the note() function. It therefore seems prudent to specify >> a minimum version number for the module in

Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders

Alvaro Herrera writes: > Simon Riggs wrote: >> Replication lag tracking for walsenders >> >> Adds write_lag, flush_lag and replay_lag cols to pg_stat_replication. > Did anyone notice that this seems to be causing buildfarm member 'tern' > to fail the recovery check?

Re: [HACKERS] Unportable implementation of background worker start

Tom, On 2017-04-21 13:49:27 -0400, Tom Lane wrote: > >> * If we are in PM_WAIT_DEAD_END state, then we don't want to accept > >> - * any new connections, so we don't call select(), and just > >> sleep. > >> + * any new connections, so we don't call WaitEventSetWait(), > >>

Re: [HACKERS] Unportable implementation of background worker start

Tom Lane writes: > Andres Freund writes: >> On 2017-04-21 14:08:21 -0400, Tom Lane wrote: >>> but I see that SUSv2 >>> mandates that fcntl.h provide both F_SETFD and FD_CLOEXEC, so by our own >>> coding rules it ought to be okay to assume they're there.

Re: [HACKERS] Old versions of Test::More

Peter Eisentraut writes: > On 4/21/17 14:49, Andrew Dunstan wrote: >> I'll add a comment, but doing it in PostgresNode.pm would mean jacana >> (for instance) couldn't run any of the TAP tests. I'mm looking at >> installing a sufficiently modern Test::Simple

[HACKERS] Missing feature in Phrase Search?

Oleg, Teodor, folks: I was demo'ing phrase search for a meetup yesterday, and the user feedback I got showed that there's a missing feature with phrase search. Let me explain by example: 'fix <-> error' will match 'fixed error', 'fixing error' but not 'fixed language error' or 'fixed a small

Re: [HACKERS] scram and \password

On 04/10/2017 08:42 AM, Michael Paquier wrote: As there have been some conflicts because of the commit of SASLprep, here is a rebased set of patches. I've committed a modified version of the first patch, to change the on-disk format to RFC 5803, as mentioned on the other thread

Re: [HACKERS] some review comments on logical rep code

On Fri, Apr 21, 2017 at 4:02 PM, Masahiko Sawada wrote: > On Fri, Apr 21, 2017 at 1:19 AM, Fujii Masao wrote: >> On Tue, Apr 18, 2017 at 5:16 PM, Masahiko Sawada >> wrote: >>> On Tue, Apr 18, 2017 at 12:24 PM, Kyotaro

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

On Fri, Apr 21, 2017 at 1:43 AM, Stephen Frost wrote: >> + Once >> + partitions exist, we do not support using ONLY to >> + add or drop constraints on only the partitioned table. >> >> I wonder if the following sounds a bit more informative: Once partitions >>

[HACKERS] multithreading in Batch/pipelining mode for libpq

Hello, I'm investigating Batch/pipelining mode for libpq connected to this thread: https://www.postgresql.org/message-id/flat/CADT4RqA6XoDCVY-G13ME1oRVshE2oNk4fRHKZC0K-jJymQJV0Q%40mail.gmail.com#cadt4rqa6xodcvy-g13me1orvshe2onk4frhkzc0k-jjymqj...@mail.gmail.com And I'm wondering, what are the

Re: [HACKERS] Why is get_cheapest_parallel_safe_total_inner() in pathkeys.c?

On Fri, Apr 21, 2017 at 12:10 PM, David Rowley wrote: > This probably ended up here because there's a bunch of other functions > named get_cheapest* in that file, but all of those relate to getting a > path for specific PathKeys.

Re: [HACKERS] multithreading in Batch/pipelining mode for libpq

On 2017-04-22 09:14:50 +0800, Craig Ringer wrote: > 2) if the answer to the previous question is negative, is it possible to > send asynchronous queries in one thread while reading results in another > thread? > > > Not right now. libpq's state tracking wouldn't cope. > > I imagine it could be

Re: [HACKERS] Unportable implementation of background worker start

Alvaro Herrera writes: > Tom Lane wrote: >> It also appears to me that do_start_bgworker's treatment of fork >> failure is completely brain dead. Did anyone really think about >> that case? > Hmm, I probably modelled it on autovacuum without giving that case much >

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Apr 21, 2017 at 8:41 AM, Ashutosh Bapat wrote: > I don't see how is that fixed. For a join relation we need to come up > with one set of partition bounds by merging partition bounds of the > joining relation and in order to understand how to interpret the

Re: [HACKERS] scram and \password

On Sat, Apr 22, 2017 at 5:04 AM, Heikki Linnakangas wrote: > I'll continue reviewing the rest of the patch on Monday, but one glaring > issue is that we cannot add an argument to the existing libpq > PQencryptPassword() function, because that's part of the public API. It > would

Re: [HACKERS] multithreading in Batch/pipelining mode for libpq

On 22 Apr. 2017 6:04 am, "Ilya Roublev" wrote: 1) is it possible technically (possibly by changing some part of libpq code) to ignore results (especially for this sort of queries like insert), processing somehow separately the situation when some error occurs? There is a

Re: [HACKERS] Old versions of Test::More

On 22 Apr. 2017 4:23 am, "Tom Lane" wrote: Peter Eisentraut writes: > On 4/21/17 14:49, Andrew Dunstan wrote: >> I'll add a comment, but doing it in PostgresNode.pm would mean jacana >> (for instance) couldn't run any of the TAP tests. I'mm