🚀 go-pugleaf

>... Czy jest możliwe, aby tabela założona w bazie była
> widoczna po jakimś opóźnieniu?
Jest możliwe. Nie raz, pszyczyn może być wiele.
Np pracujesz na bazie debagera, ona nie gmera się bazie oryginalnej,
robią się odpowiedznie kopie, to trawa, do tego zmiany dzisiejsze mogą 
zniknąć do jutra itp.
Inne pszypadki , te najbardziej oczywiste, wynikają z sieciowości.
Inne pszyczyny też mogą być, zależy od producenta sytuacji itp.



>.
>zakładamy tabelę poleceniem create, potem próbujemy dodać do niej
>rekord poleceniem insert i otrzymujemy komunikat z błędem, że
>tabela nie istnieje.
Może być jak wyżej, a może po prostu tabela się nie założyła, a ty jakąś 
instrukcją zignorowałeś komunikat, albo wogule nie stprawdziłeś wyniku, czy 
się założyła?


>Ku ścisłości, zarówno create jak i insert
>były w plikach tekstowych, problemy pojawiały się przy imporcie
>danych i struktury bazy z plików tekstowych.
Import kojaży mi się nierozłąznie z uprawnieniami.


-- 
_____http://ortografia.ma7.eu_____zmiana adresu strony
w zakładce 'inne', nowa wersja syntezatora mowy GdakMini2_99 ,
z nowym głosem
(tekst bez: ó, ch, rz i -ii) Ortografia to NAWYK, często nielogiczny,
ktury ludzie ociężali umysłowo, nażucają bezmyślnie następnym pokoleniom.

On Friday, November 27, 2015 at 3:03:18 PM UTC+1, Stokrotka wrote:
> >... Czy jest możliwe, aby tabela założona w bazie była
> > widoczna po jakimś opóźnieniu?
> Jest możliwe. Nie raz, pszyczyn może być wiele.
Hmmmm.

Może dopowiem jeszcze. Jest jakaś baza, kilkadziesiąt tabel, kilkanaście GB
danych. Jest skrypt który zrzuca do dwóch plików: strukturę i dane. Jest
skrypt który importuje najpierw z jednego pliku strukturę potem z drugiego
dane. Operację powtarzam często na tym samym komputerze i systemie. Nagle
robię to samo, ale inserty nie zadziałały. Wyświetla błąd, że nie ma tabeli.
Próbuję ręcznie się zalogować i wydać komendy importu. Znowu błąd że nie
ma tabel. Wylogowuję się, czekam chwilę, loguję się ponownie. Znowu ten
sam błąd. Robię listę tabel - wszystkie tabele są na listingu. Wytężam 
pamięć, czy czegoś nie zmieniałem od ostatniego razu - nic. Ponawiam jeszcze
kilka razy, znowu nie działa, aż w końcu działa normalnie. Na drugi dzień
aż myślę sobie: to chyba zmęczenie. Powtarzam operację i znowu to samo. 
Przez krótki czas (może kilka minut) nie działają inserty, bo nie ma
tabel. Po kilku wylogowaniach, zalogowaniach, po listingu tabel, w końcu
zadziałało. Czy to może się czasami zdarzać? Jeśli tak, to dlaczego nigdy
wcześniej nie miałem takich przypadków?

Pozdrawiam

W dniu 27.11.2015 o 14:31, M.M. pisze:
> Witam
>
> Mam pytanie. Czy jest możliwe, aby tabela założona w bazie była
> widoczna po jakimś opóźnieniu? Mam na myśli taką sytuację, że
> zakładamy tabelę poleceniem create, potem próbujemy dodać do niej
> rekord poleceniem insert i otrzymujemy komunikat z błędem, że
> tabela nie istnieje. Ku ścisłości, zarówno create jak i insert
> były w plikach tekstowych, problemy pojawiały się przy imporcie
> danych i struktury bazy z plików tekstowych. Zabiegi tego typu
> przeprowadzałem setki razy, nigdy wcześniej nie miałem takich
> problemów. Nagle dwa razy tego samego dnia inserty mogłem dodawać
> do bazy dopiero po czasie około 5 minut. W czasie tych 5 minut
> szukałem błędów na różne sposoby i błędów nie były. Kilka razy
> ponawiałem inserty i nadal był błąd. W końcu nagle zadziałało
> bez żadnych poprawek. Czy spotkaliście się kiedyś z takim
> problemem? Jeśli tak, to co może być prawdopodobną przyczyną?
>
> Pozdrawiam
>
Spróbuj odpytać systemowy widok pg_stat_activity. W ten sposób 
stwierdzisz co dzieje się z wykonywanymi zapytaniami, może po prostu 
sprawdzić co się dzieje, dlaczego coś jest blokowane.
Zajrzyj tutaj:
https://wiki.postgresql.org/wiki/Lock_Monitoring


Pozdrawiam
Rony

On Friday, November 27, 2015 at 7:40:04 PM UTC+1, Ronald Kuczek wrote:
> [...]

Dzięki za sugestię. Nie pomyślałbym że komunikat 'tabela nie istnieje' może
być na skute jakiejś blokady.

Pozdrawiam

W dniu 27.11.2015 o 20:32, M.M. pisze:
> On Friday, November 27, 2015 at 7:40:04 PM UTC+1, Ronald Kuczek wrote:
>> [...]
>
> Dzięki za sugestię. Nie pomyślałbym że komunikat 'tabela nie istnieje' może
> być na skute jakiejś blokady.
>
> Pozdrawiam
>
To pierwsze, co mi przyszło do głowy. Jak rozumiem w skryptach 
wykonujesz drop table/create table i być może z JAKIEGOŚ dobrego powodu 
albo te zapytania na *coś* czekają albo Postgresql robi *coś* 
niezwykłego o czym nie wiem. Tom Lane pisał kiedyś, że długi czas 
tworzenia tabel może być związany z możliwym lockiem na auth_user 
zakładanym przez aktywne transakcje. Nigdy aż tak bardzo nie zagłębiałem 
się w systemowe procesy Postgresa ale chyba warto ten trop sprawdzić.

Pozdrawiam
Rony

On Friday, November 27, 2015 at 9:31:07 PM UTC+1, Ronald Kuczek wrote:
> W dniu 27.11.2015 o 20:32, M.M. pisze:
> > On Friday, November 27, 2015 at 7:40:04 PM UTC+1, Ronald Kuczek wrote:
> >> [...]
> >
> > Dzięki za sugestię. Nie pomyślałbym że komunikat 'tabela nie istnieje' może
> > być na skute jakiejś blokady.
> >
> > Pozdrawiam
> >
> To pierwsze, co mi przyszło do głowy. Jak rozumiem w skryptach 
> wykonujesz drop table/create table i być może z JAKIEGOŚ dobrego powodu 
> albo te zapytania na *coś* czekają albo Postgresql robi *coś* 
> niezwykłego o czym nie wiem. Tom Lane pisał kiedyś, że długi czas 
> tworzenia tabel może być związany z możliwym lockiem na auth_user 
> zakładanym przez aktywne transakcje. Nigdy aż tak bardzo nie zagłębiałem 
> się w systemowe procesy Postgresa ale chyba warto ten trop sprawdzić.

Tak, warto wziąć to pod uwagę. Dziękuję.

>..Jest jakaś baza, kilkadziesiąt tabel, kilkanaście GB
>danych. Jest skrypt który zrzuca do dwóch plików: strukturę i dane.
Typowe.

>Jest
>skrypt który importuje najpierw z jednego pliku strukturę potem z drugiego
>dane. Operację powtarzam często na tym samym komputerze i systemie. Nagle
>robię to samo, ale inserty nie zadziałały. Wyświetla błąd, że nie ma 
>tabeli.
>Próbuję ręcznie się zalogować i wydać komendy importu. Znowu błąd że nie
>ma tabel. Wylogowuję się, czekam chwilę, loguję się ponownie. Znowu ten
>sam błąd. Robię listę tabel - wszystkie tabele są na listingu. Wytężam
>pamięć, czy czegoś nie zmieniałem od ostatniego razu - nic. Ponawiam 
>jeszcze
>kilka razy, znowu nie działa, aż w końcu działa normalnie. Na drugi dzień
>aż myślę sobie: to chyba zmęczenie. Powtarzam operację i znowu to samo.
>Przez krótki czas (może kilka minut) nie działają inserty, bo nie ma
>tabel. Po kilku wylogowaniach, zalogowaniach, po listingu tabel, w końcu
>zadziałało. Czy to może się czasami zdarzać? Jeśli tak, to dlaczego nigdy
>wcześniej nie miałem takich przypadków?

Nie możesz pszed insertami sprawdzać, czy tabele już są?
Często jest taka możliwość, albo bezpośrednio zakłądanie tabel daje wynik 
zwrotny czy się udało, albo osbną instrukcją sprawdzasz czy istnieje.

-- 
_____http://ortografia.ma7.eu_____zmiana adresu strony
w zakładce 'inne', nowa wersja syntezatora mowy GdakMini2_99 ,
z nowym głosem
(tekst bez: ó, ch, rz i -ii) Ortografia to NAWYK, często nielogiczny,
ktury ludzie ociężali umysłowo, nażucają bezmyślnie następnym pokoleniom.


Pozdrawiam 

On Saturday, November 28, 2015 at 4:29:14 PM UTC+1, Stokrotka wrote:
> Nie możesz pszed insertami sprawdzać, czy tabele już są?
> Często jest taka możliwość, albo bezpośrednio zakłądanie tabel daje wynik 
> zwrotny czy się udało, albo osbną instrukcją sprawdzasz czy istnieje.

Sprawdzałem. Zrobiłem listing tabel. Na pewno była tabela której dotyczył
insert. Czy były dokładnie wszystkie tabele, to przyznaję, że nie
sprawdziłem.

Pozdrawiam

On Sat, 28 Nov 2015 07:59:14 -0800 (PST), M.M. wrote:

> Sprawdzałem. Zrobiłem listing tabel. Na pewno była tabela której dotyczył
> insert. Czy były dokładnie wszystkie tabele, to przyznaję, że nie
> sprawdziłem.

A czy po tych operacjach DDL wykonujesz jawnie commita?


-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On Saturday, November 28, 2015 at 5:06:30 PM UTC+1, szemrany wrote:
> On Sat, 28 Nov 2015 07:59:14 -0800 (PST), M.M. wrote:
> 
> > Sprawdzałem. Zrobiłem listing tabel. Na pewno była tabela której dotyczył
> > insert. Czy były dokładnie wszystkie tabele, to przyznaję, że nie
> > sprawdziłem.
> 
> A czy po tych operacjach DDL wykonujesz jawnie commita?

Używam plików wygenerowanych automatycznie, musiałem sprawdzić grepem czy
nie ma commit w ten sposób:

cat struktura_bazy.sql | grep -i 'commit'
cat struktura_bazy.sql | grep -i 'begin'
cat struktura_bazy.sql | grep -i 'lock'

No i nie ma.

Ciekawe jest to, że wiele razy wszystko działało idealnie. Nagle, bez
żadnych zmian... też działa, ale trzeba zrobić przerwę pomiędzy
create table a insert.

Pozdrawiam

On Sat, 28 Nov 2015 09:22:46 -0800 (PST), M.M. wrote:

> Ciekawe jest to, że wiele razy wszystko działało idealnie. Nagle, bez
> żadnych zmian... też działa, ale trzeba zrobić przerwę pomiędzy
> create table a insert.

Możliwy scenariusz jaki sobie wyobrażam, choć oczywiście bazuję tylko na
fantazji, bo nie wiem jak wewnętrznie działa psql, jest taki, że
przetwarzanie skryptu z pliku tekstowego działa wielowątkowo, np. DDL na
jednym a DML na inny wątku. I każdy z tych wątków ma własne connection,
które gdy nie jest jawnie zacommitowane to "wisi do timeoutu/leży w puli" i
dopiero po czasie się commituje (timeout/ponownie wykorzystanie puli).
Tak mi tylko przyszło do głowy, skoro już trzeba szukać prawdy w entropii
;-)

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On Saturday, November 28, 2015 at 7:52:06 PM UTC+1, szemrany wrote:
> On Sat, 28 Nov 2015 09:22:46 -0800 (PST), M.M. wrote:
> 
> > Ciekawe jest to, że wiele razy wszystko działało idealnie. Nagle, bez
> > żadnych zmian... też działa, ale trzeba zrobić przerwę pomiędzy
> > create table a insert.
> 
> Możliwy scenariusz jaki sobie wyobrażam, choć oczywiście bazuję tylko na
> fantazji, bo nie wiem jak wewnętrznie działa psql, jest taki, że
> przetwarzanie skryptu z pliku tekstowego działa wielowątkowo, np. DDL na
> jednym a DML na inny wątku. I każdy z tych wątków ma własne connection,
> które gdy nie jest jawnie zacommitowane to "wisi do timeoutu/leży w puli" i
> dopiero po czasie się commituje (timeout/ponownie wykorzystanie puli).
> Tak mi tylko przyszło do głowy, skoro już trzeba szukać prawdy w entropii
> ;-)

Przez chwilę też tak pomyślałem. To by oznaczało, że klient sam 
sparsował zapytanie, zamiast zlecić to serwerowi bazy danych. Teoretycznie
może klient sam parsować i optymalizować połączenia z bazą, ale to
by się kończyło często takimi błędami.

Pozdrawiam

On Sat, 28 Nov 2015 13:10:18 -0800 (PST), M.M. wrote:

>> Możliwy scenariusz jaki sobie wyobrażam, choć oczywiście bazuję tylko na
>> fantazji, bo nie wiem jak wewnętrznie działa psql, jest taki, że
>> przetwarzanie skryptu z pliku tekstowego działa wielowątkowo, np. DDL na
>> jednym a DML na inny wątku. I każdy z tych wątków ma własne connection,
>> które gdy nie jest jawnie zacommitowane to "wisi do timeoutu/leży w puli" i
>> dopiero po czasie się commituje (timeout/ponownie wykorzystanie puli).
>> Tak mi tylko przyszło do głowy, skoro już trzeba szukać prawdy w entropii
>> ;-)
> 
> Przez chwilę też tak pomyślałem. To by oznaczało, że klient sam 
> sparsował zapytanie, zamiast zlecić to serwerowi bazy danych. Teoretycznie
> może klient sam parsować i optymalizować połączenia z bazą, ale to
> by się kończyło często takimi błędami.

Często* przy założeniu, że skrypt nie trzyma się zasad, np. jawnie nie
commituje zmian w strukturze bazy. Gdyby zaś skrypt miał te commity to nie
ma prawa się to zdarzać. Z tym, że to teoria. Ale ...łatwa do sprawdzenia
empirycznego :-)

* - to z kolei zależy od reszty zmiennych czyli stopnia obciążenia serwera,
wolnych zasobów, struktury skryptu, innych tego typu detali

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On Sunday, November 29, 2015 at 11:28:18 AM UTC+1, szemrany wrote:
> On Sat, 28 Nov 2015 13:10:18 -0800 (PST), M.M. wrote:
> 
> >> Możliwy scenariusz jaki sobie wyobrażam, choć oczywiście bazuję tylko na
> >> fantazji, bo nie wiem jak wewnętrznie działa psql, jest taki, że
> >> przetwarzanie skryptu z pliku tekstowego działa wielowątkowo, np. DDL na
> >> jednym a DML na inny wątku. I każdy z tych wątków ma własne connection,
> >> które gdy nie jest jawnie zacommitowane to "wisi do timeoutu/leży w puli" i
> >> dopiero po czasie się commituje (timeout/ponownie wykorzystanie puli).
> >> Tak mi tylko przyszło do głowy, skoro już trzeba szukać prawdy w entropii
> >> ;-)
> > 
> > Przez chwilę też tak pomyślałem. To by oznaczało, że klient sam 
> > sparsował zapytanie, zamiast zlecić to serwerowi bazy danych. Teoretycznie
> > może klient sam parsować i optymalizować połączenia z bazą, ale to
> > by się kończyło często takimi błędami.
> 
> Często* przy założeniu, że skrypt nie trzyma się zasad, np. jawnie nie
> commituje zmian w strukturze bazy. Gdyby zaś skrypt miał te commity to nie
> ma prawa się to zdarzać. Z tym, że to teoria. Ale ...łatwa do sprawdzenia
> empirycznego :-)
> 
> * - to z kolei zależy od reszty zmiennych czyli stopnia obciążenia serwera,
> wolnych zasobów, struktury skryptu, innych tego typu detali

Wszystko o czym piszesz miałoby sens gdyby:
1) do bazy był podłączony tylko jeden klient,
2) klient byłby na innym kompie niż baza.
W takich warunkach klient mógłby pewne obliczenia zoptymalizować i
zaoszczędzić na transferach. 

Druga sprawa: gdy nie ma jawnie użytych transakcji, to silnik bazy 
obejmuje każde zapytanie w transakcję. 

Pozdrawiam

>Wszystko o czym piszesz miałoby sens gdyby:
>1) do bazy był podłączony tylko jeden klient,
>2) klient byłby na innym kompie niż baza.

Według mnie to nie ma znaczenia, bo nie jest w twoim pszypadku ważne, czy w 
danej hwili było do bazy podłączonyh 1, 2 czy 3 uzytkownikuw,
tylko jest ważne jak jesteś traktowany: jako jedyny użytkownik, czy jako 
jeden z wielu = 1 uzytkownikuw.

-- 
_____http://ortografia.ma7.eu_____zmiana adresu strony
w zakładce 'inne', nowa wersja syntezatora mowy GdakMini2_99 ,
z nowym głosem
(tekst bez: ó, ch, rz i -ii) Ortografia to NAWYK, często nielogiczny,
ktury ludzie ociężali umysłowo, nażucają bezmyślnie następnym pokoleniom.

On Mon, 30 Nov 2015 08:10:13 -0800 (PST), M.M. wrote:

>> Często* przy założeniu, że skrypt nie trzyma się zasad, np. jawnie nie
>> commituje zmian w strukturze bazy. Gdyby zaś skrypt miał te commity to nie
>> ma prawa się to zdarzać. Z tym, że to teoria. Ale ...łatwa do sprawdzenia
>> empirycznego :-)
>> 
>> * - to z kolei zależy od reszty zmiennych czyli stopnia obciążenia serwera,
>> wolnych zasobów, struktury skryptu, innych tego typu detali
> 
> Wszystko o czym piszesz miałoby sens gdyby:
> 1) do bazy był podłączony tylko jeden klient,
> 2) klient byłby na innym kompie niż baza.
> W takich warunkach klient mógłby pewne obliczenia zoptymalizować i
> zaoszczędzić na transferach. 

Skąd te wnioski? Nie widzę związku. To czy klient jest na tym samym czy
innym kompie nie ma znaczenia, bo i tak połączenie jest po tcp/ip. To czy
jest jeden czy pięciu też bez znaczenia, bo do tego są transakcje by ich
separować. O co zatem chodzi?
 
> Druga sprawa: gdy nie ma jawnie użytych transakcji, to silnik bazy 
> obejmuje każde zapytanie w transakcję. 

To oczywiste, czy twierdziłem inaczej?

-- 
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

On Tuesday, December 1, 2015 at 11:40:49 AM UTC+1, szemrany wrote:
> On Mon, 30 Nov 2015 08:10:13 -0800 (PST), M.M. wrote:
> 
> >> Często* przy założeniu, że skrypt nie trzyma się zasad, np. jawnie nie
> >> commituje zmian w strukturze bazy. Gdyby zaś skrypt miał te commity to nie
> >> ma prawa się to zdarzać. Z tym, że to teoria. Ale ...łatwa do sprawdzenia
> >> empirycznego :-)
> >> 
> >> * - to z kolei zależy od reszty zmiennych czyli stopnia obciążenia serwera,
> >> wolnych zasobów, struktury skryptu, innych tego typu detali
> > 
> > Wszystko o czym piszesz miałoby sens gdyby:
> > 1) do bazy był podłączony tylko jeden klient,
> > 2) klient byłby na innym kompie niż baza.
> > W takich warunkach klient mógłby pewne obliczenia zoptymalizować i
> > zaoszczędzić na transferach. 
> 
> Skąd te wnioski? Nie widzę związku. To czy klient jest na tym samym czy
> innym kompie nie ma znaczenia, bo i tak połączenie jest po tcp/ip. To czy
> jest jeden czy pięciu też bez znaczenia, bo do tego są transakcje by ich
> separować. O co zatem chodzi?
Chodzi o wolne łącze internetowe do zdalnego komputera.


> > Druga sprawa: gdy nie ma jawnie użytych transakcji, to silnik bazy 
> > obejmuje każde zapytanie w transakcję. 
> 
> To oczywiste, czy twierdziłem inaczej?
Jeśli źle zrozumiałem, to przepraszam.


Pozdrawiam