On Thu, 7 Dec 2023 at 04:50, Nathan Bossart wrote:
>
> On Wed, Dec 06, 2023 at 11:30:02AM -0600, Nathan Bossart wrote:
> > On Wed, Dec 06, 2023 at 06:27:04PM +0100, Peter Eisentraut wrote:
> >> Makes sense. Can you commit that?
> >
> > Yes, I will do so shortly.
>
> Committed. Apologies for the
On Wed, Dec 06, 2023 at 11:30:02AM -0600, Nathan Bossart wrote:
> On Wed, Dec 06, 2023 at 06:27:04PM +0100, Peter Eisentraut wrote:
>> Makes sense. Can you commit that?
>
> Yes, I will do so shortly.
Committed. Apologies for the delay.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon
On Wed, Dec 06, 2023 at 06:27:04PM +0100, Peter Eisentraut wrote:
> Makes sense. Can you commit that?
Yes, I will do so shortly.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On 06.12.23 17:18, Nathan Bossart wrote:
On Wed, Dec 06, 2023 at 10:23:52AM +0100, Peter Eisentraut wrote:
Ok, I have committed your 0001 patch.
My compiler is unhappy about this one:
../postgresql/src/bin/pg_test_fsync/pg_test_fsync.c:605:2: error: ignoring
return value of ‘write’, declared
On Wed, Dec 06, 2023 at 10:28:49AM -0600, Tristan Partin wrote:
> According to my setup, I am hitting the /* Ignore */ variant of __wur. I am
> guessing that Fedora doesn't add fortification to the default CFLAGS. What
> distro are you using? But yes, something like what you proposed sounds good
>
On Wed Dec 6, 2023 at 10:18 AM CST, Nathan Bossart wrote:
On Wed, Dec 06, 2023 at 10:23:52AM +0100, Peter Eisentraut wrote:
> Ok, I have committed your 0001 patch.
My compiler is unhappy about this one:
../postgresql/src/bin/pg_test_fsync/pg_test_fsync.c:605:2: error: ignoring
return value of
On Wed, Dec 06, 2023 at 10:23:52AM +0100, Peter Eisentraut wrote:
> Ok, I have committed your 0001 patch.
My compiler is unhappy about this one:
../postgresql/src/bin/pg_test_fsync/pg_test_fsync.c:605:2: error: ignoring
return value of ‘write’, declared with attribute warn_unused_result
[-Werro
On 04.12.23 18:20, Tristan Partin wrote:
On Mon Dec 4, 2023 at 9:22 AM CST, Peter Eisentraut wrote:
On 01.12.23 23:10, Tristan Partin wrote:
> On Wed Jul 12, 2023 at 9:35 AM CDT, Tristan Partin wrote:
>> On Wed Jul 12, 2023 at 9:31 AM CDT, Peter Eisentraut wrote:
>> > On 12.07.23 16:23, Tristan
On Mon Dec 4, 2023 at 9:22 AM CST, Peter Eisentraut wrote:
On 01.12.23 23:10, Tristan Partin wrote:
> On Wed Jul 12, 2023 at 9:35 AM CDT, Tristan Partin wrote:
>> On Wed Jul 12, 2023 at 9:31 AM CDT, Peter Eisentraut wrote:
>> > On 12.07.23 16:23, Tristan Partin wrote:
>> > > It has come to my att
On 01.12.23 23:10, Tristan Partin wrote:
On Wed Jul 12, 2023 at 9:35 AM CDT, Tristan Partin wrote:
On Wed Jul 12, 2023 at 9:31 AM CDT, Peter Eisentraut wrote:
> On 12.07.23 16:23, Tristan Partin wrote:
> > It has come to my attention that STDOUT_FILENO might not be
portable and
> > fileno(3) is
On Wed Jul 12, 2023 at 9:35 AM CDT, Tristan Partin wrote:
On Wed Jul 12, 2023 at 9:31 AM CDT, Peter Eisentraut wrote:
> On 12.07.23 16:23, Tristan Partin wrote:
> > It has come to my attention that STDOUT_FILENO might not be portable and
> > fileno(3) isn't marked as signal-safe, so I have just u
On Wed Jul 12, 2023 at 9:31 AM CDT, Peter Eisentraut wrote:
> On 12.07.23 16:23, Tristan Partin wrote:
> > It has come to my attention that STDOUT_FILENO might not be portable and
> > fileno(3) isn't marked as signal-safe, so I have just used the raw 1 for
> > stdout, which as far as I know is port
On 12.07.23 16:23, Tristan Partin wrote:
It has come to my attention that STDOUT_FILENO might not be portable and
fileno(3) isn't marked as signal-safe, so I have just used the raw 1 for
stdout, which as far as I know is portable.
We do use STDOUT_FILENO elsewhere in the code, and there are eve
On Wed Jul 12, 2023 at 3:56 AM CDT, Peter Eisentraut wrote:
> On 06.07.23 22:43, Tristan Partin wrote:
> > /* Finish incomplete line on stdout */
> > - puts("");
> > - exit(1);
> > + write(STDOUT_FILENO, "", 1);
> > + _exit(1);
>
> puts() writes a newline, so it should probably be somet
On 06.07.23 22:43, Tristan Partin wrote:
/* Finish incomplete line on stdout */
- puts("");
- exit(1);
+ write(STDOUT_FILENO, "", 1);
+ _exit(1);
puts() writes a newline, so it should probably be something like
write(STDOUT_FILENO, "\n", 1);
Windows has support for some signals[0], like SIGTERM and SIGINT. SIGINT
must be handled with care on Windows since it is handled in a separate
thread. SIGTERM however can be handled in a similar way to UNIX-like
systems. I audited a few pqsignal calls that were blocked by WIN32 to
see if they coul
16 matches
Mail list logo
