ਡੇਟਾਬੇਸ ਜਗਾਉਣਾ, ਮਰੇ ਹੋਏ ਕਨੈਕਸ਼ਨਾਂ ਤੋਂ ਬਿਨਾਂ

Mythex ’ਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਐਪਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਡੇਟਾਬੇਸ ਕੋਈ ਵਰਤੋਂ ਨਾ ਹੋਣ ’ਤੇ ਸੌਂ ਜਾਂਦੇ ਹਨ। ਜਦੋਂ ਐਪ ਜਾਗਦੀ ਸੀ, ਤਾਂ ਉਹ ਆਪਣੀ ਪਹਿਲੀ ਬੇਨਤੀ 10–12 ਸਕਿੰਟ ਰੋਕ ਕੇ ਰੱਖਦੀ ਸੀ, ਕਿਉਂਕਿ ਉਹ ਉਹਨਾਂ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਮੁੜ ਵਰਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਸੀ ਜੋ ਸਭ ਕੁਝ ਸੌਂਦੇ ਸਮੇਂ ਮਰ ਚੁੱਕੇ ਸਨ। ਹੁਣ ਅਸੀਂ Spring Boot ਐਪਾਂ ਨੂੰ ਡੇਟਾਬੇਸ ਸੈਟਿੰਗਾਂ ਦਿੰਦੇ ਹਾਂ ਜੋ ਸੌਣ ਤੋਂ ਬਾਅਦ ਵੀ ਸੁਰੱਖਿਅਤ ਹਨ, ਅਤੇ ਏਜੰਟ ਨੂੰ ਕਹਿੰਦੇ ਹਾਂ ਕਿ ਹਰ ਸਟੈਕ ਦੀਆਂ ਐਪਾਂ ਇਸੇ ਤਰ੍ਹਾਂ ਬਣਾਏ। ਹੋਸਟਿੰਗ ਪਲੇਟਫਾਰਮ ’ਤੇ, ਜਾਗਣ ਤੋਂ ਬਾਅਦ ਪਹਿਲੀ ਬੇਨਤੀ 12.7 ਸਕਿੰਟਾਂ ਤੋਂ 2.3 ਸਕਿੰਟ ਹੋ ਗਈ।

ਐਪਾਂ ਅਤੇ ਡੇਟਾਬੇਸ ਕਿਉਂ ਸੌਂਦੇ ਹਨ

ਇੱਕ ਪ੍ਰਕਾਸ਼ਿਤ Mythex ਐਪ ਇੱਕ ਐਸੀ ਮਸ਼ੀਨ ’ਤੇ ਚੱਲਦੀ ਹੈ ਜੋ ਕੁਝ ਮਿੰਟਾਂ ਦੀ ਵਿਹਲ ਬਾਅਦ ਮੁਅੱਤਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਉਸਦਾ ਡੇਟਾਬੇਸ ਸਰਵਰਲੈੱਸ Postgres ਹੈ ਜੋ ਪੰਜ ਮਿੰਟ ਦੀ ਵਿਹਲ ਬਾਅਦ ਸੌਂਦਾ ਹੈ ਅਤੇ ਅਗਲੀ ਬੇਨਤੀ ’ਤੇ ਜਾਗਦਾ ਹੈ। ਇਸੇ ਕਾਰਨ ਸ਼ਾਂਤ ਐਪ ਸਸਤੀ ਰਹਿੰਦੀ ਹੈ: ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਦੀ ਅਸਲ ਵਰਤੋਂ ਦਾ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ, ਅਤੇ ਸੌਂਦੀ ਐਪ ਕੰਪਿਊਟ ’ਤੇ ਕੁਝ ਖਰਚ ਨਹੀਂ ਕਰਦੀ। ਬਿਲਿੰਗ ਵਾਲੇ ਪਾਸੇ ਬਾਰੇ ਅਸੀਂ ਡੇਟਾਬੇਸ ਦੀ ਬਿਲਿੰਗ ਉਹਨਾਂ ਦੀ ਅਸਲ ਵਰਤੋਂ ਨਾਲ ਵਿੱਚ ਲਿਖਿਆ ਸੀ।

ਪਰ ਦੋਵੇਂ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਸੌਂਦੇ ਹਨ, ਅਤੇ ਉਹ ਕਨੈਕਸ਼ਨ ਕੀ ਹੈ ਇਸ ਬਾਰੇ ਸਹਿਮਤ ਨਹੀਂ ਹੁੰਦੇ।

ਲੱਛਣ: ਪਹਿਲੀ ਫੇਰੀ ਹੌਲੀ

ਜ਼ਿਆਦਾਤਰ ਸਰਵਰ ਐਪਾਂ ਕਨੈਕਸ਼ਨ ਪੂਲ ਰੱਖਦੀਆਂ ਹਨ: ਕੁਝ ਖੁੱਲ੍ਹੇ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ ਤਿਆਰ ਰੱਖੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਜੋ ਹਰ ਬੇਨਤੀ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਣ ਦੀ ਲਾਗਤ ਨਾ ਦੇਵੇ। ਹਮੇਸ਼ਾ ਚਾਲੂ ਐਪ ਲਈ ਇਹ ਸਹੀ ਡਿਜ਼ਾਈਨ ਹੈ।

ਨੀਂਦ ਨਾਲ ਇਹ ਹੁੰਦਾ ਹੈ:

1. ਐਪ ਚੱਲ ਰਹੀ ਹੈ, ਪੂਲ ਵਿੱਚ ਕੁਝ ਵਿਹਲੇ ਕਨੈਕਸ਼ਨ ਹਨ।
2. ਕੋਈ ਨਹੀਂ ਆਉਂਦਾ। ਐਪ ਦੀ ਮਸ਼ੀਨ ਮੁਅੱਤਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਜੰਮ ਕੇ, ਪੂਲ ਸਮੇਤ।
3. ਡੇਟਾਬੇਸ ਸੌਂ ਜਾਂਦਾ ਹੈ ਅਤੇ ਹਰ ਕਨੈਕਸ਼ਨ ਦਾ ਆਪਣਾ ਸਿਰਾ ਛੱਡ ਦਿੰਦਾ ਹੈ।
4. ਇੱਕ ਵਿਜ਼ਿਟਰ ਆਉਂਦਾ ਹੈ। ਐਪ ਬਿਲਕੁਲ ਉਸੇ ਹਾਲਤ ਵਿੱਚ ਜਾਗਦੀ ਹੈ, ਪਰ ਅਜੇ ਵੀ ਉਹ ਕਨੈਕਸ਼ਨ ਫੜੀ ਬੈਠੀ ਹੈ ਜੋ ਡੇਟਾਬੇਸ ਹੁਣ ਨਹੀਂ ਜਾਣਦਾ।
5. ਪੂਲ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਕਨੈਕਸ਼ਨ ਦਿੰਦਾ ਹੈ। ਉਸਨੂੰ ਪਹਿਲਾਂ ਪਤਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਉਹ ਮਰ ਚੁੱਕਾ ਹੈ, ਉਸਨੂੰ ਵਰਤ ਕੇ ਅਤੇ ਉਡੀਕ ਕਰਕੇ, ਫਿਰ ਹੀ ਛੱਡਿਆ ਜਾਂਦਾ ਹੈ।

ਇੱਕ Spring Boot ਐਪ ਵਿੱਚ, ਮਰੇ ਹੋਏ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਜਾਂਚ ਪਹਿਲੀ ਬੇਨਤੀ ਨੂੰ ਲਗਭਗ 10 ਸਕਿੰਟ ਰੋਕਦੀ ਸੀ, ਫਿਰ “Connection is not available” ਨਾਲ ਅਸਫਲ ਹੋ ਜਾਂਦੀ। ਵਿਜ਼ਿਟਰ ਲਈ ਸਾਈਟ ਬਸ ਅਟਕ ਜਾਂਦੀ ਸੀ, ਅਤੇ ਫਿਰ ਸ਼ਾਇਦ ਇੱਕ ਗਲਤੀ ਦਿਖਾਉਂਦੀ ਸੀ।

Spring ਐਪਾਂ ਸਭ ਤੋਂ ਵੱਧ ਕਿਉਂ ਪ੍ਰਭਾਵਿਤ ਸਨ

Spring Boot ਇੱਕ ਪ੍ਰਸਿੱਧ Java ਫਰੇਮਵਰਕ ਹੈ, ਅਤੇ ਇਹ ਡਿਫਾਲਟ ਤੌਰ ’ਤੇ HikariCP ਨਾਮ ਦਾ ਕਨੈਕਸ਼ਨ ਪੂਲ ਵਰਤਦਾ ਹੈ। Spring ਉਸ ਪੂਲ ਨੂੰ ਸੈਟਿੰਗਾਂ ਤੋਂ ਸੰਰਚਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਕਿੰਨੇ ਵਿਹਲੇ ਕਨੈਕਸ਼ਨ ਰੱਖਣੇ ਹਨ ਇਹ ਵੀ ਸ਼ਾਮਲ ਹੈ।

ਪਰ Mythex ਹਰ ਐਪ ਨੂੰ ਉਸਦਾ ਡੇਟਾਬੇਸ ਇੱਕ ਹੀ DATABASE_URL ਵਜੋਂ ਦਿੰਦਾ ਹੈ, ਜਿਸਦਾ ਰੂਪ postgresql://user:pass@host/db ਹੁੰਦਾ ਹੈ। Spring ਇਸ ਫਾਰਮੈਟ ਨੂੰ ਸਿੱਧਾ ਨਹੀਂ ਪੜ੍ਹ ਸਕਦਾ। ਇਸ ਲਈ Mythex ’ਤੇ ਬਣੀਆਂ Spring ਐਪਾਂ ਉਸ URL ਨੂੰ ਪਾਰਸ ਕਰਕੇ ਕੋਡ ਵਿੱਚ ਆਪਣਾ ਪੂਲ ਬਣਾ ਰਹੀਆਂ ਸਨ, ਅਤੇ ਹੱਥੀਂ ਬਣਿਆ ਪੂਲ Spring ਦੀਆਂ ਸਾਰੀਆਂ spring.datasource.* ਸੈਟਿੰਗਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ। ਭਾਵੇਂ ਕਿਸੇ ਨੂੰ ਸਹੀ ਪੂਲ ਸੈਟਿੰਗਾਂ ਪਤਾ ਹੁੰਦੀਆਂ, ਉਹ ਕਿੱਥੇ ਲਾਗੂ ਹੋਣਗੀਆਂ, ਇਸਦੀ ਕੋਈ ਥਾਂ ਹੀ ਨਹੀਂ ਸੀ।

ਫਿਕਸ ਭਾਗ 1: Spring ਵਰਤ ਸਕਣ ਵਾਲੀਆਂ ਸੈਟਿੰਗਾਂ

ਜਦੋਂ ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ ਕੋਲ ਡੇਟਾਬੇਸ ਹੁੰਦਾ ਹੈ, ਹੁਣ ਅਸੀਂ ਉਸਨੂੰ ਐਨਵਾਇਰਨਮੈਂਟ ਵੇਰੀਏਬਲ ਵੀ ਦਿੰਦੇ ਹਾਂ ਜੋ Spring ਸਿੱਧੇ ਪੜ੍ਹਦਾ ਹੈ:

• SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME ਅਤੇ SPRING_DATASOURCE_PASSWORD, DATABASE_URL ਤੋਂ ਬਦਲੇ ਹੋਏ (SSL ਲੋੜੀਂਦਾ ਹੈ ਜਦ ਤੱਕ URL ਹੋਰ ਨਾ ਕਹੇ)।
• ਪੂਲ ਸੈਟਿੰਗਾਂ ਜੋ ਨੀਂਦ ਤੋਂ ਬਚਦੀਆਂ ਹਨ:

ਕੋਈ ਵਿਹਲਾ ਕਨੈਕਸ਼ਨ ਨਾ ਰੱਖਣ ਨਾਲ, ਜਾਗੀ ਐਪ ਮਰੇ ਹੋਏ ਕਨੈਕਸ਼ਨਾਂ ਵਿੱਚੋਂ ਲੰਘਣ ਦੀ ਥਾਂ ਇੱਕ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦੀ ਹੈ।

ਇਹ ਵੇਰੀਏਬਲ ਮੌਜੂਦ ਹੋਣ ’ਤੇ Spring ਪੂਲ ਆਪ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਸੈਟਿੰਗਾਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ। ਪ੍ਰੋਜੈਕਟ ਨੇ ਜੋ ਆਪ ਸੈੱਟ ਕੀਤਾ ਹੈ, ਉਹ ਹਮੇਸ਼ਾ ਜਿੱਤਦਾ ਹੈ; ਅਸੀਂ ਸਿਰਫ਼ ਉਹ ਭਰਦੇ ਹਾਂ ਜੋ ਗਾਇਬ ਹੈ। ਗੈਰ-Spring ਐਪਾਂ ਇਹਨਾਂ ਵੇਰੀਏਬਲਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀਆਂ ਹਨ।

ਉਹ ਵੇਰਵਾ ਜਿਸਨੇ ਇਸਨੂੰ ਕੁਝ ਨਾ ਕਰਨ ਵਾਲਾ ਬਣਾਉਣਾ ਸੀ

Spring ਐਨਵਾਇਰਨਮੈਂਟ ਵੇਰੀਏਬਲਾਂ ਨੂੰ ਆਪਣੀਆਂ ਸੈਟਿੰਗਾਂ ਨਾਲ ਇੱਕ ਨਿਯਮ ਨਾਲ ਜੋੜਦਾ ਹੈ ਜਿਸਨੂੰ ਗਲਤ ਕਰਨਾ ਆਸਾਨ ਹੈ। ਸੈਟਿੰਗ minimum-idle ਨੂੰ SPRING_DATASOURCE_HIKARI_MINIMUMIDLE ਲਿਖਣਾ ਪੈਂਦਾ ਹੈ: ਡੈਸ਼ ਹਟਾਏ ਹੋਏ, ਸ਼ਬਦ ਜੁੜੇ ਹੋਏ। SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE ਲਿਖਣਾ, ਜੋ ਕੁਦਰਤੀ ਲੱਗਦਾ ਹੈ, ਇੱਕ ਵੱਖਰੀ, ਮੌਜੂਦ ਨਾ ਹੋਣ ਵਾਲੀ ਸੈਟਿੰਗ (minimum.idle) ਨਾਲ ਜੁੜਦਾ ਹੈ ਅਤੇ ਚੁੱਪ-ਚਾਪ ਅਣਡਿੱਠਾ ਹੋ ਜਾਂਦਾ ਹੈ।

ਇਹ ਅਜਿਹੀ ਗਲਤੀ ਹੈ ਜੋ ਹਰ ਸਮੀਖਿਆ ਪਾਸ ਕਰ ਜਾਂਦੀ ਹੈ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਕਰਦੀ। ਇਸ ਲਈ ਇੱਕ ਟੈਸਟ ਜਾਂਚਦਾ ਹੈ ਕਿ ਮੁੱਲ ਸੈੱਟ ਹਨ, ਅਤੇ ਕੋਈ ਵੀ ਵੇਰੀਏਬਲ ਅੰਡਰਸਕੋਰ-ਵੱਖ ਰੂਪ ਵਿੱਚ ਨਹੀਂ।

ਫਿਕਸ ਭਾਗ 2: ਹਰ ਹੋਰ ਸਟੈਕ

Spring ਇਕੱਲਾ ਫਰੇਮਵਰਕ ਨਹੀਂ ਜਿਸਦਾ ਪੂਲ ਹੈ, ਅਤੇ ਅਸੀਂ ਹਰ ਭਾਸ਼ਾ ਦੀ ਹਰ ਲਾਇਬ੍ਰੇਰੀ ਪਹਿਲਾਂ ਤੋਂ ਸੰਰਚਿਤ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਇਸ ਲਈ Mythex ਏਜੰਟ, ਜੋ ਤੁਹਾਡੀ ਐਪ ਲਿਖਦਾ ਹੈ, ਹੁਣ ਕਿਸੇ ਵੀ ਸਟੈਕ ਲਈ ਇੱਕ ਸਥਾਈ ਹਿਦਾਇਤ ਲੈਂਦਾ ਹੈ: ਪ੍ਰਕਾਸ਼ਿਤ ਐਪਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਡੇਟਾਬੇਸ ਵਿਹਲ ’ਤੇ ਸੌਂਦੇ ਹਨ, ਇਸ ਲਈ ਖੁੱਲ੍ਹਾ ਰੱਖਿਆ ਕਨੈਕਸ਼ਨ ਅਗਲੀ ਬੇਨਤੀ ’ਤੇ ਮਰਿਆ ਹੋ ਸਕਦਾ ਹੈ। ਉਸਨੂੰ ਚਾਹੀਦਾ ਹੈ:

• ਬੇਨਤੀਆਂ ਵਿਚਕਾਰ ਕੋਈ ਵਿਹਲਾ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ ਖੁੱਲ੍ਹਾ ਨਾ ਰੱਖੇ, ਜਾਂ ਹਰ ਇੱਕ ਨੂੰ ਵਰਤਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੇ,
• ਕਨੈਕਸ਼ਨ ਗਲਤੀ ’ਤੇ ਇੱਕ ਵਾਰ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰੇ, ਅਤੇ
• ਆਪਣਾ ਪੂਲ ਬਣਾਉਣ ਦੀ ਥਾਂ ਉਹ ਡੇਟਾਬੇਸ ਸੈਟਿੰਗਾਂ ਵਰਤੇ ਜੋ ਪਲੇਟਫਾਰਮ ਐਨਵਾਇਰਨਮੈਂਟ ਵਿੱਚ ਦਿੰਦਾ ਹੈ, ਨਾ ਕਿ DATABASE_URL ਪਾਰਸ ਕਰਕੇ।

ਆਖਰੀ ਗੱਲ ਭਾਗ 1 ਨਾਲ ਚੱਕਰ ਪੂਰਾ ਕਰਦੀ ਹੈ: ਜੋ ਐਪ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ ਸੈਟਿੰਗਾਂ ’ਤੇ ਬਣੀ ਹੈ, ਉਹ ਨੀਂਦ-ਸੁਰੱਖਿਅਤ ਸੰਰਚਨਾ ਆਪ ਚੁੱਕ ਲੈਂਦੀ ਹੈ।

ਨਤੀਜਾ

ਹੋਸਟਿੰਗ ਪਲੇਟਫਾਰਮ ’ਤੇ ਮਾਪਿਆ ਗਿਆ, ਜਿੱਥੇ ਅਸੀਂ ਪ੍ਰਕਾਸ਼ਿਤ ਐਪਾਂ ਚਲਾਉਂਦੇ ਹਾਂ, ਜਾਗਣ ਤੋਂ ਬਾਅਦ ਪਹਿਲੀ ਬੇਨਤੀ 12.7 ਸਕਿੰਟਾਂ ਤੋਂ 2.3 ਸਕਿੰਟ ਹੋ ਗਈ।

ਅਸੀਂ ਇਸ ਤੋਂ ਕੀ ਸਿੱਖਿਆ

• ਹਰ ਸੌਣ ਵਾਲੀ ਪਰਤ ਨੂੰ ਇਸ ਗੱਲ ’ਤੇ ਸਹਿਮਤ ਹੋਣਾ ਪੈਂਦਾ ਹੈ ਕਿ ਕੀ ਬਚਦਾ ਹੈ। ਜੰਮੀ ਐਪ ਅਤੇ ਸੌਂਦੇ ਡੇਟਾਬੇਸ ਨੇ ਹਰ ਇੱਕ ਨੇ ਵਾਜਬ ਫੈਸਲਾ ਲਿਆ। ਇਕੱਠੇ, ਐਪ ਉਸ ਹਾਲਤ ਨਾਲ ਜਾਗੀ ਜੋ ਹੁਣ ਸੱਚ ਨਹੀਂ ਸੀ।
• ਹਮੇਸ਼ਾ ਚਾਲੂ ਸਰਵਰਾਂ ਲਈ ਬਣੇ ਡਿਫਾਲਟ ਉਹਨਾਂ ਐਪਾਂ ਲਈ ਠੀਕ ਨਹੀਂ ਬੈਠਦੇ ਜੋ ਜ਼ੀਰੋ ’ਤੇ ਸਕੇਲ ਹੁੰਦੀਆਂ ਹਨ। ਕਨੈਕਸ਼ਨ ਗਰਮ ਰੱਖਣਾ ਚੰਗਾ ਵਿਚਾਰ ਹੈ, ਜਦ ਤੱਕ ਉਹਨਾਂ ਦੁਆਲੇ ਸਭ ਕੁਝ ਠੰਢਾ ਨਾ ਹੋ ਜਾਵੇ।
• ਫਰੇਮਵਰਕਾਂ ਨੂੰ ਉਹਨਾਂ ਦਾ ਡੇਟਾ ਉਹਨਾਂ ਦੇ ਆਪਣੇ ਫਾਰਮੈਟ ਵਿੱਚ ਦਿਓ। ਇੱਕ URL ਸਾਡੇ ਲਈ ਸਾਦਾ ਸੀ, ਪਰ ਹਰ Spring ਐਪ ਨੂੰ ਆਪਣਾ ਪੂਲ ਹੱਥੀਂ ਬਣਾਉਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਸੀ ਜੋ ਆਪਣੀ ਸੰਰਚਨਾ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਸੀ।
• ਟੈਸਟ ਕਰੋ ਕਿ ਸੈਟਿੰਗ ਉਸ ਤਰ੍ਹਾਂ ਲਿਖੀ ਹੈ ਜਿਵੇਂ ਫਰੇਮਵਰਕ ਪੜ੍ਹਦਾ ਹੈ। ਗਲਤ ਨਾਮ ਹੇਠ ਸਹੀ ਮੁੱਲ ਚੁੱਪ-ਚਾਪ ਕੁਝ ਨਹੀਂ ਕਰਦਾ।

ਜੇ ਤੁਸੀਂ Mythex ’ਤੇ ਡੇਟਾਬੇਸ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ ਇਸ ਲਈ ਨਵੇਂ ਹੋ, ਤਾਂ ਡੇਟਾਬੇਸ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਸਾਡੀ ਵਿਆਖਿਆ Postgres ਕੀ ਹੈ ਵੇਖੋ।