Re: Support for NSS as a libpq TLS backend

On Tue, Feb 02, 2021 at 08:33:35PM +, Jacob Champion wrote: > Note that this changes the error message printed during the invalid- > root tests, because NSS is now sending the root of the chain. So the > server's issuer is considered untrusted rather than unrecognized. I think that it is not a

Re: Correct comment in StartupXLOG().

On Thu, Feb 4, 2021 at 9:39 AM Amul Sul wrote: > > On Thu, Feb 4, 2021 at 6:18 AM Kyotaro Horiguchi > wrote: > > > > At Wed, 3 Feb 2021 16:36:13 +0530, Amul Sul wrote in > > > On Wed, Feb 3, 2021 at 2:48 PM Dilip Kumar wrote: > > > > > > > > On Wed, Feb 3, 2021 at 2:28 PM Amul Sul wrote: > > >

Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?

Hello, I noticed that CheckAttributeNamesTypes() prevents to create a table that has more than MaxHeapAttributeNumber (1600) columns, for foreign-table also. IIUC, this magic number comes from length of the null-bitmap can be covered with t_hoff in HeapTupleHeaderData. For heap-tables, it seems to

Re: Typo in tablesync comment

On Thu, Feb 04, 2021 at 10:50:11AM +1100, Peter Smith wrote: > OK. I attached an updated patch using this new text. Thanks, applied. -- Michael signature.asc Description: PGP signature

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Tue, Feb 2, 2021, at 13:51, Mark Rofail wrote: >Array-ELEMENT-foreign-key-v17.patch When working on my pit tool, I found another implicit type casts problem. First an example to show a desired error message: CREATE TABLE a ( a_id smallint, PRIMARY KEY (a_id) ); CREATE TABLE b ( b_id bigint,

Re: Removing support for COPY FROM STDIN in protocol version 2

On Wed, Feb 03, 2021 at 11:29:37AM -0500, Tom Lane wrote: > Then let's kill it dead, server and libpq both. Yeah. -- Michael signature.asc Description: PGP signature

Re: Can we have a new SQL callable function to get Postmaster PID?

On Thu, Feb 04, 2021 at 11:30:09AM +0530, Bharath Rupireddy wrote: > But sometimes we may also have to debug postmaster code, on different > platforms maybe. I don't know how the postmaster pid from the user > perspective will be useful in customer environments and I can't think > of other usages o

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On Wed, Feb 03, 2021 at 07:54:42PM +0900, Michael Paquier wrote: > Not sure I like that. Here is a proposal: > "it is recommended to separately use ALTER TABLE ONLY on them so as > any new partitions attached inherit the new tablespace value." So, I have done more work on this stuff today, and ap

Re: Can we have a new SQL callable function to get Postmaster PID?

On Thu, Feb 4, 2021 at 3:27 AM Tom Lane wrote: > > Tomas Vondra writes: > > On 2/3/21 4:08 PM, Tom Lane wrote: > >> I'm disinclined to think that this is a good idea from a security > >> perspective. Maybe if it's superuser-only it'd be ok (since a > >> superuser would have other routes to disco

Re: Can we have a new SQL callable function to get Postmaster PID?

On Thu, Feb 4, 2021 at 2:39 AM Tomas Vondra wrote: > > On 2/3/21 7:12 AM, Bharath Rupireddy wrote: > > Hi, > > > > Can we have a new function, say pg_postgres_pid(), to return > > postmaster PID similar to pg_backend_pid()? At times, it will be > > Curious question - why do you actually need PID o

Re: a curious case of force_parallel_mode = on with jit'ing

On Thu, Feb 4, 2021 at 1:41 PM Tom Lane wrote: > Amit Langote writes: > > On Thu, Feb 4, 2021 at 1:08 AM Tom Lane wrote: > >> Works for me on HEAD (using RHEL8.3, gcc 8.3.1, LLVM 10.0.1). > > > Thanks for checking. Must be my LLVM setup I guess: > > > $ llvm-config --version > > 7.0.1 > > $ cat

Re: pg_replication_origin_drop API potential race condition

On Thu, Feb 4, 2021 at 9:57 AM Peter Smith wrote: > > On Wed, Feb 3, 2021 at 11:17 PM Amit Kapila wrote: > > > > > How about if we call replorigin_by_name() inside replorigin_drop after > > acquiring the lock? Wouldn't that close this race condition? We are > > doing something similar for pg_repl

Re: Is Recovery actually paused?

On Mon, Feb 1, 2021 at 1:41 PM Dilip Kumar wrote: > > On Mon, Feb 1, 2021 at 11:59 AM Kyotaro Horiguchi > wrote: > > > > At Sun, 31 Jan 2021 11:24:30 +0530, Dilip Kumar > > wrote in > > > On Fri, Jan 29, 2021 at 4:33 PM Dilip Kumar wrote: > > > > > > > > On Fri, Jan 29, 2021 at 3:25 PM Yugo NA

Re: a curious case of force_parallel_mode = on with jit'ing

Amit Langote writes: > On Thu, Feb 4, 2021 at 1:08 AM Tom Lane wrote: >> Works for me on HEAD (using RHEL8.3, gcc 8.3.1, LLVM 10.0.1). > Thanks for checking. Must be my LLVM setup I guess: > $ llvm-config --version > 7.0.1 > $ cat /etc/redhat-release > CentOS Linux release 7.7.1908 (Core) > $

Re: pg_replication_origin_drop API potential race condition

On Wed, Feb 3, 2021 at 11:17 PM Amit Kapila wrote: > > How about if we call replorigin_by_name() inside replorigin_drop after > acquiring the lock? Wouldn't that close this race condition? We are > doing something similar for pg_replication_origin_advance(). > Yes, that seems ok. I wonder if it

Re: Single transaction in the tablesync worker?

On Wed, Feb 3, 2021 at 11:38 PM Amit Kapila wrote: > Thanks for the report. The problem here was that the error occurred > when we were trying to copy the large data. Now, before fetching the > entire data we issued a rollback that led to this problem. I think the > alternative here could be to f

Re: New IndexAM API controlling index vacuum strategies

On Tue, Feb 2, 2021 at 12:17 PM Peter Geoghegan wrote: > > On Fri, Jan 29, 2021 at 5:26 PM Peter Geoghegan wrote: > > It'll be essential to have good instrumentation as we do more > > benchmarking. We're probably going to have to make subjective > > assessments of benchmark results, based on mult

Re: a curious case of force_parallel_mode = on with jit'ing

On Thu, Feb 4, 2021 at 1:08 AM Tom Lane wrote: > > Amit Langote writes: > > Has anybody seen this: > > Works for me on HEAD (using RHEL8.3, gcc 8.3.1, LLVM 10.0.1). Thanks for checking. Must be my LLVM setup I guess: $ llvm-config --version 7.0.1 $ cat /etc/redhat-release CentOS Linux release

Re: Correct comment in StartupXLOG().

On Thu, Feb 4, 2021 at 6:18 AM Kyotaro Horiguchi wrote: > > At Wed, 3 Feb 2021 16:36:13 +0530, Amul Sul wrote in > > On Wed, Feb 3, 2021 at 2:48 PM Dilip Kumar wrote: > > > > > > On Wed, Feb 3, 2021 at 2:28 PM Amul Sul wrote: > > > > > > > > Hi, > > > > > > > > SharedRecoveryState member of XLo

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

On Wed, Feb 3, 2021 at 4:22 PM Fujii Masao wrote: > Maybe my explanation in the previous email was unclear. What I think is; If > the server-level option is explicitly specified, its setting is used whatever > GUC is. On the other hand, if the server-level option is NOT specified, GUC > setting

typo in "Determine XID horizons" comment in procarray.c

Hi, Second paragraph of this comment (procarray.c:1604) says: * See the definition of ComputedXidHorizonsResult for the various computed It should say ComputeXidHorizonsResult (it has an extra "d" in Computed) -- Jaime Casanova Director de Servicios Profesionales SystemGuards - Consultores de Po

Re: Multiple full page writes in a single checkpoint?

On Wed, Feb 3, 2021 at 08:07:16PM -0500, Bruce Momjian wrote: > > > I can try to add a hint-bit-page-write page counter, but that might > > > overflow, and then we will need a way to change the LSN anyway. > > > > That's just a question of width... > > Yeah, the hint bit counter is just delaying

Re: Recording foreign key relationships for the system catalogs

On Wed, Feb 3, 2021, at 21:41, Joel Jacobson wrote: >Otherwise I think it would be more natural to change both is_array and is_opt >to boolean[] with the same cardinality as fkcols and pkcols, >to allow unnest()ing of them as well. Another option would perhaps be to add a new system view in src/ba

Re: Is it useful to record whether plans are generic or custom?

At Thu, 04 Feb 2021 10:16:47 +0900, torikoshia wrote in > Chengxi Sun, Yamada-san, Horiguchi-san, > > Thanks for all your comments. > Adding only the number of generic plan execution seems acceptable. > > On Mon, Jan 25, 2021 at 2:10 PM Kyotaro Horiguchi > wrote: > > Note that ActivePortal is

Re: Bug in COPY FROM backslash escaping multi-byte chars

At Wed, 3 Feb 2021 15:46:30 +0200, Heikki Linnakangas wrote in > On 03/02/2021 15:38, John Naylor wrote: > > On Wed, Feb 3, 2021 at 8:08 AM Heikki Linnakangas > > wrote: > > > > > > Hi, > > > > > > While playing with COPY FROM refactorings in another thread, I notice

RE: libpq debug log

From: 'Alvaro Herrera' > > (41) > > +void > > +PQtraceEx(PGconn *conn, FILE *debug_port, int flags) > > +{ > > I'm not really sure about making this a separate API call. We could just > make it PQtrace() and increment the libpq so version. I don't think > it's a big deal, frankly. If we change

possibly outdated pg_file_read() errhint

Hackers, The following errhint in pg_read_file() makes little sense: errhint("Consider using %s, which is part of core, instead.", "pg_file_read()"))); Grep'ing through master, there is almost nothing named pg_file_read, and what does exist is dropped w

Re: WIP: BRIN multi-range indexes

> For 0007-Remove-the-special-batch-mode-use-a-larger--20210203.patch : > > > > + /* same as preceding value, so store it */ > > + if (compare_values(&range->values[start + i - 1], > > + &range->values[

RE: libpq debug log

From: Alvaro Herrera > I'm pretty sure I named the flag PQTRACE_SUPPRESS_TIMESTAMP (and I > prefer SUPPRESS to NOOUTPUT), because the idea is that the timestamp is > printed by default. I think that's the sensible decision: applications > prefer to have timestamps, even if there's a tiny bit of o

Re: Is it useful to record whether plans are generic or custom?

Chengxi Sun, Yamada-san, Horiguchi-san, Thanks for all your comments. Adding only the number of generic plan execution seems acceptable. On Mon, Jan 25, 2021 at 2:10 PM Kyotaro Horiguchi wrote: Note that ActivePortal is the closest nested portal. So it gives the wrong result for nested portal

Re: Multiple full page writes in a single checkpoint?

On Wed, Feb 3, 2021 at 05:00:19PM -0800, Andres Freund wrote: > Hi, > > On 2021-02-03 19:21:25 -0500, Bruce Momjian wrote: > > On Wed, Feb 3, 2021 at 03:29:13PM -0800, Andres Freund wrote: > > > Changing this is *completely* infeasible. In a lot of workloads it'd > > > cause a *massive* explosio

Re: Multiple full page writes in a single checkpoint?

Hi, On 2021-02-03 19:21:25 -0500, Bruce Momjian wrote: > On Wed, Feb 3, 2021 at 03:29:13PM -0800, Andres Freund wrote: > > Changing this is *completely* infeasible. In a lot of workloads it'd > > cause a *massive* explosion of WAL volume. Like quadratically. You'll > > need to find another way to

Re: WIP: BRIN multi-range indexes

On 2/4/21 1:49 AM, Zhihong Yu wrote: > Hi, > For 0007-Remove-the-special-batch-mode-use-a-larger--20210203.patch : > > +       /* same as preceding value, so store it */ > +       if (compare_values(&range->values[start + i - 1], > +                        

RE: Parallel INSERT (INTO ... SELECT ...)

From: Amit Kapila > On Mon, Jan 18, 2021 at 2:40 PM Tang, Haiying > wrote: > > Execute EXPLAIN on Patched: > > postgres=# explain (ANALYZE, BUFFERS, VERBOSE) insert into test_part > select * from test_data1; > >QUERY PLAN > > > -

Re: Correct comment in StartupXLOG().

At Wed, 3 Feb 2021 16:36:13 +0530, Amul Sul wrote in > On Wed, Feb 3, 2021 at 2:48 PM Dilip Kumar wrote: > > > > On Wed, Feb 3, 2021 at 2:28 PM Amul Sul wrote: > > > > > > Hi, > > > > > > SharedRecoveryState member of XLogCtl is no longer a boolean flag, got > > > changes > > > in 4e87c4836ab9

Re: WIP: BRIN multi-range indexes

Hi, For 0007-Remove-the-special-batch-mode-use-a-larger--20210203.patch : + /* same as preceding value, so store it */ + if (compare_values(&range->values[start + i - 1], + &range->values[start + i], + (void

Re: WIP: WAL prefetch (another approach)

Hi, I did a bunch of tests on v15, mostly to asses how much could the prefetching help. The most interesting test I did was this: 1) primary instance on a box with 16/32 cores, 64GB RAM, NVMe SSD 2) replica on small box with 4 cores, 8GB RAM, SSD RAID 3) pause replication on the replica (pg_wal

Re: Multiple full page writes in a single checkpoint?

On Wed, Feb 3, 2021 at 03:29:13PM -0800, Andres Freund wrote: > > Is the above case valid, and would it cause two full page writes to WAL? > > More specifically, wouldn't it cause every write of the page to the file > > system to use a new LSN? > > No. 8) won't happen. Look e.g. at XLogSaveBuffe

Re: Dumping/restoring fails on inherited generated column

Hi, + if (attribute->attgenerated && !childatt->attgenerated) + ereport(ERROR, ... + if (attribute->attgenerated && childatt->attgenerated) + { Looks like for the second if statement, checking attribute->attgenerated should be enough (due to the check fr

Re: DROP TABLE can crash the replication sync worker

On Wed, Feb 3, 2021 at 11:49 PM Amit Kapila wrote: > > On Wed, Feb 3, 2021 at 2:53 PM Peter Smith wrote: > > > > Hi Hackers. > > > > As discovered in another thread [master] there is an *existing* bug in > > the PG HEAD code which can happen if a DROP TABLE is done at same time > > a replication

Re: Typo in tablesync comment

On Wed, Feb 3, 2021 at 11:55 PM Amit Kapila wrote: > > On Wed, Feb 3, 2021 at 1:35 PM Michael Paquier wrote: > > > > On Wed, Feb 03, 2021 at 06:52:56PM +1100, Peter Smith wrote: > > > > > Maybe better to rewrite it more drastically? > > > > > > e.g > > > - > > > *The catalog pg_subscript

Re: logical replication worker accesses catalogs in error context callback

Hi, On 2021-02-03 16:35:29 +0530, Bharath Rupireddy wrote: > On Sat, Jan 30, 2021 at 8:23 AM Andres Freund wrote: > > On 2021-01-28 11:14:03 +0530, Amit Kapila wrote: > > > On Wed, Jan 27, 2021 at 9:38 AM Bharath Rupireddy > > > wrote: > > > > > > > > On Wed, Jan 27, 2021 at 7:48 AM Zhihong Yu

Re: Multiple full page writes in a single checkpoint?

Hi, On 2021-02-03 18:05:56 -0500, Bruce Momjian wrote: > log_hint_bits already gives us a unique nonce for the first hint bit > change on a page during a checkpoint, but we only encrypt on page write > to the file system, so I am researching if log_hint_bits will already > generate a unique LSN fo

Multiple full page writes in a single checkpoint?

Cluster file encryption plans to use the LSN and page number as the nonce for heap/index pages. I am looking into the use of a unique nonce during hint bit changes. (You need to use a new nonce for re-encrypting a page that changes.) log_hint_bits already gives us a unique nonce for the first hi

Re: new heapcheck contrib module

On Tue, Feb 2, 2021 at 6:10 PM Mark Dilger wrote: > 0001 -- no changes Committed. > 0002 -- fixing omissions in @pgfeutilsfiles in file > src/tools/msvc/Mkvcbuild.pm Here are a few minor cosmetic issues with this patch: - connect_utils.c lacks a file header comment. - Some or perhaps all of t

Re: Can we have a new SQL callable function to get Postmaster PID?

Tomas Vondra writes: > On 2/3/21 4:08 PM, Tom Lane wrote: >> I'm disinclined to think that this is a good idea from a security >> perspective. Maybe if it's superuser-only it'd be ok (since a >> superuser would have other routes to discovering the value anyway). > Is the postmaster PID really se

Re: Tid scan improvements

Thanks for looking at this. On Thu, 4 Feb 2021 at 10:19, Andres Freund wrote: > Perhaps something like > > typedef struct TableScanTidRange TableScanTidRange; > > TableScanTidRange* table_scan_tid_range_start(TableScanDesc sscan, > ItemPointer mintid, ItemPointer maxtid); > bool table_scan_tid_r

Re: Tid scan improvements

Hi, On 2021-01-26 14:22:42 +1300, David Rowley wrote: > diff --git a/src/include/access/tableam.h b/src/include/access/tableam.h > index 33bffb6815..d1c608b176 100644 > --- a/src/include/access/tableam.h > +++ b/src/include/access/tableam.h > @@ -325,6 +325,26 @@ typedef struct TableAmRoutine >

Re: Can we have a new SQL callable function to get Postmaster PID?

On 2/3/21 4:08 PM, Tom Lane wrote: > Bharath Rupireddy writes: >> Can we have a new function, say pg_postgres_pid(), to return >> postmaster PID similar to pg_backend_pid()? > > I'm disinclined to think that this is a good idea from a security > perspective. Maybe if it's superuser-only it'd be

Re: Can we have a new SQL callable function to get Postmaster PID?

On 2/3/21 7:12 AM, Bharath Rupireddy wrote: > Hi, > > Can we have a new function, say pg_postgres_pid(), to return > postmaster PID similar to pg_backend_pid()? At times, it will be > difficult to use OS level commands to get the postmaster pid of a > backend to which it is connected. It's even wo

Re: Next Commitfest Manager.

On 2/3/21 3:13 PM, Stephen Frost wrote: Greetings, * Ibrar Ahmed (ibrar.ah...@gmail.com) wrote: Anyone else already volunteers that? It is my first time so need some access, if all agree. Thanks for volunteering! That said, our last commitfest tends to be the most difficult as it's the last

Re: Recording foreign key relationships for the system catalogs

On Mon, Feb 1, 2021, at 21:03, Tom Lane wrote: >"Joel Jacobson" writes: >> The is_array OUT parameter doesn't say which of the possibly many fkcols >> that is the array column. > >Yeah, I didn't write the sgml docs yet, but the comments explain that >the array is always the last fkcol. Maybe som

Re: Next Commitfest Manager.

Greetings, * Ibrar Ahmed (ibrar.ah...@gmail.com) wrote: > Anyone else already volunteers that? It is my first time so need some > access, if all agree. Thanks for volunteering! That said, our last commitfest tends to be the most difficult as it's the last opportunity for features to land in time

Re: Dumping/restoring fails on inherited generated column

On 2021-01-29 17:41, Tom Lane wrote: Also, in the example from [2], d3=# create table pp1 (a int, b int GENERATED ALWAYS AS (a * 2) STORED); CREATE TABLE d3=# create table cc1 (a int, b int GENERATED ALWAYS AS (a * 3) STORED); CREATE TABLE d3=# alter table cc1 inherit pp1; ALTER TABLE pg_dump n

Re: Key management with tests

On Wed, Feb 3, 2021 at 10:33:57AM -0500, Stephen Frost wrote: > > I am thinking group read-access might be a requirement for cluster file > > encryption to be effective. > > People certainly do use group read-access, but I don't see that as being > a requirement for cluster file encryption to be

Re: Removing support for COPY FROM STDIN in protocol version 2

Heikki Linnakangas writes: > Since we're on a removal-spree, it'd also be nice to get rid of the > "fast-path" function call interface, PQfn(). However, libpq is using it > internally in the lo_*() functions, so if we remove it from the server, > lo_*() will stop working with old libpq versions

Re: Extensions not dumped when --schema is used

Hi, Thanks for the review. Le mer. 3 févr. 2021 à 18:33, Asif Rehman a écrit : > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: not tested > Documentation:

Re: Extensions not dumped when --schema is used

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested The patch applies cleanly and looks fine to me. However consider this

Re: Removing support for COPY FROM STDIN in protocol version 2

On 03/02/2021 18:29, Tom Lane wrote: Alvaro Herrera writes: On 2021-Feb-03, Tom Lane wrote: I have a vague recollection that JDBC users still like to use protocol 2 for some reason --- is that out of date? [ yes, since 2016 ] Then let's kill it dead, server and libpq both. Ok, works for

Re: Removing support for COPY FROM STDIN in protocol version 2

Alvaro Herrera writes: > On 2021-Feb-03, Tom Lane wrote: >> I have a vague recollection that JDBC users still like to use >> protocol 2 for some reason --- is that out of date? > [ yes, since 2016 ] Then let's kill it dead, server and libpq both. regards, tom lane

Re: join plan with unexpected var clauses

Luc Vlaming writes: > Given the testcase we see that the outer semi join tries to join the > outer with the inner table id columns, even though the middle table id > column is also there. Is this expected behavior? I don't see anything greatly wrong with it. The planner has concluded that _inn

Re: Removing support for COPY FROM STDIN in protocol version 2

On 2021-Feb-03, Tom Lane wrote: > I have a vague recollection that JDBC users still like to use > protocol 2 for some reason --- is that out of date? 2016: commit c3d8571e53cc5b702dae2f832b02c872ad44c3b7 Author: Vladimir Sitnikov AuthorDate: Sat Aug 6 12:22:17 2016 +0300 CommitDate: Sat Aug

Re: a curious case of force_parallel_mode = on with jit'ing

Amit Langote writes: > Has anybody seen this: Works for me on HEAD (using RHEL8.3, gcc 8.3.1, LLVM 10.0.1). regards, tom lane

Re: Removing support for COPY FROM STDIN in protocol version 2

Heikki Linnakangas writes: > I propose that we remove server support for COPY FROM STDIN with > protocol version 2, per attached patch. Even if we could still support > it, it would be a very rarely used and tested codepath, prone to bugs. > Perhaps we could remove support for the old protocol

Removing support for COPY FROM STDIN in protocol version 2

Hi, The server still supports the old protocol version 2. Protocol version 3 was introduced in PostgreSQL 7.4, so there shouldn't be many clients around anymore that don't support it. COPY FROM STDIN is particularly problematic with the old protocol, because the end-of-copy can only be detec

Re: Key management with tests

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Mon, Feb 1, 2021 at 07:47:57PM -0500, Bruce Momjian wrote: > > On Mon, Feb 1, 2021 at 06:31:32PM -0500, Stephen Frost wrote: > > > * Bruce Momjian (br...@momjian.us) wrote: > > > > The purpose of cluster file encryption is to prevent us

Re: Dumping/restoring fails on inherited generated column

Peter Eisentraut writes: > On 2021-01-29 17:41, Tom Lane wrote: >> However ... this doesn't solve all the cases noted in this thread. >> In the first example I gave at [1], >> d3=# create table parent (f1 int default 2); >> CREATE TABLE >> d3=# create table child (f1 int default 3) inherits(parent

Re: Dumping/restoring fails on inherited generated column

On 2021-01-29 17:41, Tom Lane wrote: However ... this doesn't solve all the cases noted in this thread. In the first example I gave at [1], d3=# create table parent (f1 int default 2); CREATE TABLE d3=# create table child (f1 int default 3) inherits(parent); NOTICE: merging column "f1" with inh

Re: Prevent printing "next step instructions" in initdb and pg_upgrade

On 2021-01-17 14:38, Magnus Hagander wrote: On Thu, Jan 7, 2021 at 11:53 AM Peter Eisentraut wrote: After pondering this again, I think we can go with initdb --no-instructions, as in your patch. As a minor nitpick, I would leave out the else printf(_("\nSuccess.\n")); in the

Re: Can we have a new SQL callable function to get Postmaster PID?

Bharath Rupireddy writes: > Can we have a new function, say pg_postgres_pid(), to return > postmaster PID similar to pg_backend_pid()? I'm disinclined to think that this is a good idea from a security perspective. Maybe if it's superuser-only it'd be ok (since a superuser would have other routes

Re: Improve new hash partition bound check error messages

On 2021-02-02 13:26, Heikki Linnakangas wrote: How about this? CREATE TABLE fail_part PARTITION OF hash_parted FOR VALUES WITH (MODULUS 25, REMAINDER 3); ERROR: every hash partition modulus must be a factor of the next larger modulus DETAIL: 25 is not divisible by 10, the modulus of existing p

Re: Can we have a new SQL callable function to get Postmaster PID?

On Wed, Feb 3, 2021, at 3:12 AM, Bharath Rupireddy wrote: > Can we have a new function, say pg_postgres_pid(), to return > postmaster PID similar to pg_backend_pid()? It is not that difficult to read the postmaster PID using existing functions. postgres=# SELECT (regexp_match(pg_read_file('postmas

a curious case of force_parallel_mode = on with jit'ing

Hi, Has anybody seen this: $ psql regression Timing is on. psql (14devel) Type "help" for help. regression=# set force_parallel_mode to on; SET Time: 0.888 ms regression=# set jit to on; SET Time: 0.487 ms regression=# set jit_above_cost to 1; SET Time: 0.476 ms regression=# SELECT p1.f1, p2.f1,

Re: libpq debug log

On 2021-Feb-03, tsunakawa.ta...@fujitsu.com wrote: > From: 'Alvaro Herrera' > > > + conn->fe_msg->num_fields != DEF_FE_MSGFIELDS) > > > The rationale for that second condition is this: if the memory allocated > > is the initial size, we don't free memory, because it would just be > > all

Re: libpq debug log

On 2021-Feb-03, tsunakawa.ta...@fujitsu.com wrote: > (39) > + of tracing. If (flags & > PQTRACE_OUTPUT_TIMESTAMPS) is > + true, then timestamp is not printed with each message. > > The flag name (OUTPUT) and its description (not printed) doesn't match. > > I think you can use less pr

Re: libpq debug log

On 2021-Feb-03, Kyotaro Horiguchi wrote: > Looking the doc mentioned in the comment #39: > > + flags contains flag bits describing the operating > mode > + of tracing. If (flags & > PQTRACE_OUTPUT_TIMESTAMPS) is > + true, then timestamp is not printed with each message. > > PQT

Re: Bug in COPY FROM backslash escaping multi-byte chars

On 03/02/2021 15:38, John Naylor wrote: On Wed, Feb 3, 2021 at 8:08 AM Heikki Linnakangas > wrote: > > Hi, > > While playing with COPY FROM refactorings in another thread, I noticed > corner case where I think backslash escaping doesn't work correctly. > Consider the

Re: Bug in COPY FROM backslash escaping multi-byte chars

On Wed, Feb 3, 2021 at 8:08 AM Heikki Linnakangas wrote: > > Hi, > > While playing with COPY FROM refactorings in another thread, I noticed > corner case where I think backslash escaping doesn't work correctly. > Consider the following input: > > \么.foo I've seen multibyte delimiters in the wild,

Re: Typo in tablesync comment

On Wed, Feb 3, 2021 at 1:35 PM Michael Paquier wrote: > > On Wed, Feb 03, 2021 at 06:52:56PM +1100, Peter Smith wrote: > > > Maybe better to rewrite it more drastically? > > > > e.g > > - > > *The catalog pg_subscription_rel is used to keep information about > > *subscribed tables an

Re: DROP TABLE can crash the replication sync worker

On Wed, Feb 3, 2021 at 2:53 PM Peter Smith wrote: > > Hi Hackers. > > As discovered in another thread [master] there is an *existing* bug in > the PG HEAD code which can happen if a DROP TABLE is done at same time > a replication tablesync worker is running. > > It seems the table's relid that the

Re: Next Commitfest Manager.

Hi, Anyone else already volunteers that? It is my first time so need some access, if all agree. On Mon, Feb 1, 2021 at 10:17 PM Ibrar Ahmed wrote: > As Commitfest 2021-01 is now closed. I am volunteering to manage next > commitfest. > > > -- > Ibrar Ahmed > -- Ibrar Ahmed

Re: Single transaction in the tablesync worker?

On Wed, Feb 3, 2021 at 1:28 PM Ajin Cherian wrote: > > On Tue, Feb 2, 2021 at 9:03 PM Ajin Cherian wrote: > > > I am sorry, my above steps were not correct. I think the reason for > > the failure I was seeing were some other steps I did prior to this. I > > will recreate this and update you with

Re: pg_replication_origin_drop API potential race condition

On Wed, Jan 27, 2021 at 4:58 AM Peter Smith wrote: > > Hi Hackers. > > As discovered elsewhere [ak0125] there is a potential race condition > in the pg_replication_origin_drop API > > The current code of pg_replication_origin_drop looks like: > > roident = replorigin_by_name(name, false); > A

pg_dump: Add const decorations

Something that came out of work on pg_dump recently. I added const decorations to the *info arguments of the dump* functions, to clarify that they don't modify that argument. Many other nearby functions modify their arguments, so this can help clarify these different APIs a bit. From a2ec95a39

Bug in COPY FROM backslash escaping multi-byte chars

Hi, While playing with COPY FROM refactorings in another thread, I noticed corner case where I think backslash escaping doesn't work correctly. Consider the following input: \么.foo I hope that came through in this email correctly as UTF-8. The string contains a sequence of: backslash, multi

Re: Dumping/restoring fails on inherited generated column

On 2021-01-29 17:41, Tom Lane wrote: Peter Eisentraut writes: I've had another go at this, and I've found a solution that appears to address all the issues I'm aware of. It's all very similar to the previously discussed patches. The main difference is that previous patches had attempted to us

Re: Correct comment in StartupXLOG().

On Wed, Feb 3, 2021 at 2:48 PM Dilip Kumar wrote: > > On Wed, Feb 3, 2021 at 2:28 PM Amul Sul wrote: > > > > Hi, > > > > SharedRecoveryState member of XLogCtl is no longer a boolean flag, got > > changes > > in 4e87c4836ab9 to enum but, comment referring to it still referred as the > > boolean f

Re: logical replication worker accesses catalogs in error context callback

On Sat, Jan 30, 2021 at 8:23 AM Andres Freund wrote: > > Hi, > > On 2021-01-28 11:14:03 +0530, Amit Kapila wrote: > > On Wed, Jan 27, 2021 at 9:38 AM Bharath Rupireddy > > wrote: > > > > > > On Wed, Jan 27, 2021 at 7:48 AM Zhihong Yu wrote: > > > > > > Thanks for pointing to the changes in the c

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On Wed, Feb 03, 2021 at 01:35:26PM +0300, Alexey Kondratov wrote: > This check for OidIsValid() seems to be excessive, since you moved the whole > ACL check under 'if (tablespacename != NULL)' here. That's more consistent with ATPrepSetTableSpace(). > +SELECT relid, parentrelid, level FROM > pg_p

Re: logical replication worker accesses catalogs in error context callback

On Thu, Jan 28, 2021 at 11:14 AM Amit Kapila wrote: > > On Wed, Jan 27, 2021 at 9:38 AM Bharath Rupireddy > wrote: > > > > On Wed, Jan 27, 2021 at 7:48 AM Zhihong Yu wrote: > > > > Thanks for pointing to the changes in the commit message. I corrected > > them. Attaching v4 patch set, consider it

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On Wed, Feb 03, 2021 at 12:53:42AM -0600, Justin Pryzby wrote: > On Wed, Feb 03, 2021 at 03:37:39PM +0900, Michael Paquier wrote: >> index 627b36300c..4ee3951ca0 100644 >> --- a/doc/src/sgml/ref/reindex.sgml >> +++ b/doc/src/sgml/ref/reindex.sgml >> @@ -293,8 +311,30 @@ REINDEX [ ( > class="paramet

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

On 2021/02/03 13:56, Bharath Rupireddy wrote: On Tue, Feb 2, 2021 at 9:45 AM Fujii Masao wrote: One merit of keep_connections that I found is that we can use it even when connecting to the older PostgreSQL that doesn't support idle_session_timeout. Also it seems simpler to use keep_connectio

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On 2021-02-03 09:37, Michael Paquier wrote: On Tue, Feb 02, 2021 at 10:32:19AM +0900, Michael Paquier wrote: On Mon, Feb 01, 2021 at 06:28:57PM +0300, Alexey Kondratov wrote: > Hm, IIUC, REINDEX CONCURRENTLY doesn't use either of them. It directly uses > index_create() with a proper tablespaceOi

Re: POC: Cleaning up orphaned files using undo logs

On Wed, Feb 3, 2021 at 2:45 PM tsunakawa.ta...@fujitsu.com wrote: > > From: Antonin Houska > > not really an "ordinary patch". > > > > [1] > > https://www.postgresql.org/message-id/CA%2BhUKG%2BMpzRsZFE7ChhR > > q-Br5VYYi6mafVQ73Af7ahioWo5o8w%40mail.gmail.com > > I'm a bit interested in zheap-rela

Re: Single transaction in the tablesync worker?

On Wed, Feb 3, 2021 at 2:51 PM Peter Smith wrote: > > On Wed, Feb 3, 2021 at 1:34 PM Amit Kapila wrote: > > > > On Wed, Feb 3, 2021 at 6:38 AM Peter Smith wrote: > > > > > > On Wed, Feb 3, 2021 at 12:26 AM Amit Kapila > > > wrote: > > > > > > > > On Tue, Feb 2, 2021 at 3:31 PM Peter Smith >

Re: Printing backtrace of postgres processes

On Wed, Feb 3, 2021 at 1:49 PM vignesh C wrote: > > On Wed, Feb 3, 2021 at 1:00 PM Tom Lane wrote: > > > > vignesh C writes: > > > On Mon, Feb 1, 2021 at 11:04 AM Bharath Rupireddy > > > wrote: > > >> Are these superuser and permission checks enough from a security > > >> standpoint that we don

DROP TABLE can crash the replication sync worker

Hi Hackers. As discovered in another thread [master] there is an *existing* bug in the PG HEAD code which can happen if a DROP TABLE is done at same time a replication tablesync worker is running. It seems the table's relid that the sync worker is using gets ripped out from underneath it and is i

Re: Correct comment in StartupXLOG().

On Wed, Feb 3, 2021 at 2:28 PM Amul Sul wrote: > > Hi, > > SharedRecoveryState member of XLogCtl is no longer a boolean flag, got changes > in 4e87c4836ab9 to enum but, comment referring to it still referred as the > boolean flag which is pretty confusing and incorrect. +1 for the comment change

RE: POC: Cleaning up orphaned files using undo logs

From: Antonin Houska > not really an "ordinary patch". > > [1] > https://www.postgresql.org/message-id/CA%2BhUKG%2BMpzRsZFE7ChhR > q-Br5VYYi6mafVQ73Af7ahioWo5o8w%40mail.gmail.com I'm a bit interested in zheap-related topics. I'm reading this discussion to see what I can do. (But this thread i

Re: POC: Cleaning up orphaned files using undo logs

Bruce Momjian wrote: > On Fri, Jan 29, 2021 at 06:30:15PM +0100, Antonin Houska wrote: > > Antonin Houska wrote: > > > Well, on repeated run of the test I could also hit the first one. I could > > > fix > > > it and will post a new version of the patch (along with some other small > > > changes

  1   2   >