Configuration

이 장에서는 데이터베이스 시스템의 운영에 영향을 미치는 환경 변수의 의미와 이를 설정하는 방법에 대해 설명합니다.

Configuration Settings Reference

Setting parameters

모든 매개변수 이름은 대소문자를 구분합니다. 각 매개변수 값은 Boolean(또는 문자열), 정수, 부동 소수점, 열거형(enum)의 다섯 가지 타입 중 하나입니다. 데이터 타입은 매개변수 설정 구문을 결정합니다.

  • Boolean: 값을 “on, off, true, false, yes, no, 1, 0(대소문자 구분 안 함)” 중 하나 또는 “t, f, y, n” 중 하나로 설정할 수 있습니다.

  • String: 일반적으로 양쪽 끝에 작은따옴표를 붙입니다. 값 자체에 작은따옴표가 포함되어 있으면 작은따옴표를 하나 더 추가합니다. 값이 일반적이고 단순한 숫자나 식별자인 경우 따옴표를 생략할 수 있습니다.

  • Numeric(정수 및 부동 소수점): 소수점은 부동 소수점 매개변수인 경우에만 허용됩니다. 천 단위 구분 기호(예: 1,000,000의 ‘,’)는 사용하지 마십시오. 따옴표는 필요하지 않습니다.

  • Numeric with Unit: 일부 숫자 매개변수는 메모리나 시간을 나타내는 데 사용되기 때문에 암시적인 단위를 가집니다. 단위는 킬로바이트, 블록(보통 8킬로바이트), 밀리초, 초, 분일 수 있습니다. 이러한 설정 중 단위가 없는 숫자 값은 설정의 기본 단위를 사용하며, 이는 pg_settings.unit에서 확인할 수 있습니다. 편의를 위해 설정에 단위를 명시적으로 지정할 수 있습니다. 예를 들어 시간 값이 “120 ms”인 경우 해당 매개변수의 실제 단위는 “ms”로 변환됩니다. 이 기능을 사용하려면 값을 문자열(따옴표 포함)로 작성해야 한다는 점에 유의하십시오. 단위 이름은 대소문자를 구분하며, 숫자 값과 단위 사이에 공백을 넣을 수 있습니다.

    • 유효한 메모리 단위는 kB(킬로바이트), MB(메가바이트), GB(기가바이트), TB(테라바이트)입니다. 메모리 배수는 1024(1000이 아님)입니다.

    • 유효한 시간 단위는 ms(밀리초), s(초), min(분), h(시간), d(일)입니다.

  • Enumerated: “enumerated” 타입의 매개변수는 문자열 매개변수와 동일한 방식으로 생성되지만, 단일 값 집합으로 제한됩니다. 이러한 매개변수의 허용 값은 pg_settings.enumvals에서 확인할 수 있습니다. Enum 매개변수 값은 대소문자를 구분하지 않습니다.

Parameter Interaction via the Configuration File

이러한 매개변수를 설정하는 가장 기본적인 방법은 postgresql.conf를 편집하는 것이며, 이 파일은 보통 데이터 디렉터리에 있습니다. 데이터베이스 클러스터 디렉터리가 초기화되면 기본 복사본이 설치됩니다. 이 파일과 유사한 예는 다음과 같습니다.

# This is a comment
log_connections = yes
log_destination = 'syslog'
search_path = '"$user", public'
shared_buffers = 128MB

한 줄에 하나의 매개변수를 지정합니다. 이름과 값 사이의 등호는 선택 사항입니다. 공백은 (따옴표로 묶인 매개변수를 제외하고) 중요하지 않으며 빈 줄은 무시됩니다. 해시 기호(#)는 해당 줄의 나머지 부분이 주석임을 의미합니다. 단순 식별자나 숫자가 아닌 매개변수 값은 작은따옴표를 사용해야 합니다. 매개변수 값에 작은따옴표를 포함하려면 작은따옴표를 하나 더 추가하거나 백슬래시와 따옴표를 사용해야 합니다.

이렇게 설정된 매개변수는 클러스터에서 기본적으로 제공됩니다. 재정의하지 않는 한 활성 세션에서 보이는 설정은 이 값들입니다. 다음 절에서는 관리자나 사용자가 이러한 기본값을 재정의하는 방법을 설명합니다.

메인 서버 프로세스가 SIGHUP 신호를 받을 때마다 설정 파일을 다시 읽습니다. 명령줄에서 pg_ctl reload를 실행하거나 SQL 함수 pg_reload_conf ()를 호출하면 SIGHUP이 전송됩니다. 메인 서버 프로세스는 또한 이 신호를 현재 실행 중인 모든 서버 프로세스에 전파하여 (현재 실행 중인 클라이언트 명령이 완료된 후) 기존 세션에 새 값이 적용되도록 합니다. 또는 사용자가 단일 서버 프로세스에 직접 신호를 보낼 수도 있습니다. 일부 매개변수는 서버 시작 시에만 설정할 수 있습니다. 설정 파일의 항목을 변경하더라도 서버가 다시 시작될 때까지 무시됩니다. 마찬가지로 설정 파일의 잘못된 매개변수 설정도 SIGHUP 처리 중에 무시됩니다(단, 로그에는 기록됨).

postgresql.conf 외에도 AgensGraph 데이터 디렉터리($AGDATA)에는 postgresql.conf와 동일한 형식을 가진 postgresql.auto.conf가 포함되어 있습니다. postgresql.auto.conf는 직접 편집해서는 안 됩니다. 이 파일에는 ALTER SYSTEM 명령으로 제공된 설정이 들어 있습니다. postgresql.conf가 존재할 때마다 이 파일이 자동으로 읽히고 해당 설정이 동일한 방식으로 적용됩니다. postgresql.auto.conf의 설정은 postgresql.conf의 설정보다 우선합니다.

Parameter Interaction via SQL

AgensGraph는 설정 기본값을 지정하기 위한 세 가지 SQL 명령을 제공합니다. 위에서 언급한 ALTER SYSTEM 명령은 SQL 구문을 사용하여 전역 기본값을 변경하는 방법을 제공하며, 이는 기능상 postgresql.conf를 편집하는 것과 동일합니다. 또한 각 데이터베이스나 롤별로 기본 설정을 지정할 수 있는 두 가지 명령이 있습니다.

  • ALTER DATABASE: 데이터베이스별로 전역 설정을 재정의합니다.

  • ALTER ROLE: 전역 설정과 데이터베이스별 설정을 모두 사용자 지정 값으로 재정의합니다.

ALTER DATABASE 및 ALTER ROLE을 사용하여 설정한 값은 새 데이터베이스 세션을 시작할 때만 적용됩니다. 이는 설정 파일이나 서버 명령줄에서 얻은 값을 재정의하며 나머지 세션 동안 기본값으로 적용됩니다. 일부 설정은 서버 시작 후에 변경할 수 없으므로 이 명령(또는 아래에 나열된 명령 중 하나)을 사용한 설정은 불가능합니다.

클라이언트가 데이터베이스에 연결되면 AgensGraph 세션 로컬 설정과 상호 작용할 수 있는 두 가지 추가 SQL 명령(또는 동등한 함수)을 제공합니다.

  • SHOW 명령으로 모든 매개변수의 현재 값을 확인할 수 있습니다. 해당 함수는 current_setting (setting_name text)입니다.

  • SET 명령을 사용하면 매개변수의 현재 값을 수정할 수 있으며, 이는 세션 내에서 로컬로 설정할 수 있습니다. 이는 다른 세션에 영향을 주지 않습니다. 해당 함수는 set_config (setting_name, new_value, is_local)입니다.

시스템 뷰 pg_settings도 세션 로컬 값을 확인하고 변경하는 데 사용할 수 있습니다.

  • 뷰 쿼리는 SHOW ALL과 유사하지만 더 자세한 결과를 보여줍니다. 또한 필터 조건을 지정하거나 다른 릴레이션과 조인할 수 있어 더 유연합니다.

  • 뷰에서 UPDATE를 사용하여 setting 열을 갱신하는 것은 SET 명령을 실행하는 것과 동일합니다. 예를 들면 다음과 같습니다.

SET configuration_parameter TO DEFAULT;

위 구문은 아래 구문과 동일합니다.

UPDATE pg_settings SET setting = reset_val WHERE name = 'configuration_parameter';

Managing Configuration File Contents

AgensGraph는 복잡한 postgresql.conf를 더 작은 파일로 세분화하는 기능을 제공합니다. 이 기능들의 설정 방법이 동일하지는 않지만, 특히 관련된 서버를 관리하는 데 유용합니다.

개별 매개변수를 설정하는 것 외에도 postgresql.conf에는 “include” 지시어가 있습니다. 이 지시어는 읽을 다른 파일을 지정하고 마치 해당 파일이 설정 파일에 삽입된 것처럼 처리합니다. 이 기능은 설정 파일을 물리적으로 분할합니다. 다음은 include의 간단한 예입니다.

include 'filename'

파일 이름이 절대 경로가 아니면 참조하는 설정 파일 디렉터리에 대한 상대 경로로 처리됩니다. “include”는 중첩될 수 있습니다.

“include_if_exists” 지시어도 있는데, 이는 참조 파일이 존재하지 않거나 파일을 읽을 수 없는 경우를 제외하고는 include 지시어와 동일하게 작동합니다. “include”는 이를 오류 조건으로 처리하지만, include_if_exists는 단순히 메시지를 기록하고 참조된 설정 파일을 계속 처리합니다.

postgresql.conf에는 다음과 같이 포함할 설정 파일의 경로를 지정하는 include_dir도 포함될 수 있습니다.

include_dir 'path'

절대 경로가 아니면 참조된 설정 파일 디렉터리에 대한 상대 경로로 처리됩니다. 지정된 디렉터리 내에서 디렉터리가 아닌 파일은 이름이 .conf로 끝날 때만 포함됩니다. 이러한 파일은 일부 플랫폼에서 숨겨질 수 있으므로, 실수를 방지하기 위해 .로 시작하는 파일 이름도 무시됩니다. include 디렉터리의 파일은 파일 이름 순서(C 로케일 규칙에 따라, 예를 들어 숫자-알파벳 순서 및 대문자-소문자 순서)로 처리됩니다.

단일 postgresql.conf 파일을 사용하는 대신, “include” 파일이나 디렉터리를 사용하여 데이터베이스 설정을 논리적으로 분리할 수 있습니다. 서로 다른 메모리 용량을 가진 두 개의 데이터베이스 서버를 운영하는 회사를 가정해 봅시다. 로깅의 경우 두 데이터베이스가 공유하는 설정 요소가 있을 가능성이 높습니다. 그러나 두 서버는 서로 다르게 사용자 지정된 메모리 관련 매개변수를 가질 가능성이 높습니다. 이러한 상황을 관리하는 방법은 변경된 사용자 지정 설정 내용을 세 개의 파일로 분할하는 것입니다. 사용자는 postgresql.conf 파일 끝에 다음 코드를 추가하여 각 파일을 포함할 수 있습니다.

include 'shared.conf'
include 'memory.conf'
include 'server.conf'

모든 시스템에서 shared.conf 파일은 동일합니다. 메모리 크기가 다른 각 서버는 동일한 memory.conf를 공유할 수 있습니다. 사용자는 8GB RAM 서버와 16GB RAM 서버를 모두 단일 파일로 관리할 수 있습니다. 서버별 설정 정보는 server.conf에 포함됩니다.

설정 파일 디렉터리를 만들고 이 정보를 파일에 추가할 수도 있습니다. 예를 들어 conf.d 디렉터리를 postgresql.conf의 마지막 항목으로 참조할 수 있습니다.

include_dir 'conf.d'

그런 다음 conf.d 디렉터리의 파일 이름을 다음과 같이 지정합니다.

00shared.conf
01memory.conf
02server.conf

이 명명 규칙은 파일 로딩 순서를 명확히 합니다. 서버가 설정 파일을 읽을 때 마지막 매개변수 설정만 적용됩니다. 이 예에서 conf.d/02server.conf에 설정된 값은 conf.d/01memory.conf에 설정된 값을 재정의합니다.

이 방법을 사용하여 파일에 설명적인 이름을 지정할 수 있습니다.

00shared.conf
01memory-8GB.conf
02server-foo.conf

이러한 배치 순서는 각 설정 파일 변경에 고유한 이름을 할당합니다. 이를 통해 여러 서버 설정이 단일 위치(예: 버전 관리 저장소)에 저장될 때 모호함을 줄일 수 있습니다.

File Locations

기본적으로 세 개의 설정 파일(postgresql.conf, pg_hba.conf, pg_ident.conf)은 데이터베이스 클러스터의 데이터 디렉터리에 저장되며, 다음 매개변수를 사용하여 설정 파일을 다른 위치에 배치할 수 있습니다. 설정 파일을 별도로 보관하면 설정 파일의 관리와 올바른 백업을 더 쉽게 수행할 수 있습니다.

  • data_directory (string) 데이터를 저장할 디렉터리를 지정합니다. 이 매개변수는 서버 시작 시에만 설정할 수 있습니다.

  • hba_file (string) 호스트 기반 인증을 위한 설정 파일(pg_hba.conf)을 지정합니다. 이 매개변수는 서버 시작 시에만 설정할 수 있습니다.

  • ident_file (string) 사용자 이름 매핑을 위한 설정 파일(pg_ident.conf)을 지정합니다. 이 매개변수는 서버 시작 시에만 설정할 수 있습니다.

  • external_pid_file (string) 서버 관리 프로그램에서 사용할 수 있도록 서버가 생성해야 하는 추가 프로세스 ID(PID) 파일의 이름을 지정합니다. 이 매개변수는 서버 시작 시에만 설정할 수 있습니다.

위 매개변수는 기본 설치에서 명시적으로 설정되지 않습니다. 데이터 디렉터리는 AGDATA 환경 변수로 지정되며, 모든 설정 파일은 데이터 디렉터리에서 찾을 수 있습니다.

설정 파일을 데이터 디렉터리가 아닌 다른 곳에 보관하려면, AGDATA 환경 변수에 설정 파일이 포함되어야 하고 데이터 디렉터리가 물리적으로 위치하도록 postgresql.conf에 data_directory 매개변수를 설정해야 합니다. data_directory는 (설정 파일의 위치가 아니라) 데이터 디렉터리의 위치에 대해 데이터 디렉터리를 재정의합니다.

원하는 경우 config_file, hba_file, ident_file을 사용하여 설정 파일의 이름/위치를 개별적으로 지정할 수 있으며, 기본 설정 파일(postgresql.conf) 내에서 설정할 수 있습니다. 세 개의 매개변수와 data_directory가 명시적으로 설정되어 있다면 AGDATA를 지정할 필요가 없습니다.

이러한 매개변수를 설정할 때 상대 경로는 Agens가 시작되는 디렉터리를 기준으로 해석됩니다.

Resource Consumption

Memory

  • shared_buffers (integer)

    • 데이터베이스 서버가 공유 메모리 버퍼에 사용하는 메모리 양을 설정합니다. 기본값은 일반적으로 128메가바이트(128MB)이지만, 커널 설정에서 지원되지 않으면 이 값에 도달하지 못할 수 있습니다(initdb 중에 결정됨). 이 설정은 최소 128킬로바이트 이상이어야 합니다. (기본값이 아닌 BLCKSZ 값은 최소값을 변경합니다.) 좋은 성능이 필요한 경우 최소값보다 훨씬 큰 설정이 사용됩니다.

    • 1GB 이상의 RAM을 가진 전용 데이터베이스 서버를 사용하는 경우 shared_buffers의 적절한 시작 값은 시스템 메모리의 25%입니다. 워크로드는 shared_buffers를 더 크게 설정할수록 더 효과적입니다. 그러나 AgensGraph는 운영 체제 캐시에도 의존하므로, 시스템 효율성을 위해 RAM의 40% 이상을 shared_buffers에 할당하는 것은 권장되지 않습니다. 많은 양의 신규 또는 변경된 데이터 쓰기 작업을 장시간 실행하기 위해 shared_buffers를 더 크게 설정하는 경우 checkpoint_segments의 설정도 그에 맞게 늘려야 합니다.

    • 시스템 RAM이 1GB 미만인 경우 운영 체제를 위한 적절한 공간이 필요합니다. 따라서 RAM 비율을 더 작게 만드는 것이 올바른 결정입니다. Windows에서는 shared_buffers 값을 늘리는 것이 효과적이지 않습니다. 이 설정을 더 작게 만들고 운영 체제를 위한 캐시를 상대적으로 크게 만들면 더 나은 결과를 얻을 수 있습니다. Windows 시스템에서 shared_buffers의 유용한 범위는 64MB에서 512MB입니다.

  • huge_pages (enum)

    • Huge page를 활성/비활성으로 설정합니다. 유효한 값은 try(기본값)와 on, off입니다.

    • 현재 이 기능은 Linux에서만 지원됩니다. try로 설정하면 다른 시스템에서는 무시됩니다.

    • huge page를 사용하면 더 작은 페이지 테이블을 사용하고 메모리 관리에 더 적은 CPU를 사용하므로 성능이 향상됩니다.

    • huge_pages를 try로 설정하면 서버가 huge page를 사용합니다. 그러나 실패하면 일반 할당을 사용하는 것으로 대체됩니다. on으로 설정하면 huge page 사용에 실패할 경우 서버가 시작되지 않습니다. off로 설정하면 huge page를 사용하지 않습니다.

  • temp_buffers (integer)

    • 각 데이터베이스 세션에서 사용하는 임시 버퍼의 최대 개수를 설정합니다. 임시 테이블에 접근하는 데에만 사용되는 세션 로컬 버퍼가 있습니다. 기본값은 8메가바이트(8 MB)입니다. 설정은 개별 세션 내에서 변경할 수 있지만, 세션에서 임시 테이블을 처음 사용하기 전에만 가능합니다. 이후 값을 변경하더라도 해당 세션에는 적용되지 않습니다.

    • 세션은 temp_buffers에 설정된 한도까지 임시 버퍼를 할당합니다. 실제로 임시 버퍼가 많이 필요하지 않은 세션에서 큰 값을 설정하는 데 드는 비용은 temp_buffers가 증가할 때마다 버퍼 디스크립터에 해당하는 약 64바이트에 불과합니다. 그러나 버퍼가 실제로 사용되면 추가로 8192바이트(또는 일반적으로 BLCKSZ 바이트)가 필요합니다.

  • max_prepared_transactions (integer)

    • 동시에 “ready” 상태에 있을 수 있는 트랜잭션의 최대 개수입니다.

    • prepared transaction을 사용할 계획이 없다면, prepared transaction을 생성하는 실수를 방지하기 위해 이 매개변수를 “0”으로 설정해야 합니다. prepared transaction을 사용할 때 max_prepared_transactions를 최소 max_connections로 설정하면 세션이 prepared transaction을 유지하도록 할 수 있습니다.

    • 스탠바이 서버가 실행 중인 경우 마스터 서버 값보다 크거나 같게 설정해야 합니다. 그렇지 않으면 스탠바이 서버가 쿼리를 허용하지 않습니다.

  • work_mem (integer)

    • 임시 디스크 파일을 쓰기 전에 내부 Align 명령과 해시 테이블에서 사용할 메모리 양을 지정합니다. 기본값은 4메가바이트(4MB)입니다. 복잡한 쿼리의 경우 여러 개의 Align 또는 해시 명령이 병렬로 실행될 수 있습니다. 각 명령은 데이터를 임시 파일에 쓰기 전에 이 값으로 지정된 양의 메모리를 사용할 수 있습니다. 실행 중인 세션들도 이 명령을 동시에 실행할 수 있습니다. 사용되는 총 메모리는 work_mem의 배수입니다. Align 명령은 ORDER BY, DISTINCT, 머지 조인에 사용됩니다. 해시 테이블은 해시 조인, 해시 기반 집계, IN 서브쿼리의 해시 기반 처리에 사용됩니다.

  • maintenance_work_mem (integer)

    • VACUUM, CREATE INDEX, ALTER TABLE ADD FOREIGN KEY와 같은 유지 관리 명령에서 사용하는 최대 메모리 양을 지정합니다. 기본값은 64메가바이트(64 MB)입니다. 이 명령은 데이터베이스 세션에서 한 번에 하나씩 실행될 수 있으며, 일반적인 설치에서는 여러 개의 동시 명령을 가질 수 없습니다. 이 값을 work_mem보다 훨씬 큰 값으로 설정하는 것은 안전합니다. 큰 설정은 vacuuming 및 데이터베이스 덤프 복구 성능을 향상시킬 수 있습니다.

    • autovacuum이 실행 중인 경우 이 메모리는 autovacuum_max_workers의 배수로 할당될 수 있습니다. 따라서 기본값을 너무 높게 설정하지 마십시오. autovacuum_work_mem을 별도로 설정/관리하는 것이 유용할 수 있습니다.

  • autovacuum_work_mem (integer)

    • 각 autovacuum worker 프로세스가 사용하는 최대 메모리 양을 지정합니다. 기본값은 -1이며, 이는 대신 maintenance_work_mem을 사용해야 함을 의미합니다. 이 설정은 다른 컨텍스트에서 실행될 때의 VACUUM에는 영향을 주지 않습니다.

  • max_stack_depth (integer)

    • 서버 실행 스택의 최대 안전 깊이를 지정합니다. 이상적인 설정은 커널이 강제로 지정한 안전 마진(ulimit -s로 설정되거나 로컬에 해당)보다 약간 짧게 설정하는 것입니다. 안전 마진이 필요한 이유는 서버의 모든 루틴이 아니라 잠재적 재귀 루틴(예: 표현식 평가)의 중요한 부분만 스택 깊이가 검사되기 때문입니다. 기본 설정은 충돌 가능성이 낮은 2메가바이트(2MB)로 기본적으로 작습니다. 그러나 설정이 너무 작으면 복합 함수를 실행하기 어려울 수 있습니다. 슈퍼유저만 이 설정을 변경할 수 있습니다.

    • max_stack_depth를 실제 커널 한도보다 큰 값으로 설정하면, 폭주하는 재귀 함수가 백엔드 프로세스와 충돌할 수 있습니다. AgensGraph가 커널 한도를 결정할 수 있는 플랫폼에서는 서버가 이 변수를 불안정한 값으로 설정하는 것을 허용하지 않습니다. 그러나 모든 플랫폼이 정보를 제공하는 것은 아니므로 값을 선택할 때 주의해야 합니다.

  • dynamic_shared_memory_type (enum)

    • 서버가 사용할 동적 공유 메모리 구현을 지정합니다. 가능한 값으로는 posix(shm_open을 통해 할당되는 POSIX 공유 메모리), sysv(shmget을 통해 할당되는 System V 공유 메모리), windows(Windows 공유 메모리), mmap(데이터 디렉터리에 저장된 메모리 맵을 사용하는 공유 메모리 시뮬레이션), none(기능 비활성화)이 있습니다. 이들 중 일부는 특정 플랫폼에서 지원되지 않습니다. 첫 번째로 지원되는 옵션이 해당 플랫폼의 기본 설정입니다. 일반적으로 플랫폼에서 기본값이 아닌 mmap 옵션을 사용하는 것은 권장되지 않습니다. 이는 운영 체제가 수정된 페이지를 디스크에 반복적으로 다시 쓰면서 시스템 I/O 부하가 증가하기 때문입니다. 그러나 pg_dynshmem 디렉터리를 RAM 디스크에 저장하거나 다른 공유 메모리 기능을 비활성화하는 경우 디버깅에 유용할 수 있습니다.

Write Ahead Log

Settings

  • wal_level (enum)

    • wal_level은 WAL에 기록할 정보의 양을 결정합니다. 기본값은 minimal로, 충돌이나 즉시 종료로부터 복구하는 데 필요한 정보만 기록합니다. archive는 WAL 아카이브에 필요한 로깅만 추가합니다. hot_standby는 읽기 전용 쿼리를 위해 스탠바이 서버에 더 많은 정보를 추가합니다. logical은 논리적 디코딩을 지원하는 데 필요한 정보를 추가합니다. 각 레벨은 하위 레벨에서 기록되는 정보를 포함합니다. 이 매개변수는 서버 시작 시 설정됩니다.

    • minimal 레벨에서는 대량으로 실행되는 일부 WAL 로깅을 안전하게 건너뛸 수 있습니다. 이렇게 하면 실행 속도가 빨라집니다. 이 최적화를 적용할 수 있는 실행에는 다음이 포함됩니다.

      1. CREATE TABLE AS

      2. CREATE INDEX

      3. CLUSTER

      4. 동일한 트랜잭션에서 생성되거나 truncate된 테이블로의 COPY.

      위 실행은 동일한 트랜잭션에서 생성된 테이블이나 레코드가 삭제된 테이블에 적용됩니다.

    • 그러나 minimal WAL은 베이스 백업과 WAL 로그에서 데이터를 재구성하기에 충분한 정보를 얻지 못하므로, WAL 아카이빙(archive_mode)과 스트리밍 복제를 수행하려면 archive 이상을 사용해야 합니다.

    • hot_standby 레벨에서는 archive와 동일한 정보와 실행 중인 트랜잭션의 상태를 재구성하는 데 필요한 정보가 WAL에 기록됩니다. 스탠바이 서버에서 읽기 전용 쿼리를 사용하려면 운영 서버에서 wal_level을 hot_standby 이상으로 설정하고 스탠바이 서버에서 hot_standby를 활성화하십시오. hot_standby 레벨과 archive 레벨 간에는 측정 가능한 성능 차이가 없다고 봅니다. 운영상 눈에 띄는 변화를 발견하시면 언제든지 피드백을 보내 주십시오.

    • logical 레벨에서는 hot_standby를 사용하는 것과 동일하다고 간주되는 정보와 논리적 변경 집합을 사용하는 데 필요한 정보가 WAL에 기록됩니다. logical 레벨을 사용하면 WAL 볼륨이 증가합니다. 특히 여러 테이블을 REPLICA IDENTITY FULL로 설정하고 여러 개의 UPDATE 및 DELETE 구문을 실행할 때 그렇습니다.

  • fsync (boolean)

    • 이 매개변수가 on이면 AgensGraph 서버는 fsync () 시스템 호출이나 해당 방법(wal_sync_method 참조)을 사용하여 업데이트가 디스크에 물리적으로 기록되었는지 여부를 확인하려고 시도합니다. 따라서 운영 체제나 하드웨어와의 충돌 후에 데이터베이스 클러스터를 특정 상태로 복원할 수 있습니다.

    • fsync를 끄면 성능상의 이점이 있습니다. 그러나 정전이나 시스템 장애 발생 시 데이터 손상을 복구하지 못할 수 있습니다. 따라서 외부 데이터로 전체 데이터베이스를 쉽게 재구축할 수 있는 경우에만 fsync를 끄는 것이 바람직합니다.

    • fsync를 끄는 것이 안전하다고 간주되는 경우와 초기 로딩 중에 백업 파일에서 새 데이터베이스 클러스터를 로드할 계획인 경우, 재구축할 데이터베이스에서 데이터를 일괄 처리하거나, 장애 조치에만 사용되는 읽기 전용 데이터베이스를 재구축할 수 있습니다. 고성능 하드웨어만을 위해 fsync를 끄는 것은 바람직하지 않습니다.

    • fsync를 비활성화했다가 다시 활성화하는 경우, 복구 신뢰성을 위해 커널의 변경된 모든 버퍼를 영구 저장 영역으로 강제로 옮겨야 합니다. 이는 initdb –sync-only 또는 sync를 실행하거나, 파일 시스템을 마운트 해제하거나, 서버를 재부팅하여 수행할 수 있습니다.

    • 중요하지 않은 트랜잭션에 대해 synchronous_commit을 비활성화하면, 데이터 충돌 위험 없이 fsync를 비활성화하므로 잠재적인 성능 이점을 얻을 수 있습니다.

    • fsync는 postgresql.conf 파일이나 서버 명령줄에서만 설정할 수 있습니다. 이 매개변수를 비활성화하는 경우 full_page_writes를 비활성화하는 것도 고려해야 합니다.

  • synchronous_commit (enum)

    • 명령이 클라이언트에 “success” 표시를 반환하기 전에 트랜잭션 커밋이 WAL 레코드가 디스크에 기록될 때까지 기다려야 하는지 여부를 지정합니다. 유효한 값은 on, remote_write, local, off입니다. 기본값이자 안전한 설정은 on입니다. off로 설정하면 클라이언트에 “success” 표시가 전달되는 시점과 서버 충돌 없이 트랜잭션이 진정으로 안전하다고 보장되는 시점 사이에 지연이 있을 수 있습니다. (최대 지연은 wal_writer_delay의 세 배입니다.) fsync와 달리 이 매개변수를 off로 설정해도 데이터베이스 일관성 문제가 발생하지 않습니다. 운영 체제나 데이터베이스 장애로 인해 이른바 최근에 커밋된 트랜잭션이 부분적으로 손실되는 것은 사실이지만, 데이터베이스 상태는 트랜잭션이 깔끔하게 종료된 것처럼 보입니다. 따라서 트랜잭션 내구성에 대한 확실성보다 성능이 더 중요한 경우 synchronous_commit을 비활성화하는 것이 유용한 대안이 될 수 있습니다.

    • synchronous_standby_names가 설정되어 있으면 이 매개변수는 트랜잭션의 WAL 레코드가 스탠바이 서버로 복제될 때까지 트랜잭션 커밋이 기다려야 하는지 여부도 제어합니다. on으로 설정하면 커밋은 스탠바이 서버로부터 트랜잭션 커밋 레코드를 수신하고 현재 동기 스탠바이 서버로부터 디스크에 기록되었음을 나타내는 응답을 받을 때까지 기다립니다. 이는 운영 서버와 스탠바이 서버 모두에서 데이터베이스 저장소가 손상되지 않은 경우 트랜잭션이 손실되지 않도록 보장합니다. remote_write로 설정하면 커밋은 i) 트랜잭션의 커밋 레코드가 수신되어 스탠바이 서버의 운영 체제에 기록되었지만, ii) 데이터가 스탠바이 서버의 안정적인 저장소에 도달했는지는 불확실함을 나타내는 응답을 받을 때까지 기다립니다. 데이터 보존을 위해 이 설정은 AgensGraph의 스탠바이 서버 인스턴스가 실패하더라도 충분합니다. 그러나 스탠바이 서버가 운영 체제 수준에서 실패하는 경우에는 그렇지 않습니다.

    • 동기 복제를 사용하는 경우 일반적으로 i) 로컬 디스크에 기록될 때까지 기다리거나, ii) WAL 레코드의 복제를 기다리거나, iii) 트랜잭션이 비동기적으로 커밋되도록 허용하는 것이 합리적입니다. 그러나 local 설정은 (동기 복제가 아니라) 로컬 디스크 쓰기를 기다리는 트랜잭션에 사용할 수 있습니다. synchronous_standby_names를 설정하지 않으면 on, remote_write, local 설정은 동일한 동기화 수준을 제공하며, 트랜잭션 커밋은 로컬 디스크 쓰기만을 기다립니다.

    • 이 매개변수는 언제든지 변경할 수 있습니다. 모든 트랜잭션의 동작은 실제로 커밋될 때의 설정에 따라 결정됩니다. 따라서 일부 트랜잭션 커밋은 동기로, 다른 트랜잭션 커밋은 비동기로 만드는 것이 가능하고 유용합니다. 예를 들어 기본값이 반대인 경우, 여러 구문이 있는 단일 트랜잭션 커밋을 비동기로 만들려면 트랜잭션 내에서 SET LOCAL synchronous_commit TO OFF를 실행해야 합니다.

  • wal_sync_method (enum)

    • 이 방법은 디스크에 WAL을 강제로 업데이트하는 데 사용됩니다. fsync가 off이면 WAL 파일이 강제로 업데이트되지 않으므로 이 설정은 무시됩니다. 가능한 값은 다음과 같습니다.

      1. open_datasync (open()의 O_DSYNC 옵션으로 WAL 파일 쓰기)

      2. fdatasync (각 커밋 시 fdatasync() 호출)

      3. fsync (각 커밋 시 fsync() 호출)

      4. fsync_writethrough (각 커밋 시 fsync()를 호출하여 디스크 쓰기 캐시의 write-through 강제)

      5. open_sync (open()의 O_SYNC 옵션으로 WAL 파일 쓰기)

    • open_* 옵션도 필요한 경우 O_DIRECT를 사용하십시오. 이 옵션은 일부 플랫폼에서 사용할 수 없을 수 있습니다. 위 목록에서 플랫폼이 지원하는 첫 번째 타입이 기본값입니다. 그러나 Linux에서는 fdatasync가 기본값입니다. 기본값이 반드시 이상적인 것은 아닙니다. 장애 안전 설정을 만들거나 성능을 최적화하려면 값을 변경하거나 시스템 설정의 다른 측면을 변경해야 할 수 있으며, 이는 13.1장에서 다룹니다. 이 매개변수는 postgresql.conf 파일이나 서버 명령줄에서만 설정할 수 있습니다.

  • full_page_writes (boolean)

    • 이 매개변수가 on이면 AgensGraph 서버는 체크포인트 이후 각 디스크 페이지의 첫 번째 수정 시 디스크에 있는 각 페이지의 전체 내용을 WAL에 기록합니다. 이는 운영 체제 장애가 발생할 경우 진행 중인 페이지 쓰기가 부분적으로만 완료되어 디스크의 페이지에 이전/새 데이터가 공존할 수 있기 때문에 필요합니다. 일반적으로 충돌 복구 중에 WAL에 저장된 행 수준 변경 데이터만으로는 이러한 페이지를 완전히 복구할 수 없습니다. 전체 페이지 이미지를 저장하면 페이지가 올바르게 복구되도록 보장할 수 있지만, WAL에 기록할 데이터의 크기가 확실히 증가합니다. (WAL 재생은 항상 체크포인트에서 시작되므로, 체크포인트 이후 각 페이지의 첫 번째 변경 시 이 작업을 수행하는 것으로 충분합니다.) 전체 페이지를 WAL에 쓰는 비용을 줄이는 한 가지 방법은 체크포인트 간격 매개변수를 늘리는 것입니다.

    • 이 매개변수를 끄면 일반적인 운영 속도가 향상되지만, 시스템 장애 발생 시 손상된 데이터를 복구하지 못하거나 데이터 손상이 드러나지 않을 수 있습니다. 이러한 위험은 작지만 fsync를 끌 때와 유사합니다. 즉, 이 매개변수는 환경이 fsync에서 권장되는 조건과 동일한 경우에만 비활성화할 수 있습니다.

    • 이 매개변수를 비활성화해도 시점 복구(PITR)를 위한 WAL 아카이빙 사용에는 영향을 주지 않습니다.

    • 이 매개변수는 postgresql.conf 파일이나 서버 명령줄에서만 설정할 수 있습니다. 기본값은 on입니다.

  • wal_log_hints (boolean)

    • 이 매개변수가 on이면 AgensGraph 서버는 체크포인트 이후 각 디스크 페이지의 첫 번째 수정 시 이른바 hint bit의 사소한 수정을 포함하여 페이지의 전체 내용을 WAL에 기록합니다.

    • 데이터 체크섬이 활성화되어 있으면 hint bit 업데이트는 항상 WAL에 기록되고 이 매개변수 설정은 무시됩니다. 데이터베이스에서 데이터 체크섬이 활성화된 경우, 이 매개변수 설정을 사용하여 추가 WAL 로깅이 얼마나 발생하는지 테스트할 수 있습니다.

    • 이 매개변수는 서버 시작 시 설정됩니다. 기본값은 off입니다.

  • wal_buffers (integer)

    • WAL 데이터에 사용되며 아직 디스크에 기록되지 않은 공유 메모리의 합계입니다. 기본 설정 “-1”의 크기는 shared_buffers의 1/32(약 3%)와 동일합니다(64kB 이상, WAL 세그먼트 하나 미만, 보통 16MB). 자동 설정이 너무 크거나 작으면 직접 선택할 수 있으며, 32kB 미만이면 32kB로 처리됩니다. 이 매개변수는 서버 시작 시 설정됩니다.

    • WAL 버퍼의 내용은 트랜잭션 커밋마다 디스크에 기록되므로, 지나치게 큰 값은 이점이 거의 없을 가능성이 높습니다. 그러나 이 값을 최소 몇 메가바이트로 설정하면 여러 클라이언트가 한 번에 커밋할 수 있게 하여 바쁜 서버의 쓰기 성능을 향상시킬 수 있습니다. 기본 설정인 -1로 자동 튜닝하면 대부분의 경우 합리적인 결과가 산출됩니다.

  • wal_writer_delay (integer)

    • WAL writer의 작업 사이의 지연을 결정합니다. 각 작업에서 writer는 WAL을 디스크에 씁니다. 밀리초(wal_writer_delay) 동안 sleep한 후 프로세스를 반복합니다. 기본값은 200밀리초(200ms)입니다. 많은 시스템에서 효율적인 sleep 지연 설정은 10밀리초입니다. wal_writer_delay를 10의 배수가 아닌 값으로 설정하면, 그 결과는 10의 배수로 반올림하여 설정한 값과 동일합니다. 이 매개변수는 postgresql.conf나 서버 명령줄에서만 설정할 수 있습니다.

  • commit_delay (integer)

    • commit_delay는 WAL flush를 초기화하기 전에 측정된 시간 지연을 마이크로초 단위로 추가합니다. 시스템 부하가 충분히 커서 주어진 간격 내에 추가 트랜잭션을 커밋할 준비가 된 경우, 대량의 트랜잭션을 단일 WAL flush를 통해 커밋하도록 허용함으로써 그룹 커밋 처리량을 향상시킬 수 있습니다. 그러나 이는 또한 WAL flush당 최대 commit_delay 마이크로초까지 대기 시간을 증가시킵니다. 커밋할 준비가 된 트랜잭션이 없는 경우, 지연은 시간 낭비입니다. 따라서 쓰기가 막 시작되려고 할 때, 필요한 수(최소 commit_siblings)의 트랜잭션이 수행되고 있을 때 지연이 수행됩니다. 또한 fsync가 비활성화되어 있으면 지연이 수행되지 않습니다. 기본 commit_delay는 0(지연 없음)입니다. 슈퍼유저만 이 설정을 변경할 수 있습니다.

  • commit_siblings (integer)

    • commit_delay를 수행하는 데 필요한 동시 열린 트랜잭션의 최소 개수입니다. 값이 크면 지연 간격 동안 적어도 하나의 다른 트랜잭션이 커밋할 준비가 되어 있을 가능성이 높습니다. 기본값은 5개의 트랜잭션입니다.

Query Planning

Planner Method Configuration

이 설정 매개변수들은 쿼리 옵티마이저가 선택하는 쿼리 계획에 영향을 미치는 대략적인 방법을 제공합니다. 특정 쿼리에 대해 옵티마이저가 선택한 기본 계획이 최적이 아닌 경우, 이러한 설정 매개변수 중 하나를 임시방편으로 사용하여 옵티마이저가 다른 계획을 선택하도록 강제할 수 있습니다. 옵티마이저가 선택하는 계획의 수준을 개선하는 더 나은 방법은 planner 비용 상수를 조정하고, ANALYZE를 수동으로 실행하고, default_statistics_target 설정 매개변수를 늘리고, ALTER TABLE SET STATISTICS를 사용하는 것입니다. 이렇게 하면 특정 열에 대해 수집되는 통계를 늘릴 수 있습니다.

  • enable_bitmapscan (boolean)

    • 쿼리 planner의 bitmap-scan 계획 타입 사용을 활성화 또는 비활성화합니다. 기본값은 on입니다.

  • enable_hashagg (boolean)

    • 쿼리 planner의 해시 집계 계획 타입 사용을 활성화 또는 비활성화합니다. 기본값은 on입니다.

  • enable_hashjoin (boolean)

    • 쿼리 planner의 해시 조인 계획 타입 사용을 활성화 또는 비활성화합니다. 기본값은 on입니다.

  • enable_indexscan (boolean)

    • 쿼리 planner의 index-scan 계획 타입 사용을 활성화 또는 비활성화합니다. 기본값은 on입니다.

  • enable_indexonlyscan (boolean)

    • 쿼리 planner의 index-only-scan 계획 타입 사용을 활성화 또는 비활성화합니다. 기본값은 on입니다.

  • enable_material (boolean)

    • 쿼리 planner의 materialization 사용을 활성화 또는 비활성화합니다. materialization을 완전히 억제하기는 어렵지만, 이 변수를 끄면 정확성이 필요한 경우를 제외하고는 planner가 materialize 노드를 삽입하지 못하게 됩니다. 기본값은 on입니다.

  • enable_mergejoin (boolean)

    • 쿼리 planner의 머지 조인 계획 타입 사용을 활성화 또는 비활성화합니다. 기본값은 on입니다.

  • enable_nestloop (boolean)

    • 쿼리 planner의 nested-loop 조인 계획 사용을 활성화 또는 비활성화합니다. nested-loop 조인을 완전히 억제하기는 어렵지만, 이 변수를 끄면 다른 대체 방법이 있는 경우 planner가 이를 사용하지 못하게 됩니다. 기본값은 on입니다.

  • enable_seqscan (boolean)

    • 쿼리 planner의 순차 스캔 계획 타입 사용을 활성화 또는 비활성화합니다. 순차 스캔을 완전히 억제하기는 어렵지만, 이 변수를 끄면 다른 대체 방법이 있는 경우 planner가 이를 사용하지 못하게 됩니다. 기본값은 on입니다.

  • enable_sort (boolean)

    • 쿼리 planner의 명시적 정렬 단계 사용을 활성화 또는 비활성화합니다. 명시적 정렬을 완전히 억제하기는 어렵지만, 이 변수를 끄면 다른 대체 방법이 있는 경우 planner가 이를 사용하지 못하게 됩니다. 기본값은 on입니다.

  • enable_tidscan (boolean)

    • 쿼리 planner의 TID scan 계획 타입 사용을 활성화 또는 비활성화합니다. 기본값은 on입니다.

다음은 AgensGraph에 추가된 매개변수입니다.

  • enable_eager (boolean)

    • 쿼리 planner에서 eager 계획의 사용을 활성화하거나 비활성화합니다. 기본값은 ON입니다.

  • enable_gathermerge (boolean)

    • 쿼리 planner에서 gather merge 계획의 사용을 활성화하거나 비활성화합니다. 기본값은 ON입니다.

  • enable_multiple_update (boolean)

    • 사용자는 enable_multiple_update를 활성화/비활성화하여 그래프 요소의 다중 수정을 허용/허용하지 않을 수 있습니다. 기본값은 ON입니다.

Planner Cost Constants

이 절에서 설명하는 비용 변수는 임의의 척도로 계산됩니다. 상대적인 값만이 관련되므로, 동일한 계수로 위아래로 이동하더라도 쿼리 계획은 변경되지 않습니다. 기본적으로 이러한 비용 변수는 순차 페이지를 가져오는 비용을 기준으로 합니다. seq_page_cost는 일반적으로 1.0으로 설정되므로, 다른 비용 변수는 seq_page_cost를 기준으로 설정됩니다. 원하는 경우 특정 머신에서 실제로 실행되는 밀리초 수와 같은 다른 비용을 사용할 수 있습니다.

참고: 안타깝게도 비용 변수의 이상적인 값을 결정하는 적절한 방법은 없습니다. 특정 설치 환경에서 수신되는 전체 쿼리 조합의 평균으로 처리하는 것이 가장 좋습니다. 일부 경험에 비추어 볼 때, 이 값을 변경하는 것은 매우 위험할 수 있다고 말씀드립니다.

  • seq_page_cost (floating point)

    • planner가 예상하는 순차 fetch 방법의 일부인 디스크 페이지 fetch 비용을 설정합니다. 기본값은 1.0입니다. 이 값은 동일한 이름의 테이블스페이스 매개변수를 설정하여 특정 테이블스페이스의 테이블과 인덱스를 재정의할 수 있습니다.

  • random_page_cost (floating point)

    • planner가 예상하는 비순차적으로 fetch되는 디스크 페이지의 처리 비용을 설정합니다. planner가 예상하는 순차 fetch 방법의 일부인 디스크 페이지 fetch 비용을 설정합니다. 기본값은 4.0입니다. 이 값은 동일한 이름의 테이블스페이스 매개변수를 설정하여 특정 테이블스페이스의 테이블과 인덱스를 재정의할 수 있습니다.

    • seq_page_cost에 비례하여 이 값을 줄이면 시스템이 인덱스 스캔 쪽으로 편향됩니다. 이 값을 늘리면 인덱스 스캔의 비용이 더 높아집니다. 두 값을 함께 늘리거나 줄여서 CPU 비용에 비례하여 디스크 I/O 비용의 중요성을 변경할 수 있습니다. 이 기능은 다음 매개변수에서 설명합니다.

    • 디스크 저장소에 대한 무작위 접근은 일반적으로 순차 접근보다 약 4배 더 비쌉니다. 그러나 인덱스 읽기와 마찬가지로 디스크에 대한 대부분의 무작위 접근은 캐시에서 발생하므로 작은 기본값(4.0)이 사용됩니다. 무작위 접근이 순차 접근보다 40배 느린 것처럼 보이더라도, 실제 무작위 읽기의 90%가 캐시될 것으로 예상할 수 있습니다.

    • 사용자의 워크로드에서 90% 캐시 비율이 잘못된 가정이라면, random_page_cost를 늘려 무작위 저장소 읽기의 실제 비용을 반영할 수 있습니다. 따라서 데이터베이스가 전체 서버 메모리보다 작고 데이터가 완전히 캐시되어 있다면 random_page_cost를 줄이는 것이 적절할 수 있습니다. SSD와 같이 무작위 읽기 비용이 상대적으로 낮은 저장소는 더 낮은 random_page_cost 값으로 더 잘 모델링될 수 있습니다.

    팁: 시스템에서 random_page_cost를 seq_page_cost보다 낮게 설정하는 것이 허용되지만, 실제로 그렇게 하는 것은 합리적이지 않습니다. 그러나 전체 데이터베이스가 RAM에 캐시되어 있다면 순서가 아닌 페이지를 접근하는 데 비용이 들지 않으므로 두 매개변수를 동일하게 설정할 수 있습니다. 또한 과도하게 캐시된 데이터베이스에서 이미 RAM에 있는 페이지를 가져오는 비용은 일반적인 상태의 페이지를 가져오는 비용보다 훨씬 낮으므로, 사용자는 CPU 매개변수에 비례하여 두 값을 모두 줄여야 합니다.

  • cpu_tuple_cost (floating point)

    • planner가 예상하는 쿼리 동안 각 행의 처리 비용을 설정합니다. 기본값은 0.01입니다.

  • cpu_index_tuple_cost (floating point)

    • planner가 예상하는 인덱스 스캔 동안 각 인덱스 항목의 처리 비용을 설정합니다. 기본값은 0.005입니다.

  • cpu_operator_cost (floating point)

    • planner가 예상하는 쿼리 동안 각 연산자 또는 함수의 처리 비용을 설정합니다. 기본값은 0.0025입니다.

  • effective_cache_size (integer)

    • planner가 추정할 단일 쿼리에 사용할 수 있는 디스크 캐시의 유효 크기를 설정합니다. 이 매개변수는 인덱스 사용 비용에 반영됩니다. 값이 클수록 인덱스 스캔이 사용될 가능성이 높아집니다. 값이 작을수록 순차 스캔이 사용될 가능성이 높아집니다. 이 매개변수를 설정할 때는 AgensGraph 데이터 파일이 사용하는 커널의 공유 버퍼와 디스크 캐시를 모두 고려해야 합니다. 서로 다른 테이블에 대해 예상되는 동시 쿼리 수도 고려해야 합니다. 이 매개변수는 AgensGraph가 할당하는 공유 메모리의 양에 영향을 주지 않으며, 커널 디스크 캐시를 보존하지도 않습니다. 추정 목적으로만 사용됩니다. 또한 시스템은 쿼리 간에 데이터가 디스크 캐시에 남아 있다고 가정하지 않습니다. 기본값은 4기가바이트(4GB)입니다.

Error Reporting and Logging

Where To Log

  • log_destination (string)

    • stderr, csvlog, syslog를 비롯하여 서버 메시지를 기록하는 여러 가지 방법이 있습니다. 이러한 매개변수를 쉼표로 구분하여 원하는 로그 대상 목록에 추가합니다. 기본값은 stderr에만 기록하는 것입니다. 이 매개변수는 postgresql.conf나 서버 명령줄에서만 설정할 수 있습니다.

    • log_destination에 csvlog가 포함되어 있으면 프로그램으로 더 쉽게 로드할 수 있도록 로그 항목이 “쉼표로 구분된 값(CSV)” 형식으로 출력됩니다.

  • logging_collector (boolean)

    • 이 매개변수는 logging_collector를 사용하여 stderr로 전송된 로그 메시지를 캡처하고 로그 파일로 리디렉션하는 백그라운드 프로세스입니다. 일부 유형의 메시지는 syslog 출력에 나타나지 않기 때문에, 이 방식은 syslog에 로깅하는 것보다 더 유용합니다. (일반적인 예로는 동적 링크 오류 메시지와 archive_command와 같은 스크립트에서 생성되는 오류 메시지가 있습니다.) 이 매개변수는 서버 시작 시에만 설정할 수 있습니다.

  • log_directory (string)

    • logging_collector가 활성화되어 있으면 이 매개변수는 로그 파일이 생성될 디렉터리를 결정합니다. 절대 경로로 지정하거나 클러스터 데이터 디렉터리를 기준으로 지정할 수 있습니다. 이 매개변수는 postgresql.conf나 서버 명령줄에서만 설정할 수 있습니다. 기본 설정은 pg_log입니다.

  • log_filename (string)

    • logging_collector가 활성화되어 있으면 이 매개변수는 생성되는 로그 파일의 파일 이름을 설정합니다. 이 값은 strftime 패턴으로 처리되므로 %-escapes 파일 이름을 지정하는 데 사용할 수 있습니다. (시간대에 의존하는 %-escapes가 있는 경우, log_timezone에 지정된 영역을 기준으로 작업이 수행됩니다.) 지원되는 %-escapes는 Open Group의 strfectime 사양에 나열된 것과 유사합니다. 시스템의 strfectime이 직접 사용되지 않으므로 플랫폼별(비표준) 확장은 작동하지 않습니다. 기본값은 postgresql-%Y-%m-%d_%H%M%S.log입니다. 파일 이름을 지정하는 경우 전체 디스크를 채우지 않도록 로그를 재사용하십시오.

      log_destination에서 CSV 형식 출력을 활성화하면 .csv가 타임스탬프 로그 파일 이름으로 추가되어 CSV 형식의 파일 이름이 생성됩니다(log_filename을 .log로 작성하면 .log가 생성됨).

      이 매개변수는 postgresql.conf나 서버 명령줄에서만 설정할 수 있습니다.

  • log_file_mode (integer)

    • UNIX 시스템에서 이 매개변수는 logging_collector가 활성화되어 있을 때 로그 파일의 권한을 설정합니다(이 매개변수는 Microsoft Windows에서는 무시됨). 매개변수 값은 chmod 및 umask 호출에서 승인하는 형식 모드로 지정해야 합니다(일반적인 8진수 형식을 사용하려면 숫자가 0(zero)으로 시작해야 함).

      기본 권한은 0600이며, 서버 소유자만 로그 파일을 읽거나 쓸 수 있습니다. 또 다른 일반적으로 유용한 설정은 0640으로, 사용자 그룹이 파일을 읽을 수 있게 합니다. 이러한 설정을 사용하려면 클러스터 데이터 디렉터리 외부에 파일을 저장하도록 log_directory를 변경해야 합니다. 경우에 따라 민감한 데이터가 포함될 수 있으므로 로그 파일을 누구나 읽을 수 있게 설정하는 것은 현명하지 않습니다.

      이 매개변수는 postgresql.conf나 서버 명령줄에서만 설정할 수 있습니다.

  • log_rotation_age (integer)

    • logging_collectoris가 활성화되어 있으면 이 매개변수는 개별 로그 파일의 최대 수명을 결정합니다. 최대 수명이 만료되면 새 로그 파일이 생성됩니다. 시간 기준으로 새 로그 파일을 만들지 않으려면 이 매개변수를 0으로 설정하십시오. 이 매개변수는 postgresql.conf나 서버 명령줄에서만 설정할 수 있습니다.

  • log_rotation_size (integer)

    • logging_collector가 활성화되어 있으면 이 매개변수는 개별 로그 파일의 최대 크기를 결정합니다. 지정된 크기의 KB 파일이 생성된 후 새 로그 파일이 생성됩니다. 크기 기준으로 새 로그 파일을 만들지 않으려면 이 매개변수를 0으로 설정하십시오. 이 매개변수는 postgresql.conf나 서버 명령줄에서만 설정할 수 있습니다.

  • log_truncate_on_rotation (boolean)

    • logging_collector가 활성화되어 있으면 이 매개변수는 AgensGraph가 새 로그를 추가하는 대신 동일한 이름의 기존 로그 파일을 덮어쓰게 합니다. 단, truncate는 서버 재시작이나 크기 기반 회전이 아니라 시간 기반 회전으로 새 파일이 열릴 때만 발생합니다. 매개변수가 off이면 모든 경우에 기존 파일에 내용이 추가됩니다. 예를 들어 log_filename을 postgresql-%H.log와 같이 설정하면 24시간 로그 파일을 만든 다음 주기적으로 덮어쓸 수 있습니다. 이 매개변수는 postgresql.conf나 서버 명령줄에서만 설정할 수 있습니다.

      예: 7일 로그를 유지하려면 매일 server_log.Mon, server_log.Tue 등으로 명명된 로그 파일을 만듭니다. 지난주 로그를 이번 주 로그로 자동으로 덮어쓰려면 log_filename을 server_log.%a로 설정하고, log_truncate_on_rotation을 on으로 설정하고, log_rotation_age를 1440으로 설정하십시오.

      예: 24시간 로그를 유지하려면 시간당 하나의 로그 파일이 필요합니다. 파일 크기가 1GB를 초과하면 더 빠른 순환 로깅이 가능하므로, log_filename을 server_log.%H%M으로 설정하고, log_truncate_on_rotation을 on으로 설정하고, log_rotation_age를 60으로 설정하고, log_rotation_size를 1000000으로 설정하십시오. log_filename에 %M이 포함되어 있으면 시간 지정 파일 이름과 다른 파일 이름을 선택하여 크기 기반 회전을 허용할 수 있습니다.

  • syslog_facility (enum)

    • syslog로의 로깅을 활성화하면 이 매개변수는 사용할 syslog “facility”를 결정합니다. LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7 중에서 하나를 선택할 수 있습니다. 기본값은 LOCAL0입니다. 시스템 syslog 데몬에 대한 문서를 참조하십시오. 이 매개변수는 postgresql.conf나 서버 명령줄에서만 설정할 수 있습니다.

  • syslog_ident (string)

    • syslog로의 로깅을 활성화하면 이 매개변수는 syslog 로그에서 AgensGraph 메시지를 식별하는 데 사용되는 프로그램의 이름을 결정합니다. 기본값은 PostgreSQL입니다. 이 매개변수는 postgresql.conf나 서버 명령줄에서만 설정할 수 있습니다.

  • syslog_sequence_numbers (boolean)

    • syslog에 로깅되고 매개변수가 on(기본값)이면 각 메시지에 증가하는 시퀀스 번호(예: [2])가 접두사로 붙습니다. 이 순환은 많은 syslog 구현에서 요구하는 “— last message iteration frequency—“의 억제를 의미합니다. 더 최신 syslog 구현은 반복 메시지 억제를 설정할 수 있으므로 이것이 필요하지 않을 수 있습니다(예: rsyslog의 $RepeatedMsgReduction). 반복 메시지를 정말로 차단하려는 경우 이 옵션을 비활성화할 수도 있습니다.

      이 매개변수는 postgresql.conf나 서버 명령줄에서만 설정할 수 있습니다.

  • syslog_split_messages (boolean)

    • syslog로의 로깅을 활성화하면 이 매개변수는 메시지가 syslog로 전달되는 방식을 결정합니다. on(기본값)으로 설정하면 메시지가 줄 단위로 분할됩니다. 긴 줄은 기존 syslog 구현의 일반적인 크기 한도인 1024바이트로 분할됩니다. off로 설정하면 AgensGraph 서버 로그 메시지가 syslog 서비스로 전달되고, 잠재적으로 큰 메시지를 처리하기 위해 syslog 서비스에 연결됩니다.

      syslog가 궁극적으로 텍스트 파일에 로깅되는 경우, 대부분의 syslog 구현이 큰 메시지를 처리하지 못하거나 비정상적인 방식으로 구성하므로 설정을 그대로 두는 것이 좋습니다. 그러나 syslog가 궁극적으로 다른 매체에 사용되는 경우, 메시지를 논리적으로 유지하는 것이 더 유용할 수 있습니다.

      이 매개변수는 postgresql.conf나 서버 명령줄에서만 설정할 수 있습니다.

  • event_source (string)

    • 이벤트 로그에 로깅을 활성화하면 이 매개변수는 로그에서 AgensGraph 메시지를 식별하는 데 사용되는 프로그램 이름을 결정합니다. 기본값은 PostgreSQL입니다. 이 매개변수는 postgresql.conf나 서버 명령줄에서만 설정할 수 있습니다.

Version and Platform Compatibility

Other Platforms and Clients

다음은 AgensGraph에 추가된 매개변수입니다.

  • allow_null_properties (boolean)

    • 정점과 간선에 null 속성을 삽입하도록 허용할 수 있습니다. 기본값은 OFF입니다.

  • case_sensitive_ident (boolean)

    • 대소문자를 구분하는 식별자의 사용을 설정할 수 있습니다. case_sensitive_ident가 ON이면 모든 식별자는 대소문자를 구분합니다. 기본값은 OFF입니다.

  • case_compat_type_func (boolean)

    • case_sensitive_ident가 ON일 때, 타입 및 함수 이름에 대해 대소문자를 구분하지 않는 식별자를 사용할 수 있습니다. 기본값은 OFF입니다.