Re: Missing Column names with multi-insert

On 2/18/19 2:34 PM, Liz Frost wrote: > Hello all, > > I'm working on a foreign data wrapper that uses INSERT, and I noticed > some odd behaviour. If I insert just one row, the > TupleDesc->attr[0]->attname.data has the column names in it. However, > in a multi-row string, all those are empty

RE: [PATCH] Fix Proposal - Deadlock Issue in Single User Mode When IO Failure Occurs

Thank you so much Amit! I have created the patch below: https://commitfest.postgresql.org/22/2003/ Please let me know should you have more suggestions. Thank you! Best regards, -- Chengchao Yu Software Engineer | Microsoft | Azure Database for PostgreSQL

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Hi, On 2019-02-18 20:29:29 -0500, Tom Lane wrote: > Andres Freund writes: > > but it's smaller (althoug there's plenty trailing space). > > I think you're supposing that these things are independently palloc'd, but > they aren't --- dynahash lays them out in arrays without palloc padding. I

Re: Prepared transaction releasing locks before deregistering its GID

On Mon, Feb 18, 2019 at 05:05:13PM +0100, Oleksii Kliukin wrote: > That looks like a race condition to me. What happens is that another > transaction with the name identical to the running one can start and proceed > to the prepare phase while the original one commits, failing at last instead > of

Re: Reaping Temp tables to avoid XID wraparound

On Tue, Feb 19, 2019 at 10:52:54AM +1100, James Sewell wrote: > I agree the use case is narrow - but it's also pretty critical. Yeah.. > I suppose an in-core way of disconnecting idle sessions after x time would > work too - but that seems like a sledgehammer approach. Such solutions at SQL

[Bug Fix] ECPG: could not use set xxx to default statement

Hi, I found ECPG's bug which SET xxx = DEFAULT statement could not be used. [PROBLEM] When the source code (*.pgc) has "EXEC SQL set xxx = default;", created c program by ECPG has no " = default". For example, "EXEC SQL set search_path = default;" in *.pgc will be converted to "{

Re: Prepared transaction releasing locks before deregistering its GID

On 2019-Feb-19, Michael Paquier wrote: > diff --git a/src/include/access/twophase.h b/src/include/access/twophase.h > index 6228b091d8..2dcd08e9fa 100644 > --- a/src/include/access/twophase.h > +++ b/src/include/access/twophase.h > @@ -34,7 +34,7 @@ extern void TwoPhaseShmemInit(void); > extern

Re: [Bug Fix] ECPG: could not use set xxx to default statement

"Higuchi, Daisuke" writes: > [ missing semicolon in gram.y breaks ecpg parsing of same construct ] That's pretty nasty. The fix in gram.y is certainly needed, but I'm unexcited by the regression test additions you propose. What I really want to know is why a syntax error in gram.y wasn't

Re: Prevent extension creation in temporary schemas

On Mon, Feb 18, 2019 at 05:39:09AM +, Kuroda, Hayato wrote: > I seem this patch is enough, but could you explain the reason > you drop initial proposal more detail? > I'm not sure why extensions contained by temporary schemas are > acceptable. Because there are cases where they actually

Re: Prevent extension creation in temporary schemas

On Mon, Feb 18, 2019 at 08:02:54PM +0900, Masahiko Sawada wrote: > I'd vote for accepting the extension creation in temporary schemas and > fixing \dx and \dx+. Thanks. > However the error raised by creating extensions > in temporary schema still looks strange to me. Since we don't search >

Re: Prepared transaction releasing locks before deregistering its GID

On Tue, Feb 19, 2019 at 01:07:06AM -0300, Alvaro Herrera wrote: > On 2019-Feb-19, Michael Paquier wrote: >> extern GlobalTransaction MarkAsPreparing(TransactionId xid, const char *gid, > > Hmm, ABI break ... Well, sure. I always post patches for HEAD first. And I was actually wondering if

Re: Offline enabling/disabling of data checksums

On Sun, Feb 17, 2019 at 07:31:38PM +0100, Michael Banck wrote: > New patch attached. - * src/bin/pg_verify_checksums/pg_verify_checksums.c + * src/bin/pg_checksums/pg_checksums.c That's lacking a rename, or this comment is incorrect. +#if PG_VERSION_NUM >= 10 +

Re: [Bug Fix] ECPG: could not use set xxx to default statement

I wrote: > "Higuchi, Daisuke" writes: >> [ missing semicolon in gram.y breaks ecpg parsing of same construct ] > That's pretty nasty. The fix in gram.y is certainly needed, but I'm > unexcited by the regression test additions you propose. What I really > want to know is why a syntax error in

Re: Prevent extension creation in temporary schemas

Michael Paquier writes: > On Mon, Feb 18, 2019 at 05:39:09AM +, Kuroda, Hayato wrote: >> I'm not sure why extensions contained by temporary schemas are >> acceptable. > Because there are cases where they actually work. More to the point, it doesn't seem that hard to think of cases where

Re: 2019-03 CF Summary / Review - Tranche #2

On 2/19/19 1:23 AM, Tom Lane wrote: Andrew Dunstan writes: On 2/18/19 12:43 PM, Tom Lane wrote: Andres Freund writes: It's CF app nannyism. One can't move a patch to the next CF that's waiting-on-author. I've complained about that a number of times, but... So change it to another state,

RE: Protect syscache from bloating with negative cache entries

Hi Horiguchi-san, This is the rest of my review comments. (5) patch 0003 CatcacheClockTimeoutPending = 0; + + /* Update timetamp then set up the next timeout */ + false is better than 0, to follow other **Pending variables. timetamp -> timestamp (6) patch 0003

RE: SQL statement PREPARE does not work in ECPG

Hi I think SQL statement PREPARE *without* parameter is supported, but one with parameter is not supported (or has some fatal bugs). Because route for SQL statement PREPARE (line-1837 of preproc.y) always has output an invalid SQL statement and there is no regression test for SQL statement

Some thoughts on NFS

Hello hackers, As discussed in various threads, PostgreSQL-on-NFS is viewed with suspicion. Perhaps others knew this already, but I first learned of the specific mechanism (or at least one of them) for corruption from Craig Ringer's writing[1] about fsync() on Linux. The problem is that close()

RE: Protect syscache from bloating with negative cache entries

From: 'Bruce Momjian' [mailto:br...@momjian.us] > I think, in general, smaller is better, as long as making something > smaller doesn't remove data that is frequently accessed. Having a timer > to expire only old entries seems like it accomplished this goal. > > Having a minimum size and not

Re: Change of email address

On Tue, Feb 19, 2019 at 6:54 PM Shawn Debnath wrote: > On Tue, Feb 19, 2019 at 03:54:59PM +1300, Thomas Munro wrote: > > This change is just to avoid sending automated corporate footer messages > > that are intended for a different audience, in line with standard mailing > > list etiquette. > > >

Re: proposal: pg_restore --convert-to-text

Em qui, 14 de fev de 2019 às 22:41, Andreas Karlsson escreveu: > Agreed, "-f -" would be acceptable. I use pg_restore to stdout a lot, > but almost always manually and would have to have to remember and type > "--convert-to-text". > Since no one has stepped up, I took a stab at it. It will

Re: Delay locking partitions during INSERT and UPDATE

David Rowley writes: > On Tue, 19 Feb 2019 at 11:47, Tom Lane wrote: >> Are we talking about the same patch? The one I'm looking at seems >> to be mostly planner and plancache changes: > Looks like you're looking at the patch from the "Delay locking > partitions during query execution" thread

RE: Protect syscache from bloating with negative cache entries

Hi Horiguchi-san, I've looked through your patches. This is the first part of my review results. Let me post the rest after another work today. BTW, how about merging 0003 and 0005, and separating and deferring 0004 in another thread? That may help to relieve other community members by

RE: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax

Hi, Meskes-san > Thank you, committed. Thank you! By the way, I have found another bugs which are related to ECPG , so I will post that later. Regards, Daisuke, Higuchi

Re: Delay locking partitions during query execution

On Tue, 19 Feb 2019 at 12:50, Tom Lane wrote: > > [ reposting some questions asked in the wrong thread ] > > What I'd like to understand about this patch is how it relates > to Amit L.'s work on making the planner faster for partitioned > UPDATE/DELETE cases

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Hi, On 2019-02-18 19:13:31 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2019-02-18 19:01:06 -0500, Tom Lane wrote: > >> Mmm ... AIUI, the patches currently proposed can only help for what > >> David called "point lookup" queries. There are still going to be > >> queries that scan a

RE: speeding up planning with partitions

On Mon, Feb 18, 2019 at 5:28 PM, Tom Lane wrote: > Frankly, that code is just horrid. Having a function with side effects > in an if-test is questionable at the best of times, and having it be the > second of three conditions (which the third condition silently depends > on) is unreadable and

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Andres Freund writes: > On 2019-02-18 19:24:54 -0500, Tom Lane wrote: >> Yeah, but if we want to rearrange the members into an illogical order >> to save some space, we should do that independently of this patch --- > Sure, we should do that. I don't buy the "illogical" bit, just moving >

Change of email address

Hello hackers, I am switching to this new email address for PostgreSQL mailing lists. I just wanted you to know that I'm still reachable at my EnterpriseDB address and I'm still happily employed by EnterpriseDB, working on PostgreSQL! This change is just to avoid sending automated corporate

Re: Delay locking partitions during INSERT and UPDATE

What I'd like to understand about this patch is how it relates to Amit L.'s work on making the planner faster for partitioned UPDATE/DELETE cases (https://commitfest.postgresql.org/22/1778/). I think that that might render this moot? And if it doesn't, how much does it really matter? You can't

Re: Inadequate executor locking of indexes

On Tue, 12 Feb 2019 at 09:58, Julien Rouhaud wrote: > > On Mon, Feb 11, 2019 at 5:32 AM David Rowley > wrote: > > 1. Adding a new field to RangeTblEntry to indicate the operation type > > that's being performed on the relation; or > > 2. Adding a Bitmapset field to PlannerGlobal that sets the

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Andres Freund writes: > On 2019-02-18 19:01:06 -0500, Tom Lane wrote: >> Mmm ... AIUI, the patches currently proposed can only help for what >> David called "point lookup" queries. There are still going to be >> queries that scan a large proportion of a partition tree, so if you've >> got tons

Re: speeding up planning with partitions

Thanks for looking. On 2019/02/19 2:27, Tom Lane wrote: > Amit Langote writes: >> [ v22 patch set ] > > I started to look at this, and immediately choked on the 0001 patch: > > if (childpruned || > !apply_child_basequals(root, rel, childrel, childRTE, appinfo) || >

Re: crash in pg_identify_object_as_address

On Mon, Feb 18, 2019 at 05:13:27PM -0500, Tom Lane wrote: > Hm, does this overlap with Paquier's much-delayed patch in > https://commitfest.postgresql.org/22/1947/ It partially overlaps, still my patch set would crash as well in that case. Treating object_names the same way as object_args sounds

RE: libpq debug log

Hi Iwata-san, Currently, the patch fails to build according to CF app. As you know, it has something to do with the misspelling of function. GetTimezoneInformation --> GetTimeZoneInformation It sounds more logical to me if there is a parameter that switches on/off the logging similar to other

Re: proposal: pg_restore --convert-to-text

Euler Taveira writes: > Since no one has stepped up, I took a stab at it. It will prohibit > standard output unless '-f -' be specified. -l option also has the > same restriction. Hm, don't really see the need to break -l usage here. Pls add to next CF, if you didn't already.

Re: 2019-03 CF Summary / Review - Tranche #2

On 2/18/19 12:43 PM, Tom Lane wrote: > Andres Freund writes: >> On 2019-02-18 12:37:27 -0500, Tom Lane wrote: >>> Can't you do it now? The status summary line already shows one >>> patch as having been pushed to the next CF. >> It's CF app nannyism. One can't move a patch to the next CF that's

Re: Speed up transaction completion faster after many relations are accessed in a transaction

On Tue, 19 Feb 2019 at 12:56, Andres Freund wrote: > Isn't a large portion of benefits in this patch going to be mooted by > the locking improvements discussed in the other threads? I.e. there's > hopefully not going to be a ton of cases with low overhead where we > acquire a lot of locks and

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Andres Freund writes: > On 2019-02-18 18:42:32 -0500, Tom Lane wrote: >> Do we really want a dlist here at all? I'm concerned that bloating >> LOCALLOCK will cost us when there are many locks involved. This patch >> increases the size of LOCALLOCK by 25% if I counted right, which does >> not

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Hi, On 2019-02-18 19:24:54 -0500, Tom Lane wrote: > Yeah, but if we want to rearrange the members into an illogical order > to save some space, we should do that independently of this patch --- Sure, we should do that. I don't buy the "illogical" bit, just moving hashcode up to after tag isn't

Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's

James Coleman writes: > I forgot to update in v8 so attaching v9. So ... this is actively wrong. This case shows that you can't ignore the empty-array possibility for a ScalarArrayOpExpr with useOr = false, because "SELECT null::int = all(array[]::int[])" yields TRUE: contrib_regression=#

Re: Delay locking partitions during INSERT and UPDATE

On Tue, 19 Feb 2019 at 11:47, Tom Lane wrote: > Are we talking about the same patch? The one I'm looking at seems > to be mostly planner and plancache changes: > > src/backend/catalog/dependency.c | 1 + > src/backend/commands/createas.c | 1 + >

Re: Speed up transaction completion faster after many relations are accessed in a transaction

"Tsunakawa, Takayuki" writes: > The attached patch speeds up transaction completion when any prior > transaction accessed many relations in the same session. Hm. Putting a list header for a purely-local data structure into shared memory seems quite ugly. Isn't there a better place to keep

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Hi, On 2019-02-19 12:52:08 +1300, David Rowley wrote: > On Tue, 19 Feb 2019 at 12:42, Tom Lane wrote: > > My own thought about how to improve this situation was just to destroy > > and recreate LockMethodLocalHash at transaction end (or start) > > if its size exceeded $some-value. Leaving it

Re: Speed up transaction completion faster after many relations are accessed in a transaction

David Rowley writes: > On Tue, 19 Feb 2019 at 12:42, Tom Lane wrote: >> My own thought about how to improve this situation was just to destroy >> and recreate LockMethodLocalHash at transaction end (or start) >> if its size exceeded $some-value. Leaving it permanently bloated seems >> like

SQL statement PREPARE does not work in ECPG

Hi, In the PostgreSQL Documentation, both ECPG PREPARE and SQL statement PREPARE can be used in ECPG [1]. However, SQL statement PREPARE does not work. I wrote the source code as follows. EXEC SQL PREPARE test_prep (int) AS SELECT id from test_table where id =

Re: speeding up planning with partitions

"Imai, Yoshikazu" writes: > ISTM the 0004 patch eventually removes these codes from multiple places > (set_append_rel_size and set_inherited_target_rel_sizes) so we might be > better to not be struggling here? Yeah, Amit just pointed that out (and I'd not read 0004 before reacting to 0001).

Re: crash in pg_identify_object_as_address

Alvaro Herrera writes: > I just came across a crash while debugging some corrupted system > catalogs; pg_identify_object_as_address fails to cope with some NULL > input, causing a crash. Attached patch fixes it. Naturally, the output > array will contain NULL members in the output, but that's

Re: Delay locking partitions during INSERT and UPDATE

David Rowley writes: > On Tue, 19 Feb 2019 at 11:11, Tom Lane wrote: >> What I'd like to understand about this patch is how it relates >> to Amit L.'s work on making the planner faster for partitioned >> UPDATE/DELETE cases (https://commitfest.postgresql.org/22/1778/). >> I think that that might

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Hi, On 2019-02-18 18:42:32 -0500, Tom Lane wrote: > "Tsunakawa, Takayuki" writes: > > The attached patch speeds up transaction completion when any prior > > transaction accessed many relations in the same session. > > Hm. Putting a list header for a purely-local data structure into shared >

Re: Delay locking partitions during INSERT and UPDATE

On Tue, 19 Feb 2019 at 11:11, Tom Lane wrote: > > What I'd like to understand about this patch is how it relates > to Amit L.'s work on making the planner faster for partitioned > UPDATE/DELETE cases (https://commitfest.postgresql.org/22/1778/). It's close to being unrelated and completely

Re: Delay locking partitions during INSERT and UPDATE

Hi, On 2019-02-18 17:47:07 -0500, Tom Lane wrote: > David Rowley writes: > > Not sure what you mean here. This is an executor change. What does > > the planner care about what the executor does? > > Are we talking about the same patch? The one I'm looking at seems > to be mostly planner and

Re: Delay locking partitions during INSERT and UPDATE

On Tue, 19 Feb 2019 at 12:15, Tom Lane wrote: > Now that I've looked at *this* thread's patch, I agree that having > the executor acquire locks based on find_all_inheritors() is a > pretty horrid idea. However, it still seems like this is being > done in a vacuum without attention to locks

Re: Reaping Temp tables to avoid XID wraparound

On Mon, 18 Feb 2019 at 12:31, Michael Paquier wrote: > On Sun, Feb 17, 2019 at 05:47:09PM +0100, Magnus Hagander wrote: > > We could I guess add a field specifically for temp_namespace_xid or such. > > The question is if it's worth the overhead to do that. > > That would mean an extra 4 bytes in

Re: Speed up transaction completion faster after many relations are accessed in a transaction

On Tue, 19 Feb 2019 at 12:42, Tom Lane wrote: > My own thought about how to improve this situation was just to destroy > and recreate LockMethodLocalHash at transaction end (or start) > if its size exceeded $some-value. Leaving it permanently bloated seems > like possibly a bad idea, even if we

Re: Speed up transaction completion faster after many relations are accessed in a transaction

Hi, On 2019-02-18 19:01:06 -0500, Tom Lane wrote: > Andres Freund writes: > > Isn't a large portion of benefits in this patch going to be mooted by > > the locking improvements discussed in the other threads? I.e. there's > > hopefully not going to be a ton of cases with low overhead where we >

RE: [PROPOSAL]a new data type 'bytea' for ECPG

Meskes-san > This looks very good. Committed to HEAD. Thank you so match. Regards Ryo Matsumura

Re: [PATCH] xlogreader: do not read a file block twice

On 18.02.2019 04:09, Michael Paquier wrote: And done, after doing and extra pass, doing more testing using by own plugins, pg_waldump and more fancy stuff with a primary/standby and pgbench. Thank you Michael. -- Arthur Zakirov Postgres Professional: http://www.postgrespro.com Russian

Re: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax

Hi Higuchi-san, > My goal is to accept syntax which is currently rejected by ECPG. To > realize that, I am considering following two ways: > (a) new syntax of create as statement should be added to ECPG Correct. > (b) make ECPG to use not ecpg.trailer but gram.y in the syntax of > create as

RE: libpq debug log

Hi, Because I mistook something about how to reply to e-mails, my last reply is not reflected in the thread. Response to Nagaura san's review point, I fixed all his review notes, except for pointing out about psql. Please see the attached updated patch. > 1) > It would be better making the

Re: propagating replica identity to partitions

> On Fri, Feb 15, 2019 at 10:02 PM Alvaro Herrera > wrote: > > On 2019-Feb-07, Dmitry Dolgov wrote: > > > Could there be a race condition somewhere? The idea and the code looks > > reasonable, but when I'm testing ALTER TABLE ... REPLICA IDENTITY with this > > patch and concurrent partition

Re: Prevent extension creation in temporary schemas

On Mon, Feb 18, 2019 at 6:40 AM Kuroda, Hayato wrote: > Dear Michael, > > I seem this patch is enough, but could you explain the reason > you drop initial proposal more detail? > I'm not sure why extensions contained by temporary schemas are acceptable. > Here's my objection. Everything a

Re: Prevent extension creation in temporary schemas

On Thu, Feb 14, 2019 at 4:57 PM Michael Paquier wrote: > > On Wed, Feb 13, 2019 at 12:08:50PM +0100, Chris Travers wrote: > > If the point is visibility in \dx it seems to me we want to fix the \dx > > query. > > Yes, I got to think a bit more about that case, and there are cases > where this

RE: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax

Hi, Meskes-san > Yes, I fully understand that. However, in doing so you accept > statements that the backend later on rejects. The sole reason for > the big ecpg grammar is to prevent those cases whenever possible. Ok, I agree with you. > > I also want to hear your opinion. I will change my

Re: [PROPOSAL]a new data type 'bytea' for ECPG

Matsumura-san, > I attach a new patch. > ... Thank you so much. This looks very good. Committed to HEAD. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL

Re: Incorrect visibility test function assigned to snapshot

On 2019-Feb-18, Michael Paquier wrote: > On Fri, Feb 15, 2019 at 01:01:29PM +0100, Antonin Houska wrote: > > As for the bug fix, I think the additional assignment does not make things > > worse because SnapBuildInitialSnapshot() already does overwrite some fields: > > "xip" and "xnt". > > Ah,

Re: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax

Hi Higuchi-san, > I updated and attached the patch. As I show in previous post, this > version is that "IF NOT EXISTS" keyword and variable for "WITH NO > DATA" are added to ecpg.trailer. Thank you, committed. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot

Re: Progress reporting for pg_verify_checksums

Hi, Am Montag, den 18.02.2019, 12:24 +0900 schrieb Michael Paquier: > On Sun, Feb 17, 2019 at 09:00:29PM +0100, Michael Banck wrote: > > Well, pg_rewind is also using kB, so should I switch it back to that? > > I am not sure which one is better, sorry :) > > There is an argument for switching

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

Hi Andres, Thank you for your feedback. On 16.02.2019 6:41, Andres Freund wrote: It sounds like a seriously bad idea to use a different parser for pg_rewind. Why don't you just use postgres for it? As in /path/to/postgres -D /path/to/datadir/ -C shared_buffers ? Initially, when I started

Re: Ryu floating point output patch

On 2/17/19 6:49 PM, Tom Lane wrote: > Andrew Gierth writes: >> "Andrew" == Andrew Dunstan writes: >> Andrew> Would you like to reformulate this, then? >> How about: >> Use the specified value of extra_float_digits when dumping >> floating-point data, instead of the maximum available

Re: Reporting script runtimes in pg_regress

On 2019-02-15 15:54, Tom Lane wrote: >> We should also strive to align "FAILED" properly. > Hmm. The reasonable ways to accomplish that look to be either > (a) pad "ok" to the width of "FAILED", or (b) rely on emitting a tab. > I don't much like either, especially from the localization angle. >

Re: libpq environment variables in the server

On 2019-01-21 11:42, Peter Eisentraut wrote: > Maybe pg_ctl should have some functionality to clear the environment, > and maybe there could be a facility in postgresql.conf to set > environment variables. After pondering this, this seemed to be the best solution. Many init systems already clear

Re: libpq debug log

Hi, I have tested the trace log implementation.Please find my feedback for the same. Issues found while testing - 1) If invalid value is given to PGLOGMINLEVEL, empty log file is created which should not happen. 2) If log file size exceeds the value configured in

Re: pg_dump multi VALUES INSERT

On Sat, Feb 2, 2019 at 11:26 AM Fabien COELHO wrote: > There is a test, that is good! Charater "." should be backslashed in the > regexpr. I'd consider also introducing limit cases: empty table, empty > columns by creating corresponding tables and using -t repeatedly I see that there are

Re: Protect syscache from bloating with negative cache entries

On 2019-Feb-15, Tomas Vondra wrote: > ISTM there's a couple of ways to deal with that: > > 1) Ignore the memory amounts entirely, and do just time-base eviction. > > 2) If we want some size thresholds (e.g. to disable eviction for > backends with small caches etc.) use the number of entries

Use varargs macro for CACHEDEBUG

I propose the attached patch to replace the CACHEX_elog() macros with a single varargs version. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services From 588f73169cecfb401bf5165ab71021d82d693bb8 Mon Sep 17 00:00:00

Re: Use varargs macro for CACHEDEBUG

Hi, On 2019-02-18 13:56:52 +0100, Peter Eisentraut wrote: > I propose the attached patch to replace the CACHEX_elog() macros with a > single varargs version. +1 Greetings, Andres Freund

Re: Copy function for logical replication slots

Hi, On 2019-02-18 16:57:07 +0900, Masahiko Sawada wrote: > > Stupid question, but couldn't we optimize this to something like: > > > > /* > > * First copy current data of the slot. Then install those in the > > * new slot. The src slot could have progressed while installing, > >

Re: Progress reporting for pg_verify_checksums

Hi, Am Montag, den 18.02.2019, 13:42 -0300 schrieb Alvaro Herrera: > On 2019-Feb-18, Bernd Helmle wrote: > > > Am Montag, den 18.02.2019, 16:52 +0100 schrieb Michael Banck: > > > > Surely we know at that point whether this first scan is needed, and > > > > we can skip it if not? > > > > > >

Re: 2019-03 CF Summary / Review - Tranche #2

Hi, On 2019-02-18 18:59:22 +0200, David Steele wrote: > On 2/16/19 7:45 AM, Andres Freund wrote: > > > - Add timeline to partial WAL segments > > > >WOA: Seems to need a good bit more work, and touches sensitive bits. > > > >Andres: +0.5 for punting to v13 > I have labelled this patch

Re: 2019-03 CF Summary / Review - Tranche #2

David Steele writes: > Even so, I'll push it when I can to get it out of my hair, as it were. > I'll be spending a lot of time look at that list next month. Can't you do it now? The status summary line already shows one patch as having been pushed to the next CF.

Re: 2019-03 CF Summary / Review - Tranche #2

On 2019-02-18 12:37:27 -0500, Tom Lane wrote: > David Steele writes: > > Even so, I'll push it when I can to get it out of my hair, as it were. > > I'll be spending a lot of time look at that list next month. > > Can't you do it now? The status summary line already shows one > patch as having

Re: 2019-03 CF Summary / Review - Tranche #2

Andres Freund writes: > On 2019-02-18 12:37:27 -0500, Tom Lane wrote: >> Can't you do it now? The status summary line already shows one >> patch as having been pushed to the next CF. > It's CF app nannyism. One can't move a patch to the next CF that's > waiting-on-author. I've complained about

Re: unconstify equivalent for volatile

Hi, On 2019-02-18 10:43:50 -0500, Tom Lane wrote: > Peter Eisentraut writes: > > I propose to add an equivalent to unconstify() for volatile. When > > working on this, I picked the name unvolatize() mostly as a joke, but it > > appears it's a real word. Other ideas? > > Umm ... wouldn't this

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

Hi, On 2019-02-18 16:26:55 +0300, Alexey Kondratov wrote: > Hi Andres, > > Thank you for your feedback. > > On 16.02.2019 6:41, Andres Freund wrote: > > It sounds like a seriously bad idea to use a different parser for > > pg_rewind. Why don't you just use postgres for it? As in > >

Re: Progress reporting for pg_verify_checksums

On 2019-Feb-18, Bernd Helmle wrote: > Am Montag, den 18.02.2019, 16:52 +0100 schrieb Michael Banck: > > > Surely we know at that point whether this first scan is needed, and > > we > > > can skip it if not? > > > > Yeah - new patch attached. > > Maybe i'm wrong, but my thought is that this

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

On 2019-Feb-18, Andres Freund wrote: > Hi, > > On 2019-02-18 16:26:55 +0300, Alexey Kondratov wrote: > > Hi Andres, > > > > Thank you for your feedback. > > > > On 16.02.2019 6:41, Andres Freund wrote: > > > It sounds like a seriously bad idea to use a different parser for > > > pg_rewind.

Re: 2019-03 CF Summary / Review - Tranche #2

On 2/16/19 7:45 AM, Andres Freund wrote: - Add timeline to partial WAL segments WOA: Seems to need a good bit more work, and touches sensitive bits. Andres: +0.5 for punting to v13 I have labelled this patch v13 and I'll push it as soon as the CF app allows me to do so. I think this

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

On 18.02.2019 19:49, Alvaro Herrera wrote: On 16.02.2019 6:41, Andres Freund wrote: It sounds like a seriously bad idea to use a different parser for pg_rewind. Why don't you just use postgres for it? As in /path/to/postgres -D /path/to/datadir/ -C shared_buffers ? Eh, this is what I

Re: 2019-03 CF Summary / Review - Tranche #2

On 2/18/19 7:03 PM, Andres Freund wrote: Hi, On 2019-02-18 18:59:22 +0200, David Steele wrote: On 2/16/19 7:45 AM, Andres Freund wrote: - Add timeline to partial WAL segments WOA: Seems to need a good bit more work, and touches sensitive bits. Andres: +0.5 for punting to v13 I

Re: WAL insert delay settings

Greetings, * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: > On 2/15/19 7:41 PM, Andres Freund wrote: > > On 2019-02-15 08:50:03 -0500, Stephen Frost wrote: > >> * Andres Freund (and...@anarazel.de) wrote: > >>> On 2019-02-14 11:02:24 -0500, Stephen Frost wrote: > On Thu, Feb 14, 2019

Re: speeding up planning with partitions

Amit Langote writes: > [ v22 patch set ] I started to look at this, and immediately choked on the 0001 patch: if (childpruned || !apply_child_basequals(root, rel, childrel, childRTE, appinfo) || relation_excluded_by_constraints(root, childrel, childRTE))

FOP warnings about id attributes in title tags

Over on our shiny new PDF builder at   FOP is complaining about a bunch of unresolved ID references. It appears that these are due to title elements having id tags. At

Re: FOP warnings about id attributes in title tags

On 2019-02-18 16:12, Andrew Dunstan wrote: > Over on our shiny new PDF builder at > >   > FOP is complaining about a bunch of unresolved ID references. Yes, this is an ancient issue. The

Re: FOP warnings about id attributes in title tags

Andrew Dunstan writes: > Over on our shiny new PDF builder at > >   > FOP is complaining about a bunch of unresolved ID references. > It appears that these are due to title elements having

Re: Progress reporting for pg_verify_checksums

On 2019-Feb-17, Michael Banck wrote: > + /* > + * As progress status information may be requested, we need to scan the > + * directory tree(s) twice, once to get the idea how much data we need > to > + * scan and finally to do the real legwork. > + */ > + total_size =

Re: [PATCH v20] GSSAPI encryption support

Andres Freund writes: > On 2018-12-18 14:12:46 -0500, Robbie Harwood wrote: > >> Subject: [PATCH] libpq GSSAPI encryption support > > Could some of these be split into separate patches that could be more > eagerly merged? This is a somewhat large patch... What splits do you propose? (It's been

unconstify equivalent for volatile

I propose to add an equivalent to unconstify() for volatile. When working on this, I picked the name unvolatize() mostly as a joke, but it appears it's a real word. Other ideas? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

Re: unconstify equivalent for volatile

Peter Eisentraut writes: > I propose to add an equivalent to unconstify() for volatile. When > working on this, I picked the name unvolatize() mostly as a joke, but it > appears it's a real word. Other ideas? Umm ... wouldn't this amount to papering over actual bugs? I can think of legitimate

Re: unconstify equivalent for volatile

Hi, On February 18, 2019 7:39:25 AM PST, Peter Eisentraut wrote: >I propose to add an equivalent to unconstify() for volatile. When >working on this, I picked the name unvolatize() mostly as a joke, but >it >appears it's a real word. Other ideas? Shouldn't we just remove just about all those

  1   2   >