Re: Recomended front ends?

[Paolo Saudin]

For web/mobile applications we use Mojolicious, https://mojolicious.org witch
work pretty well with Postgresql, is written in Perl and has plenty of nice
features.
Paolo Saudin

Il giorno gio 8 ago 2019 alle ore 22:09 DiasCosta 
ha scritto:

> Hi,
> After many years of using Oracle Forms and Oracle Reports with Oracle DB,
> I have been using Lazarus and "Code Typhon"
> for many years now.
> Both work with Free Pascal Compiler and both are open source and free.
> Both have a very good IDE, the code produced is Pascal (very easily
> readable), and they connect directly to many DBMS including PostgreSQL,
> Oracle,  MSSQL, SQLITE, etc..
>
> You can find information here:
> https://en.wikipedia.org/wiki/Lazarus_(IDE)
> and here:  https://www.pilotlogic.com/sitejoom/
>
> Also here:   https://en.wikipedia.org/wiki/Lazarus_(IDE)
> you can find some interesting information.
>
> Also here:   https://www.getlazarus.org/learn/tutorials/intro/
> "If you are haven't used Lazarus <http://www.lazarus-ide.org> recently
> then this tutorial is for you. In it we give users a broad overview of
> Lazarus
> and some of its key features. We look at the type of applications you can
> create with Lazarus, and show you the core
> concepts to desktop application development it makes so very easy.
> Highlights include the two way design process, events handlers, testing
> and debugging, and deployment.
> A brief gallery of applications
> <https://www.getlazarus.org/community/showcase> I've personally created
> with Lazarus is included at the end, and I honestly believe it's
> the best tool in the world for developing platform agnostic desktop
> applications. Like the video says, give Lazarus a try
> <https://www.getlazarus.org/setup>."
>
>
> Dias Costa
>
>
>
>
>
>
>
>
>
> On 08-08-2019 20:26, Basques, Bob (CI-StPaul) wrote:
>
> All,
>
> No Web driven, but . . . . we’ve had some success with using 
> LibreOffice(calc) as a frontend.  Fairly easy to build forms, etc.  Only 
> limited experience so far, but was able to build domain lists from SQL calls, 
> for form pulldown lists, etc.
>
> bobb
>
>
>
> On Aug 8, 2019, at 2:10 PM, Rich Shepard  
>  wrote:
>
> Think Before You Click: This email originated outside our organization.
>
>
> On Thu, 8 Aug 2019, Tim Clarke wrote:
>
>
> We tried Django without any pleasant results.
>
> Tim,
>
> That's unexpected and too bad.
>
>
> I'd also caution using MS Access, we're desperate to get away from it.
> Sharing code has challenges and it is horribly aggressive with caching
> unless you use un-bound forms and write all the CRUD interface code
> yourself.
>
> Slightly off-topic, but I've not seen anything good about Access. My
> understanding is it's a flat-file database intended as a user front end to
> Microsoft's relational database product. My experiences with those who use
> it have been painful.
>
> Just yesterday I downloaded a very large database of fisheries data from a
> federal agency and have started translating it to postgres using the
> mdbtools. There's no schema provided, only 32 pages of table columns and
> types without descriptions of the column names. No primary keys, no foreign
> keys, and only 66 tables were found in the .mdb file while all table names
> starting with s through z were not available. There are also many tables
> that hold redundant data which should not exist as the contents are easily
> generated by SQL queries. It will take me a while to make it a working
> relational database.
>
> Rich
>
>
>
>
>
>
> --
> J. M. Dias Costa
> Telef. 214026948 Telem. 939307421
>
> Se divulgar esta mensagem por terceiros, por favor:
> 1. Apague o meu endereço de correio electrónico e o meu nome.
> 2. Apague também os endereços dos seus amigos antes de distribuir.
> 3. Enderece como cópia oculta (Cc ou Bcc) para os SEUS destinatários.
> Agindo deste modo, dificultará a disseminação de "vírus", "spams" e
> "banners" e contribuirá para manter a privacidade de todos e cada um.
> Obrigado.
>
> Nota: Não se deverá ao acaso a ocorrência de palavras na minha escrita que 
> não respeitem o
> malfadado acordo ortográfico.
>
>

Replication sequence

[Paolo Saudin]

Hi all,
I have two servers, a primary and a secondary one with a streaming replica
setup.
Today I noticed that some sequences are not lined-up, the replica ones are
well ahead, while the records number is the same. How is it possible?

Thanks,
Paolo

--
-- primary server
--
postgres@db-srv1:~$ psql
psql (9.5.19)
cf-db-srv1:5432 postgres@rete_llpp=# SELECT last_value FROM
bobo.menu_pages_mp_id_seq;
┌┐
│ last_value │
├┤
│ 74 │
└┘
  cf-db-srv1:5432 postgres@rete_llpp=# select count(*) from bobo.menu_pages;
┌───┐
│ count │
├───┤
│74 │
└───┘

--
-- replica server
--
postgres@db-srv2:~$ psql
psql (9.5.24)
cf-db-srv2:5433 postgres@rete_llpp=# SELECT last_value FROM
bobo.menu_pages_mp_id_seq;
┌┐
│ last_value │
├┤
│105 │
└┘
cf-db-srv2:5433 postgres@rete_llpp=# select count(*) from bobo.menu_pages;
┌───┐
│ count │
├───┤
│74 │
└───┘

Re: Replication sequence

[Paolo Saudin]

Il giorno lun 15 feb 2021 alle ore 20:40 Loles  ha
scritto:

> One thing is the number of records in the table and another is the current
> value of the sequence.
>
> Execute:
>
> select max (field) from bobo.menu_pages;
>
> In both master and slave server.
>
> What give you back?
>
> "field" is the data that belongs to the sequence.
>
>
>
> El lun., 15 feb. 2021 18:55, Paolo Saudin 
> escribió:
>
>> Hi all,
>> I have two servers, a primary and a secondary one with a streaming
>> replica setup.
>> Today I noticed that some sequences are not lined-up, the replica ones
>> are well ahead, while the records number is the same. How is it possible?
>>
>> Thanks,
>> Paolo
>>
>> --
>> -- primary server
>> --
>> postgres@db-srv1:~$ psql
>> psql (9.5.19)
>> cf-db-srv1:5432 postgres@rete_llpp=# SELECT last_value FROM
>> bobo.menu_pages_mp_id_seq;
>> ┌┐
>> │ last_value │
>> ├┤
>> │ 74 │
>> └┘
>>   cf-db-srv1:5432 postgres@rete_llpp=# select count(*) from
>> bobo.menu_pages;
>> ┌───┐
>> │ count │
>> ├───┤
>> │74 │
>> └───┘
>>
>> --
>> -- replica server
>> --
>> postgres@db-srv2:~$ psql
>> psql (9.5.24)
>> cf-db-srv2:5433 postgres@rete_llpp=# SELECT last_value FROM
>> bobo.menu_pages_mp_id_seq;
>> ┌┐
>> │ last_value │
>> ├┤
>> │105 │
>> └┘
>> cf-db-srv2:5433 postgres@rete_llpp=# select count(*) from
>> bobo.menu_pages;
>> ┌───┐
>> │ count │
>> ├───┤
>> │74 │
>> └───┘
>>
>>
Hi, I checked and the number of records are identical,

cf-db-srv1:5432 postgres@rete_llpp=# select max(mp_id) from bobo.menu_pages;
┌─┐
│ max │
├─┤
│  74 │
└─┘

cf-db-srv2:5433 postgres@rete_llpp=# select max(mp_id) from bobo.menu_pages;
┌─┐
│ max │
├─┤
│  74 │
└─┘
Thank you,
Paolo

Re: Replication sequence

[Paolo Saudin]

Il giorno mar 16 feb 2021 alle ore 10:51 Jehan-Guillaume de Rorthais <
j...@dalibo.com> ha scritto:

> On Mon, 15 Feb 2021 18:55:14 +0100
> Paolo Saudin  wrote:
>
> > Hi all,
> > I have two servers, a primary and a secondary one with a streaming
> replica
> > setup.
> > Today I noticed that some sequences are not lined-up, the replica ones
> are
> > well ahead, while the records number is the same. How is it possible?
>
> This is because sequences are not WAL logged on every nextval() call, but
> by
> batch of sequence cache+32 values. As standbys are fed with WAL stream from
> primary, their sequences appears jump, then stall, then jump, etc.
>
> See:
>
> https://git.postgresql.org/cgit/postgresql.git/tree/src/backend/commands/sequence.c?id=f672df5fdd22dac14c98d0a0bf5bbaa6ab17f8a5#n52
>
>
> https://git.postgresql.org/cgit/postgresql.git/tree/src/backend/commands/sequence.c?id=f672df5fdd22dac14c98d0a0bf5bbaa6ab17f8a5#n661
>
> I'm not sure if this is documented somewhere... ?
>

Thank you very much!
So in case the primary server crashes, and the backup one gets live, it
will eventually have different sequences. I suppose there is no way to
avoid this, isnt'it?
Paolo

Re: Replication sequence

[Paolo Saudin]

Thank you!

Il giorno mar 16 feb 2021 alle ore 13:38 Jehan-Guillaume de Rorthais <
j...@dalibo.com> ha scritto:

> On Tue, 16 Feb 2021 13:10:54 +0100
> Paolo Saudin  wrote:
>
> > Il giorno mar 16 feb 2021 alle ore 10:51 Jehan-Guillaume de Rorthais <
> >  [...]
> >
> >  [...]
> >  [...]
> >  [...]
> >  [...]
> >  [...]
> >  [...]
> >  [...]
> >
> > Thank you very much!
> > So in case the primary server crashes, and the backup one gets live, it
> > will eventually have different sequences.
>
> No. You will just have a gap in the sequence, on both side.
>
> And if you decided to promote your standby to production, you'll have to
> resync
> the old primary anyway.
>
> > I suppose there is no way to
> > avoid this, isnt'it?
>
> You can't avoid gap.
>
>
>

Re: Import csv to temp table

[Paolo Saudin]

Il giorno mar 2 gen 2024 alle ore 21:17 Adrian Klaver <
adrian.kla...@aklaver.com> ha scritto:

> On 1/2/24 11:47, arun chirappurath wrote:
>
> Reply to list
> Ccing list
> > Hi Adrian,
> >
> > Love this tool..however it doesn't like supporting RDS.
>
> 1) This was Daniel Vérité's suggestion not mine.
>
> 2) Define "... doesn't like supporting RDS".
>
> a) You can generate an SQL statement without connecting to the database.
> Then use that statement directly in the database.
>
> b) If SQLAlchemy can reach the database then csvkit should be able to.
>
> >
> > https://csvkit.readthedocs.io/en/latest/
> > 
> >
> > Regards
> > Arun
> >
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
>
>
You can user pgloader (https://pgloader.io/) as well to load data from CSV
to Postgres
Paolo