Re: Next Steps with Hash Indexes

On Wed, 13 Oct 2021 at 20:16, Peter Geoghegan wrote: > > On Wed, Oct 13, 2021 at 3:44 AM Simon Riggs > wrote: > > > IMO it'd be nice to show some numbers to support the claims that storing > > > the extra hashes and/or 8B hashes is not worth it ... > > > > Using an 8-byte hash is possible, but on

Re: GIN pending list cleanup during autoanalyze blocks cleanup by VACUUM

On Thu, Oct 14, 2021 at 7:58 AM Peter Geoghegan wrote: > > On Sat, Oct 9, 2021 at 5:51 PM Peter Geoghegan wrote: > > While I'm no closer to a backpatchable fix than I was on Thursday, I > > do have some more ideas about what to do on HEAD. I now lean towards > > completely ripping analyze_only ca

Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit()

At Wed, 13 Oct 2021 19:52:52 +0900 (JST), Kyotaro Horiguchi wrote in > Although needing a bit of care for the difference of invalid values > for both though, BackendId can be easily replaced with pgprocno almost > mechanically except sinvaladt. Therefore, we can confine the current > backend ID

Re: [Proposal] Global temporary tables

> 2021年10月13日 13:08，Andrew Bille 写道： > > Thanks for the fix. It works for me. > > Now I'm exploring another crash related to GTT, but I need a few days to > present a simple repro. Be deeply grateful. Perhaps you can give the stack of problems so that you can start analyzing them as soon as

Re: Skipping logical replication transactions on subscriber side

On Tue, Oct 12, 2021 at 4:00 PM Masahiko Sawada wrote: > > I've attached updated patches. > A couple more comments for some issues that I noticed in the v16 patches: v16-0002 doc/src/sgml/ref/alter_subscription.sgml (1) Order of parameters that can be reset doesn't match those that can be set.

Re: a misbehavior of partition row movement (?)

On Mon, Sep 20, 2021 at 3:32 PM Amit Langote wrote: > The problem was that the tuplestore > (afterTriggers.query_stack[query_level].tuplestore) that I decided to > use to store the AFTER trigger tuples of a partitioned table that is > the target of an cross-partition update lives only for the dura

Re: Reset snapshot export state on the transaction abort

On Thu, Oct 14, 2021 at 12:24 PM Michael Paquier wrote: > > On Wed, Oct 13, 2021 at 10:53:24AM +0530, Dilip Kumar wrote: > > Actually, it is not required because 1) Snapshot export can not be > > allowed within a transaction block, basically, it starts its own > > transaction block and aborts that

Some doubts about streaming startpoint in WaitForWALToBecomeAvailable()

Hi, all I have some doubts about the request xlog streaming startpoint in WaitForWALToBecomeAvailable(). In this function, RecPtr is the endpoint lsn we are waiting for, tliRecPtr is the position of the WAL record we are interested in, I want to know why use RecPtr rather than tliRecPtr as the

Fwd: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber

Hi All, Publisher 'DateStyle' is set as "SQL, MDY", whereas in Subscriber as "SQL, DMY", the logical replication is not working... >From Publisher: postgres=# INSERT INTO calendar VALUES ('07-18-1036', '1'), ('05-15-1135', '1'); INSERT 0 2 Getting below error in the subscriber log file, 2021-10-

Re: Added schema level support for publication.

On Wed, Oct 13, 2021 at 1:40 PM Greg Nancarrow wrote: > > On Wed, Oct 13, 2021 at 12:15 AM vignesh C wrote: > > > > Attached v40 patch has the fix for the above comments. > > > > [Maybe this has some overlap with what Hou-san reported, and I have > not tested this against his proposed fixes] > >

Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES

Masahiko Sawada writes: >> I agree with your analysis on this bug. For non-default >> (defaclnamespace != 0) entries, their acl should be compared to NULL. >> >> The fix also looks good to me. But I think it'd be better to add tests for >> this. > Since the patch conflicts with the current HEAD

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Hi Gilles, > Any though and interest in this feature? Personally, I wouldn't call this feature particularly useful. `SELECT *` is intended for people who are working with DBMS directly e.g. via psql and want to see ALL columns. The applications should never use `SELECT *`. So I can't see any real

Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber

On Thu, Oct 14, 2021 at 3:48 PM Sadhuprasad Patro wrote: > > Hi All, > > Publisher 'DateStyle' is set as "SQL, MDY", whereas in Subscriber as > "SQL, DMY", the logical replication is not working... > > From Publisher: > postgres=# INSERT INTO calendar VALUES ('07-18-1036', '1'), ('05-15-1135', >

Re: Make query ID more portable

On 14/10/21 10:40, Julien Rouhaud wrote: On Thu, Oct 14, 2021 at 12:37 PM Andrey Lepikhov wrote: On 12/10/21 18:45, Bruce Momjian wrote: On Tue, Oct 12, 2021 at 09:40:47AM -0400, Tom Lane wrote: Andrey Lepikhov writes: I think that there are just too many arbitrary decisions that could be

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Hi again, > So all in all, -1. [...] Here is something I would like to add: 1. As far as I know, "all the rest of DBMS have this" was never a good argument in the PostgreSQL community. Generally, using it will turn people against you. 2. I recall there was a proposal of making the SQL syntax its

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

On 10/14/21 1:47 PM, Aleksander Alekseev wrote: > Hi Gilles, > >> Any though and interest in this feature? > > Personally, I wouldn't call this feature particularly useful. `SELECT > *` is intended for people who are working with DBMS directly e.g. via > psql and want to see ALL columns. I disag

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Hi Vik, > I have not looked at the patch, but +1 for the feature. Maybe you could describe your use case in a little more detail? How did you end up working with PostGIS geometry via psql on regular basis? What exactly do you find of annoyance? How will the proposed patch help? I find it great t

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

On Thu, 14 Oct 2021 at 07:17, Gilles Darold wrote: > The user defined columns are always visible in the PostgreSQL. If user > wants to hide some column(s) from a SELECT * returned values then the > hidden columns feature is useful. Hidden column can always be used and > returned by explicitly re

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

čt 14. 10. 2021 v 14:13 odesílatel Vik Fearing napsal: > On 10/14/21 1:47 PM, Aleksander Alekseev wrote: > > Hi Gilles, > > > >> Any though and interest in this feature? > > > > Personally, I wouldn't call this feature particularly useful. `SELECT > > *` is intended for people who are working wit

Re: prevent immature WAL streaming

On Wed, Oct 13, 2021 at 10:58 PM Alvaro Herrera wrote: > > On 2021-Oct-13, Amul Sul wrote: > > > I have one more question, regarding the need for other global > > variables i.e. abortedRecPtr. (Sorry for coming back after so long.) > > > > Instead of abortedRecPtr point, isn't enough to write > >

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Le 14/10/2021 à 13:47, Aleksander Alekseev a écrit : Hi Gilles, Any though and interest in this feature? Personally, I wouldn't call this feature particularly useful. `SELECT *` is intended for people who are working with DBMS directly e.g. via psql and want to see ALL columns. The application

Re: pg14 psql broke \d datname.nspname.relname

On Wed, Oct 13, 2021 at 4:43 PM Mark Dilger wrote: > The function where the processing occurs is processSQLNamePattern, which is > called by pg_dump, pg_dumpall, and psql. All three callers expect > processSQLNamePattern to append where-clauses to a buffer, not to execute any > sql of its own.

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

On Wed, Oct 13, 2021 at 7:45 PM Jeff Davis wrote: > users to be relying on that undocumented function. Is there a good way > to define a view kind of like a SECURITY DEFINER function so that the > superuser would only need to issue a GRANT statement on the view? According to https://www.postgresq

Re: [RFC] building postgres with meson

Josef Šimánek writes: > The only problem I do have currently is auto-detection of perl. I'm > getting error related to missing "Opcode.pm". PERL is autodetected and > enabled (https://pastebin.com/xfRRrDcU). Your Perl (not PERL) installation seems to be incomplete. Opcode.pm is a core module, an

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Le 14/10/2021 à 14:09, Aleksander Alekseev a écrit : Hi again, > So all in all, -1. [...] Here is something I would like to add: 1. As far as I know, "all the rest of DBMS have this" was never a good argument in the PostgreSQL community. Generally, using it will turn people against you. I

Re: [RFC] building postgres with meson

čt 14. 10. 2021 v 15:14 odesílatel Dagfinn Ilmari Mannsåker napsal: > > Josef Šimánek writes: > > > The only problem I do have currently is auto-detection of perl. I'm > > getting error related to missing "Opcode.pm". PERL is autodetected and > > enabled (https://pastebin.com/xfRRrDcU). > > Your

Re: [RFC] building postgres with meson

On 2021-Oct-14, Josef Šimánek wrote: > I'm using Fedora 34 and I still see perl-Opcode.x86_64 as a separate > package. Anyway it behaves differently with autoconf tools and the > meson build system. Is perl disabled by default in the current build > system? Yes, you have to use --with-perl in ord

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Le 14/10/2021 à 14:28, Pavel Stehule a écrit : čt 14. 10. 2021 v 14:13 odesílatel Vik Fearing mailto:v...@postgresfriends.org>> napsal: On 10/14/21 1:47 PM, Aleksander Alekseev wrote: > Hi Gilles, > >> Any though and interest in this feature? > > Personally, I wouldn'

Re: [RFC] building postgres with meson

Josef Šimánek writes: > čt 14. 10. 2021 v 15:14 odesílatel Dagfinn Ilmari Mannsåker > napsal: >> >> Josef Šimánek writes: >> >> > The only problem I do have currently is auto-detection of perl. I'm >> > getting error related to missing "Opcode.pm". PERL is autodetected and >> > enabled (https:/

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

On Thu, Oct 14, 2021 at 2:32 PM Gilles Darold wrote: > Le 14/10/2021 à 14:28, Pavel Stehule a écrit : > > > > čt 14. 10. 2021 v 14:13 odesílatel Vik Fearing > napsal: > >> On 10/14/21 1:47 PM, Aleksander Alekseev wrote: >> > Hi Gilles, >> > >> >> Any though and interest in this feature? >> > >>

Re: Next Steps with Hash Indexes

On Thu, Oct 14, 2021 at 12:48 AM Simon Riggs wrote: > The hash index tuples are 20-bytes each. If that were rounded up to > 8-byte alignment, then that would be 24 bytes. > > Using pageinspect, the max(live_items) on any data page (bucket or > overflow) is 407 items, so they can't be 24 bytes long

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

On Thu, Oct 14, 2021 at 01:16:45PM +0200, Gilles Darold wrote: > Hi, > > > Here is a proposal to implement HIDDEN columns feature in PostgreSQL. > Great! Actually I found this very useful, especially for those people using big fields (geometry, files, large texts). > The user defined columns a

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Le 14/10/2021 à 17:38, Jaime Casanova a écrit : On Thu, Oct 14, 2021 at 01:16:45PM +0200, Gilles Darold wrote: Hi, Here is a proposal to implement HIDDEN columns feature in PostgreSQL. Great! Actually I found this very useful, especially for those people using big fields (geometry, files, la

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

On Thu, 14 Oct 2021 at 09:11, Robert Haas wrote: > > According to https://www.postgresql.org/docs/current/sql-createview.html > it always works like that: "Access to tables referenced in the view is > determined by permissions of the view owner. In some cases, this can > be used to provide secure

Re: refactoring basebackup.c

Thanks, Robert for reviewing the patch. On Tue, Oct 12, 2021 at 11:09 PM Robert Haas wrote: This is the only place where CHUNK_SIZE gets used, and I don't think I > see any point to it. I think the 5th argument to LZ4F_compressUpdate > could just be avail_in. And as soon as you do that then I t

Re: [RFC] building postgres with meson

Hi, On 2021-10-14 10:29:42 -0300, Alvaro Herrera wrote: > On 2021-Oct-14, Josef Šimánek wrote: > > > I'm using Fedora 34 and I still see perl-Opcode.x86_64 as a separate > > package. Anyway it behaves differently with autoconf tools and the > > meson build system. Is perl disabled by default in th

Re: [RFC] building postgres with meson

Hi, On 2021-10-13 23:58:12 +0200, Josef Šimánek wrote: > st 13. 10. 2021 v 1:54 odesílatel Andres Freund napsal: > > This *very* likely is related to building in a source tree that also > > contains > > a "non-meson" build "in place". The problem is that the meson build picks up > > the pg_confi

Re: [Patch] ALTER SYSTEM READ ONLY

On Tue, Oct 12, 2021 at 8:18 AM Amul Sul wrote: > In the attached version I have fixed this issue by restoring > missingContrecPtr. > > To handle abortedRecPtr and missingContrecPtr newly added global > variables thought the commit # ff9f111bce24, we don't need to store > them in the shared memor

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

Greetings, * Isaac Morland (isaac.morl...@gmail.com) wrote: > On Thu, 14 Oct 2021 at 09:11, Robert Haas wrote: > > According to https://www.postgresql.org/docs/current/sql-createview.html > > it always works like that: "Access to tables referenced in the view is > > determined by permissions of t

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Gilles Darold writes: > Le 14/10/2021 à 17:38, Jaime Casanova a écrit : >> On Thu, Oct 14, 2021 at 01:16:45PM +0200, Gilles Darold wrote: >>> Here is a proposal to implement HIDDEN columns feature in PostgreSQL. >> Another use case I can think of is not covered in this patch, but it >> could be (

Re: Inconsistency in startup process's MyBackendId and procsignal array registration with ProcSignalInit()

Hi, On 2021-10-14 17:28:34 +0900, Kyotaro Horiguchi wrote: > At Wed, 13 Oct 2021 19:52:52 +0900 (JST), Kyotaro Horiguchi > wrote in > > Although needing a bit of care for the difference of invalid values > > for both though, BackendId can be easily replaced with pgprocno almost > > mechanically

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

Greetings, * Jeff Davis (pg...@j-davis.com) wrote: > On Wed, 2021-10-13 at 10:03 -0400, Robert Haas wrote: > > Yeah. I think we should really only use predefined roles where it's > > not practical to have people use GRANT/REVOKE. > > That sounds like a good rule. > > A minor complaint though: to

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

čt 14. 10. 2021 v 13:17 odesílatel Gilles Darold napsal: > > Hi, > > > Here is a proposal to implement HIDDEN columns feature in PostgreSQL. > > The user defined columns are always visible in the PostgreSQL. If user > wants to hide some column(s) from a SELECT * returned values then the > hidden c

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

On Thu, 14 Oct 2021 at 13:43, Stephen Frost wrote: > I feel this might relate to the discussion of triggers, which I claim > > should execute in the context of the table owner (or maybe the trigger > > owner, if that were a separate concept). There are lots of triggers one > > might want to write

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

On Thursday, October 14, 2021, Tom Lane wrote: > Gilles Darold writes: > > Le 14/10/2021 à 17:38, Jaime Casanova a écrit : > >> On Thu, Oct 14, 2021 at 01:16:45PM +0200, Gilles Darold wrote: > > > Why not, I will add it if there is a consencus about logging hidden > > column use, this is not a b

Re: refactoring basebackup.c

On Thu, Oct 14, 2021 at 1:21 PM Jeevan Ladhe wrote: > Agree. Removed the CHUNK_SIZE and the loop. Try harder. :-) The loop is gone, but CHUNK_SIZE itself seems to have evaded the executioner. > Fair enough. I have made the change in the bbsink_lz4_begin_backup() to > make sure we reserve enough

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

On Thu, 2021-10-14 at 13:43 -0400, Stephen Frost wrote: > I'm not sure that it's really inconsistent- if you want the function > to > run as someone else, define it as SECURITY DEFINER and it will. There are two issues: 1. Does having permissions to read a view give the reader the ability to exec

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

On Thu, Oct 14, 2021 at 1:43 PM Stephen Frost wrote: > I'm not sure that it's really inconsistent- if you want the function to > run as someone else, define it as SECURITY DEFINER and it will. If the > function is defined as SECURITY INVOKER then it'll run with the > privileges of the user invoki

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

"David G. Johnston" writes: > Taking this a bit further, I dislike tying the suppression of the column > from the select-list star to the behavior of insert without a column list > provided. I’m not fully on board with having an attribute that is not > fundamental to the data model but rather an

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Le 14/10/2021 à 19:44, Tom Lane a écrit : As for the proposal itself, I'm kind of allergic to the terminology you've suggested, because the column is in no way hidden. It's still visible in the catalogs, you can still select it explicitly, etc. Anybody who thinks this is useful from a security

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

I wrote: > Yeah, me too. I think it would add a lot of clarity if we defined this > as "this affects the behavior of SELECT * and nothing else" ... although > even then, there are squishy questions about how much it affects the > behavior of composite datums that are using the column's rowtype. R

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Le 14/10/2021 à 20:43, Tom Lane a écrit : Re-reading that, I realize I probably left way too much unstated, so let me spell it out. Should this feature affect SELECT * FROM my_table t; ? Yes, absolutely. How about SELECT t.* FROM my_table t; ? Yup, one would think so. Now how

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Le 14/10/2021 à 20:26, Tom Lane a écrit : "David G. Johnston" writes: Taking this a bit further, I dislike tying the suppression of the column from the select-list star to the behavior of insert without a column list provided. I’m not fully on board with having an attribute that is not fundame

Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

On Thu, 2021-10-14 at 14:22 -0400, Robert Haas wrote: > I am not really sure that we can get away with changing this, since > it > is long-established behavior. At least, if we do, we are going to > have > to warn people to watch out for backward-compatibility issues, some > of > which may not be t

Re: [RFC] building postgres with meson

I wrote: > Ok great, it builds now! :-) Now something's off with dynamic loading. There are libraries in ./tmp_install/usr/local/lib/ but apparently initdb doesn't know to look for them there: > > $ cat /Users/john/pgdev/meson/build/testrun/main/pg_regress/log/initdb.log > dyld: Library not loaded

Re: [RFC] building postgres with meson

čt 14. 10. 2021 v 15:32 odesílatel Dagfinn Ilmari Mannsåker napsal: > > Josef Šimánek writes: > > > čt 14. 10. 2021 v 15:14 odesílatel Dagfinn Ilmari Mannsåker > > napsal: > >> > >> Josef Šimánek writes: > >> > >> > The only problem I do have currently is auto-detection of perl. I'm > >> > gett

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Le 14/10/2021 à 20:55, Gilles Darold a écrit : gilles=# SELECT row_to_json(t.*) FROM htest0 t;    row_to_json --  {"a":1,"b":"htest0 one"}  {"a":2,"b":"htest0 two"} (2 rows) gilles=# SELECT row_to_json(t) FROM htest0 t;    row_to_json --  

Re: [RFC] building postgres with meson

čt 14. 10. 2021 v 19:24 odesílatel Andres Freund napsal: > > Hi, > > On 2021-10-14 10:29:42 -0300, Alvaro Herrera wrote: > > On 2021-Oct-14, Josef Šimánek wrote: > > > > > I'm using Fedora 34 and I still see perl-Opcode.x86_64 as a separate > > > package. Anyway it behaves differently with autocon

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

On 15/10/21 07:01, Josef Šimánek wrote: čt 14. 10. 2021 v 13:17 odesílatel Gilles Darold napsal: Hi, Here is a proposal to implement HIDDEN columns feature in PostgreSQL. The user defined columns are always visible in the PostgreSQL. If user wants to hide some column(s) from a SELECT * retur

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

On Thu, 14 Oct 2021 at 07:16, Gilles Darold wrote: > Hi, > > Here is a proposal to implement HIDDEN columns feature in PostgreSQL. > > The user defined columns are always visible in the PostgreSQL. If user > wants to hide some column(s) from a SELECT * returned values then the > hidden columns fe

Re: Gather performance analysis

On Tue, Oct 12, 2021 at 10:14 AM Dilip Kumar wrote: > Thanks, yeah now it looks in line with other results. Since it seems there are no remaining concerns here, and we have benchmarking results showing that the patch helps, I have committed the patch. I wonder whether the new code in shm_mq_send

Re: [RFC] building postgres with meson

Hi, On October 14, 2021 12:14:16 PM PDT, John Naylor wrote: >I wrote: > >> Ok great, it builds now! :-) Now something's off with dynamic loading. >There are libraries in ./tmp_install/usr/local/lib/ but apparently initdb >doesn't know to look for them there: >> >> $ cat /Users/john/pgdev/meson/b

Re: BUG #17212: pg_amcheck fails on checking temporary relations

On 10/14/21 12:15 AM, Tom Lane wrote: > Peter Geoghegan writes: >> Any idea what the problems on drongo are? >> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2021-10-14%2001%3A27%3A19 > It says > > # pg_ctl start failed; logfile: > 2021-10-14 02:10:33.996 UTC [491848:1] LOG:

Re: [RFC] building postgres with meson

On Thu, Oct 14, 2021 at 4:34 PM Andres Freund wrote: > Is this a Mac with SIP enabled? The Mac CI presumably has that disabled, which is why I didn't see this issue there. Probably need to implement whatever Tom figured out to do about that for the current way of running tests. System Informatio

Re: [PATCH] Proposal for HIDDEN/INVISIBLE column

Le 14/10/2021 à 22:01, Gavin Flower a écrit : > On 15/10/21 07:01, Josef Šimánek wrote: >> čt 14. 10. 2021 v 13:17 odesílatel Gilles Darold >> napsal: >>> Hi, >>> >>> >>> Here is a proposal to implement HIDDEN columns feature in PostgreSQL. >>> >>> The user defined columns are always visible in th

Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 14, 2021, at 1:50 PM, Andrew Dunstan wrote: > > Bowerbird is having similar issues, so I don't think this is just a > transient. The pg_amcheck patch Peter committed for me adds a new test, src/bin/pg_amcheck/t/006_bad_targets.pl, which creates two PostgresNode objects (a primary a

Re: BUG #17212: pg_amcheck fails on checking temporary relations

Andrew Dunstan writes: > On 10/14/21 12:15 AM, Tom Lane wrote: >> Looks like a transient/phase of the moon issue to me. > Bowerbird is having similar issues, so I don't think this is just a > transient. Yeah, I noticed that too today, and poked around a bit. But I don't see what this test is do

Re: BUG #17212: pg_amcheck fails on checking temporary relations

Mark Dilger writes: > The pg_amcheck patch Peter committed for me adds a new test, > src/bin/pg_amcheck/t/006_bad_targets.pl, which creates two PostgresNode > objects (a primary and a standby) and uses PostgresNode::background_psql(). > It doesn't bother to "finish" the returned harness, which

Re: [RFC] building postgres with meson

I wrote: > > Is this a Mac with SIP enabled? The Mac CI presumably has that disabled, which is why I didn't see this issue there. Probably need to implement whatever Tom figured out to do about that for the current way of running tests. > > System Information says it's disabled. Running "csrutil s

Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 14, 2021, at 2:13 PM, Tom Lane wrote: > > (a) Isn't that just holding open one connection, not the whole instance? Yes. > (b) Wouldn't finish()ing that connection cause the temp tables to be > dropped, negating the entire point of the test? The finish() would have to be the last li

Re: BUG #17212: pg_amcheck fails on checking temporary relations

On Thu, Oct 14, 2021 at 2:13 PM Tom Lane wrote: > TBH, I seriously doubt this test case is worth expending buildfarm > cycles on forevermore. I'm more than a bit tempted to just drop > it, rather than also expending developer time figuring out why it's > not as portable as it looks. I agree. I c

Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 14, 2021, at 2:21 PM, Peter Geoghegan wrote: > > I agree. I can go remove the whole file now, and will. > > Mark: Any objections? None of the "pride of ownership" type, but I would like to see something more about the limitations of background_psql(). It's the closest thing we hav

Re: BUG #17212: pg_amcheck fails on checking temporary relations

On Thu, Oct 14, 2021 at 2:24 PM Mark Dilger wrote: > None of the "pride of ownership" type, but I would like to see something more > about the limitations of background_psql(). I'm not sure what that means for the buildfarm. Are you suggesting that we leave things as-is pending an investigation

Re: BUG #17212: pg_amcheck fails on checking temporary relations

> On Oct 14, 2021, at 2:28 PM, Peter Geoghegan wrote: > > I'm not sure what that means for the buildfarm. Are you suggesting > that we leave things as-is pending an investigation on affected BF > animals, or something else? I was just waiting a couple minutes to see if Andrew wanted to jump i

Re: BUG #17212: pg_amcheck fails on checking temporary relations

Mark Dilger writes: >> On Oct 14, 2021, at 2:13 PM, Tom Lane wrote: >> (b) Wouldn't finish()ing that connection cause the temp tables to be >> dropped, negating the entire point of the test? > The finish() would have to be the last line of the test. > ... > I'm curious if the test is indicating

Re: BUG #17212: pg_amcheck fails on checking temporary relations

On 10/14/21 5:09 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 10/14/21 12:15 AM, Tom Lane wrote: >>> Looks like a transient/phase of the moon issue to me. >> Bowerbird is having similar issues, so I don't think this is just a >> transient. > Yeah, I noticed that too today, and poked around

Re: [RFC] building postgres with meson

Hi, On 14.10.2021 23:54, John Naylor wrote: On Thu, Oct 14, 2021 at 4:34 PM Andres Freund > wrote: > Is this a Mac with SIP enabled? The Mac CI presumably has that disabled, which is why I didn't see this issue there. Probably need to implement whatever Tom figured

Re: [RFC] building postgres with meson

John Naylor writes: >> System Information says it's disabled. Running "csrutil status" complains >> of an unsupported configuration, which doesn't sound good, so I should >> probably go fix that independent of anything else. :-/ > Looking online, I wonder if the "unsupported" message might be ove

Re: BUG #17212: pg_amcheck fails on checking temporary relations

On Thu, Oct 14, 2021 at 2:31 PM Mark Dilger wrote: > I was just waiting a couple minutes to see if Andrew wanted to jump in. > Having heard nothing, I guess you can revert it. Okay. Pushed a commit removing the test case just now. Thanks -- Peter Geoghegan

Re: BUG #17212: pg_amcheck fails on checking temporary relations

Andrew Dunstan writes: > Yes, that's been puzzling me too. I've just been staring at it again and > nothing jumps out. But maybe we can investigate that offline if this > test is deemed not worth keeping. As Mark says, it'd be interesting to know whether the use of background_psql is related, bec

Re: [RFC] building postgres with meson

Andres Freund writes: > Is this a Mac with SIP enabled? The Mac CI presumably has that disabled, > which is why I didn't see this issue there. Probably need to implement > whatever Tom figured out to do about that for the current way of running > tests. AFAIR the only cases we've made work are

Re: [RFC] building postgres with meson

Andres Freund writes: > Hm, so it seems we should make the test separately verify that perl -M{Opcode, > ExtUtils::Embed, ExtUtils::ParseXS} doesn't fail, so that we can fail perl > detection with a useful message? Our existing policy is that we should check this at configure time, not later. Si

Re: relation OID in ReorderBufferToastReplace error message

On 9/23/21, 11:26 AM, "Alvaro Herrera" wrote: > On 2021-Sep-23, Jeremy Schneider wrote: > >> On 9/22/21 20:11, Amit Kapila wrote: >> > >> > On Thu, Sep 23, 2021 at 3:06 AM Jeremy Schneider >> > wrote: >> >> >> >> Any chance of back-patching this? >> > >> > Normally, we don't back-patch code impr

Re: [RFC] building postgres with meson

On 10/13/21 7:11 PM, Andrew Dunstan wrote: > On 10/13/21 5:46 PM, Andres Freund wrote: >> Hi, >> >> On 2021-10-13 16:06:32 -0400, Andrew Dunstan wrote: >>> If you prep a patch I'll test it. >> Well, right now I'm wondering if the better fix is to just remove the whole >> win32 block. I don't know

Re: [RFC] building postgres with meson

On Fri, Oct 15, 2021 at 11:00 AM Tom Lane wrote: > Peter E. did some hacking towards another solution awhile ago, > but IIRC it involved changing the built binaries, and I think > we concluded that the benefits didn't justify that. Yeah, by now there are lots of useful blogs from various projects

Re: [RFC] building postgres with meson

Thomas Munro writes: > I wish I could find the Xnu source that shows exactly how and when the > environment is suppressed in this way to understand better, but it > doesn't jump out of Apple's github; maybe it's hiding in closed source > machinery... I recall that we figured out awhile ago that t

Re: [RFC] building postgres with meson

Hi, On 2021-10-14 18:00:49 -0400, Tom Lane wrote: > Andres Freund writes: > > Is this a Mac with SIP enabled? The Mac CI presumably has that disabled, > > which is why I didn't see this issue there. Probably need to implement > > whatever Tom figured out to do about that for the current way of

[PATCH] Prefer getenv("HOME") to find the UNIX home directory

According to getpwnam(3): An application that wants to determine its user's home directory should inspect the value of HOME (rather than the value getpwuid(getuid())->pw_dir) since this allows the user to modify their notion of "the home directory" during a login session. This is importan

Re: [RFC] building postgres with meson

I wrote: > I recall that we figured out awhile ago that the environment gets trimmed > when make (or whatever) executes some command via the shell; seemingly, > Apple has decided that /bin/sh is a security-critical program that mustn't > be run with a non-default DYLD_LIBRARY_PATH. Dunno if that h

Re: [RFC] building postgres with meson

Hi, On 2021-10-15 11:23:00 +1300, Thomas Munro wrote: > On Fri, Oct 15, 2021 at 11:00 AM Tom Lane wrote: > > Peter E. did some hacking towards another solution awhile ago, > > but IIRC it involved changing the built binaries, and I think > > we concluded that the benefits didn't justify that. >

Re: [RFC] building postgres with meson

Andres Freund writes: > If, and perhaps that's too big an if, relative rpaths actually work despite > SIP, it might be worth setting a relative install_rpath, because afaict that > should then work both for a "real" installation and our temporary test one. >From what we know so far, it seems like

Re: [RFC] building postgres with meson

On Thu, Oct 14, 2021 at 6:55 PM Andres Freund wrote: > Ah, I thought it was more than that. In that case, John, does meson's test > succeed after you did the "proper" install? Assuming it's in a path that's > allowed to provide shared libraries? Oh, it can act like installcheck? [checks] Yep, "me

Re: [RFC] building postgres with meson

Hi, On 2021-10-14 18:08:58 -0400, Tom Lane wrote: > Andres Freund writes: > > Hm, so it seems we should make the test separately verify that perl > > -M{Opcode, > > ExtUtils::Embed, ExtUtils::ParseXS} doesn't fail, so that we can fail perl > > detection with a useful message? > > Our existing po

Re: [RFC] building postgres with meson

Andres Freund writes: > On 2021-10-14 18:08:58 -0400, Tom Lane wrote: >> Andres Freund writes: >>> Hm, so it seems we should make the test separately verify that perl >>> -M{Opcode, >>> ExtUtils::Embed, ExtUtils::ParseXS} doesn't fail, so that we can fail perl >>> detection with a useful message

Re: [RFC] building postgres with meson

Hi, On 2021-10-14 19:27:17 -0400, John Naylor wrote: > On Thu, Oct 14, 2021 at 6:55 PM Andres Freund wrote: > > Ah, I thought it was more than that. In that case, John, does meson's test > > succeed after you did the "proper" install? Assuming it's in a path that's > > allowed to provide shared l

Re: [RFC] building postgres with meson

On Fri, Oct 15, 2021 at 12:04 PM Tom Lane wrote: > [tgl@pro ~]$ cat checkenv.c > #include > #include > > int > main(int argc, char **argv) > { > char *pth = getenv("DYLD_LIBRARY_PATH"); > > if (pth) > printf("DYLD_LIBRARY_PATH = %s\n", pth); > else > printf("DYLD_LIBRARY_PATH is un

Re: Added schema level support for publication.

On Thu, Oct 14, 2021 at 9:59 PM Amit Kapila wrote: > > > If partitions belong to a different schema than the parent partitioned > > table, then the current patch implementation allows the partitions to > > (optionally) be explicitly added to a publication that includes the > > parent partitioned t

Re: [RFC] building postgres with meson

Thomas Munro writes: > On Fri, Oct 15, 2021 at 12:04 PM Tom Lane wrote: >> This may indicate that they've applied this policy on a blanket >> basis to everything in /bin and /usr/bin (and other system >> directories, maybe), rather than singling out the shell. > Looks like it. If I've found the

Re: [RFC] building postgres with meson

Hi, On 2021-10-14 22:46:07 -0400, Tom Lane wrote: > Thomas Munro writes: > > I suppose you could point SHELL at an unsigned copy of sh (codesign > > --remove-signature, or something from brew/ports/x) so that GNU make > > should respect, but I don't know how many other exec("/bin/sh") calls > > m

Re: [PATCH] Added TRANSFORM FOR for COMMENT tab completion

On 2021-10-14 14:30, katouknl wrote: It is very good, but it seems to me that there are some tab-completion missing in COMMENT command. For example, - CONSTRAINT ... ON DOMAIN - OPERATOR CLASS - OPERATOR FAMILY - POLICY ... ON - [PROCEDURAL] - RULE ... ON - TRIGGER ... ON I think these tab-comle

  1   2   >