Log Message:
---
update parallel files
Modified Files:
--
src/externaltable/parallel_sql:
parallel_sql.c (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgexternaltable/src/externaltable/parallel_sql/parallel_sql.c?r1=1.1&r2=1.2)
paralle
Log Message:
---
Disallow RESET ROLE and RESET SESSION AUTHORIZATION inside security-definer
functions.
This extends the previous patch that forbade SETting these variables inside
security-definer functions. RESET is equally a security hole, since it
would allow regaining privileges of th
Log Message:
---
Disallow RESET ROLE and RESET SESSION AUTHORIZATION inside security-definer
functions.
This extends the previous patch that forbade SETting these variables inside
security-definer functions. RESET is equally a security hole, since it
would allow regaining privileges of th
Log Message:
---
Make LOAD of an already-loaded library into a no-op, instead of attempting
to unload and re-load the library.
The difficulty with unloading a library is that we haven't defined safe
protocols for doing so. In particular, there's no safe mechanism for
getting out of a "hoo
Log Message:
---
Make LOAD of an already-loaded library into a no-op, instead of attempting
to unload and re-load the library.
The difficulty with unloading a library is that we haven't defined safe
protocols for doing so. In particular, there's no safe mechanism for
getting out of a "hoo
Log Message:
---
Disallow RESET ROLE and RESET SESSION AUTHORIZATION inside security-definer
functions.
This extends the previous patch that forbade SETting these variables inside
security-definer functions. RESET is equally a security hole, since it
would allow regaining privileges of th
Log Message:
---
Make LOAD of an already-loaded library into a no-op, instead of attempting
to unload and re-load the library.
The difficulty with unloading a library is that we haven't defined safe
protocols for doing so. In particular, there's no safe mechanism for
getting out of a "hoo
Log Message:
---
Make LOAD of an already-loaded library into a no-op, instead of attempting
to unload and re-load the library.
The difficulty with unloading a library is that we haven't defined safe
protocols for doing so. In particular, there's no safe mechanism for
getting out of a "hoo
Log Message:
---
Disallow RESET ROLE and RESET SESSION AUTHORIZATION inside security-definer
functions.
This extends the previous patch that forbade SETting these variables inside
security-definer functions. RESET is equally a security hole, since it
would allow regaining privileges of th
Log Message:
---
Disallow RESET ROLE and RESET SESSION AUTHORIZATION inside security-definer
functions.
This extends the previous patch that forbade SETting these variables inside
security-definer functions. RESET is equally a security hole, since it
would allow regaining privileges of th
Log Message:
---
Disallow RESET ROLE and RESET SESSION AUTHORIZATION inside security-definer
functions.
This extends the previous patch that forbade SETting these variables inside
security-definer functions. RESET is equally a security hole, since it
would allow regaining privileges of th
Log Message:
---
Disallow RESET ROLE and RESET SESSION AUTHORIZATION inside security-definer
functions.
This extends the previous patch that forbade SETting these variables inside
security-definer functions. RESET is equally a security hole, since it
would allow regaining privileges of th
Heikki Linnakangas writes:
> A completely different approach would be to treat any failure on all
> platforms as non-fatal. We shouldn't really cut the checkpoint short if
> recycling a WAL file fails, whatever the reason. That seems like a more
> robust approach than trying to guess which error c
Tom Lane wrote:
> I wouldn't be too surprised if that rat's nest in InstallXLogFileSegment
> isn't right :-(. But we have to treat "file can't be renamed" as a
> nonfatal condition on Windows.
I added some debugging code, and I'm getting an ERROR_SHARING_VIOLATION
error when another program keeps
Heikki Linnakangas writes:
> FWIW, the checkpoint is mostly complete at that point, all that's left
> is non-critical cleanup. I admit it's still annoying.
"Mostly complete" isn't good enough, and it's much more than just an
annoyance --- failure to complete checkpoints will lead to disk full,
an
Tom Lane wrote:
> [email protected] (Heikki Linnakangas) writes:
>> Fix that by renaming the file with ".deleted" extension before deleting it.
>> Also check the return value of rename() and unlink(), so that if the removal
>> fails for any reason (e.g another process is holding the file locked
Log Message:
---
Add note that the logging collector can block backends in high load situations.
Modified Files:
--
pgsql/doc/src/sgml:
config.sgml (r1.225 -> r1.226)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml?r1=1.225&r2=1.226
[email protected] (Heikki Linnakangas) writes:
> Fix that by renaming the file with ".deleted" extension before deleting it.
> Also check the return value of rename() and unlink(), so that if the removal
> fails for any reason (e.g another process is holding the file locked), we
> don't delete
Log Message:
---
pgbench has #defines for number of branches, tellers, and accounts. There
are used to populate the tables with -i, but when running actual benchmark
it has values separately hard-coded in the query metacommands. This patch
makes the metacommands obtain their values from t
Log Message:
---
On Windows, when a file is deleted and another process still has an open
file handle on it, the file goes into "pending deletion" state where it
still shows up in directory listing, but isn't accessible otherwise. That
confuses RemoveOldXLogFiles(), making it think that the
Log Message:
---
On Windows, when a file is deleted and another process still has an open
file handle on it, the file goes into "pending deletion" state where it
still shows up in directory listing, but isn't accessible otherwise. That
confuses RemoveOldXLogFiles(), making it think that the
Log Message:
---
On Windows, when a file is deleted and another process still has an open
file handle on it, the file goes into "pending deletion" state where it
still shows up in directory listing, but isn't accessible otherwise. That
confuses RemoveOldXLogFiles(), making it think that the
Log Message:
---
On Windows, when a file is deleted and another process still has an open
file handle on it, the file goes into "pending deletion" state where it
still shows up in directory listing, but isn't accessible otherwise. That
confuses RemoveOldXLogFiles(), making it think that the
23 matches
Mail list logo
