Re: Gradual migration from integer to bigint?
W dniu 30.09.2023 o 07:55, James Healy pisze: ... We shouldn't have let them get so big, but that's a conversation for another day. Some are approaching overflow and we're slowly doing the work to migrate to bigint. Mostly via the well understood "add a new id_bigint column, populate on new tuples, backfill the old, switch the PK" method. The backfill is slow on these large tables, but it works and there's plenty of blog posts and documentation to follow. wouldn't wrapping to negative numbers like: https://www.youtube.com/watch?v=XYRgTazYuZ4&t=1338s be a solution for you? At least for buying more time for the slow migration process. Or even as a definite solution if you now take care and not let the keys grow too quickly.
Re: Need to find the no. of connections for a database
W dniu 2020-02-27 o 12:35, sivapostg...@yahoo.com pisze: I need to prevent other users from entering any transaction till I finish taking reports from my application. All users will be using the same application, from which this report is supposed to be printed. maybe advisory lock is what you need? https://www.postgresql.org/docs/current/explicit-locking.html#ADVISORY-LOCKS
Re: Need to find the no. of connections for a database
W dniu 2020-02-27 o 14:37, sivapostg...@yahoo.com pisze: Hello, I'm saying isolation will not work out to my requirement. The steps. 1. On completion of all entries by all, say for a day. 2. Lock, so that no one enters any other data. 3. Create a report from the entered data. 4. Create / Modify required entries from the values arrived in the report. [ long process ] 5. Once completed, commit all data. 6. Unlock, so that other users can enter data again. Data entered will be for another date. Data cannot [should] not entered for the processed date. so wouldn't pg_advisory_lock() in step 2, and pg_advisory_unlock() in step 6, make the process work in the way you expect? https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS On Thursday, 27 February, 2020, 06:29:00 pm IST, Ireneusz Pluta/wp.pl wrote: W dniu 2020-02-27 o 12:35, sivapostg...@yahoo.com <mailto:sivapostg...@yahoo.com> pisze: > I need to prevent other users from entering any transaction till I finish taking reports from my > application. All users will be using the same application, from which this report is supposed to > be printed. > maybe advisory lock is what you need? https://www.postgresql.org/docs/current/explicit-locking.html#ADVISORY-LOCKS
Re: Need to find the no. of connections for a database
W dniu 2020-02-27 o 15:26, sivapostg...@yahoo.com pisze: Need to lock around 10 tables. Let me try with pg_advisory_lock(). I am not sure why you mention table locks at this point. Just in case: with advisory locks you lock an "application flow", not database objects. On Thursday, 27 February, 2020, 07:39:13 pm IST, Ireneusz Pluta/wp.pl wrote: W dniu 2020-02-27 o 14:37, sivapostg...@yahoo.com <mailto:sivapostg...@yahoo.com> pisze: > Hello, > > I'm saying isolation will not work out to my requirement. The steps. > > 1. On completion of all entries by all, say for a day. > 2. Lock, so that no one enters any other data. > 3. Create a report from the entered data. > 4. Create / Modify required entries from the values arrived in the report. [ long process ] > 5. Once completed, commit all data. > 6. Unlock, so that other users can enter data again. Data entered will be for another date. > Data cannot [should] not entered for the processed date. > so wouldn't pg_advisory_lock() in step 2, and pg_advisory_unlock() in step 6, make the process work in the way you expect? https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS > > > On Thursday, 27 February, 2020, 06:29:00 pm IST, Ireneusz Pluta/wp.pl <mailto:ipl...@wp.pl>> wrote: > > > W dniu 2020-02-27 o 12:35, sivapostg...@yahoo.com <mailto:sivapostg...@yahoo.com> <mailto:sivapostg...@yahoo.com <mailto:sivapostg...@yahoo.com>> pisze: > > > I need to prevent other users from entering any transaction till I finish taking reports from my > > application. All users will be using the same application, from which this report is supposed to > > be printed. > > > > maybe advisory lock is what you need? > > https://www.postgresql.org/docs/current/explicit-locking.html#ADVISORY-LOCKS > > > >
Re: Switching Primary Keys to BigInt
W dniu 2020-07-21 o 17:30, Mohamed Wael Khobalatte pisze: we are planning to move some primary keys from int to bigint because we are approaching the type limit If that does not break your business logic, you might arrange to use the negative half of the ::int value range. Ugly, but this might at least buy you some time before finding the definite and elegant way, if you are under some pressure. I do not recommend this, but this is what once saved my life (or at least one night), after I realized that my PK already reached the limit :-).
Re: how to switch off: WARNING: psql major version 11, server major version 13
W dniu 2020-09-28 o 13:39, Matthias Apitz pisze: El día lunes, septiembre 28, 2020 a las 12:17:26p. m. +0200, Paul Förster escribió: $ psql -Usisis -dsisis SET psql (11.4, server 13.0) WARNING: psql major version 11, server major version 13. Some psql features might not work. Type "help" for help. sisis=# try the -q switch to psql: $ psql -q That should do. Yes, I know this flag. But this removes also the lines psql (11.4, server 13.0) Type "help" for help. I only want remove the WARNING lines. matthias Matthias, just install the psql binary of the 13.0 release in a separate path, and use it when connecting to the 13.0 server.
Re: Table sizes
W dniu 2020-09-30 o 14:11, luis.robe...@siscobra.com.br pisze: Hi! I'm trying to use this query to get table sizes, however I'm getting a strange error: select tablename,pg_relation_size(tablename::text) from pg_tables; In PG 13: SQL Error [42P01]: ERROR: relation "sql_implementation_info" does not exist In PG 12: SQL Error [42P01]: ERROR: relation "sql_parts" does not exist You need to use full tablenames, using schemaname of pg_tables too.
Re: using psql 11.4 with a server 13.0 && meta commands
W dniu 2020-10-21 o 13:54, Matthias Apitz pisze: Hello, I've found the following problem using psql 11.4 against a server 13.0: you may install a separate 13.0 psql binary and use that one against the 13.0 server
Re: Featured Big Name Users of Postgres
W dniu 2019-06-11 o 19:45, Igal Sapir pisze: I'm doing a presentation about Postgres to SQL Server users this weekend, and I want to showcase some of the big names that use Postgres, e.g. MasterCard, Government agencies, Banks, etc. You might be interested in this: https://www.theguardian.com/info/2018/nov/30/bye-bye-mongo-hello-postgres
