> On May 2, 2023, at 12:15, Tomas Pospisek wrote:
>
> Oh, I think your idea to use pgbouncer to take care of the SSL termination is
> elegant. I don't think me I'd characterize it as a hack if properly set up.
> Why do you consider it a hack?
It's really only a hack in the sense that pgboun
> On Apr 27, 2023, at 12:40, Michael Xu wrote:
> In our env, it throws 42P01:relation "ads.MyTableName" does not exist.
The function of double quotes in SQL is to allow you do include characters that
would otherwise not be legal in an identifier (as well as making the identifier
case-sensiti
> On Apr 25, 2023, at 09:35, Peter Geoghegan wrote:
>
> It's skipped by VACUUM, but not by ANALYZE. So if you're using the
> reloption version of index_cleanup=off, it isn't necessarily going to
> stop autovacuum/autoanalyze from doing pending list cleanup.
Ugh, thanks. I wasn't aware that i
Does VACUUM (INDEX_CLEANUP OFF) flush the pending list for GIN indexes, or is
that skipped as well?
> On Apr 18, 2023, at 03:45, Robert Sjöblom wrote:
> I'm aware of that. But you can, however, do something like:
>
> SELECT * FROM FOO WHERE CTID = (SELECT MAX(CTID) FROM FOO);
>
> on both sides. The idea being that if I change FOO, the CTID of the changed
> row will not be the same on both
> On Apr 18, 2023, at 01:20, Robert Sjöblom wrote:
> Another idea we've had would be to use CTID to fetch the last row
> (update/insert) in each table on both sides and compare row content, is this
> feasible? Is it safe to rely on CTIDs across logical replication?
No. CTIDs aren't sent ove
> On Mar 29, 2023, at 12:11, Sebastien Flaesch
> wrote:
> But to make PostgreSQL more Informix-compatible, zero should have been
> considered as well.
There is an infinite family of strange features that various databases have
(DUAL from Oracle, anyone?); PostgreSQL will rapidly become unus
> On Mar 28, 2023, at 03:39, Sebastien Flaesch
> wrote:
> Do I have to cast() ?
Yes:
select * from t where ctid='(0,1)'::tid;
The string representation can be up to 17 characters: 10 for the page number, 4
for the tuple number, and three for the delimiters.
Remember that updating
> We have an Oracle DB which is around 1TB and we want to migrate to
> PostgreSQL that have a new table structure, so we want to perform
> data transformation and real time CDC from Oracle to PostgreSQL. Do
> we have any good open source tool to achieve this with No Coding
> involved.??
To meet al
> On Mar 6, 2023, at 16:24, Siddharth Jain wrote:
> My question: How can it then store a B Tree on disk? I would think storing a
> B Tree requires storing disk offset addresses and so on (for a node to
> navigate to another etc.). For this, one would need to write directly to the
> disk usin
> On Feb 21, 2023, at 10:48, Brad White wrote:
>
> Running the table_bloat_check query from here
> https://github.com/pgexperts/pgx_scripts/blob/master/bloat/table_bloat_check.sql
>
> shows some tables with over 20MB and over 20% bloat while my threshold is set
> to 0.1.
Apples-to-oranges
> On Feb 21, 2023, at 09:54, Brad White wrote:
> Any suggestions on how to proceed?
First, look at pg_stat_user_tables to see how many inserts etc. have occurred
on the tables that are not showing an autovacuum; they may have simply not
reached the threshold yet. If they have, do a VACUUM V
> On Feb 20, 2023, at 17:54, Bryn Llewellyn wrote:
>
>
> I’ve no idea how I might have found this without human help.
That sounds like an excellent documentation patch!
> On Feb 20, 2023, at 11:57, Bryn Llewellyn wrote:
> 2. If I send over "begin" and then "insert into s.t(v) values(42)", then (so
> far) a second session will not see the effect of my SQL's. It sees this only
> when I send over "commit". (If I send over "rollback" instead of "commit",
> then
> On Feb 18, 2023, at 18:52, Ian Lawrence Barwick wrote:
>
> Historical trivia: PostgreSQL had a (backend) "autocommit" GUC in 7.3
> only, which remained as
> a dummy GUC until 9.5 (see: https://pgpedia.info/a/autocommit.html ).
Well, that was a pretty whacky idea. :-)
> On Feb 18, 2023, at 15:49, Bryn Llewellyn wrote:
>
> I’ve searched in vain for an account of how "autocommit" mode actually works.
I realize now I may have misinterpreted your question... apologies if so! If
you mean the BEGIN and COMMIT statement that some client libraries insert into
t
> On Feb 18, 2023, at 15:49, Bryn Llewellyn wrote:
>
> Or is it done server-side?
It's done server-side. Note that what really happens is that, when a statement
begins execution and there is no open transaction, a snapshot is taken and then
released when the statement finishes (just as hap
> On Feb 18, 2023, at 06:59, Peter J. Holzer wrote:
> I think the reason
> is that the use case (the exact same query is submitted repeatedly) is
> sufficiently rare that it isn't all that effective in practice.
And, in this use case, a prepared statement is in effect a cache of the parsing
a
> On Feb 8, 2023, at 14:14, Siddharth Jain wrote:
>
> If the B-Tree index will be so large that it cannot fit in memory, then is it
> worth creating it at all?
Yes. Of course, more memory is better, and more recently versions of
PostgreSQL have optimizations that are valuable for large B-
> On Feb 8, 2023, at 13:17, Siddharth Jain wrote:
>
> As I explained in my question that is indeed our dilemma. Our insertion order
> will not be equal to index order. i.e., referring to your response:
>
> > who's data is added in the same order as the key in the BRIN index
>
> does NOT hol
> On Feb 1, 2023, at 10:45, David G. Johnston
> wrote:
> The system just isn't that intelligent for "sequential scan", instead it does
> literally what the label says, goes through the table one page at a time and
> returns any live rows it finds.
Although this does raise a question: Could
> On Jan 31, 2023, at 07:40, Dimitrios Apostolou wrote:
> Is this bloat even affecting queries that do not use the index?
No, but a bloated index often (although not always) goes along with a bloated
table.
> It seems I have to add VACUUM FULL to nightly maintainance.
I wouldn't go that far
> On Jan 28, 2023, at 11:29, Miles Elam wrote:
> Why does this error result?
While the standard order of operations is to evaluate the WHERE before the
SELECT list, it's not guaranteed to result in short-cut execution. In
particular, constant folding happens very early in the processing of
> On Jan 27, 2023, at 13:01, Rumpi Gravenstein wrote:
>
> We are using the pg_indexes view (indexdef) to retrieve the index definition.
This is as expected. Once the index is created on the partitioned set of
tables, the index on the *root* table will be ON ONLY that table; the child
table
> On Jan 26, 2023, at 11:17, veem v wrote:
> So we want to understand from experts here, if there are any clear rules
> available or if we have any pros vs cons list available for each of those to
> understand the exact scenario in which we should go for one over other?
Clear rules are a bit
> On Jan 25, 2023, at 14:21, Dirschel, Steve
> wrote:
> From my perspective "idle in transaction" isn't necessarily a problem
> (although I don't like seeing sessions sitting like that for a long time).
> The problem is when pg_stat_activity.backend_xmin is populated- that can
> prevent a
> On Jan 24, 2023, at 07:37, Zwettler Markus (OIZ)
> wrote:
>
> Is a logical replication crash recovery safe?
You might want to give more detail about the scenario you are concerned about.
Changes that are received by a subscriber as part of logical replication are
WAL-logged, observe tra
> On Jan 16, 2023, at 09:53, David G. Johnston
> wrote:
>
> I don't see any good way to say: "given this function signature, and the fact
> it cannot be found, what are the next closest function signatures that are
> present".
I can see a use-case for such functionality, though: A "did you
> On Jan 11, 2023, at 22:07, Tom Lane wrote:
> No, not directly, but you could look at EXPLAIN ANALYZE to see which
> of the RI triggers is eating the time. It's not going to be hard to
> figure out which one(s) are using indexed plans and which are not.
Also, IIRC, the SELECTs generated to d
> On Jan 5, 2023, at 21:28, Laurenz Albe wrote:
>
> On Tue, 2023-01-03 at 16:03 +, Zwettler Markus (OIZ) wrote:
>> We are using a DIY Postgres backup:
>> ---
>> psql -c "select pg_start_backup ('Full');"
>> save -s "${NSR_SERVER}" -g "${NSR_POOL}" "${PGDATA}"
>> psql -c "select pg_stop_bac
> On Jan 5, 2023, at 19:38, Bhautik Chudasama
> wrote:
>
> Does it mean when we commit transaction, client will wait until all replicas
> successfully committed the transaction.
It depends. If all the settings are the defaults, no, the client won't wait
for the replicas to acknowledge the
> On Jan 5, 2023, at 16:03, Ron wrote:
>
> Even in asynchronous replication?
Yes. Asynchronous replication controls when the client doing the transaction
is told that the transaction is complete; it doesn't allow for dirty reads on
either the primary or secondary.
> On Jan 5, 2023, at 12:07, Louis Laborde wrote:
>
> Are PG replicas updated atomically following the same transactions boundaries
> as the source DB ?
Yes. The same transactional guarantees apply to the replica as do to the
original transactions on the primary.
While working on a different FDW, I discovered that postgres_fdw doesn't push a
DISTINCT clause to the foreign server, unless it's part of an aggregate
function:
k=# explain verbose select distinct i from tf;
QUERY PLAN
> On Dec 15, 2022, at 10:23, Christophe Pettus wrote:
> Is there a way from SQL to get the size of a particular attribute (field in a
> row) with a variable-length typed as stored on disk (including compression)?
> The use case is to determine the size distribution
Hi,
Is there a way from SQL to get the size of a particular attribute (field in a
row) with a variable-length typed as stored on disk (including compression)?
The use case is to determine the size distribution for setting
TOAST_TUPLE_TARGET and making other decisions about what to store in tha
> On Dec 2, 2022, at 08:02, Tom Lane wrote:
>
> Pasi Oja-Nisula writes:
>> I would be perfectly satisfied, if the sql that produced the procedure
>> would be stored "as is" read-only copy when it was compiled.
> If you want an audit comparison point, I'd suggest capturing
> the result of pg_
> On Dec 1, 2022, at 11:05, Dominique Devienne wrote:
>
> I see. Still, Oracle preserves SQL as-is. SQLite preserve SQL as-is.
> Would be nice if PostgreSQL did too. That's all I'm saying.
Since this is a custom-built system, there is nothing keeping you from creating
your own table in the d
> On Dec 1, 2022, at 05:45, Rizwan Shaukat wrote:
> we hv requiremnt from security to secure pg_hba.conf file was encryption or
> password protected on server to protect ip visibilty because these server
> access by application n thy can amend as well. how we can achive it pls
The only prac
> On Nov 30, 2022, at 07:40, Atul Kumar wrote:
> So please let me know how I should do it in a quicker backup for my 10TB
> database ? Is there any tool to take backups and subsequently incremental
> backups in a faster way and restore it for PITR in a faster way when required.
For an initia
> On Nov 27, 2022, at 10:53, Igor Korot wrote:
> Are you saying I can't run any query on other DB? Or connect to DB and
> run select?
The query you run only looks at the system catalogs for the database you are
connected to (with the exception of the small number of global catalogs, like
pg_
> On Nov 27, 2022, at 10:42, Igor Korot wrote:
>
> It doesn't say anything about "current" DB - only the DB.
In PostgreSQL terminology, a single PostgreSQL instance (the cluster) can have
multiple databases. The database the connection is currently open to is the
current database.
> On Nov 23, 2022, at 12:06, Siddharth Jain wrote:
> Is there any way to accomplish what I want? Thanks.
There is:
https://www.postgresql.org/docs/current/sql-alterdefaultprivileges.html
> On Nov 13, 2022, at 12:45, Karsten Hilbert wrote:
> REINDEX DATABASE db_in_question;
> ALTER DATABASE db_in_question REFRESH COLLATION VERSION;
> ALTER COLLATION every_collation_from_pg_collation REFRESH VERSION;
I may be totally off-base here, but shouldn't the REINDEX be
> On Nov 7, 2022, at 17:43, Jan Bilek wrote:
>
> Well, superuser (our App) is already logged in and as it is designed
> very much as an "appliance" it simply does that job - manages its
> database.
Well... don't do that. :) The problem is analogous to having root log into a
Linux box and
> On Nov 7, 2022, at 17:24, Jan Bilek wrote:
> Would there be any way to go around this?
The typical configuration is to not permit the PostgreSQL superuser to log in
remotely. The database can be managed by a different, non-superuser role,
including schema migrations.
> CREATE OR REPLACE
> On Nov 3, 2022, at 10:38, Siddharth Jain wrote:
> I read an old article comparing MySQL to Postgres and wanted to get answers
> to following questions.
Given your questions, I suspect that you read the technical note from Uber
about why they switched back to MySQL from PostgreSQL. There
> On Oct 20, 2022, at 11:45, Vince McMahon
> wrote:
>
> Thanks. I guess it is time for vacuum. 😂
Ironically, vacuum is the main issue. The main reason that you can't just slap
a few gigabytes onto the end of a table is that the next time vacuum runs, it
will happily truncate it all away.
> On Oct 20, 2022, at 10:29, Ron wrote:
> There's no pre-allocation in Postgresql.
This is correct in that you can't say "please allocate 3GB for this table for
me now." The number of pages that are added to the end of a file isn't always
one though; it can allocate more based on recent act
> On Oct 20, 2022, at 09:52, Vince McMahon
> wrote:
> The number of rows are different.
This isn't unexpected. EXPLAIN does not actually run the query and determine
how many rows are returned; it calculates an estimate based on the current
system statistics, which vary constantly dependin
> On Oct 18, 2022, at 19:18, gogala.mla...@gmail.com wrote:
>
> Commit within a loop is an extremely bad idea.
This is an over-generalization. There are many use-cases for this (if there
were not, procedures wouldn't have been nearly as important a feature).
For example, if you are processi
> On Oct 18, 2022, at 14:15, Bryn Llewellyn wrote:
> Could the limitation be lifted by making tractable internal implementation
> changes? Or is it rooted in profoundly deep features of the
> architecture—meaning that it could never be lifted?
That is a very good question. One of the issues
> On Oct 18, 2022, at 14:29, Ravi Krishna wrote:
>
> > You can commit in a loop, but not in BEGIN / END block that has an
> > exception handler:
> > that creates a subtransaction for the duration of the BEGIN / END.
>
> The reason I have to deal with error exception is that I want to ignore
> On Oct 18, 2022, at 13:14, Ravi Krishna wrote:
>
> I am getting error at COMMIT -> cannot commit while a subtransaction is
> active.
> Is commit not possible in a loop
You can commit in a loop, but not in BEGIN / END block that has an exception
handler: that creates a subtransaction for t
> On Oct 8, 2022, at 17:14, Theodore M Rolle, Jr. wrote:
>
> What are the pros and cons of using a TF card to store data?
Assuming by TF you mean Transflash, a trade name for SD cards, the bandwidth on
them is not particularly spectacular. The absolute fastest is an SDUC card at
~980Mb/s,
> On Oct 7, 2022, at 17:16, Bryn Llewellyn wrote:
> What does "make for a good bug report" mean, David?
Well, first of all, brevity. :-)
> Is it:
>
> (1.1) You, David, or somebody else who has been officially recognized as a PG
> Contributor (https://www.postgresql.org/community/contributor
> On Oct 6, 2022, at 10:44, Ron wrote:
> Sadly, that VM doesn't have nearly enough disk space to hold the backup
> folder.
Use file mode, and stream the output via scp/ssh to a different machine?
> On Oct 6, 2022, at 10:20, Kaushal Shriyan wrote:
>
> I am not sure if I understand the difference between binary and logical
> replication between PostgreSQL Master and Standby/Slave server.
It's best to review the documentation here:
https://www.postgresql.org/docs/10/logical-rep
> On Oct 6, 2022, at 09:46, Ron wrote:
> Because installing new software on production servers requires hurdles
> (Service Now change ticket approved by the application support manager,
> Delivery Service Manager, Engineering Change Board, and a one week lead time
> before installing during
> On Oct 5, 2022, at 17:16, Bryn Llewellyn wrote:
> B.t.w, the value of "quote_ident()" rests on the distinction between a name
> (what you provide with the function's actual argument) and an identifier
> (what it returns).
There is no first-class "identifier" type in PostgreSQL, so a functi
> On Oct 5, 2022, at 09:32, Kaushal Shriyan wrote:
>
> Hi,
>
> Is replication possible between PostgreSQL support Master database running
> 9.6.1 version which is a lower version to Standby/Slave running version
> 10.17?
Binary replication is not possible between different major versions.
> On Sep 24, 2022, at 09:04, Barry Kimelman wrote:
> Unfortunately, that is exactly what I need to do, I need to modify the data
> on the 2nd request so that it also gets inserted.
The best approach is to optimistically insert the row, catch the error if
there's a conflict, and modify the da
> On Sep 24, 2022, at 08:49, Barry Kimelman wrote:
> I thought the whole point of ON CONFLICT DO UPDATE was so that you could
> modify the data so that it would be inserted
ON CONFLICT DO UPDATE allows you to modify the existing row that conflicted
with the row being inserted, but it won't a
> On Sep 24, 2022, at 08:29, Barry Kimelman wrote:
> Thanks for the response. When I ran the INSERT with your suggested change I
> got an error message telling me
> "column reference 'company_name' is ambiguous"
As previously noted, you'll need to do both: add "excluded." to qualify the
colu
> On Sep 24, 2022, at 07:29, Barry Kimelman wrote:
>
> CREATE UNIQUE INDEX my_companies_company_name_unique ON
> my_companies(company_name) WHERE delete_timestamp IS NULL;
The issue here is that the unique index is partial (it has a WHERE clause). In
order to use that as an arbiter, you ne
> On Sep 16, 2022, at 14:20, Tom Lane wrote:
> IOW: I think they want you to get that from macports or homebrew instead.
> It certainly works a lot easier if you do.
Yeah, I installed openjdk8 using MacPorts, but it puts its stuff in a rather
idiosyncratic location. I guess it's "create-a-sy
I'm attempting to build the pgspider JDBC foreign data wrapper on MacOS, and
not having an enormously successful time. The driver source is at:
https://github.com/pgspider/jdbc_fdw
It (unsurprisingly) needs to link with libjvm.dylib, so I've included the path
to it in the PostgreSQL ./
> On Sep 13, 2022, at 14:10, Tom Lane wrote:
>
> Perhaps you'd already revoked from public in this database?
Very possible!
> On Sep 13, 2022, at 11:39, Bryn Llewellyn wrote:
>
> What are you seeing that I'm failing to?
It works correctly for me, on MacOS:
swift-239:~ xof$ psql
psql (14.5)
Type "help" for help.
xof=# create user r1;
CREATE ROLE
xof=# revoke execute on function pg_terminate_backend from r1;
REVOK
> On Sep 13, 2022, at 11:23, Bryn Llewellyn wrote:
>
> There must be some-or-other non-standard setting in my environment that
> results in the behavior that I see and that other's don't.
From the documentation:
> superuser status
> A database superuser bypasses all permission checks,
> On Sep 12, 2022, at 20:44, Bryn Llewellyn wrote:
> Version 16? Thus might be the clue, then.
It behaves as David describes on:
PostgreSQL 14.5 on x86_64-apple-darwin19.6.0, compiled by Apple clang
version 12.0.0 (clang-1200.0.32.29), 64-bit
> On Sep 12, 2022, at 15:51, Bryn Llewellyn wrote:
> The implication is that every client program must follow every database call
> with defensive code to detect error "57P01" and programmatically re-try.
That situation exists even without the ability for a role to kill other
sessions author
> On Sep 5, 2022, at 23:10, Karthik K L V wrote:
> The above query fails with the below exception when the value of ?1 resolves
> to null.
> org.postgresql.util.PSQLException: ERROR: operator does not exist: character
> varying = bytea
> Hint: No operator matches the given name and argument
> On Sep 5, 2022, at 19:40, Jeffrey Walton wrote:
> And finally, try the new password:
>
>PGPASSWORD=hi...HS psql -U postgres
>psql: error: connection to server on socket
> "/var/run/postgresql/.s.PGSQL.5432" failed:
>FATAL: Peer authentication failed for user "postgres"
If it's
> On Sep 2, 2022, at 14:22, Jeffrey Walton wrote:
> Given the NOTES in the man page, how do we determine if a user and
> database are present using the shell? Is there another utility we
> should be using?
pg_isready literally only checks that the server can be reached over the
connection pat
> On Sep 1, 2022, at 21:41, Meera Nair wrote:
> Archival hangs. Is this expected?
> postgres=# select pg_start_backup('test', true, false);
> pg_start_backup
> -
> 1/F960
> (1 row)
>
> postgres=# select pg_stop_backup('f');
> NOTICE: base backup done, waiting for required
> On Sep 1, 2022, at 10:14, V wrote:
> I want new/old tuples with pgoutput. how?
I assume here you are reading the pgoutput protocol directly.
Logical decoding sends out two tuple structures:
1. The replica identity of the row (in the case of update and delete).
2. The new row data (in the c
> On Aug 26, 2022, at 18:47, Bryn Llewellyn wrote:
> No, I’m not proposing any code change.
Thanks for clarifying.
> On Aug 26, 2022, at 15:33, Bryn Llewellyn wrote:
> [...]
I'm still not clear on what you are proposing. Are you proposing a change to
PostgreSQL to remove the "connamespace" column from the "pg_constraint" table,
since it can be derived from other tables?
> On Aug 25, 2022, at 21:43, Bryn Llewellyn wrote:
> [...]
I've read this a few times, and I am having trouble understanding what behavior
you were expecting out of PostgreSQL, and what behavior you received that you
didn't think was correct. If it is "pg_constraint has a column connamespac
> On Aug 20, 2022, at 15:42, Perry Smith wrote:
>
> To rephrase, is it possible to write a view that would work from the child
> terms out towards the ancestors?
Assuming that the concern is that you want to parameterize this predicate:
WHERE basename = '10732.emlx'
... you mig
I am reasonably sure the answer to this is "no", but can the oldest xmin that
hot_standby_feedback sends to the primary also delay SIReadLocks cleanup?
Going through the code, it looks like they're independent, but this isn't a
part of the system I know particularly well.
> On Aug 17, 2022, at 22:57, Abdul Qoyyuum wrote:
> Question is, do we have to shutdown traffic and close all existing open
> connections in order to drop and properly recreate the index?
No, you don't.
On the CREATE INDEX CONCURRENTLY command, what is likely going on is that when
the conne
> On Aug 17, 2022, at 13:06, Ivan N. Ivanov wrote:
>
> How to speed up recovering of WAL files?
Since you are running on your own hardware, you might take a look at:
https://github.com/TritonDataCenter/pg_prefaulter
> On Aug 3, 2022, at 10:16, zaphod61 wrote:
>
>
> I've inherited a postgresql 12.3 installation. It has 1 database in it. I
> need to upgrade it to the newest version, which appears to be 12.11. Can I
> just download the installer for 12
> 11 and run that to upgrade the product and still m
> On Jul 28, 2022, at 18:49, Bryn Llewellyn wrote:
> It's this that surprises me. And it's this, and only this, that I'm asking
> about: might _just_ this be a fixable bug?
It might be surprising, but it's not a bug. You can demonstrate it with a very
small test case:
CREATE FUNCTION f() R
> On Jul 28, 2022, at 18:04, Bryn Llewellyn wrote:
> Is this expected?
Yes. This isn't a bug.
> In other words, is there a careful explanation of what "parse" means in the
> context of "create or replace" for a subprogram that predicts all of the
> outcomes that I reported here?
Database
> On Jul 18, 2022, at 20:03, merryok wrote:
>
> I've read the doc, and it doesn't help too much.
> Finally I've found START_CRIT_SECTION and END_CRIT_SECTION. It's like
> mtr.start(), mtr.commit() in mysql. May I ask why many places are wrapped
> into START_CRIT_SECTION/END_CRIT_SECTION duri
> On Jul 6, 2022, at 12:51, Matthias Apitz wrote:
> it is uniqu to identify a row in a table once
> known.
I think the point that we are trying to make here is that a ctid *isn't* that.
There is no guarantee, at all, at any level, that the ctid of a row will remain
stable, not even between
> On Jul 6, 2022, at 09:48, Bryn Llewellyn wrote:
> Neither causes an error. The "show", in each case, prints the bare value with
> no quotes. It never struck me try try double quotes around the timezone
> argument. I'm shocked that they are silently accepted here and seem to have
> the same
> On Jul 5, 2022, at 22:35, Matthias Apitz wrote:
> Internally, in the DB layer, the read_where() builds the row list matching
> the WHERE clause as a SCROLLED CURSOR of
>
>SELECT ctid, * FROM d01buch WHERE ...
>
> and each fetch() delivers the next row from this cursor. The functions
> s
> On Jul 5, 2022, at 11:12, Bryn Llewellyn wrote:
> Finally, what do you think of a possible future enhancement to allow setting
> a null search_path?
You use the empty string, rather than NULL, but it works right now:
xof=# show search_path;
search_path
-
"$user", pub
> On Jun 28, 2022, at 23:42, Laurenz Albe wrote:
> That is not enough in the general case. You are not allowed to redefine
> an IMMUTABLE function in a way that changes its behavior [...]
I think "not allowed" is putting it too strongly. It would be a bit much to
ask that every single user-
> On Jun 28, 2022, at 18:41, Bryn Llewellyn wrote:
> Should I simply understand that when I have such a dynamic dependency chain
> of "immutable" functions, and should I drop and re-create the function at the
> start of the chain, then all bets are off until I drop and re-create every
> func
> On Jun 12, 2022, at 23:07, Pavel Stehule wrote:
> The lazy implementation theoretically can be possible, but why?
Isn't one of the reasons for the savepoint (in fact, the principal reason) to
reset the connection back to non-error state so that execution can continue?
In that case, it rea
> On Nov 8, 2021, at 11:47, Oleg Serov wrote:
> I'm sorry, when I mean users, I mean application end-user (e.g.
> j...@doe.com), not the postgres role.
You can also set it as a session-level variable. :-)
SET synchronous_commit = 'on';
You could flip it on for the application-le
> On Nov 8, 2021, at 10:03, Oleg Serov wrote:
> That does not seem to be feasible for our application. Using synchronous
> commit affects performance and really makes replication not really useful...
> What we want to achieve is to have a consistent DB state across all
> connections for mast
> On Nov 7, 2021, at 19:42, Oleg Serov wrote:
> How would you accomplish this otherwise?
Synchronous commit. It sounds like you are attempting to build the same kind
of guarantees that synchronous commit provides, only in the application by
polling LSNs. It might be best just to use synchr
> On Nov 4, 2021, at 12:16, Alanoly Andrews wrote:
>
> Thanks, Ninad, for the response.
> So, am I to understand that when there is a long-running query on the
> subscriber, the vacuumed data updates from the publisher are held over on the
> subscriber until the query completes? If so, where
> On Sep 27, 2021, at 10:42, Christophe Pettus wrote:
> We've encountered some unexpected behavior with statement_timeout not
> cancelling a query in DECLARE CURSOR, but only if the DECLARE CURSOR is
> outside of a transaction:
A bit more poking revealed the reason: The
101 - 200 of 287 matches
Mail list logo
